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) '
   <draft-ietf-sipping-3gpp-r5-requirements-00.txt> 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

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce