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.