Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
RFC 4092

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    sip mailing list <sip@ietf.org>, 
    sip chair <sip-chairs@tools.ietf.org>
Subject: Protocol Action: 'Usage of the Session Description 
         Protocol (SDP) Alternative Network Address Types (ANAT) 
         Semantics in the Session Initiation Protocol (SIP)' to Proposed 
         Standard 

The IESG has approved the following document:

- 'Usage of the Session Description Protocol (SDP) Alternative Network 
   Address Types (ANAT) Semantics in the Session Initiation Protocol 
   (SIP) '
   <draft-ietf-sip-anat-usage-01.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working 
Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-anat-usage-01.txt

Technical Summary

   This document describes how to use the Alternative Network
   Address Types (ANAT) semantics of the SDP
   grouping framework in SIP. In particular, we define the sdp-anat SIP
   option-tag. This SIP option-tag ensures that SDP session descriptions
   using ANAT are only handled by SIP entities with ANAT support. 

   The document describes the issues if SIP entities interpret ANAT media 
   grouping without the expectation that an option-tag will identify them.

   ANAT media groupings allow a SIP entity to signal its peer that it
   has both IPv4 and IPv6 address support (within SDP's ability to
   express both families).  There is no presumption of how these
   addresses should be chosen by the two peers, but the ANAT grouping
   in SDP supports the application's use of ICE (Interactive Connectivity
   Establishment) RFC 3424-aware NAT traversal methodology.
 
Working Group Summary

  This draft was developed because draft-ietf-mmusic-anat required a
  SIP option-tag for use with SIP.  The SIP Working Group supported 
  working group adoption and advancement of the draft. 
 
Protocol Quality
 
 The specification was reviewed for the IESG by Allison Mankin.
 Some discussion was needed to require strong error handling.  

RFC Editor Note:

Expand the first appearance of ANAT in the Abstract and the
Introduction  -  Alternative Network Address Types

Security Considerations

OLD:
   The natural choice to integrity
   protect header fields in SIP is S/MIME.

NEW:
   The natural choice to integrity
   protect header fields in SIP is S/MIME. [RFC3853]

 And please add a normative reference to RFC 3853.