Meeting, date:

December 24, 2003

Study Group:


Working Party:



ITU-T SG15, Q.14/15


Liaison Statement To IETF Transport Area on Change Procedures for RSVP



IESG; IETF Transport Area Directors


ITU-T SG15 Q14/15 Correspondence




February 13, 2004


Hing-Kam Lam

Lucent Technologies


Tel: +1 732-949-8338

Fax: +1 732-949-1196



Q14/15 thanks IETF Transport Area Directors for the opportunity to comment on the document “Procedures for Modifying RSVP” <draft-kompella-rsvp-change-01.txt>.

Q14/15 would like to offer the following comments.

(1)   In section 1, there is the paragraph:

A standards body other than the IETF that wishes to obtain an assignment for an RSVP entity must decide from which type of name/number space they desire their assignment be made from, and then submit the appropriate documentation.

Clarification on “appropriate documentation” is needed. Is an incoming ITU-T liaison statement to IETF considered as an appropriate documentation?

(2)   What ranges would apply for RSVP entities requested by standards bodies outside of IETF?

(3)   In the past we have obtained assignment for RSVP entities and documented in informational RFC. Such procedure seems not covered in <draft-kompella-rsvp-change-01.txt>.

(4)   The draft is a specific policy for RSVP-TE development.  SDOs wanting to use RSVP-TE, especially for non-IP purposes may have their proposed extensions rejected if those reviewing it in the IETF are not familiar with the application domain.  Could the IESG please clarify what process should be used if there is disagreement with an IETF ruling?

(5)   Does the IESG see this becoming a general approach to all protocols that are/were developed at the IETF?  Would this draft be setting precedent?

(6)   Both OIF and ITU-T SG15 sent liaisons to CCAMP regarding RSVP-TE and in the absence of response, proceeded with Informational RFCs 3474 and 3476.  These enabled the completion and consent of OIF UNI 1.0 and G.7713.2 respectively.  Only recently has CCAMP liaised to SG15 regarding G.7713.2.  It seems then that the established ITU-T/IETF liaison process should be more effectively used first before adding another policy.