[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce