Subject: The requirements cycle (Re: WG review: Layer 2 Virtual....)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 03 Jul 2003 03:53:50 +0200

apologies for a long delay in responding.... I am not the responsible AD 
for this WG, and have not been closely involved, so I may not have all my 
facts straight, especially for the Time Before The ID-Tracker.....

--On mandag, juni 30, 2003 11:26:12 -0400 Eric Rosen <[email-masked]> 
wrote:

>
> Harald> It might  have something  to do with  the fact  that the WG  has
> not requested that the  IESG process these drafts.... if  the WG
> has not come  to consensus on  asking for  the drafts  to be
> published, I'm afraid the IESG cannot do anything.
>
> I consider this answer to be rather disingenuous.

It was; I missed the context, which I should have been aware of.
Back to the arguments on requirements documents and dependencies...

> The WG has  not requested that the IESG process these  drafts because the
> WG chairs have  told the  WG that  the ADs have  told them  that the
> drafts in question cannot be submitted to the IESG until numerous other
> drafts that no one  will  ever  read  (requirements,  framework,
> architecture)  have  been approved by the  IESG.  Of course, most of
> those  numerous other drafts were completed about 18 months ago, though a
> few of them have now come out of the seemingly endless  "IESG reviews,
> WG makes minor  change, IESG  reviews, WG change" cycle.

to be specific - are you talking about draft-ietf-ppvpn-requirements and 
draft-ietf-ppvpn-framework? (I couldn't find a ppvpn-architecture in the 
tracker). Are there others in the set?

For -requirements, the tracker shows to be first submitted for IESG 
evaluation on June 21, 2002 (version 04), comments sent to author on July 
29, with a comment from the WG chair saying "2 months' work" on July 30, 
and the next mention in the tracker on February 17. Still issues with 
version -06; the tracker has interesting comments to read.

For -framework, the tracker shows it first submitted for IESG evaluation on 
June 21, 2002 (version 05). Version -08 was approved on May 23 this year.

I'll agree that these have been in the IESG spin cycle 12 months. But I 
won't agree that they were *completed* either 12 or 18 months ago.

And I don't understand why WG updates to fix problems take 2-3 months per 
cycle when the WG thinks that it's important to be finished with the docs.

> So you  can't honestly  answer Yakov by  saying "the  WG hasn't asked  us
> to process  these  drafts";  the  answer   to  Yakov's  question  would
> be  an explanation of (a) why all these  prior drafts are really
> necessary, (b) why it is reasonable for such a long  review cycle, and
> (c) why it is reasonable to delay  starting to process the  protocol
> specs until the  prior specs are already on the RFC Editor's queue.

(a) did any of the technologies change because of issues that were 
discovered in the discussions that were needed to clarify the requirements 
and framework?
If yes - I rest my case.
If no - why did it take any time at all to produce them?

(b) 3-6 month cycles are not reasonable.
Unfortunately, there is little that the IESG can do when the WG knows what 
the comments are and chooses not to act upon them for 2-5 months. Yelling 
more at the people responsible (WG chairs and document editors) might have 
helped. But whose job is that, really?

(c) is the IESG supposed to care about inconsistencies between the 
requirements (which are what the *WG* thinks should be satisfied) and the 
technologies that will be proposed for standardization?
if yes - how can the IESG do that when the requirements are not stable?
if no - I do not understand what "WG consensus on requirements" can mean.

I think we have unanimous agreement that the PPVPN WG's framework documents 
have taken far too long. We probably also agree that it's rare that 
blame-shifting on a public mailing list improves communication.

But I think it's too simplistic to say that "the IESG is the problem".

                 Harald

---

From: Eric Rosen <[email-masked]>
Date: Thu, 03 Jul 2003 12:52:48 -0400

Harald> did  any of  the technologies  change  because of  issues that  were
Harald> discovered  in  the discussions  that  were  needed  to clarify  the
Harald> requirements and framework? 

No. 

Harald> If no - why did it take any time at all to produce them? 

Not sure what you mean, it always  takes time to produce a document, even if
the document is just a "rock fetch". 

Harald> there is  little that  the IESG can  do when  the WG knows  what the
Harald> comments are and chooses not to act upon them for 2-5 months. 

This reminds me  of Dilbert's pointy-haired boss, who  says "your project is
late,  so I  want  you to  give me  hourly  status reports."   When we  have
documents which aren't really necessary in the first place, which ultimately
will not  have any impact on the  technology, but which need  to be massaged
and remassaged  so as to get  them past the  IESG, I think it's  quite clear
where the responsibility for the delay is coming from. 

Harald> And  I don't  understand why  WG updates  to fix  problems  take 2-3
Harald> months  per cycle  when  the WG  thinks  that it's  important to  be
Harald> finished with the docs. 

Well, each  objection from  the IESG  needs to be  discussed and  a response
crafted.  

Harald> is  the IESG  supposed  to care  about  inconsistencies between  the
Harald> requirements (which  are what the  *WG* thinks should  be satisfied)
Harald> and the technologies that will be proposed for standardization? 

Sure; but the reqs,  framework, protocol specs, and applicability statements
were all  ready 18 months ago.  They  could have been submitted  as a group.
But we were told, "first you need  to submit the first document, then a year
or so  later you can  submit the  second".  This is  a very peculiar  way to
encourage progress  ;-) From the WG  perspective, the specs  have been ready
for review  forever, but  the IESG has  refused to  look at them  because of
bogus process issues.  And then they turn around and accuse the WG of making
slow progress!

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Jul 2003 14:59:17 -0400

> Sure; but the reqs,  framework, protocol specs, and applicability
> statements were all  ready 18 months ago.  They  could have been
> submitted  as a group. But we were told, "first you need  to submit
> the first document, then a year or so  later you can  submit the 
> second".  This is  a very peculiar  way to encourage progress  ;-)

L2VPN is not progress.  It's the opposite.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 03 Jul 2003 22:32:56 +0200

high level bit of this reply:

from my perspective, the management of the PPVPN WG appears not to have 
been optimal, to say the least. But I'm not willing to blame *all* the 
delay and confusion on the IESG.

even if a WG feels abused by the IESG, or its AD, that's no excuse for a WG 
not fighting back - in this case, by rapidly removing the IESG's apparent 
excuses for delay.

Dejection is an explanation, not an excuse.

Details:

--On torsdag, juli 03, 2003 12:52:48 -0400 Eric Rosen <[email-masked]> 
wrote:

>
> Harald> did  any of  the technologies  change  because of  issues that
> were Harald> discovered  in  the discussions  that  were  needed  to
> clarify  the Harald> requirements and framework?
>
> No.
>
> Not sure what you mean, it always  takes time to produce a document, even
> if the document is just a "rock fetch".

sorry; "rock fetch" is beyond my scope of American idiom. But version -01 
of the framework document is dated July 19, 2001, and the first version 
submitted to the IESG is dated February 15, 2002. (I don't have a copy of 
-00). So the WG spent at least 7 months and 5 versions on it before 
submission. I took that as a hint that there might have been controversy in 
the working group about it.

> Harald> there is  little that  the IESG can  do when  the WG knows  what
> the Harald> comments are and chooses not to act upon them for 2-5 months.
>
> This reminds me  of Dilbert's pointy-haired boss, who  says "your project
> is late,  so I  want  you to  give me  hourly  status reports."

just as well that I did not suggest that the IESG could yell more at the WG 
to update the documents, then....

> When we
> have documents which aren't really necessary in the first place, which
> ultimately will not  have any impact on the  technology, but which need
> to be massaged and remassaged  so as to get  them past the  IESG, I think
> it's  quite clear where the responsibility for the delay is coming from.

If I accepted your evaluation as true, I'd agree with you.

> Harald> And  I don't  understand why  WG updates  to fix  problems  take
> 2-3 Harald> months  per cycle  when  the WG  thinks  that it's  important
> to  be Harald> finished with the docs.
>
> Well, each  objection from  the IESG  needs to be  discussed and  a
> response crafted.

which should take approximately 3 days of work, IMHO.
Comments that translate to "you are referencing an obsolete version of 
LDAP" should take approximately 2 minutes to fix.

> Harald> is  the IESG  supposed  to care  about  inconsistencies between
> the Harald> requirements (which  are what the  *WG* thinks should  be
> satisfied) Harald> and the technologies that will be proposed for
> standardization?
>
> submitted  as a group. But we were told, "first you need  to submit the
> first document, then a year or so  later you can  submit the  second".
> This is  a very peculiar  way to encourage progress  ;-) From the WG
> perspective, the specs  have been ready for review  forever, but  the
> IESG has  refused to  look at them  because of bogus process issues.  And
> then they turn around and accuse the WG of making slow progress!

I did not see that instruction.
On the surface, your suggestion seems a sensible one; if the WG had 
officially declared consensus on all the documents at that time, I do not 
understand why you couldn't do it that way.

Did the WG declare consensus on all those documents 18 months ago (January 
2002)? (And in the interest of being specific, I'd like you to say which 
documents you think of when you say that......)

                    Harald

---

From: Randy Bush <[email-masked]>
Date: Thu, 3 Jul 2003 14:11:06 -0700

> L2VPN is not progress.  It's the opposite.

users do want ways to bridge a layer two lan across the internet.
and this seems a legitimate desire that should be doable without
breaking anything.  of course, this will drift into areas where we
know large l2 networks have problems.  but, if properly done, that
should not affect the internet across which the lans are bridged.

otoh, those kinds of l2 issues and others should make us very
cautious when evaluating schemes to make the transforming the
internet core into an l2 circuit network.

randy

---

From: Keith Moore <[email-masked]>
Date: Thu, 3 Jul 2003 17:14:32 -0400

] > L2VPN is not progress.  It's the opposite.
] 
] users do want ways to bridge a layer two lan across the internet.

yeah, I know.  of course, there are some things users want to do that you simply 
cannot make work well.  not that we've let that stop us before...

---

From: Dave Crocker <[email-masked]>
Date: Sat, 5 Jul 2003 17:53:41 +0200

Harald,

HTA> even if a WG feels abused by the IESG, or its AD, that's no excuse for a WG
HTA> not fighting back - in this case, by rapidly removing the IESG's apparent
HTA> excuses for delay.

HTA> Dejection is an explanation, not an excuse.

This seems to reflect a view of human behavior that might work well for
machines, but not for humans.  When people in positions of authority
impose situations that are silly, wasteful, damaging, etc., those on
whom they are imposed usually view them as silly, wasteful, damaging, etc.

When people believe their actions are s/w/d/... they have a reaction
that is generally called "natural".  A typical result of this reaction
is de-motivation.

We might applaud those who can overcome this natural process, but we
should never lame those who do not.

Blame the folks doing the imposing.

Or, to state this more constructively, do not focus on the people who
become discouraged by external forces that are... discouraging.

Focus in getting those forces turned into something constructive.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Scott W Brim <[email-masked]>
Date: Sat, 5 Jul 2003 19:45:12 -0400

This is wayyy too abstract and theoretical.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Jul 2003 22:58:06 +0200

Scott,

SWB> This is wayyy too abstract and theoretical.  

Unfortunately, it was intentional.

I was sufficiently surprised that anyone would blame the working group
for failing to overcome inappropriate barriers, imposed by management
that I fell into academic mode, to try to moderate the reaction.

d/

---

From: Eric Rosen <[email-masked]>
Date: Mon, 07 Jul 2003 16:19:35 -0400

Eric> Not sure  what you mean, it  always takes time to  produce a document,
Eric> even if the document is just a "rock fetch".

Harald> sorry; "rock fetch" is beyond my scope of American idiom. 

"Rock  fetch":   when  the "boss"  sends  the  workers  out on  useless  but
time-consuming tasks.  

Harald> But version  -01 of the framework  document is dated  July 19, 2001,
Harald> and the  first version submitted to  the IESG is  dated February 15,
Harald> 2002. 

About six months to get the WG  to agree on the framework, that doesn't seem
excessive for a document.  It's a rock fetch though because there is no real
need for a framework document. 

Harald> I took that as a hint  that there might have been controversy in the
Harald> working group about it. 

It  was  never a  very  controversial  document.   My recollection  is  that
framework and requirements were ready about  January of 2002, which is why I
said that they were ready about  18 months ago.  So were the protocol specs,
applicability statements, etc.

Eric> Well,  each  objection from  the  IESG needs  to  be  discussed and  a
Eric> response crafted. 

Harald> which should take approximately 3 days of work, IMHO.  Comments that
Harald> translate  to "you  are  referencing an  obsolete  version of  LDAP"
Harald> should take approximately 2 minutes to fix. 

Comments which were  received last fall (I first saw them  a few weeks prior
to  the Atlanta  IETF  meeting)  required a  considerable  reworking of  the
document.  (Sisyphus comes to mind here ;-))

Harald> Did the  WG declare consensus on  all those documents  18 months ago
Harald> (January 2002)? 

The WG  was told by the  WG chairs that the  IESG would not allow  the WG to
even consider  the solutions documents until the  framework and requirements
documents  were approved  by the  IESG.  Something  is very  wrong  with the
process here.

The L3VPN  protocol specs  themselves haven't changed  in years, which  is a
good thing, given  the large amount of interoperable  deployment by multiple
vendors!

---

From: Alex Zinin <[email-masked]>
Date: Mon, 7 Jul 2003 16:41:30 -0700

Eric,

  Looking at this from the high-level perspective...

  Though I became the responsible AD for PPVPN just recently, I was
  exposed to certain aspects of interaction between ADs are PPVPN WG
  chairs. There was clearly a communication problem there. I believe
  it's been solved and we are in a much better shape now. Trying to
  investigate who said what and whose fault that was in the past will
  not be pretty, so I suggest we don't go there. One thing I can say
  for sure is that we (IESG) don't say things like "first you need to
  submit the first document, then a year or so later you can submit
  the second."

  Regarding requirements and framework documents being "rock fetching"
  in general:

  Again, I was not on the IESG when PPVPN was started, however, I
  think that naturally well-scoped technologies with a clear direction
  in the solution space very often do not need requirements and
  frameworks. If the problem space is reasonably big and/or there are
  multiple possible solutions that address seemingly identical
  problems, clearly documented requirements may help the IETF decide
  whether different solutions represent major approaches providing
  different coverage of the problem space (and hence satisfying
  requirements of different subsets of customers) and thus make sense
  to be progressed in parallel as independent technologies.
  Requirements may also help the SP decide which technology to deploy
  in their networks by checking how requirements important to them are
  addressed in each technology.

  A framework document seems to be a good idea when the technology is
  composed of multiple pieces that are not obviously related to each
  other and/or the relationship aspects among them are not clearly
  visible.

  It seems that the VPN problem and solution spaces are large and
  complex enough to warrant both requirements and framework documents.
  That said, these documents do not have to be long and fat, and it
  should be possible to produce an acceptable quality document within
  6 months.

  Regarding IESG feedback (where my piece was probably the biggest):
  Predicated on the assumption that reqs/fw documents are not needed,
  any feedback, whether it is from the IESG or not, will be perceived
  as a rock fetch. If we assume those are useful, IESG review is part
  of the process of ensuring high quality of these documents.

  Regards,
  
-- 
Alex
http://www.psg.com/~zinin/

Monday, July 7, 2003, 1:19:35 PM, Eric Rosen wrote:

Eric>> Not sure  what you mean, it  always takes time to  produce a document,
Eric>> even if the document is just a "rock fetch".

Harald>> sorry; "rock fetch" is beyond my scope of American idiom. 

> "Rock  fetch":   when  the "boss"  sends  the  workers  out on  useless  but

Harald>> But version  -01 of the framework  document is dated  July 19, 2001,
Harald>> and the  first version submitted to  the IESG is  dated February 15,
Harald>> 2002. 

> need for a framework document. 

Harald>> I took that as a hint  that there might have been controversy in the
Harald>> working group about it. 

> applicability statements, etc.

Eric>> Well,  each  objection from  the  IESG needs  to  be  discussed and  a
Eric>> response crafted. 

Harald>> which should take approximately 3 days of work, IMHO.  Comments that
Harald>> translate  to "you  are  referencing an  obsolete  version of  LDAP"
Harald>> should take approximately 2 minutes to fix. 

> document.  (Sisyphus comes to mind here ;-))

Harald>> Did the  WG declare consensus on  all those documents  18 months ago
Harald>> (January 2002)?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 09 Jul 2003 09:04:39 +0200

Dave,

I try to work from the theory that neither of the parties involved in this 
conflict are technically incompetent or deliberately malicious.

Assigning "blame" to one party, and appearing to declare their actions to 
have no possible rational explanation, is not compatible with this theory.

(Note that one party's actions being *wrong* when viewed in hindsight is 
*not* incompatible with the theory!)

                           Harald

--On søndag, juli 06, 2003 22:58:06 +0200 Dave Crocker 
<[email-masked]> wrote:

> _______________________________________________
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed. Decisions on
> what to pass are made solely by Raffaele D'Albenzio.
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Jul 2003 16:24:14 +0200

Harald,

HTA> I try to work from the theory that neither of the parties involved in this
HTA> conflict are technically incompetent or deliberately malicious.

Me too.

That's why talking about "intentions" or even "competence" in these
discussions is usually not very helpful.  So, it's a good thing that I
did not do that.

HTA> Assigning "blame" to one party, and appearing to declare their actions to
HTA> have no possible rational explanation, is not compatible with this theory.

I do not recall "declar[ing] their actions to have no possible rational
explanation".  What text are you referring to?

I was careful in my characterization of the problem being discussed. It
was a very specific situation, and it does occur.

Now, I do acknowledge that the word "blame" is uncomfortable, but it has
the correct denotation for its use.

We are discussing problems. Problems have causes. The word "blame" is an
efficient and precise term for referring to the source (cause) of a
problem.

However, saying something like "we should focus our attention on the source of
the difficulty, rather than suggest focusing our attention on those who
are the object of it" strikes me as awkward enough to be silly.

Please remember that I was responding to a note from you in which you
said:

In other words, you appear to be saying that a working group should be
expected to perform any action imposed on them, no matter how
unreasonable. Perhaps that is not what you meant, but it is the meaning
I take from your sentence.

And it is a position with which I disagree strongly.

That is:

       When an inappropriate requirement is imposed on a working group,
       the correct action is to remove the requirement.

       It is not appropriate to tell the working group that they have
       "no excuse.. [for not] rapidly removing the IESG's apparent
       excuses for delay."

HTA> (Note that one party's actions being *wrong* when viewed in hindsight is
HTA> *not* incompatible with the theory!)

Sometimes a problem is truly due to a "systems" difficulty, in which all
of the participants have a problem in the overall interaction.  In these
cases, it is extremely counter-productive to assign blame.

However, I described a very specific situation and I was (and am)
claiming that this is not a "system" problem but a problem in the
administration of the process.  Hence it is appropriate to focus on
those doing this kind of problematic administration.

You may well respond that their administration is not the problem. Given
the conditions that I specified, it would be extremely helpful to hear
why it is acceptable to delay competent work that conforms to its
charter and has no known technical problems.

However it is not true that everyone always performs well.  There are
errors made.

In these cases, we need to discuss the error and its cause, so we can
discuss how to fix it.

We are not going to make progress fixing the IETF's problems if people
have no permission to speak frankly.

     We are one year after Yokohama, and no changes have yet been made.

For that matter, we have little participation in the discussions.

     That should worry folks, quite a lot.

d/

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 14 Jul 2003 10:18:17 -0700

Alex,

>   not be pretty, so I suggest we don't go there. 

I suggest we *do* go there (irrespective of whether it will, or
will not be pretty), as doing this could help us to understand the
mistakes that have been made. And unless we do understand these
mistakes, we are (very) likely to repeat them.

Yakov.