Subject: Re: Concerns regarding ...

From: Danny McPherson <[email-masked]>
Date: Wed, 20 Dec 2000 14:08:52 -0700

> Progress is accomplished by achieving results, however imperfect
> they might be, and moving on to the next problem.  Progress is
> not attained as a result of an endless search for the perfect goal.
> 
> If you see a problem with a specification, I suggest that you write
> a separate specification to address it.  This is under the heading
> of "moving on to the next problem".  IF, in attempting to write a
> new specification, you uncover reasons why the existing one will
> not be useful to anyone, THEN it is likely that the existing one
> will be discarded in favor of a new, improved version.
> 
> I do not think the reasons stated so far are sufficient to justify
> such a course of action.  I believe there is abundant evidence that
> the existing specifications are useful to someone.

Sure they are, even as they exist today -- in draft form.

However, fundamental problems brushed off as aesthetics in 
order to more promptly publish a specification is a clear 
indication that some folks are more concerned about generating 
documents than they are about generating clean protocol 
specifications.  

Suggesting that we fix things that are broke in this draft 
later, with yet another patchwork of I-Ds, goes against the 
entire I-D process.

-danny

---

From: Eric Gray <[email-masked]>
Date: Wed, 20 Dec 2000 17:06:58 -0500

Danny,

    Please.  I submit that no one has yet convinced me, at
least, that a problem exists.  Therefore, I'm not suggesting
that "we fix things that are broken" at all.  I merely suggest
that - if someone (not me) feels that there is something they
would like to "fix" - they should "fix" it in future work.

    What goes against the I-D process is the idea of trying
to word-smith an I-D a full year after last call. And that is
exactly what I see being proposed.  I have not see any one
suggest that people will not be able to implement MPLS
because of the fact that it seems to be tied into IP.  Such a
suggestion would be ridiculous.  And I have seen at least
one person show how any "misunderstanding" of MPLS
specifications is explainable as a perspective problem.

    Many people have - over the last 2 or 3 (thousand, it
seems) years suggested that an MPLS header is a form
of short hand for an IP header.  So, while some people
feel that words should be added to the specification to
make it clear that an IPv4 L3PID applies only if the stack
depth is 1, others may think that stack depth is not only
irrelevant, but not something they want to check all of the
time (or maybe even know any of the time).  For the latter
group, the analogy that an MPLS label "stands in" for an
IP header (similar to the way that a compressed IP header
does) is more than sufficient justification for the wording
as is.

    For those people who have wanted to use MPLS to
transport something other than IPv4 packets, from the
beginning of time it seems, it might seem irrelevant that
MPLS labels "stand in" for an IP header.  But it makes
how things other than IPv4 packets are to be carried
across an IPv4 network much more intuitive if we look
at it this way.

    Finally, considering how many revisions many of the
base MPLS drafts have been through, not to mention one
or more last calls, calling for closure is not the same as
generating documents.  In reviewing the original posting
on this subject, I believe the whole discussion derives
from a misunderstanding of what it means when you say
"SHOULD" in a protocol specification.  I suggest that
we eventually reach a point where we are clarifying a
thing to death.

    Perhaps that is the goal?

--
Eric Gray

You wrote:

> ...

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 21 Dec 2000 09:10:07 +0200 (EET)

Eric Gray writes:

 > to word-smith an I-D a full year after last call. 

just set the record straigth, i brought the problems up more than a
full year ago when i believe we still were in the last call process:

  From: Juha Heinanen <[email-masked]>
  Date: Tue, 23 Nov 1999 20:45:52 +0200
  Subject: bridging over mpls
  ...
  the mpls label stack encoding i-d should be edited to explicitly allow
  mpls packets to carry anything.

-- juha

---

From: Eric Gray <[email-masked]>
Date: Thu, 21 Dec 2000 08:56:15 -0500

Juha,

    I know this.  Many people are frustrated with the amount
of control that the authors (and specifically the editors) have
in the I-D process.  However, that is the process.

    You raise issues during last call, the authors "address"
them and you have another shot at raising issues with the
way that the author addressed them.  If your raising of an
issue the second time does not get a lot of support, then -
I believe - the WG chair will conclude that the existing
resolution is supported by a rough consensus.  As it now
stands, that is the way it is done.

    If we are going to change the process, then I suspect we
will jeopardize the stability of all I-Ds in progress.  I remind
you of the occasionally recurring issue with field-ordering
and word boundaries in RSVP-TE.  There are many other
such issues.

    Once again, I plea that closure (and stability) is a better
goal than perfection.

--
Eric Gray

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 21 Dec 2000 07:55:26 -0800

Eric,

>    Once again, I plea that closure (and stability) is a better

Just to add, Proposed Standard is not the last step in the
standardization process. Documents could be improved as they
move along the standards track.

Yakov.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 21 Dec 2000 18:03:23 +0200 (EET)

eric,

i think that the chairs of the working group and also the area director
rob coltun who was in the ietf meeting when i raised my concerns agreed
that the i-d was broken.  their response, however, was that they don't
want to delay the publication of the i-d by fixing it and then issuing a
new last call.  now in retrospect it turned out that we would not have
been in any hurry.

i understood the eagerness of the wg to get the rfc published as soon as
possible. what bothered me the most that the iesg or whoever was
supposed to review the i-d didn't seem care about the quality of the
wg's output.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 21 Dec 2000 18:24:03 +0200 (EET)

i would like to make one more comment regarding the ietf process.  i
personally don't have time to read all i-ds during the time when they
are created, but i try to read all i-d that i'm interested in when i see
that a last call is issued.  

my understanding has been that a wg issues a last call when the authors
and the participants on the mailing list think that the i-d doesn't
anymore contain any problems or critical open issues and is ready for
publication.  

the last call process is then for outsiders to check the result and give
their comments.  i must have misunderstod the process if those comments
can't anymore result in anything else than minor editorial changes.

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Thu, 21 Dec 2000 12:11:17 -0500

Juha,

You may  "remember" that everyone agreed  with you, but that  sure isn't the
way I remember it!! 

Eric

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 21 Dec 2000 19:46:40 +0200 (EET)

> You may  "remember" that everyone agreed  with you, but that  sure isn't the

i don't start an argument about a year old thing, but the fact remains
that the i-d is badly broken in its wording on what is carried in
labeled packets.  if there is no time to fix the i-d then at the minimum
i would suggest a warning in the introduction saying something like
"this i-d is outdated regarding the type of packets that can be carried
in mpls frames and will be fixed in a next version".

-- juha

---

From: Ben Black <[email-masked]>
Date: Thu, 21 Dec 2000 10:29:33 -0800

On Thu, Dec 21, 2000 at 10:17:26AM -0800, Randy Bush wrote:
> > the i-d is badly broken in its wording on what is carried in labeled
> > packets.  if there is no time to fix the i-d
> 
> how much more work would fixing the document take than having this
> discussion?
> 
> randy
> 

s/more/less/

Ben

---

From: Randy Bush <[email-masked]>
Date: Thu, 21 Dec 2000 10:17:26 -0800

randy