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

[John Drake <jdrake@calient.net>]

Bert,

I don't recall a SG15 Liason of the form 'Btw, we're planning to change a
couple of your protocols (CR-LDP, RSVP-TE), and we hope you don't mind".  

More importantly, do you really think it's a good idea to allow other
organizations to change the IETF's protocols?  As Jerry Ash pointed out,
that's the same as having the IETF develop its own version of G.709.  I
think it would have been a much better idea for the ITU to send G.7713 to
the IETF (CCAMP) and ask them to develop protocols to support it.

Thanks,

John
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Tuesday, January 21, 2003 7:42 AM
To: Kireeti Kompella
Cc: Bob Braden; iesg@ietf.org; ietf@ietf.org
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational


Inline

> -----Original Message-----
> From: Kireeti Kompella [mailto:kireeti@juniper.net]
> Sent: maandag 20 januari 2003 22:49
> To: Wijnen, Bert (Bert)
> Cc: Bob Braden; iesg@ietf.org; ietf@ietf.org
> Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
> 
> 
> 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?
> 
> 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.
> 
It would be great if you can send a list of nits and typos to the
author and copy Scott and Myself, possibly aslo the RFC-Editor.

> I would like to know what the intent is in not granting "the right
> to produce derivative works",
Did Steve Trowbridge not answer the first question?

> and whether the IETF should progress a
> document that is a derivative of IETF protocols with this clause.
> 
I think you meant a colon after "clause" and not a priod?

> 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.

Well, the ITU document should document the details. I don't think
we just want them to copy all their documentation into RFCs, do we?

> In my discussions with people who
> go to the ITU, I didn't hear a clear consensus on the need for this.
>
Well, then they should speak up in ITU I think. The ITU-T SG15 is 
discussing this in their meeting this week, and the technology is
up for consent. Any "people who go to the ITU" (to use your words)
and who do NOT agree with it should then speak up in ITU SG15,
don't you think so?

> 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.
> 
Why would we need them to replicate their own documentation into an
IETF document?

> Secondly, there is a real paucity of detail in the description and
> use of the new messages: the Call Setup Message refers to the OIF
> UNI document for formating and doesn't say much about when and how
> it is to be used; there is no justification for the format of the
> Call ID (why is there an International Segment, etc.?  Won't IP
> addresses do?  Is this to be used for telephone calls???  My
> recollection is that Fred Baker (then IETF chair) said that using
> CCAMP for telephony was a no-no ....)
> 
I will leave it to the "ITU" folk to answer the details.
But your main point seems to be that you have not seen enough
documentation. ITU-T did a Liason Statement to us, and I believe
even specifically to CCAMP WG (that you co-chair) and so can you
tell me if you read their documentation that they have made
(freely) available to us to check? And after reading that, do
your points still hold. If so, then maybe we (CCAMP) should answer
the Liason Statement and explain to them how and where they should
add more detail and ask specific questions based on what they
document in their "drafts" (or documents) to which they point.

> Call Release can be "sent by any entity of the network".  This surely
> can't be correct.
> 
Will let ITU-folk answer that.

> The Call Capability TLV is completely undocumented beyond the format
> of the TLV.
> 
How about in the documents in OIF and ITU that they point to?

> As someone else pointed out, crankback for CR-LDP has already been
> defined.  Furthermore, this document does not say what procedures
> the sender and receiver must follow, and how crankback is to be
> effected.
>
What do you mean by "has already been defined" ??
And are the procedures not documented in the documents they point to?
 
> The "Additional Error Codes" have absolutely no detail about what
> they mean, when they are to be sent, and what the receiver should
> do with them.  They also use a slew of unidentified acronyms.
> 
They do in the documents they point to.

Bert
> Kireeti.
>