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

[Kireeti Kompella <kireeti@juniper.net>]

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?