draft-ietf-avtcore-rfc5285-bis-09.txt   draft-ietf-avtcore-rfc5285-bis-10.txt 
AVTCore D. Singer AVTCore D. Singer
Internet-Draft Apple, Inc. Internet-Draft Apple, Inc.
Obsoletes: 5285 (if approved) H. Desineni Obsoletes: 5285 (if approved) H. Desineni
Intended status: Standards Track Qualcomm Intended status: Standards Track Qualcomm
Expires: October 4, 2017 R. Even, Ed. Expires: November 1, 2017 R. Even, Ed.
Huawei Technologies Huawei Technologies
April 2, 2017 April 30, 2017
A General Mechanism for RTP Header Extensions A General Mechanism for RTP Header Extensions
draft-ietf-avtcore-rfc5285-bis-09.txt draft-ietf-avtcore-rfc5285-bis-10.txt
Abstract Abstract
This document provides a general mechanism to use the header This document provides a general mechanism to use the header
extension feature of RTP (the Real-Time Transport Protocol). It extension feature of RTP (the Real-Time Transport Protocol). It
provides the option to use a small number of small extensions in each provides the option to use a small number of small extensions in each
RTP packet, where the universe of possible extensions is large and RTP packet, where the universe of possible extensions is large and
registration is de-centralized. The actual extensions in use in a registration is de-centralized. The actual extensions in use in a
session are signaled in the setup information for that session. This session are signaled in the setup information for that session. This
document obsoletes RFC5285. document obsoletes RFC5285.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 October 4, 2017. This Internet-Draft will expire on November 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Transmission Considerations . . . . . . . . . . . . . 5 4.1.1. Transmission Considerations . . . . . . . . . . . . . 5
4.1.2. Header Extension Type Considerations . . . . . . . . 6 4.1.2. Header Extension Type Considerations . . . . . . . . 6
4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7
4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 9 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 9
5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 10 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 10
6. SDP Signaling for support of mixed one byte and two bytes 6. SDP Signaling for support of mixed one byte and two bytes
header extensions. . . . . . . . . . . . . . . . . . . . . . 12 header extensions. . . . . . . . . . . . . . . . . . . . . . 12
7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 13 7. SDP Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 13
8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17
10.2. Registration of the SDP extmap Attribute . . . . . . . . 18 10.2. Registration of the SDP extmap Attribute . . . . . . . . 18
10.3. Registration of the SDP extmap-allow-mixed Attribute . . 18 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 19
11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 19 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The RTP specification [RFC3550] provides a capability to extend the The RTP specification [RFC3550] provides a capability to extend the
skipping to change at page 3, line 18 skipping to change at page 3, line 18
defining that these extension elements are named by URIs, defining an defining that these extension elements are named by URIs, defining an
IANA registry for extension elements defined in IETF specifications, IANA registry for extension elements defined in IETF specifications,
and a Session Description Protocol (SDP) method for mapping between and a Session Description Protocol (SDP) method for mapping between
the naming URIs and the identifier values carried in the RTP packets. the naming URIs and the identifier values carried in the RTP packets.
This header extension applies to RTP/AVP (the Audio/Visual Profile) This header extension applies to RTP/AVP (the Audio/Visual Profile)
and its extensions. and its extensions.
This document obsoletes [RFC5285] and removes a limitation from This document obsoletes [RFC5285] and removes a limitation from
RFC5285 that did not allow sending both one-byte and two-byte header RFC5285 that did not allow sending both one-byte and two-byte header
extensions in the same RTP stream extensions in the same RTP stream.
2. Requirements Notation 2. Requirements Notation
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. Design Goals 3. Design Goals
The goal of this design is to provide a simple mechanism whereby The goal of this design is to provide a simple mechanism whereby
skipping to change at page 4, line 43 skipping to change at page 4, line 43
the header extension is not present. The use of header extensions to the header extension is not present. The use of header extensions to
convey information that will, if missing, disrupt the behaviour of a convey information that will, if missing, disrupt the behaviour of a
higher layer application that builds on top of RTP is only acceptable higher layer application that builds on top of RTP is only acceptable
if this doesn't affect interoperability at the RTP layer. For if this doesn't affect interoperability at the RTP layer. For
example, applications that use the SDP BUNDLE extension with the MID example, applications that use the SDP BUNDLE extension with the MID
RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to
correlate RTP streams with SDP m= lines likely won't work with full correlate RTP streams with SDP m= lines likely won't work with full
functionality if the MID is missing, but the operation of the RTP functionality if the MID is missing, but the operation of the RTP
layer of those applications will be unaffected. Support for RTP layer of those applications will be unaffected. Support for RTP
header extensions based on this memo is negotiated using, for header extensions based on this memo is negotiated using, for
example, SDP offer answer [RFC3264]; intermediaries aware of the RTP example, SDP Offer/Answer [RFC3264]; intermediaries aware of the RTP
header extensions are advised to be cautious when removing or header extensions are advised to be cautious when removing or
generating RTP header extensions see section 4.7 of [RFC7667]. generating RTP header extensions see section 4.7 of [RFC7667].
The RTP header extension is formed as a sequence of extension The RTP header extension is formed as a sequence of extension
elements, with possible padding. Each extension element has a local elements, with possible padding. Each extension element has a local
identifier and a length. The local identifiers MAY be mapped to a identifier and a length. The local identifiers MAY be mapped to a
larger namespace in the negotiation (e.g., session signaling). larger namespace in the negotiation (e.g., session signaling).
4.1.1. Transmission Considerations 4.1.1. Transmission Considerations
skipping to change at page 6, line 38 skipping to change at page 6, line 38
terminate at that point, and only the extension elements present terminate at that point, and only the extension elements present
prior to the element with ID 0 and len field greater than 0 SHOULD be prior to the element with ID 0 and len field greater than 0 SHOULD be
considered. considered.
There are two variants of the extension: one-byte and two-byte There are two variants of the extension: one-byte and two-byte
headers. Since it is expected that (a) the number of extensions in headers. Since it is expected that (a) the number of extensions in
any given RTP session is small and (b) the extensions themselves are any given RTP session is small and (b) the extensions themselves are
small, the one-byte header form is preferred and MUST be supported by small, the one-byte header form is preferred and MUST be supported by
all receivers. A stream MUST contain only one-byte or two-byte all receivers. A stream MUST contain only one-byte or two-byte
headers unless it is known that all recipients support mixing, either headers unless it is known that all recipients support mixing, either
by offer/answer negotiation (see section 6) or by out-of-band by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out-
knowledge. Each RTP packet with an RTP header extension following of-band knowledge. Each RTP packet with an RTP header extension
this specification will indicate if it contains one or two byte following this specification will indicate if it contains one or two
header extensions through the use of the "defined by profile" field. byte header extensions through the use of the "defined by profile"
Extension element types that dp not match the header extension field. Extension element types that dp not match the header
format, i.e. one- or two-byte, MUST NOT be used in that RTP packet. extension format, i.e. one- or two-byte, MUST NOT be used in that RTP
Transmitters SHOULD NOT use the two-byte form when all extensions are packet. Transmitters SHOULD NOT use the two-byte form when all
small enough for the one-byte header form. Transmitters that intend extensions are small enough for the one-byte header form.
to send the two-byte form SHOULD negotiate the use of IDs above 14 if Transmitters that intend to send the two-byte form SHOULD negotiate
they want to let the Receivers know that they intend to use two-byte the use of IDs above 14 if they want to let the Receivers know that
form, for example if the RTP header extension is longer than 16 they intend to use two-byte form, for example if the RTP header
bytes. A transmitter may be aware that an intermediary may add RTP extension is longer than 16 bytes. A transmitter may be aware that
header extensions in this case, the transmitter SHOULD use two-byte an intermediary may add RTP header extensions in this case, the
form. transmitter SHOULD use two-byte form.
A sequence of extension elements, possibly with padding, forms the A sequence of extension elements, possibly with padding, forms the
header extension defined in the RTP specification. There are as many header extension defined in the RTP specification. There are as many
extension elements as fit into the length as indicated in the RTP extension elements as fit into the length as indicated in the RTP
header extension length. Since this length is signaled in full header extension length. Since this length is signaled in full
32-bit words, padding bytes are used to pad to a 32-bit boundary. 32-bit words, padding bytes are used to pad to a 32-bit boundary.
The entire extension is parsed byte-by-byte to find each extension The entire extension is parsed byte-by-byte to find each extension
element (no alignment is needed), and parsing stops at the earlier of element (no alignment is needed), and parsing stops at the earlier of
the end of the entire header extension, or in one-byte headers only the end of the entire header extension, or in one-byte headers only
case, on encountering an identifier with the reserved value of 15. case, on encountering an identifier with the reserved value of 15.
skipping to change at page 10, line 24 skipping to change at page 10, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | 0 (pad) | ID | L=4 | | data | 0 (pad) | ID | L=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data | | data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. SDP Signaling Design 5. SDP Signaling Design
The indication of the presence of this extension, and the mapping of The indication of the presence of this extension, and the mapping of
local identifiers used in the header extension to a larger namespace, local identifiers used in the header extension to a larger namespace,
MUST be performed out-of-band, for example, as part of a SIP offer/ MUST be performed out-of-band, for example, as part of an SDP Offer/
answer exchange using SDP. This section defines such signaling in Answer [RFC3264]. This section defines such signaling in SDP.
SDP.
A usable mapping MUST use IDs in the valid range, and each ID in this A usable mapping MUST use IDs in the valid range, and each ID in this
range MUST be used only once for each media (or only once if the range MUST be used only once for each media (or only once if the
mappings are session level). Mappings that do not conform to these mappings are session level). Mappings that do not conform to these
rules MAY be presented, for instance, during offer/answer negotiation rules MAY be presented, for instance, during SDP Offer/Answer
as described in the next section, but remapping to conformant values [RFC3264] negotiation as described in the next section, but remapping
is necessary before they can be applied. to conformant values is necessary before they can be applied.
Each extension is named by a URI. That URI MUST be absolute, and Each extension is named by a URI. That URI MUST be absolute, and
precisely identifies the format and meaning of the extension. URIs precisely identifies the format and meaning of the extension. URIs
that contain a domain name SHOULD also contain a month-date in the that contain a domain name SHOULD also contain a month-date in the
form mmyyyy. The definition of the element and assignment of the URI form mmyyyy. The definition of the element and assignment of the URI
MUST have been authorized by the owner of the domain name on or very MUST have been authorized by the owner of the domain name on or very
close to that date. (This avoids problems when domain names change close to that date. (This avoids problems when domain names change
ownership.) If the resource or document defines several extensions, ownership.) If the resource or document defines several extensions,
then the URI MUST identify the actual extension in use, e.g., using a then the URI MUST identify the actual extension in use, e.g., using a
fragment or query identifier (characters after a '#' or '?' in the fragment or query identifier (characters after a '#' or '?' in the
skipping to change at page 12, line 22 skipping to change at page 12, line 21
In order to allow for backward interoperability with systems that do In order to allow for backward interoperability with systems that do
not support mixing of one byte and two bytes header extensions this not support mixing of one byte and two bytes header extensions this
document defines the "a=extmap-allow-mixed" Session Description document defines the "a=extmap-allow-mixed" Session Description
Protocol (SDP) [RFC4566] attribute to indicate if the participant is Protocol (SDP) [RFC4566] attribute to indicate if the participant is
capable of supporting this new mode. The attribute takes no value. capable of supporting this new mode. The attribute takes no value.
This attribute can be used at the session or media levels. A This attribute can be used at the session or media levels. A
participant that proposes the use of this mode SHALL itself support participant that proposes the use of this mode SHALL itself support
the reception of mixed one byte and two bytes header extensions. the reception of mixed one byte and two bytes header extensions.
If offer/answer [RFC3264] is supported and used,the negotiation for If SDP Offer/Answer [RFC3264] is supported and used,the negotiation
mixed one byte and two bytes extension MUST be negotiated using for mixed one byte and two bytes extension MUST be negotiated using
offer/answer [RFC3264]. In the absence of negotiations using offer/ SDP Offer/Answer [RFC3264]. In the absence of negotiations using SDP
answer, for example when declarative SDP is used, mixed headers MUST Offer/Answer, for example when declarative SDP is used, mixed headers
NOT occur unless the transmitter has some (out of band) knowledge MUST NOT occur unless the transmitter has some (out of band)
that all potential recipients support this mode. knowledge that all potential recipients support this mode.
The formal definition of this attribute is: The formal definition of this attribute is:
Name: extmap-allow-mixed Name: extmap-allow-mixed
Value: Value:
Usage Level: session, media Usage Level: session, media
Charset Dependent: no Charset Dependent: no
skipping to change at page 13, line 5 skipping to change at page 13, line 5
When doing SDP Offer/Answer [RFC3264] an offering client that wishes When doing SDP Offer/Answer [RFC3264] an offering client that wishes
to use both one and two bytes extensions MUST include the attribute to use both one and two bytes extensions MUST include the attribute
"a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed
" is present in the offer SDP, the answerer that supports this mode " is present in the offer SDP, the answerer that supports this mode
and wishes to use it SHALL include the "a=extmap-allow-mixed " and wishes to use it SHALL include the "a=extmap-allow-mixed "
attribute in the answer. In the cases where the attribute has been attribute in the answer. In the cases where the attribute has been
excluded, both clients SHALL NOT use mixed one bytes and two bytes excluded, both clients SHALL NOT use mixed one bytes and two bytes
extensions in the same RTP stream but MAY use one-byte or two-bytes extensions in the same RTP stream but MAY use one-byte or two-bytes
form exclusively (see section 4.1.2). form exclusively (see section 4.1.2).
7. Offer/Answer 7. SDP Offer/Answer
The simple signaling described above for the extmap attribute MAY be The simple signaling described above for the extmap attribute MAY be
enhanced in an offer/answer context, to permit: enhanced in an SDP Offer/Answer [RFC3264] context, to permit:
o asymmetric behavior (extensions sent in only one direction), o asymmetric behavior (extensions sent in only one direction),
o the offer of mutually exclusive alternatives, or o the offer of mutually exclusive alternatives, or
o the offer of more extensions than can be sent in a single session. o the offer of more extensions than can be sent in a single session.
A direction attribute MAY be included in an extmap; without it, the A direction attribute MAY be included in an extmap; without it, the
direction implicitly inherits, of course, from the stream direction, direction implicitly inherits, of course, from the stream direction,
or is "sendrecv" for session-level attributes or extensions of or is "sendrecv" for session-level attributes or extensions of
skipping to change at page 17, line 5 skipping to change at page 17, line 5
used to protect RTP sessions, the RTP payload can be both encrypted used to protect RTP sessions, the RTP payload can be both encrypted
and integrity protected, while the RTP header is either unprotected and integrity protected, while the RTP header is either unprotected
or integrity protected. In order to prevent DOS attacks, for or integrity protected. In order to prevent DOS attacks, for
example, by changing the header extension integrity protection SHOULD example, by changing the header extension integrity protection SHOULD
be used. Lower layer security protection like DTLS[RFC6347] MAY be be used. Lower layer security protection like DTLS[RFC6347] MAY be
used. RTP header extensions can carry sensitive information for used. RTP header extensions can carry sensitive information for
which participants in multimedia sessions want confidentiality. which participants in multimedia sessions want confidentiality.
RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of
SRTP, to selectively encrypt RTP header extensions in SRTP. SRTP, to selectively encrypt RTP header extensions in SRTP.
The RTP application designer needs to consider their security needs,
that includes cipher strength for SRTP packets in general and what
that means for the integrity and confidentiality of the RTP header
extensions. As defined by RFC6904 [RFC6904] the encryption stream
cipher for the header extension is dependent on the chosen SRTP
cipher. It can be noted that the default SRTP ciphers (AES CM 128
bits with HMAC-SHA1) are relative weak and more modern ciphers are
stronger and should be considered.
Other security options for securing RTP are discussed in [RFC7201]. Other security options for securing RTP are discussed in [RFC7201].
10. IANA Considerations 10. IANA Considerations
This document updates the IANA consideration to reference this This document updates the IANA consideration to reference this
document and adds a new SDP attribute in section 10.3 document and adds a new SDP attribute in section 10.3
Note to IANA : change RFCxxxx to this RFC number and remove the note. Note to IANA : change RFCxxxx to this RFC number and remove the note.
10.1. Identifier Space for IANA to Manage 10.1. Identifier Space for IANA to Manage
skipping to change at page 21, line 16 skipping to change at page 21, line 16
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013, DOI 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>. <http://www.rfc-editor.org/info/rfc6904>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-36 (work in progress), October 2016. negotiation-38 (work in progress), April 2017.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>. 2003, <http://www.rfc-editor.org/info/rfc3553>.
 End of changes. 16 change blocks. 
37 lines changed or deleted 45 lines changed or added

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