Return-Path: From: The IESG To: IETF-Announce Message-Id: Date: Fri, 12 Nov 2004 13:10:54 -0500 Cc: sipping chair , Internet Architecture Board , sipping chair , sipping mailing list , sipping chair , RFC Editor Subject: [Sipping] Document Action: 'Input 3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)' to Informational RFC The IESG has approved the following document: - 'Input 3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP) ' as an Informational RFC This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. RFC Editor Notes Change Title to "Input 3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)" Add to the Introduction The document "Input 3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)" is advisory in nature. Its primary purpose is to help the IETF understand the IMS environment and the manner in which 3GPP envisions using SIP within that environment. Given this better understanding, we expect that the IETF can more effectively evolve the SIP protocol. The IETF will not respond to the requirements given in this document on a point-for-point basis. Some requiremements have been and/or will be met by extensions to the SIP protocol. Others may be addressed by effectively using existing capabilities in SIP or other protocols, and we expect that individual members of the SIP community will work with 3GPP to achieve a better understanding of these mechanisms. Some of the requirements documented in this document may not be addressed. at all by the IETF, although we believe that the act of documenting and discussing them is in itself helpful in achieving a better all-around understanding of the task at hand. Section 4. 24 Delete following paragraph: For example, once an IPsec security association or a TLS connection is established, no additional round trips are required during session setup. However, the requirement of minimizing the number of round trips is hard to satisfy with IKE or TLS. It seems that IKE [6] adds a number of roundtrips, particularly if run together with legacy authentication extensions developed in the IPSRA WG. TLS [3] uses fewer roundtrips, but on the other hand doesn't support UDP. Replace: and/or Diffie-Helman with e.g. Diffie-Hellman 4.24.3.1 Delete and replay protection