draft-ietf-rohc-rtp-impl-guide-11.txt   draft-ietf-rohc-rtp-impl-guide-12.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT P. Kremer INTERNET-DRAFT P. Kremer
Expires: October 2005 Ericsson Expires: November 2005 Ericsson
April 4, 2005 May 23, 2005
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-11.txt> <draft-ietf-rohc-rtp-impl-guide-12.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, I (we) accept the provisions of By submitting this Internet-Draft, each author accepts the provisions
Section 3 of RFC 3978 (BCP 78). of Section 3 of BCP 78.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
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".
skipping to change at page 1, line 41 skipping to change at page 1, line 41
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
This document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org. directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
This document describes common misinterpretations and some ambiguous This document clarifies common misinterpretations and some ambiguous
points of RFC 3095, which defines the framework and four profiles of points of RFC 3095, which defines the framework and four profiles of
a robust and efficient header compression scheme. The members of the the robust and efficient header compression scheme (ROHC). It also
ROHC working group have identified these issues during implementation addresses minor interpretation details of RFC 3241 (ROHC over PPP),
and at the various interoperability test events. RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles).
These issues have been identified by members of the ROHC working
group, during implementation and at interoperability test events.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction.....................................................3
2. CRC calculation and coverage issues..............................3 2. CRC calculation and coverage issues..............................4
2.1. CRC calculation.............................................3 2.1. CRC calculation.............................................4
2.2. Padding octet in CRC........................................3 2.2. Padding octet in CRC........................................4
2.3. CRC coverage in CRC feedback options........................3 2.3. CRC coverage in CRC feedback options........................4
2.4. CRC coverage of the ESP NULL header.........................4 2.4. CRC coverage of the ESP NULL header.........................4
3. Enhanced mode transition procedures..............................4 3. Enhanced mode transition procedures..............................4
3.1. Modified transition logic for enhanced transitions..........4 3.1. Modified transition logic for enhanced transitions..........5
3.2. Transition from Reliable to Optimistic mode.................5 3.2. Transition from Reliable to Optimistic mode.................6
3.3. Transition to Unidirectional mode...........................6 3.3. Transition to Unidirectional mode...........................6
4. Timestamp encoding considerations................................6 4. Timestamp encoding considerations................................7
4.1. Encoding used for compressed TS bits........................6 4.1. Encoding used for compressed TS bits........................7
4.2. (De)compression of TS without transmitted TS bits...........6 4.2. (De)compression of TS without transmitted TS bits...........7
4.3. Interpretation intervals for TS encoding....................7 4.3. Interpretation intervals for TS encoding....................8
4.4. TS_STRIDE for scaled timestamp encoding.....................8 4.4. TS_STRIDE for scaled timestamp encoding.....................8
4.5. TS wraparound with scaled timestamp encoding................8 4.5. TS wraparound with scaled timestamp encoding................9
4.6. Recalculating TS_OFFSET.....................................9 4.6. Recalculating TS_OFFSET.....................................9
4.7. TS_STRIDE and the Tsc flag in Extension 3...................9 4.7. TS_STRIDE and the Tsc flag in Extension 3..................10
5. List compression issues..........................................9 4.8. Using timer-based compression..............................10
5.1. Generic extension header list...............................9 5. List compression issues.........................................11
5.2. CSRC list items in RTP dynamic chain.......................10 5.1. Generic extension header list..............................11
5.3. RTP dynamic chain..........................................10 5.2. CSRC list items in RTP dynamic chain.......................11
5.4. Compressed lists in UO-1-ID packets........................10 5.3. RTP dynamic chain..........................................11
5.5. Bit masks in list compression..............................11 5.4. Compressed lists in UO-1-ID packets........................11
5.6. Headers compressed with list compression...................11 5.5. Bit masks in list compression..............................12
5.7. ESP NULL header list compression...........................11 5.6. Headers compressed with list compression...................12
6. Updating properties.............................................11 5.7. ESP NULL header list compression...........................12
6.1. Implicit updates...........................................11 6. Updating properties.............................................13
6.2. Updating properties of UO-1*...............................12 6.1. Implicit updates...........................................13
7. Context management and CID/context re-use.......................12 6.2. Updating properties of UO-1*...............................13
7.1. Compressor and decompressor MUST keep MAX_CID contexts.....12 7. Context management and CID/context re-use.......................14
7.2. CID/context re-use.........................................12 7.1. Compressor and decompressor MUST keep MAX_CID contexts.....14
7.2.1. Re-using a CID/context with the same profile..........13 7.2. CID/context re-use.........................................14
7.2.2. Re-using a CID/context with a different profile.......13 7.2.1. Re-using a CID/context with the same profile..........14
7.3. Context updating properties for IR packets.................13 7.2.2. Re-using a CID/context with a different profile.......15
8. Other protocol clarifications...................................14 7.3. Context updating properties for IR packets.................15
8.1. Meaning of NBO.............................................14 8. Other protocol clarifications...................................16
8.2. IP-ID......................................................14 8.1. Meaning of NBO.............................................16
8.3. Extension-3 in UO-1-ID packets.............................14 8.2. IP-ID......................................................16
8.4. Extension-3 in UOR-2* packets..............................15 8.3. Extension-3 in UO-1-ID packets.............................16
8.5. Multiple SN options in one feedback packet.................15 8.4. Extension-3 in UOR-2* packets..............................17
8.6. Multiple CRC options in one feedback packet................15 8.5. Multiple SN options in one feedback packet.................17
8.7. Packet decoding during mode transition.....................15 8.6. Multiple CRC options in one feedback packet................17
8.8. How to respond to lost feedback links?.....................16 8.7. Packet decoding during mode transition.....................17
8.9. What does "presumed zero if absent" mean on page 88?.......16 8.8. How to respond to lost feedback links?.....................18
8.10. UOR-2 in profile 2 (UDP)..................................16 8.9. What does "presumed zero if absent" mean on page 88?.......18
8.11. Sequence number LSB's in IP extension headers.............16 8.10. UOR-2 in profile 2 (UDP)..................................18
8.12. Expecting UOR-2 ACKs in O-mode............................16 8.11. Sequence number LSB's in IP extension headers.............18
8.13. Compression of SN in AH and GRE extension headers.........17 8.12. Expecting UOR-2 ACKs in O-mode............................18
9. ROHC negotiation clarifications.................................17 8.13. Compression of SN in AH and GRE extension headers.........19
10. PROFILES suboption in ROHC-over-PPP............................18 9. ROHC negotiation clarifications.................................20
11. Test configuration.............................................18 10. PROFILES suboption in ROHC-over-PPP............................20
12. Security considerations........................................19 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......20
13. IANA considerations............................................19 12. Test configuration.............................................21
14. Acknowledgment.................................................19 13. Security considerations........................................21
15. Normative references...........................................19 14. IANA considerations............................................21
16. Authors' Addresses.............................................19 15. Acknowledgment.................................................22
Appendix A - Sample CRC algorithm..................................20 16. References.....................................................22
Appendix B - Potential improvements in updated profiles............22 16.1. Normative References......................................22
16.2. Informative References....................................22
17. Authors' Addresses.............................................22
Appendix A - Sample CRC algorithm..................................23
Appendix B - Potential improvements in updated profiles............25
1. Introduction 1. Introduction
ROHC [1] defines a robust and efficient header compression algorithm, ROHC [1] defines a robust and efficient header compression algorithm,
and its description is rather long and complex. During the and its description is rather long and complex. During the
implementation and the interoperability tests of the algorithm some implementation and the interoperability tests of the algorithm some
unclear areas have been identified. This document tries to collect unclear areas have been identified. This document tries to collect
and clarify these points. Note that all section and chapter and clarify these points. A few minor interpretation details of RFC
references in this document refer to [1], if not stated otherwise. 3241 [2] (ROHC over PPP), RFC 3843 [3] (ROHC IP-only profile), and
RFC 4019 [5] (ROHC UDP-Lite profiles) are also addressed in this
document (chapter 10-11). Note that all section and chapter
references in this document refer to [1], where not stated otherwise.
2. CRC calculation and coverage issues 2. CRC calculation and coverage issues
2.1. CRC calculation 2.1. CRC calculation
ROHC uses CRC checksum in order to provide some protection against ROHC uses CRC checksum in order to provide some protection against
bit errors. CRC is used in the segmentation protocol and in the bit errors. CRC is used in the segmentation protocol and in the
compressed packets, as well. compressed packets, as well.
Section 5.2.5.2 describes the segmentation protocol and refers to Section 5.2.5.2 describes the segmentation protocol and refers to
skipping to change at page 9, line 45 skipping to change at page 10, line 20
Note also that if Tsc=1, TS is scaled using context(TS_STRIDE), not Note also that if Tsc=1, TS is scaled using context(TS_STRIDE), not
value(TS_STRIDE) as is said in the legend for Extension 3 in section value(TS_STRIDE) as is said in the legend for Extension 3 in section
5.7.5. 5.7.5.
When a compressor uses Extension 3 to re-establish a new value for When a compressor uses Extension 3 to re-establish a new value for
TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some
packets until decompressor confidence is obtained. When the TS_STRIDE packets until decompressor confidence is obtained. When the TS_STRIDE
field is present in Extension 3, the Tsc flag must thus be set to 0. field is present in Extension 3, the Tsc flag must thus be set to 0.
4.8. Using timer-based compression
Timer-based compression of the RTP timestamp, as described in section
4.5.4, may be used to reduce the number of transmitted timestamp bits
(bytes) needed when the timestamp can not be inferred from the SN. It
should thus be noted that timer-based compression has no influence on
decompression of packets where no timestamp bits are sent, in that
case the timestamp is just linearly inferred from the SN (see section
4.2 of this document).
Whether to use timer-based compression or not is controlled by the
TIME_STRIDE control field, which can be set either by an IR, an IR-
DYN, or by a compressed packet with extension 3. The compressor turns
on timer-based compression by setting TIME_STRIDE to a value > 0, but
that can be done first after the decompressor has declared its clock
resolution, which is done by sending a CLOCK feedback option for any
CID on the channel.
5. List compression issues 5. List compression issues
5.1. Generic extension header list 5.1. Generic extension header list
Section 5.7.7.4 defines the static and dynamic parts of the IPv4 Section 5.7.7.4 defines the static and dynamic parts of the IPv4
header. This section indicates a 'Generic extension header list' header. This section indicates a 'Generic extension header list'
field in the dynamic chain, which has a variable length. The field in the dynamic chain, which has a variable length. The
detailed description of this field can be found in Section 5.8.6.1. detailed description of this field can be found in Section 5.8.6.1.
The generic extension header list starts with an octet that is always The generic extension header list starts with an octet that is always
skipping to change at page 18, line 23 skipping to change at page 20, line 42
10. PROFILES suboption in ROHC-over-PPP 10. PROFILES suboption in ROHC-over-PPP
The logical union of suboptions for IPCP and IPV6CP negotiations, as The logical union of suboptions for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [2], can not be used for the PROFILES specified by ROHC over PPP [2], can not be used for the PROFILES
suboption, as the whole union would then have to be considered within suboption, as the whole union would then have to be considered within
each of the two IPCP negotiations, to avoid getting an ambiguous each of the two IPCP negotiations, to avoid getting an ambiguous
profile set. An implementation of RFC 3241 must therefore make sure profile set. An implementation of RFC 3241 must therefore make sure
the same profile set is negotiated for both IPv4 and IPv6 (IPCP and the same profile set is negotiated for both IPv4 and IPv6 (IPCP and
IPV6CP). IPV6CP).
11. Test configuration 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles
In the ROHC IP-only profile, section 3.3 of RFC 3843 [3], a mechanism
for encoding of a constant Identification value in IPv4 (constant IP-
ID) is defined. This mechanism is also used by the ROHC UDP-Lite
profiles, RFC 4019 [5].
It should be noted that the "Constant IP-ID" mechanism applies to
both the inner and the outer IP header, when present , meaning that
there will be both a SID and a SID2 context value.
12. Test configuration
ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus
every ROHC implementation has an interface that can send and receive every ROHC implementation has an interface that can send and receive
IP packets (i.e. Ethernet). On the other hand, there must be an IP packets (i.e. Ethernet). On the other hand, there must be an
interface (a serial link for example) or other means of transport (an interface (a serial link for example) or other means of transport (an
IP/UDP flow), which can transmit ROHC packets. Having these two IP/UDP flow), which can transmit ROHC packets. Having these two
interfaces several configurations can be set up. The figure below interfaces several configurations can be set up. The figure below
shows sample configurations that can be used for testing a ROHC shows sample configurations that can be used for testing a ROHC
implementation: implementation:
skipping to change at page 19, line 4 skipping to change at page 21, line 35
IP/UDP/RTP +------------+ ROHC ROHC +--------------+ IP/UDP/RTP IP/UDP/RTP +------------+ ROHC ROHC +--------------+ IP/UDP/RTP
packets | ROHC | packets packets | ROHC | packets packets | ROHC | packets packets | ROHC | packets
+----->| Compressor |----->+ +----->| Decompressor |----->+ +----->| Compressor |----->+ +----->| Decompressor |----->+
| +------------+ | | +--------------+ | | +------------+ | | +--------------+ |
| | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | Test | | | | Test | | | | Test | | | | Test | |
+<-----| Equipment |<-----+ +<------| Equipment |<------+ +<-----| Equipment |<-----+ +<------| Equipment |<------+
+------------+ +------------+ +------------+ +------------+
In the first case, the test equipment generates the RTP stream and In the first case, the test equipment generates the RTP stream and
also acts as a ROHC decompressor. The tester must recognize if the also acts as a ROHC decompressor. The tester must recognize if the
original RTP stream was compressed in a bad way and gives an alarm. original RTP stream was compressed in a bad way and gives an alarm.
In the second case, it is the test equipment that sends the In the second case, it is the test equipment that sends the
compressed ROHC packets and the Decompressor reconstructs the RTP compressed ROHC packets and the Decompressor reconstructs the RTP
stream. Since the tester knows the ROHC packets and the stream. Since the tester knows the ROHC packets and the
reconstructed RTP stream it can detect if the Decompressor makes a reconstructed RTP stream it can detect if the Decompressor makes a
mistake. mistake.
12. Security considerations 13. Security considerations
This document provides a number of clarifications to [1], but it does This document provides a number of clarifications to [1], but it does
not make any changes or additions to the protocol. As a consequence, not make any changes or additions to the protocol. As a consequence,
the security considerations of [1] apply without additions. the security considerations of [1] apply without additions.
13. IANA considerations 14. IANA considerations
This document does not require any IANA actions. This document does not require any IANA actions.
14. Acknowledgment 15. Acknowledgment
The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, The authors would like to thank Vicknesan Ayadurai, Carsten Bormann,
Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees, Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees,
Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and
Remi Pelland for their contributions and comments. Remi Pelland for their contributions and comments.
15. Normative references 16. References
[1] C. Bormann, et al., "RObust Header Compression (ROHC)", 16.1. Normative References
[1] C. Bormann, et al., "RObust Header Compression (ROHC) Framework
and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
[2] C. Bormann, "Robust Header Compression (ROHC) over PPP", [2] C. Bormann, "Robust Header Compression (ROHC) over PPP",
RFC 3241, April 2002. RFC 3241, April 2002.
[3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994. [3] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC):
A Compression Profile for IP", RFC 3843, June 2004.
16. Authors' Addresses [4] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.
16.2. Informative References
[5] G. Pelletier, "RObust Header Compression (ROHC): Profiles for
User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[6] G. Pelletier, L-E. Jonsson, and K. Sandlund, "ROHC over Channels
that can Reorder Packets", internet-draft (work in progress),
February 2005. <draft-ietf-rohc-over-reordering-02.txt>
17. Authors' Addresses
Lars-Erik Jonsson Lars-Erik Jonsson
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 8 404 29 61 Phone: +46 8 404 29 61
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
Peter Kremer Peter Kremer
Conformance and Software Test Laboratory Conformance and Software Test Laboratory
skipping to change at page 22, line 7 skipping to change at page 25, line 7
#--------------------------------- #---------------------------------
# #
# 3-bit FO/SO CRC # 3-bit FO/SO CRC
# #
# C(x) = x^0 + x^1 + x^3 # C(x) = x^0 + x^1 + x^3
# #
do_crc(3, 0x6, $string); do_crc(3, 0x6, $string);
Appendix B - Potential improvements in updated profiles Appendix B - Potential improvements in updated profiles
B.1. Minor improvements
B.1.1. Meaning of CC=0 for CSRC list presence
Regarding the CC field and CSRC list, the following interpretation Regarding the CC field and CSRC list, the following interpretation
has been proposed as an improvement: has been proposed as an improvement:
"It should be noted that when the value of this CC field is equal to "It should be noted that when the value of this CC field is equal to
zero, there is no Generic CSRC list present in the dynamic chain, zero, there is no Generic CSRC list present in the dynamic chain,
i.e. the field comment should have said "variable length, present if i.e. the field comment should have said "variable length, present if
CC > 0". "<introduction text> CC > 0". "
B.2. Improvements already applied to the IP-only and UPL-Lite profiles
B.2.1. Handling Multiple Levels of IP Headers
The profiles in RFC 3095 can only handle compression of packet
streams with at most two IP headers. The IP-only profile defines a
generic way of handling multiple IP headers (see section 3.2 of [3]).
B.2.2. The CONTEXT_MEMORY Feedback Option
To provide means for a decompressor implementation to have an upper
limit on its available context memory size, the IP-only profile
defines an additional feedback option to use (see section 3.7 of
[3]). The CONTEXT_MEMORY option informs the compressor that the
decompressor does not have sufficient memory resources to handle the
context of the packet stream, as the stream is currently compressed.
B.2.3. Compression of constant IP-ID (IPv4 only)
Most IPv4 stacks assign an IP-ID according to the value of a counter,
increasing by one for each outgoing packet. ROHC-RTP therefore
compresses the IP-ID field using offset IP-ID encoding based on the
RTP SN. For stacks generating IP-ID values using a pseudo-random
number generator, the field is not compressed and is sent as-is in
its entirety as additional octets after the compressed header.
Cases have also been found where an IPv4 stack uses a constant value
for the IP Identifier. When the IP-ID field is constant, it cannot
be compressed using offset IP-ID encoding and the field must be sent
in its entirety, although it is completely static and could had been
completely omitted in compressed headers. The IP-only profile
addresses this problem and defines an additional mechanism to cope
efficiently with constant IP-ID (see section 3.3 of [3]).
B.3. Adding tolerance to reordering between compressor and decompressor
RFC 3095 was written based on the assumption of in-order packet
delivery between compressor and decompressor. Since the publication
of RFC 3095, is has been clear that using ROHC would be desirable
also in environments where in-order delivery can not be guaranteed.
The challenges associated with such usage have been analyzed in an
informational ROHC WG document "ROHC over channels that can reorder
packets" [6], and the finding of that document should be used as a
basis when developing an enhanced ROHC that can tolerate a certain
amount of reordering, possibly a configurable reordering tolerance.
Intellectual Property Statement Intellectual Property Statement
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 Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 23, line 31 skipping to change at page 27, line 31
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires October 4, 2005. This Internet-Draft expires November 23, 2005.
 End of changes. 

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