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.
I would like to know what the intent is in not granting "the right
to produce derivative works", and whether the IETF should progress a
document that is a derivative of IETF protocols with this clause.
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.
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.
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 ....)
Call Release can be "sent by any entity of the network". This surely
can't be correct.
The Call Capability TLV is completely undocumented beyond the format
of the TLV.
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.
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.
Kireeti.