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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Not sure why Kireeti and BRaden decided to drop off the
public ietf mailing list when responding to my request for
more detail. Kireeti/Bob ?? Could you pls report to ietf
list too?

Thanks,
Bert 

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: woensdag 22 januari 2003 1:04
> To: braden@ISI.EDU; bwijnen@lucent.com; kireeti@juniper.net
> Cc: iesg@ietf.org
> Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
> 
> 
> Hi Bob,
> 
> >   *> 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.
> 
> Thanks for your support!  I feel a little less like a lone 
> voice in the
> desert now.
> 
> >   *> 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.  ;-)
> 
> This is really the author's responsibility -- isn't that why the ID
> nits page was posted, and why rfc 2223 is being reved?
> 
> But anyway here's my quick set of comments:
> 
> 1. Unfamiliar acronym (ASON) in title
> 2. Incorrect expansions of CR-LDP and GMPLS
> 3. Non-compliant running headers and footers
> 4. No double space at end of sentences
> 5. A host of unexpanded acronyms in section 5
> 6. Non-printable ASCII char in section 9
> 7. Security considerations section needs work
> 8. References not split
> 9. Unfull Full Copyright Statement at end, with year "date"
> 
> > ...
> > 
> >   *> 
> >   *> 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.
> 
> Good point.
> 
> >   *> 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.
> 
> In answer to your question, the IETF seems not to have any 
> rights, even
> with its *own* protocols.  CR-LDP was first defined in the IETF.  And
> the modifications suggested in this draft are not a fait accompli --
> the ITU has yet to do their equivalent of a Last Call -- but they want
> the code points NOW!
> 
> As far as expecting (and accepting) a fragmentary description 
> -- I say,
> shame on the IESG!  All I can do as a mere IETFer is not to give my
> consent, for what that is worth.
> 
> > 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.
> 
> The RFC Editor's heart (and head) is in the right place.  I'm not sure
> what the political realities are.  What I do know is that the 
> IETF bends
> over backwards not to upset the ITU -- if an IETF document 
> even mentions
> an ITU-T standard, we have to bow three times in their direction.  But
> when the ITU-T decides to run rough-shod over our protocols, 
> we roll out
> the red carpet.
> 
> 'Nuff said -- I suppose my IETF membership has been summarily 
> canceled :-)
> 
> Kireeti.
> 
> PS: what is the status of the equivalent doc for RSVP-TE?  Did I miss
>     the Last Call on that?
>