draft-ietf-avt-rtp-retransmission-10.txt   draft-ietf-avt-rtp-retransmission-11.txt 
Internet Draft Internet Draft
draft-ietf-avt-rtp-retransmission- J. Rey/Matsushita draft-ietf-avt-rtp-retransmission- J. Rey/Panasonic
10.txt D. Leon/Nokia 11.txt D. Leon/Nokia
A. Miyazaki/Matsushita A. Miyazaki/Panasonic
V. Varsa/Nokia V. Varsa/Nokia
R. Hakenberg/Matsushita R. Hakenberg/Panasonic
Expires: July 2004 January 2004 Expires: September 7, 2005 March 7, 2005
RTP Retransmission Payload Format RTP Retransmission Payload Format
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance By submitting this Internet-Draft, each author represents that any
with all provisions of Section 10 of RFC 2026.
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
[Note to RFC Editor: This paragraph is to be deleted when this [Note to RFC Editor: This paragraph is to be deleted when this
draft is published as an RFC. References in this draft to RFC draft is published as an RFC. References in this draft to RFC
XXXX should be replaced with the RFC number assigned to this XXXX should be replaced with the RFC number assigned to this
document.] document.]
Abstract Abstract
RTP retransmission is an effective packet loss recovery technique RTP retransmission is an effective packet loss recovery technique
for real-time applications with relaxed delay bounds. This for real-time applications with relaxed delay bounds. This
skipping to change at page 2, line 22 skipping to change at page 2, line 25
2. Terminology...................................................3 2. Terminology...................................................3
3. Requirements and design rationale for a retransmission scheme.4 3. Requirements and design rationale for a retransmission scheme.4
4. Retransmission payload format.................................6 4. Retransmission payload format.................................6
5. Asocciation of a retransmission stream to its original stream.8 5. Asocciation of a retransmission stream to its original stream.8
6. Use with the extended RTP profile for RTCP-based feedback....10 6. Use with the extended RTP profile for RTCP-based feedback....10
7. Congestion control...........................................12 7. Congestion control...........................................12
8. Retransmission Payload Format MIME type registration.........13 8. Retransmission Payload Format MIME type registration.........13
9. RTSP considerations..........................................19 9. RTSP considerations..........................................19
10. Implementation examples.....................................21 10. Implementation examples.....................................21
11. IANA considerations.........................................23 11. IANA considerations.........................................23
12. Security considerations.....................................24 12. Security considerations.....................................23
13. Acknowledgements............................................24 13. Acknowledgements............................................24
14. References..................................................25 14. References..................................................24
15. Author's Addresses..........................................25 15. Author's Addresses..........................................25
IPR Notices.....................................................26 IPR Notices.....................................................26
Full Copyright Statement........................................27 Full Copyright Statement........................................26
1. Introduction 1. Introduction
Packet losses between an RTP sender and receiver may significantly Packet losses between an RTP sender and receiver may significantly
degrade the quality of the received media. Several techniques, degrade the quality of the received media. Several techniques,
such as forward error correction (FEC), retransmissions or such as forward error correction (FEC), retransmissions or
interleaving may be considered to increase packet loss resiliency. interleaving may be considered to increase packet loss resiliency.
RFC 2354 [8] discusses the different options. RFC 2354 [8] discusses the different options.
When choosing a repair technique for a particular application, the When choosing a repair technique for a particular application, the
skipping to change at page 3, line 14 skipping to change at page 3, line 14
In the case of multimedia streaming, the user can tolerate an In the case of multimedia streaming, the user can tolerate an
initial latency as part of the session set-up and thus an end-to- initial latency as part of the session set-up and thus an end-to-
end delay of several seconds may be acceptable. RTP end delay of several seconds may be acceptable. RTP
retransmission as defined in this document is targeted at such retransmission as defined in this document is targeted at such
applications. applications.
At this point, the attention of the reader is called to the fact At this point, the attention of the reader is called to the fact
that the retransmission mechanism for RTP described in this that the retransmission mechanism for RTP described in this
document may be encumbered by patent applications filed from document may be encumbered by patent applications filed from
Matsushita. Please refer to the IPR Notices section for details. Panasonic. Please refer to the IPR Notices section for details.
Furthermore, the RTP retransmission method defined herein is Furthermore, the RTP retransmission method defined herein is
applicable to unicast and (small) multicast groups. The present applicable to unicast and (small) multicast groups. The present
document defines a payload format for retransmitted RTP packets document defines a payload format for retransmitted RTP packets
and provides protocol rules for the sender and the receiver and provides protocol rules for the sender and the receiver
involved in retransmissions. involved in retransmissions.
This retransmission payload format was designed for use with the This retransmission payload format was designed for use with the
extended RTP profile for RTCP-based feedback, AVPF [1]. It may extended RTP profile for RTCP-based feedback, AVPF [1]. It may
also be used with other RTP profiles defined in the future. also be used with other RTP profiles defined in the future.
The AVPF profile allows for more frequent feedback and for early The AVPF profile allows for more frequent feedback and for early
feedback. It defines a small number of general-purpose feedback feedback. It defines a general-purpose feedback message, i.e.
messages, e.g. ACKs and NACKs, as well as codec and application- NACK, as well as codec and application-specific feedback messages.
specific feedback messages. See [1] for details. See [1] for details.
2. Terminology 2. Terminology
The following terms are used in this document: The following terms are used in this document:
Original packet: refers to an RTP packet which carries user data Original packet: refers to an RTP packet which carries user data
sent for the first time by an RTP sender. sent for the first time by an RTP sender.
Original stream: refers to the RTP stream of original packets. Original stream: refers to the RTP stream of original packets.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
preservation requirement (requirement 6). This in turn implies preservation requirement (requirement 6). This in turn implies
that requirement 4 would not be met. Interoperability with mixers that requirement 4 would not be met. Interoperability with mixers
and translators would also be more difficult if they did not and translators would also be more difficult if they did not
understand this new retransmission payload type in a sender RTP understand this new retransmission payload type in a sender RTP
stream. For these reasons, a solution based on payload type stream. For these reasons, a solution based on payload type
multiplexing of original packets and retransmission packets in the multiplexing of original packets and retransmission packets in the
same RTP stream is excluded. same RTP stream is excluded.
Finally, the original and retransmission packets may be sent in Finally, the original and retransmission packets may be sent in
two separate streams. These two streams may be multiplexed either two separate streams. These two streams may be multiplexed either
by sending them in two different sessions , i.e. session- by sending them in two different sessions , i.e., session-
multiplexing, or in the same session using different SSRC values, multiplexing, or in the same session using different SSRC values,
i.e. SSRC-multiplexing. Since original and retransmission packets i.e. SSRC-multiplexing. Since original and retransmission packets
carry media of the same type, the objections in Section 5.2 of RTP carry media of the same type, the objections in Section 5.2 of RTP
[3] to RTP multiplexing do not apply in this case. [3] to RTP multiplexing do not apply in this case.
Mixers and translators may process the original stream and simply Mixers and translators may process the original stream and simply
discard the retransmission stream if they are unable to utilise discard the retransmission stream if they are unable to utilise
it. it.
On the other hand, sending the original and retransmission packets On the other hand, sending the original and retransmission packets
skipping to change at page 14, line 49 skipping to change at page 14, line 49
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de rey@panasonic.de
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller:
IETF AVT WG IETF AVT WG
8.3 Registration of video/rtx 8.3 Registration of video/rtx
MIME type: video MIME type: video
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
skipping to change at page 15, line 46 skipping to change at page 15, line 48
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de rey@panasonic.de
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller:
IETF AVT WG IETF AVT WG
8.4 Registration of text/rtx 8.4 Registration of text/rtx
MIME type: text MIME type: text
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
skipping to change at page 16, line 38 skipping to change at page 16, line 46
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de rey@panasonic.de
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller:
IETF AVT WG IETF AVT WG
8.5 Registration of application/rtx 8.5 Registration of application/rtx
MIME type: application MIME type: application
MIME subtype: rtx MIME subtype: rtx
Required parameters: Required parameters:
rate: the RTP timestamp clockrate is equal to the RTP rate: the RTP timestamp clockrate is equal to the RTP
timestamp clockrate of the media that is retransmitted. timestamp clockrate of the media that is retransmitted.
apt: associated payload type. The value of this parameter is apt: associated payload type. The value of this parameter is
the payload type of the associated original stream. the payload type of the associated original stream.
skipping to change at page 17, line 32 skipping to change at page 17, line 41
Additional information: none Additional information: none
Person & email address to contact for further information: Person & email address to contact for further information:
rey@panasonic.de rey@panasonic.de
david.leon@nokia.com david.leon@nokia.com
avt@ietf.org avt@ietf.org
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Authors:
Jose Rey Jose Rey
David Leon David Leon
Change controller:
IETF AVT WG IETF AVT WG
8.6 Mapping to SDP 8.6 Mapping to SDP
The information carried in the MIME media type specification has a The information carried in the MIME media type specification has a
specific mapping to fields in SDP [5], which is commonly used to specific mapping to fields in SDP [5], which is commonly used to
describe RTP sessions. When SDP is used to specify describe RTP sessions. When SDP is used to specify
retransmissions for an RTP stream, the mapping is done as retransmissions for an RTP stream, the mapping is done as
follows: follows:
skipping to change at page 21, line 32 skipping to change at page 21, line 44
This section gives an overview of different implementation options This section gives an overview of different implementation options
allowed within this specification. allowed within this specification.
The first example describes a minimal receiver implementation. The first example describes a minimal receiver implementation.
With this implementation, it is possible to retransmit lost RTP With this implementation, it is possible to retransmit lost RTP
packets, detect efficiently the loss of retransmissions and packets, detect efficiently the loss of retransmissions and
perform multiple retransmissions, if needed. Most of the perform multiple retransmissions, if needed. Most of the
necessary processing is done at the server. necessary processing is done at the server.
The second example shows how a receiver may implement additional The second example shows how retransmissions may be used in
enhancements that might help reduce sender buffer requirements and (small) multicast groups in conjunction with layered encoding. It
optimise the retransmission efficiency
The third example shows how retransmissions may be used in (small)
multicast groups in conjunction with layered encoding. It
illustrates that retransmissions and layered encoding may be illustrates that retransmissions and layered encoding may be
complementary techniques. complementary techniques.
10.1 A minimal receiver implementation example 10.1 A minimal receiver implementation example
This section gives an example of an implementation supporting This section gives an example of an implementation supporting
multiple retransmissions. The sender transmits the original data multiple retransmissions. The sender transmits the original data
in RTP packets using the MPEG-4 video RTP payload format. in RTP packets using the MPEG-4 video RTP payload format.
It is assumed that NACK feedback messages are used, as per It is assumed that NACK feedback messages are used, as per
[1]. An SDP description example with SSRC-multiplexing is given [1]. An SDP description example with SSRC-multiplexing is given
skipping to change at page 22, line 30 skipping to change at page 22, line 37
times the retransmission of a packet can be requested. times the retransmission of a packet can be requested.
The sender should retransmit the packets selectively, i.e. it The sender should retransmit the packets selectively, i.e. it
should choose whether to retransmit a requested packet depending should choose whether to retransmit a requested packet depending
on the packet importance, the observed QoS and congestion state of on the packet importance, the observed QoS and congestion state of
the network connection to the receiver. Obviously, the sender the network connection to the receiver. Obviously, the sender
processing increases with the number of receivers as state processing increases with the number of receivers as state
information and processing load must be allocated to each information and processing load must be allocated to each
receiver. receiver.
10.2 An enhanced receiver implementation example 10.2 Retransmission of Layered Encoded Media in Multicast
The receiver may have more accurate information than the sender
about the current network QoS such as available bandwidth, packet
loss rate, delay and jitter. In addition, other receiver-specific
parameters such as buffer level, estimated importance of the lost
packet and application level QoS may be used by the receiver to
make a more efficient use of RTP retransmission by selectively
sending NACKs for important lost packets and not for others. For
example, a receiver may decide to suppress a request for a packet
loss that could be concealed locally, or for a retransmission that
would arrive late.
Furthermore, a receiver may acknowledge the received packets.
This can be done by sending ACKs, as per [1]. Upon receiving an
ACK, the sender may delete all the acknowledged packets from its
retransmission buffer. Note that this would also require only
limited increase in the required RTCP bandwidth as long as ACK
packets are sent seldom enough.
This implementation may help reduce buffer requirements at the
sender and optimise the performance of the implementation by using
selective requests.
Note that these receiver enhancements do not need to be negotiated
as they do not affect the sender implementation. However, in
order to allow the receiver to acknowledge packets, it is needed
to allow the use of ACKs in the SDP description, by means of an
additional SDP "a=rtcp-fb" line, as follows:
v=0
o=mascha 2980675221 2980675778 IN IP4 host.example.net
c=IN IP4 192.0.2.0
m=video 49170 RTP/AVPF 96 97
a=rtpmap:96 MP4V-ES/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 ack
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96;rtx-time=3000
10.3 Retransmission of Layered Encoded Media in Multicast
This section shows how to combine retransmissions with layered This section shows how to combine retransmissions with layered
encoding in multicast sessions. Note that the retransmission encoding in multicast sessions. Note that the retransmission
framework is not intended as a complete solution to reliable framework is not intended as a complete solution to reliable
multicast. Refer to RFC 2887 [10], for an overview of the multicast. Refer to RFC 2887 [10], for an overview of the
problems related with reliable multicast transmission. problems related with reliable multicast transmission.
Packets of different importance are sent in different RTP Packets of different importance are sent in different RTP
sessions. The retransmission streams corresponding to the sessions. The retransmission streams corresponding to the
different layers can themselves be seen as different different layers can themselves be seen as different
skipping to change at page 23, line 41 skipping to change at page 23, line 9
In multicast, SSRC-multiplexing of the original and retransmission In multicast, SSRC-multiplexing of the original and retransmission
streams is not allowed as per Section 5.3 of this document. For streams is not allowed as per Section 5.3 of this document. For
this reason, the retransmission stream(s) MUST be sent in this reason, the retransmission stream(s) MUST be sent in
different RTP session(s) using session-multiplexing. different RTP session(s) using session-multiplexing.
An SDP description example of multicast retransmissions for An SDP description example of multicast retransmissions for
layered encoded media is given below: layered encoded media is given below:
m=video 8000 RTP/AVPF 98 m=video 8000 RTP/AVPF 98
c=IN IP4 192.0.2.0/127/3 c=IN IP4 224.2.1.0/127/3
a=rtpmap:98 MP4V-ES/90000 a=rtpmap:98 MP4V-ES/90000
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
m=video 8000 RTP/AVPF 99 m=video 8000 RTP/AVPF 99
c=IN IP4 192.0.2.4/127/3 c=IN IP4 224.2.1.3/127/3
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98;rtx-time=3000 a=fmtp:99 apt=98;rtx-time=3000
The server and the receiver may implement the retransmission The server and the receiver may implement the retransmission
methods illustrated in the previous examples. In addition, they methods illustrated in the previous examples. In addition, they
may choose to request and retransmit a lost packet depending on may choose to request and retransmit a lost packet depending on
the layer it belongs to. the layer it belongs to.
11. IANA considerations 11. IANA considerations
A new MIME subtype name, "rtx", has been registered for four A new MIME subtype name, "rtx", has been registered for four
different media types, as follows: "video", "audio", "text" and different media types, as follows: "video", "audio", "text" and
"application". An additional REQUIRED parameter, "apt", and an "application". An additional REQUIRED parameter, "apt", and an
OPTIONAL parameter, "rtx-time", are defined. See Section 8 for OPTIONAL parameter, "rtx-time", are defined. See Section 8 for
details. details.
12. Security considerations 12. Security considerations
If cryptography is used to provide security services on the If cryptography is used to provide security services on the
original stream, then the same services, with equivalent original stream, then the same services, with equivalent
skipping to change at page 25, line 55 skipping to change at page 25, line 22
12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M.
Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", Naslund, K. Norrman, "The Secure Real-Time Transport Protocol",
draft-ietf-avt-srtp-05.txt, June 2002. draft-ietf-avt-srtp-05.txt, June 2002.
13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF 13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF
Standards Process," BCP 11, RFC 2028, IETF, October 1996. Standards Process," BCP 11, RFC 2028, IETF, October 1996.
15. Author's Addresses 15. Author's Addresses
Jose Rey rey@panasonic.de Jose Rey rey@panasonic.de
Panasonic European Laboratories GmbH Panasonic R&D Center Germany GmbH
Monzastr. 4c Monzastr. 4c
D-63225 Langen, Germany D-63225 Langen, Germany
Phone: +49-6103-766-134 Phone: +49-6103-766-134
Fax: +49-6103-766-166 Fax: +49-6103-766-166
David Leon david.leon@nokia.com David Leon david.leon@nokia.com
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX. USA Irving, TX. USA
Phone: 1-972-374-1860 Phone: 1-972-374-1860
Akihiro Miyazaki akihiro@isl.mei.co.jp Akihiro Miyazaki miyazaki.akihiro@jp.panasonic.com
Core Software Development Center CE Architecture Development Center
Corporate Software Development Division
Matsushita Electric Industrial Co., Ltd. Matsushita Electric Industrial Co., Ltd.
1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan
Phone: +81-6-6900-9192 Phone: +81-6-6900-9172
Fax: +81-6-6900-9193 Fax: +81-6-6900-9173
Viktor Varsa viktor.varsa@nokia.com Viktor Varsa viktor.varsa@nokia.com
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX. USA Irving, TX. USA
Phone: 1-972-374-1861 Phone: 1-972-374-1861
Rolf Hakenberg hakenberg@panasonic.de Rolf Hakenberg hakenberg@panasonic.de
Panasonic European Laboratories GmbH Panasonic R&D Center Germany GmbH
Monzastr. 4c Monzastr. 4c
D-63225 Langen, Germany D-63225 Langen, Germany
Phone: +49-6103-766-162 Phone: +49-6103-766-162
Fax: +49-6103-766-166 Fax: +49-6103-766-166
IPR Notices IPR Notices
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For details on the IPR statement, please visit the IETF
IPR web page, http://www.ietf.org/ietf/IPR.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology
in this document or the extent to which any license under such described in this document or the extent to which any license
rights might or might not be available; neither does it represent under such rights might or might not be available; nor does it
that it has made any effort to identify any such rights. represent that it has made any independent effort to identify any
Information on the IETF's procedures with respect to rights in such rights. Information on the procedures with respect to rights
standards-track and standards-related documentation can be found in RFC documents can be found in BCP 78 and BCP 79.
in BCP 11 [13]. Copies of claims of rights made available for
publication and any assurances of licenses to be made available, Copies of IPR disclosures made to the IETF Secretariat and any
or the result of an attempt made to obtain a general license or assurances of licenses to be made available, or the result of an
permission for the use of such proprietary rights by implementers attempt made to obtain a general license or permission for the use
or users of this specification can be obtained from the IETF of such proprietary rights by implementers or users of this
Secretariat. specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be required proprietary rights that may cover technology that may be required
to practice this standard. Please address the information to the to implement this standard. Please address the information to the
IETF Executive Director. IETF at ietf-ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP
This document and translations of it may be copied and furnished 78, and except as set forth therein, the authors retain all their
to others, and derivative works that comment on or otherwise rights.
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided on This document and the information contained herein are provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/