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(_at_)lucent(_dot_)com]
Sent: Tuesday, January 21, 2003 7:42 AM
To: Kireeti Kompella
Cc: Bob Braden; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational
Inline
-----Original Message-----
From: Kireeti Kompella [mailto:kireeti(_at_)juniper(_dot_)net]
Sent: maandag 20 januari 2003 22:49
To: Wijnen, Bert (Bert)
Cc: Bob Braden; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)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.