ietf
[Top] [All Lists]

RE: Last Call: CR-LDP Extensions for ASON to Informational

2003-01-22 14:44:38


Not liking to create unnecessary noise on large public lists (really!),
I trimmed the IETF off the following message. Bert W. has suggested that
this was inappropriate, as the issue is a general IETF issue.

Bob Braden for the RFC Editor

----- Begin Included Message -----

From braden(_at_)ISI(_dot_)EDU  Tue Jan 21 13:59:39 2003
From: Bob Braden <braden(_at_)ISI(_dot_)EDU>
Date: Tue, 21 Jan 2003 21:59:32 GMT
To: bwijnen(_at_)lucent(_dot_)com, kireeti(_at_)juniper(_dot_)net
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
Cc: braden(_at_)ISI(_dot_)EDU, iesg(_at_)ietf(_dot_)org
X-AntiVirus: scanned by AMaViS 0.2.1

  *> 
  *> Hi Bert,
  *> 
  *> On Sat, 18 Jan 2003, Wijnen, Bert (Bert) wrote:
  *> 
  *> > Yes they are from the  "IETF Consensus space".
  *> >
  *> > Now can you be more specific as to why you do not consider this doc
  *> > ready for publication?

Just for the record, although I am not technically competant to pass
detailed judgment, many of Mr. Kompella's comments fit my prejudices
about this document.

  *> 
  *> There are a large number of nits and typos -- so much so that in my
  *> opinion, this document should not have been sent to IETF Last Call
  *> without another round of edits.  However, I will ignore those and
  *> concentrate on the substance.

This saddens me.  I will go reread it.  The RFC Editor DID go one round
with the author (you should have seen the FIRST version!), and we
judged that the result was "good enough".  We are now both pleased and
embarrassed when someone from the community tells us that it was
NOT good enough!  But we do appreciate such feedback, really.  ;-)

...

  *> 
  *> The main thrust of the document is the "separation of call and
  *> connection"; there is one short paragraph that describes this, and
  *> a reference to an ITU document.  In my discussions with people who
  *> go to the ITU, I didn't hear a clear consensus on the need for this.

Our gripe was that the document did not even TRY to explain what this
distinction MEANS.

  *> An *IETF* document that describes the background, needs and how this
  *> is to be used would be very useful.  This is especially important as
  *> the very next paragraph says that separation can be achieved "where
  *> the call set up request is always accaccompanied by a connection
  *> request", which (to my naive understanding) hardly is separation.
  *> 

This is an important and sticky point... what are the IETF's rights and
duties with respect to the work of other standards bodies?  One of the
reasons the RFC Editor did not press harder was that the protocol was
essentially a fait accompli and presumably documented completely and
clearly by ITU-T.  The only purpose of the RFC was to document the IANA
registration, so fragmentary description without explanation seemed all
we could expect.  The RFC Editor rather hates to publish documents like
this, but of course there are political realities to be served, and we
understand Bert's point about duplication.

Bob Braden for the RFC Editor
 


----- End Included Message -----




<Prev in Thread] Current Thread [Next in Thread>