[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: CR-LDP Extensions for ASON to Informational
*> From bwijnen@lucent.com Wed Jan 22 01:53:00 2003
*> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
*> To: Kireeti Kompella <kireeti@juniper.net>, braden@ISI.EDU, bwijnen@lucent.com
*> Cc: iesg@ietf.org
*> Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
*> Date: Wed, 22 Jan 2003 10:52:23 +0100
*> MIME-Version: 1.0
*> X-AntiVirus: scanned by AMaViS 0.2.1
*>
*> 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
I have no problmms with distributing my comments to the ietf list.
I don't remember who/when first took this off the ietf list.
Bob
*>
*> > -----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?
*> >
*>