draft-ietf-mmusic-mux-exclusive-00.txt   draft-ietf-mmusic-mux-exclusive-01.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 5761 (if approved) January 12, 2016 Intended status: Standards Track February 6, 2016
Intended status: Standards Track Expires: August 9, 2016
Expires: July 15, 2016
Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
draft-ietf-mmusic-mux-exclusive-00 draft-ietf-mmusic-mux-exclusive-01
Abstract Abstract
This document defines how an endpoint can indicate exclusive support This document defines a new SDP media-level attribute, 'rtcp-mux-
of RTP/RTCP multiplexing using the Session Description Protocol exclusive', that can be used by an endpoint to indicate exclusive
(SDP). support of RTP/RTCP multiplexing.
The document updates RFC 5761, by defining how the SDP 'rtcp'
attribute is used, together with the SDP 'rtcp-mux' attribute, to
indicate exclusive support of RTP/RTCP multiplexing.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 15, 2016. This Internet-Draft will expire on August 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SDP rtcp-mux-exclusive Attribute . . . . . . . . . . . . . . 3
4. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 3 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 3
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. RFC 5761 Section 5.1.1 Update . . . . . . . . . . . . . . 3 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 4
4.3. RFC 5761 Section 5.1.3 Update . . . . . . . . . . . . . . 4 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 4
4.4. Issues And TBDs . . . . . . . . . . . . . . . . . . . . . 5 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 4
4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 5
5. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
[RFC5761] defines how to multiplex RTP and RTCP on a single port, [RFC5761] defines how to multiplex RTP and RTCP on a single address
referred to as RTP/RTCP multiplexing. [RFC5761] also defines an and port, referred to as RTP/RTCP multiplexing. [RFC5761] also
Session Description Protocol (SDP) [RFC4566] attribute, 'rtcp-mux' defines an Session Description Protocol (SDP) [RFC4566] attribute,
that can be used by entities to indicate support of RTP/RTCP 'rtcp-mux' that can be used by entities to indicate support, and
multiplexing. negotiate usage of, RTP/RTCP multiplexing.
As defined in [RFC5761], if the peer endpoint does not support RTP/ As defined in [RFC5761], if the peer endpoint does not support RTP/
RTCP multiplexing, there must be a fallback to usage of separate RTCP multiplexing, there must be a fallback to usage of separate
ports for RTP and RTCP. However, the RTCWEB WG have defined that ports for RTP and RTCP.
support of the fallback is optional. Therefore, there needs to be a
mechanism for an endpoint to be able to indicate exclusive support of
RTP/RTCP multiplexing, i.e. to be able to indicate that the endpoint
only supports RTP/RTCP multiplexing and is not able to fallback to
usage of separate ports for receiving RTP and RTCP.
This document describes a mechanism, how the SDP 'rtcp-mux' attribute The RTCWEB WG has defined that support of the fallback mentioned
[RFC5761] and the SDP 'rtcp' attribute [RFC3605] can be used to above is optional. Therefore, there is a need for a mechanism that
indicate exclusive support of RTP/RTCP multiplexing. The document allows an endpoint to indicate exclusive support of RTP/RTCP
updates sections 5.1.1 and 5.1.3 of [RFC5761] in order to enable multiplexing, meaning that endpoint only supports RTP/RTCP
usage of the mechanism. multiplexing and is not able to fallback to usage of separate ports
for RTP and RTCP.
This document defines a new SDP media-level attribute, 'rtcp-mux-
exclusive', that can be used to indicate exclusive support of RTP/
RTCP multiplexing.
The document also describes the Interactive Connectivity The document also describes the Interactive Connectivity
Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations when Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations when
indicating exclusive support of RTP/RTCP multiplexing. indicating exclusive support of RTP/RTCP multiplexing.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Mechanism 3. SDP rtcp-mux-exclusive Attribute
As as described in [RFC5761], when an offerer sends an offer, and This section defines a new SDP media-level attribute, 'rtcp-mux-
wants to indicate support of RTP/RTCP multiplexing, it must associate exclusive'.
an SDP 'rtcp-mux' attribute with each RTP-based SDP media description
("m=" line) for which support of multiplexing is indicated. In
addition, the offerer may assign an SDP 'rtcp' attribute, in order to
provide a fallback port for RTCP in case the answerer does not
support (or is not willing to use) RTP/RTCP multiplexing.
When an offerer sends an offer, and wants to indicate exclusive Name: rtcp-mux-exclusive
support of RTP/RTCP multiplexing it MUST, in addition to the SDP
'rtcp-attribute, associate an SDP 'rtcp' attribute with each SDP
media description for which exclusive support of RTP/RTCP
multiplexing is indicated. The offerer MUST assign a port value
identical to the port value of the associated SDP media description
to the 'rtcp' attribute. The offerer MAY assign the optional IP
address part to the 'rtcp' attribute. If assigned, the IP address
part value MUST be identical to the value of the associated
connection address ("c=" line).
4. Update to RFC 5761 Value:
Usage Level: media
Charset Dependent: no
Example:
a=rtcp-mux-exclusive
In an SDP offer, the offerer uses the SDP 'rtcp-mux-exclusive'
attribute to indicate exclusive support of RTP/RTCP multiplexing for
the RTP-based media associated with the SDP media description ("m="
line).
In an SDP answer, the 'rtcp-mux-exclusive' attribute indicates that
the answerer supports, and accepts usage of, RTP/RTCP multiplexing
for the RTP-based media associated with the SDP media description
("m=" line).
The usage of the SDP 'rtcp-mux-exclusive' attribute is only defined
for RTP-based media.
The SDP offer/answer [RFC3264] procedures associated with the
attribute are defined in Section 4
4. SDP Offer/Answer Procedures
4.1. General 4.1. General
This section updates sections 5.1.1 and 5.1.3 of [RFC5761], by adding This section defines the SDP offer/answer [RFC3264] procedures for
a new paragraph in section 5.1.1 after the second paragraph, and by indicating exclusive support of, and negotiating usage of, RTP/RTCP
modifying the second paragraph in section 5.1.3. multiplexing.
4.2. RFC 5761 Section 5.1.1 Update The procedures in this section apply to individual RTP-based SDP
NEW PARAGRAPH: media descriptions ("m=" lines).
If the offerer is not able to use different ports 4.2. Generating the Initial SDP Offer
for RTP and RTCP, the SDP offer MUST also include the "a=rtcp"
attribute [10] with an attribute value identical to the associated
port value for RTP. For example:
v=0 When an offerer sends the initial offer, if the offerer wants to
o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e indicate exclusive RTP/RTCP multiplexing for RTP-based media, the
s=- offerer MUST associate an SDP 'rtcp-mux-exclusive' attribute with the
c=IN IP6 2001:DB8::211:24ff:fea3:7a2e associated SDP media description ("m=" line).
t=1153134164 1153137764
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=rtcp-mux
a=rtcp: 49170
4.3. RFC 5761 Section 5.1.3 Update In addition, if the offerer associates an SDP 'rtcp-mux-exclusive'
OLD TEXT: attribute with an SDP media description ("m=" line), the offerer MUST
also associate an SDP 'rtcp-mux' attribute with the same SDP media
description ("m=" line), following the procedures in [RFC5761].
If it is desired to use both ICE and multiplexed RTP and RTCP, the If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that SDP media description ("m=" line), and if the offerer also associates
RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" an SDP 'rtcp-mux-exclusive' attribute with the same SDP media
lines for both RTP and RTCP along with an "a=rtcp:" line indicating a description ("m=" line), the address and port values of the SDP
fallback port for RTCP in the case that the answerer does not support 'rtcp' attribute MUST match the corresponding values for RTP.
RTP and RTCP multiplexing. This MUST be done for each media where
RTP and RTCP multiplexing is desired.
NEW TEXT: NOTE: This specification does not mandate the usage of the SDP 'rtcp'
attribute for RTP/RTCP multiplexing.
If it is desired to use both ICE and multiplexed RTP and RTCP, the 4.3. Generating the Answer
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
RTP and RTCP multiplexing is desired. If the offerer supports
a fallback port for RTCP in the case that the answerer does not
support RTP and RTCP multiplexing, the initial offer MUST contain
"a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:"
line indicating a fallback port for RTCP. If the offerer is not
able to use separate ports for RTP and RTCP the offer MUST NOT
contain "a=candidate:" lines for RTCP, and the "a=rtcp:" line
MUST indicate the RTP port. If the "a=rtcp:" line indicates the
RTP port, and if the "a=rtcp:" line also contains the optional
IP address part, the IP address part value MUST be identical to
the value of the associated "c=" line. The This MUST be done for
each media where RTP and RTCP multiplexing is desired.
4.4. Issues And TBDs When an answerer receives an offer that contains an SDP 'rtcp-mux-
exclusive' attribute, associated with an RTP-based SDP media
description ("m=" line), if the answerer accepts the usage of RTP/
RTCP multiplexing, the answerer MUST associate an SDP 'rtcp-mux-
exclusive' attribute with the corresponding SDP media description
("m=") in the associated answer. If the answerer does not accept the
usage of RTP/RTCP multiplexing, the answerer MUST either reject the
SDP media description ("m=") by setting the port value to zero in the
associated answer, or reject the whole offer, following the
procedures in [RFC3264].
ISSUE #1: We may want to specify an explicit procedure for the In addition, if the answerer associates an SDP 'rtcp-mux-exclusive'
answerer too, saying that it must select mux if it receives rtcp-mux attribute with an SDP media description ("m=" line) in the answer,
and rtcp with the RTP port value. the answerer MUST also associate an SDP 'rtcp-mux' attribute with the
same SDP media description ("m=" line), following the procedures in
[RFC5761].
ISSUE #2: We may want to specify something about the case when the 4.4. Offerer Processing of the SDP Answer
answerer only supports mux, and receives an offer without mux.
If an offerer associated an SDP 'rtcp-mux-exclusive' attribute with
an RTP-based SDP media description ("m=" line) in an offer, and if
the corresponding SDP media description ("m=" line) in the associated
answer contains an SDP 'rtcp-mux-exclusive' attribute, and/or an SDP
'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP
multiplexing procedures [RFC5761] to the associated RTP-based media.
If the corresponding SDP media description ("m=" line) in the
associated answer does not contain an SDP 'rtcp-mux-exclusive'
attribute, nor an SDP 'rtcp-mux' attribute, the offerer MUST either
take appropriate actions in order to disable the associated RTP-based
media, or send a new offer without associating an SDP 'rtcp-mux-
exclusive' attribute with the SDP media description ("m=" line).
NOTE: This document does not mandate specific actions on how to
terminate the RTP media. The offerer might e.g. send a new offer,
where the port value of the SDP media description is set to zero, in
order to terminate the RTP media.
4.5. Modifying the Session
When an offerer sends a subsequent offer, if the offerer and answerer
have previously negotiated usage of RTP/RTCP multiplexing for the
media associated with an RTP-based SDP media description ("m=" line)
using the SDP 'rtcp-mux-exclusive' attribute, the offerer SHOULD
associate an SDP 'rtcp-mux-exclusive' attribute and an SDP 'rtcp-mux'
attribute with the corresponding SDP media description ("m=" line).
If the offerer does not associate the attributes with the
corresponding SDP media description ("m=" line) it is an indication
that the offerer no longer wants to use RTP/RTCP multiplexing, and
instead MUST fallback to usage of separate ports for RTP and RTCP
once the offer has been accepted by the answerer.
When an offerer sends a subsequent offer, if the offerer and answerer
have not previously negotiated usage of RTP/RTCP multiplexing for the
media associated with an RTP-based SDP media description ("m=" line),
the offerer MAY indicate exclusive support of RTP/RTCP multiplexing,
following the procedures in Section 4.2. The offerer MUST process
the associated answer following the procedures in Section 4.4.
NOTE: It is RECOMMENDED to not switch between usage of RTP/RTCP
multiplexing and usage of separate ports for RTP and RTCP in a
subsequent offer, unless there is a use-case that mandates it.
5. ICE Considerations 5. ICE Considerations
As defined in [I-D.ietf-ice-rfc5245bis], if an entity is aware that As defined in [I-D.ietf-ice-rfc5245bis], if an entity is aware that
the remote peer supports, and is willing to use, RTP/RTCP the remote peer supports, and is willing to use, RTP/RTCP
multiplexing, the entity will only provide RTP candidates (component multiplexing, the entity will only provide RTP candidates (component
ID 1). However, only providing RTP candidates does not as such imply ID 1). However, only providing RTP candidates does not as such imply
exclusive support of RTP/RTCP multiplexing. RTCP candidates would exclusive support of RTP/RTCP multiplexing. RTCP candidates would
not be provided also in cases where RTCP is not supported at all. not be provided also in cases where RTCP is not supported at all.
Therefore, additional information is needed in order to indicate Therefore, additional information is needed in order to indicate
support of exclusive RTP/RTCP multiplexing. This document defines support of exclusive RTP/RTCP multiplexing. This document defines
such mechanism using the SDP 'rtcp-mux' and 'rtcp' attributes. such mechanism using the SDP 'rtcp-mux-exclusive' attributes.
6. Security Considerations 6. Security Considerations
This document does not introduce new security considerations in This document does not introduce new security considerations in
additions to those specified in [RFC3605] and [RFC5761]. additions to those specified in [RFC3605] and [RFC5761].
7. IANA Considerations 7. IANA Considerations
This document makes no requests from IANA. This document updates the "Session Description Protocol Parameters"
registry as specified in Section 8.2.2 of [RFC4566]. Specifically,
it adds the SDP 'rtcp-mux-exclusive' attribute to the table for SDP
media level attributes.
Attribute name: rtcp-mux-exclusive
Type of attribute: media-level
Subject to charset: no
Purpose: Indicate exclusive support of RTP/RTCP multiplexing
Appropriate Values: N/A
Contact name: Christer Holmberg
8. Acknowledgments 8. Acknowledgments
Thanks to Roman Shpount, Paul Kyzivat, Ari Keraenen, Bo Burman and Thanks to Roman Shpount, Paul Kyzivat, Ari Keraenen, Bo Burman and
Tomas Frankkila for their comments and input on the draft. Tomas Frankkila for their comments and input on the draft.
9. Change Log 9. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-holmberg-mmusic-mux-exclusive-03 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00
o Submitted as draft-ietf-mmusic-mux-exclusive-00. o Defined new SDP attribute for indicating rtcp-mux-exclusive.
Changes from draft-holmberg-mmusic-mux-exclusive-02 o Additional text added to session modification section.
o Updates to RFC 5761 removed.
o IANA considerations added.
Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03
o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00.
Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02
o Intended status changed to "Standards track". o Intended status changed to "Standards track".
Changes from draft-holmberg-mmusic-mux-exclusive-01 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01
o Clarified that the SDP rtcp attribute may contain the optional IP o Clarified that the SDP rtcp attribute may contain the optional IP
address part. address part.
Changes from draft-holmberg-mmusic-mux-exclusive-00 Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00
o Additional updates to Section 5.1.1 of RFC 5761. o Additional updates to Section 5.1.1 of RFC 5761.
o ICE considerations added. o ICE considerations added.
10. Normative References 10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>. <http://www.rfc-editor.org/info/rfc5761>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-00 Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-00
(work in progress), October 2015. (work in progress), October 2015.
10.2. Informative References
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 36 change blocks. 
115 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/