Le CID espace peut être soit faible, ce qui signifie que les CID peuvent prendre la
values 0 through 15, or large, which means that CIDs take values
between 0 and 2^14 - 1 = 16383. Whether the CID space is large or
small MUST be established, possibly by negotiation, before any
compressed packet may be sent over the ROHC channel.

The CID space is distinct for each channel, ie, CID 3 over channel
A and CID 3 over channel B do not refer to the same context, even if
the endpoints of A and B are the same nodes. In particular, CIDs for

Jonsson, et al. Standards Track [Page 14]

RFC 4995 The ROHC Framework July 2007
any pair of ROHC channels are not related (two associated ROHC
channels serving as feedback channels for one another do not even
need to have CID spaces of the same size).

5.1.2. Per-Channel Parameters

The ROHC channel is based on a number of parameters that form part of
the established channel state and the per-context state. The state
of the ROHC channel MUST be established before the first ROHC packet
may be sent, which may be achieved using negotiation protocols
provided by the link layer (see also [4], which describes an option
for negotiation of ROHC parameters for PPP). This section describes
some of this channel state information in an abstract way:

LARGE_CIDS: Boolean; if false, the small CID representation (0 octets
or 1 prefix octet, covering CID 0 to 15) is used; if true, the
large CID representation (1 or 2 embedded CID octets covering CID
0 to 16383) is used. See also 5.1.1 and 5.2.1.3.

MAX_CID: Non-negative integer; highest CID number to be used by the
compressor (note that this parameter is not coupled to, but in
effect further constrained by, LARGE_CIDS). This value represents
an agreement by the decompressor that it can provide sufficient
memory resources to host at least MAX_CID+1 contexts; the
decompressor MUST maintain established contexts within this space
until either the CID gets re-used by the establishment of a new
context, or until the channel is taken down.

PROFILES: Set of non-negative integers, where each integer indicates
a profile supported by both the compressor and the decompressor.
A profile is identified by a 16-bit value, where the 8 LSB bits
indicate the actual profile, and the 8 MSB bits indicate the
variant of that profile. The ROHC compressed header format
identifies the profile used with only the 8 LSB bits; this means
that if multiple variants of the same profile are available for a
ROHC channel, the PROFILES set after negotiation MUST NOT include
more than one variant of the same profile. The compressor MUST
NOT compress using a profile that is not in PROFILES.

FEEDBACK_FOR: Optional reference to a ROHC channel in the opposite
direction between the same compression endpoints. If provided,
this parameter indicates to which other ROHC channel any feedback
sent on this ROHC channel refers (see [5]).

MRRU: Non-negative integer. Maximum Reconstructed Reception Unit.
This is the size of the largest reconstructed unit in octets that
the decompressor is expected to reassemble from segments (see
Section 5.2.5). This size includes the segmentation CRC. If MRRU

Jonsson, et al. Standards Track [Page 15]

RFC 4995 The ROHC Framework July 2007
is negotiated to be 0, segmentation MUST NOT be used on the
channel, and received segments MUST be discarded by the
decompressor.

5.1.3. Persistence of Decompressor Contexts

As part of the negotiated channel parameters, the compressor and
decompressor have through the MAX_CID parameter agreed on the highest
context identification (CID) number to be used. By agreeing on the
MAX_CID, the decompressor also agrees to provide memory resources to
host at least MAX_CID+1 contexts, and an established context with a
CID within this negotiated space SHOULD be kept by the decompressor
until either the CID gets re-used, or the channel is taken down or
re-negotiated.

5.2. ROHC Packets and Packet Types

This section uses the following convention in the diagrams when
representing various ROHC packet types, formats, and fields:

The ROHC packet type indication scheme has been designed to provide
optional padding, a feedback packet type, an optional Add-CID octet
(which includes 4 bits of CID), and a simple segmentation and
reassembly mechanism.

Padding: Any number (zero or more) of padding octets, where the
format of a padding octet is as defined in Section 5.2.1.1.

Feedback: Any number (zero or more) of feedback elements, where the
format of a feedback element is as defined in Section 5.2.4.1.

Header: Either a profile-specific CO header (see Section 5.2.1.3), an
IR or IR-DYN header (see Section 5.2.2), or a ROHC Segment (see
Section 5.2.5). There can be at most one Header in a ROHC packet,
but it may also be omitted (if the packet contains Feedback only).

Payload: Corresponds to zero or more octets of payload from the
uncompressed packet, starting with the first octet in the
uncompressed packet after the last header compressible by the
current profile.

body: Interpreted according to the packet type indication and CID
information, as defined by individual profiles.

Thus, the header either starts with a packet type indication or has a
packet type indication immediately following an Add-CID octet.

When the ROHC channel is configured with a small CID space:

o If an Add-CID immediately precedes the packet type indication,
the packet has the CID of the Add-CID; otherwise, it has CID 0.

o A small CID with the value 0 is represented using zero bits;
therefore, a flow associated with CID 0 has no CID overhead in
the compressed header. In such case, Header starts with a
packet type indication.
Jonsson, et al. Standards Track [Page 18]

RFC 4995 The ROHC Framework July 2007
o A small CID with a value from 1 to 15 is represented using the
Add-CID octet as described above. The Header starts with the
Add-CID octet, followed by a packet type indication.

o There is no large CID in the Header.

When the ROHC channel is configured with a large CID space:

o The large CID is always present and is represented using the
encoding scheme of Section 5.3.2, limited to two octets. In
this case, the Header starts with a packet type indication.

5.2.2. Initialization and Refresh (IR) Packet Types

IR packet types contain a profile identifier, which determines how
the rest of the header is to be interpreted. They also associate a
profile with a context. The stored profile parameter further
determines the syntax and semantics of the packet type identifiers
and packet types used with a specific context.

The IR and IR-DYN packets always update the context for all context-
updating fields carried in the header. They never clear the context,
except when initializing a new context (see Section 5.1.1), or unless
the profile indicated in the Profile field specifies otherwise.

Jonsson, et al. Standards Track [Page 19]

RFC 4995 The ROHC Framework July 2007
5.2.2.1. ROHC IR Packet Type

The IR header associates a CID with a profile, and typically also
initializes the context. It can typically also refresh all (or parts
of) the context. For IR, Header has the following general format:

x: Profile specific information. Interpreted according to the
profile indicated in the Profile field of the IR header.

Profile: The profile associated with the CID. In the IR header, the
profile identifier is abbreviated to the 8 least significant bits
(see Section 5.1.2).

CRC: 8-bit CRC (see Section 5.3.1.1).

Profile specific information: The content of this part of the IR
header is defined by the individual profiles. It is interpreted
according to the profile indicated in the Profile field.

5.2.2.2. ROHC IR-DYN Packet Type

In contrast to the IR header, the IR-DYN header can never initialize
a non-initialized context. However, it can redefine what profile is
associated with a context, if the profile indicated in the IR-DYN
header allows this. Thus, this packet type is also reserved at the
framework level. The IR-DYN header typically also initializes or
refreshes parts of a context. For IR-DYN, Header has the following
general format:
Jonsson, et al. Standards Track [Page 20]

Profile: The profile associated with the CID. This is abbreviated in
the same way as in IR packets.

CRC: 8-bit CRC (see Section 5.3.1.1).

Profile specific information: The content of this part of the IR-DYN
header is defined by the individual profiles. It is interpreted
according to the profile indicated in the Profile field.

5.2.3. ROHC Initial Decompressor Processing

Initially, all contexts are in no context state. Thus, all packets
referencing a non-initialized context, except packets that have
enough information on the static fields, cannot be decompressed by
the decompressor.

When the decompressor receives a packet of type IR, the profile
indicated in the IR packet determines how it is to be processed.

o If the 8-bit CRC fails to verify the integrity of the Header,
the packet MUST NOT be decompressed and delivered to upper
layers. If a profile is indicated in the context, the logic of
that profile determines what, if any, feedback is to be sent.
If no profile is noted in the context, the logic used to
determine what, if any, feedback to send is up to the
implementation. However, it may be suitable to take no further
actions, as any part of the IR header covered by the CRC may
have caused the failure.
Jonsson, et al. Standards Track [Page 21]

RFC 4995 The ROHC Framework July 2007
When the decompressor receives a packet of type IR-DYN, the profile
indicated in the IR-DYN packet determines how it is to be processed.

o If the 8-bit CRC fails to verify the integrity of the header,
the packet MUST NOT be decompressed and delivered to upper
layers. If a profile is indicated in the context, the logic of
that profile determines what, if any, feedback is to be sent.
If no profile is noted in the context, the logic used to
determine what, if any, feedback to send is up to the
implementation. However, it may be suitable to take no further
actions, as any part of the IR-DYN header covered by the CRC
may have caused the failure.

o If the context has not already been initialized, the packet
MUST NOT be decompressed and delivered to upper layers. The
logic of the profile indicated in the IR-DYN header (if
verified by the 8-bit CRC), determines what, if any, feedback
is to be sent.

If a parsing error occurs for any packet type, the decompressor MUST
discard the packet without further processing. For example, a CID
field is present in the compressed header when the large CID space is
used for the ROHC channel, and the field is coded using the self-
describing variable-length encoding of Section 5.3.2; if the field
starts with 110 or 111, this would generate a parsing error for the
decompressor because this field must not be encoded with a size
larger than 2 octets.

It is RECOMMENDED that profiles disallow the decompressor to make a
decompression attempt for packets carrying only a 3-bit CRC after it
has invalidated some or all of the entire dynamic context, until a
packet that contains sufficient information on the dynamic fields is
received, decompressed, and successfully verified by a 7- or 8-bit
CRC.

5.2.4. ROHC Feedback

Feedback carries information from the decompressor to compressor.
Feedback can be sent over a ROHC channel that operates in the same
direction as the feedback.

The general ROHC packet format allows transport of feedback using
interspersion or piggybacking (see [5]), or a combination of both,
over a ROHC channel. This is facilitated by the following
properties:
Jonsson, et al. Standards Track [Page 22]

RFC 4995 The ROHC Framework July 2007
Reserved packet type:

A feedback packet type is reserved at the framework level. The
packet type can carry variable-length feedback information.

CID information:

The feedback information sent on a particular channel is passed
to, and interpreted by, the compressor associated with feedback on
that channel. Thus, each feedback element contains CID
information from the channel for which the feedback is sent. The
ROHC feedback scheme thus requires that a channel carries feedback
to at most one compressor. How a compressor is associated with
the feedback for a particular channel is outside the scope of this
specification. See also [5].

Length information:

The length of a feedback element can be determined by examining
the first few octets of the feedback. This enables piggybacking
of feedback, and also the concatenation of more than one feedback
element in a packet. The length information thus decouples the
decompressor from the associated same-side compressor, as the
decompressor can extract the feedback information from the
compressed header without parsing its content and hand over the
extracted information.

The association between compressor-decompressor pairs operating in
opposite directions, for the purpose of exchanging piggyback and/or
interspersed feedback, SHOULD be maintained for the lifetime of the
ROHC channel. Otherwise, it is RECOMMENDED that the compressor be
notified if the feedback channel is no longer available: the
compressor SHOULD then restart compression by creating a new context
for each packet flow, and SHOULD use a CID value that was not
previously associated with the profile used to compress the flow.

5.2.4.1. ROHC Feedback Format

ROHC defines three different categories of feedback messages:
acknowledgment (ACK), negative ACK (NACK), and NACK for the entire
context (STATIC-NACK). Other types of information may be defined in
profile-specific feedback information.

ACK : Acknowledges successful decompression of a packet.
Indicates that the decompressor considers its context
to be valid.

Jonsson, et al. Standards Track [Page 23]

RFC 4995 The ROHC Framework July 2007
NACK : Indicates that the decompressor considers some or all
of the dynamic part of its context invalid.

STATIC-NACK : Indicates that the decompressor considers its entire
static context invalid, or that it has not been
established.

Feedback sent on a ROHC channel consists of one or more concatenated
feedback elements, where each feedback element has the following
format:

Code: 0 indicates that a Size octet is present.
1-7 indicates the size of the feedback data field, in octets.

Size: Indicates the size of the feedback data field, in octets.

FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below).

CID information in a feedback element indicates the context for which
feedback is sent. The LARGE_CIDS parameter that controls whether a
large CID is present is taken from the channel state of the receiving
compressor's channel, not from the state of the channel carrying the
feedback.

The large CID field, if present, is encoded according to Section
5.3.2, and it MUST NOT be encoded using more than 2 octets.

Jonsson, et al. Standards Track [Page 24]

RFC 4995 The ROHC Framework July 2007
The FEEDBACK data field can have either of the following two formats:

ROHC defines a simple segmentation protocol. The compressor may
perform segmentation, eg, to accommodate packets that are larger
than a specific size configured for the channel.

5.2.5.1. Segmentation Usage Considerations

The ROHC segmentation protocol is not particularly efficient. It is
not intended to replace link layer segmentation functions; these
SHOULD be used whenever available and efficient for the task at hand.

The ROHC segmentation protocol has been designed with an assumption
of in-order delivery of packets between the compressor and the
decompressor, using only a CRC for error detection, and no sequence
numbers. If in-order delivery cannot be guaranteed, ROHC
segmentation MUST NOT be used.

The segmentation protocol also assumes that all segments of a ROHC
packet corresponding to one context are received without interference
from other ROHC packets over the channel, including any ROHC packet
corresponding to a different context. Based on this assumption,
segments do not carry CID information, and therefore cannot be
associated with a specific context until all segments have been
received and the whole unit has been reconstructed.

Jonsson, et al. Standards Track [Page 25]

RFC 4995 The ROHC Framework July 2007
5.2.5.2. Segmentation Protocol

ROHC segmentation is applied to the combination of the Header and the
Payload fields of the ROHC packet, as defined in Section 5.2.1.

F: Final bit. If set, it indicates that this is the last segment of
a reconstructed unit.

Padding and/or Feedback may precede the segment type octet. There is
no per-segment CID, but CID information is of course part of the
reconstructed unit. The reconstructed unit MUST NOT contain padding,
segments, or feedback.

When a final segment is received, the decompressor reassembles the
segment carried in this packet and any non-final segments that
immediately preceded it into a single reconstructed unit, in the
order they were received. All segments for one reconstructed unit
have to be received consecutively and in the correct order by the
decompressor. If a non-segment ROHC packet directly follows a non-
final segment, the reassembly of the current reconstructed unit is
aborted and the decompressor MUST discard the non-final segments so
far received on this channel.

If the reconstructed unit is 4 octets or less, or if the CRC fails,
or if it is larger than the channel parameter MRRU (see Section
Jonsson, et al. Standards Track [Page 26]

RFC 4995 The ROHC Framework July 2007
5.1.2), the reconstructed unit MUST be discarded by the decompressor.
If the CRC succeeds, the reconstructed unit can be further processed.

5.3. General Encoding Methods

5.3.1. Header Compression CRCs, Coverage and Polynomials

This section describes how to calculate the CRCs used by ROHC. For
all CRCs, the algorithm used to calculate the CRC is the same as the
one used in [2], defined in Appendix A of this document, with the
polynomials specified in subsequent sections.

5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers

The coverage for the 8-bit CRC in the IR and IR-DYN headers is
profile-dependent, but it MUST cover at least the initial part of the
header ending with the Profile field, including the CID or an Add-CID
octet. Feedback and padding are not part of Header (Section 5.2.1)
and are thus not included in the CRC calculation. As a rule of thumb
for profile specifications, any other information that initializes
the decompressor context SHOULD also be covered by a CRC.

More specifically, the 8-bit CRC does not cover only and entirely the
original uncompressed header; therefore, it does not provide the
means for the decompressor to verify a decompression attempt, or the
means to verify the correctness of the entire decompressor context.
However, when successful, it does provide enough robustness for the
decompressor to update its context with the information carried
within the IR or the IR-DYN header.

The CRC polynomial for the 8-bit CRC is:

C(x) = 1 + x + x^2 + x^8

When computing the CRC, the CRC field in the header is set to zero,
and the initial content of the CRC register is set to all 1's.

5.3.1.2. 3-bit CRC in Compressed Headers

The 3-bit CRC in compressed headers is calculated over all octets of
the entire original header, before compression, in the following
manner.

The initial content of the CRC register is set to all 1's.

The polynomial for the 3-bit CRC is:

C(x) = 1 + x + x^3

Jonsson, et al. Standards Track [Page 27]

RFC 4995 The ROHC Framework July 2007
The purpose of the 3-bit CRC is to provide the means for the
decompressor to verify the outcome of a decompression attempt for
small compressed headers, and to detect context damage based on
aggregated probability over a number of decompression attempts. It
is however too weak to provide enough success guarantees from the
decompression of one single header. Therefore, compressed headers
carrying a 3-bit CRC are normally not suitable to perform context
repairs at the decompressor; hence, profiles should refrain from
allowing decompression of such a header when some or the entire
decompressor context is assumed invalid.

5.3.1.3. 7-bit CRC in Compressed Headers

The 7-bit CRC in compressed headers is calculated over all octets of
the entire original header, before compression, in the following
manner.

The initial content of the CRC register is set to all 1's.

The polynomial for the 7-bit CRC is:

C(x) = 1 + x + x^2 + x^3 + x^6 + x^7

The purpose of the 7-bit CRC is to provide the means for the
decompressor to verify the outcome of a decompression attempt for a
larger compressed header, and to provide enough protection to
validate a context repair at the decompressor. The 7-bit CRC is
strong enough to assume a repair to be successful from the
decompression of one single header; hence, profiles may allow
decompression of a header carrying a 7-bit CRC when some of the
decompressor context is assumed invalid.

5.3.1.4. 32-bit Segmentation CRC

The 32-bit CRC is used by the segmentation scheme to verify the
reconstructed unit, and it is thus calculated over the segmented
unit, ie, over the Header and the Payload fields of the ROHC
packet.

The values of many fields and compression parameters can vary widely.
To optimize the transfer of such values, a variable number of octets
are used to encode them. The first few bits of the first octet
determine the number of octets used:

First bit is 0: 1 octet.
7 bits transferred.
Up to 127 decimal.
Encoded octets in hexadecimal: 00 to 7F

This section describes the uncompressed ROHC profile. The profile
identifier for this profile is 0x0000.

Profile 0x0000 provides a way to send IP packets without compressing
them. This can be used for any packet for which a compression
profile is not available in the set of profiles supported by the ROHC
channel, or for which compression is not desirable for some reason.

After initialization, the only overhead for sending packets using
Profile 0x0000 is the size of the CID. When uncompressed packets are
frequent, Profile 0x0000 should be associated with a CID the size of
zero or one octet. Profile 0x0000 SHOULD be associated with at most
one CID.

Jonsson, et al. Standards Track [Page 29]

RFC 4995 The ROHC Framework July 2007
5.4.1. IR Packet

The initialization and refresh packet (IR packet) for Profile 0x0000
has the following Header format:

res: MUST be set to zero; otherwise, the decompressor MUST discard
the packet.

Profile: 0x00

CRC: 8-bit CRC, computed using the polynomial of Section 5.3.1.1.
The CRC covers the first octet of the IR Header through the
Profile octet of the IR Header, ie, it does not cover the CRC
itself. Neither does it cover any preceding Padding or
Feedback, nor the Payload.

Note that the first octet of the IP packet starts with the bit
pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any
reserved packet types.

When the channel uses small CIDs, and profile 0x0000 is associated
with a CID > 0, an Add-CID octet precedes the IP packet. When the
channel uses large CIDs, the CID is placed so that it starts at the
second octet of the combined Header/Payload format above.

A Normal Packet may carry Padding and/or Feedback as any other ROHC
packet, preceding the combined Header/Payload.

5.4.3. Decompressor Operation

When an IR packet is received, the decompressor first validates its
header using the 8-bit CRC.

o If the header fails validation, the decompressor MUST NOT deliver
the IP packet to upper layers.

o If the header is successfully validated, the decompressor

1) initializes the context if it has no valid context for the
given CID already associated to the specified profile,

When any other packet is received while the decompressor has no
context, it is discarded without further action.

When a Normal packet is received and the decompressor has a valid
context, the IP packet is extracted and delivered to upper layers.

5.4.4. Feedback

The only kind of feedback defined by Profile 0x0000 is ACK, using the
FEEDBACK-1 format of Section 5.2.4.1, where the value of the profile-
specific octet in the FEEDBACK-1 is 0 (zero). The FEEDBACK-2 format
is thus not defined for Profile 0x0000.

6. Overview of a ROHC Profile (Informative)

The ROHC protocol consists of a framework part and a profile part.
The framework defines the mechanisms common to all profiles, while
the profile defines the compression algorithm and profile specific
packet formats.

Section 5 specifies the details of the ROHC framework. This section
provides an informative overview of the elements that make a profile
specification. The normative specification of individual profiles is
outside the scope of this document.

A ROHC profile defines the elements that build up the compression
protocol. A ROHC profile consists of:

Packet formats:

o Bits-on-the-wire

The profile defines the layout of the bits for profile-specific
packet types that it defines, and for the profile-specific parts
of packet types common to all profiles (eg, IR and IR-DYN).

o Field encodings

Bits and groups of bits from the packet format layout, referred to
as Compressed fields, represents the result of an encoding method
specific for that compressed field within a specific packet
format. The profile defines these encoding methods.

Jonsson, et al. Standards Track [Page 32]

RFC 4995 The ROHC Framework July 2007
o Updating properties

The profile-specific packet formats may update the state of the
decompressor, and may do so in different ways. The profile
defines how individual profile-specific fields, or entire
profile-specific packet types, update the decompressor context.

o Verification

Packets that update the state of the decompressor are verified to
prevent incorrect updates to the decompressor context. The
profile defines the mechanisms used to verify the decompression of
a packet.

Context management:

o Robustness logic

Packets may be lost or reordered between the compressor and the
decompressor. The profile defines mechanism to minimize the
impacts of such events and prevent damage propagation.

o Repair mechanism

Despite the robustness logic, impairment events may still lead to
decompression failure(s), and even to context damage at the
decompressor. The profile defines context repair mechanisms,
including feedback logic if used.

7. Security Considerations

Because encryption eliminates the redundancy that header compression
schemes try to exploit, there is some inducement to forego encryption
of headers in order to enable operation over low-bandwidth links.

A malfunctioning or malicious header compressor could cause the
header decompressor to reconstitute packets that do not match the
original packets but still have valid headers and possibly also valid
transport checksums. Such corruption may be detected with end-to-end
authentication and integrity mechanisms, which will not be affected
by the compression. Moreover, the ROHC header compression scheme
uses an internal checksum for verification of reconstructed headers,
which reduces the probability of producing decompressed headers not
matching the original ones without this being noticed.

Denial-of-service attacks are possible if an intruder can introduce,
for example, bogus IR, IR-DYN, or FEEDBACK packets onto the link and
thereby cause compression efficiency to be reduced. However, an

Jonsson, et al. Standards Track [Page 33]

RFC 4995 The ROHC Framework July 2007
intruder having the ability to inject arbitrary packets at the link
layer in this manner raises additional security issues that dwarf
those related to the use of header compression.

8. IANA Considerations

An IANA registry for "RObust Header Compression (ROHC) Profile
Identifiers" [21] was created by RFC 3095 [3]. The assignment
policy, as outlined by RFC 3095, is the following:

The ROHC profile identifier is a non-negative integer. In many
negotiation protocols, it will be represented as a 16-bit value. Due
to the way the profile identifier is abbreviated in ROHC packets, the
8 least significant bits of the profile identifier have a special
significance: Two profile identifiers with identical 8 LSBs should be
assigned only if the higher-numbered one is intended to supersede the
lower-numbered one. To highlight this relationship, profile
identifiers should be given in hexadecimal (as in 0x1234, which would
for example supersede 0x0A34).

Following the policies outlined in [22], the IANA policy for
assigning new values for the profile identifier shall be
Specification Required: values and their meanings must be documented
in an RFC or in some other permanent and readily available reference,
in sufficient detail that interoperability between independent
implementations is possible. In the 8 LSBs, the range 0 to 127 is
reserved for IETF standard-track specifications; the range 128 to 254
is available for other specifications that meet this requirement
(such as Informational RFCs). The LSB value 255 is reserved for
future extensibility of the present specification.

New profiles will need new identifiers to be assigned by the IANA,
but this document does not require any additional IANA action.

Jonsson, et al. Standards Track [Page 34]

RFC 4995 The ROHC Framework July 2007
9. Acknowledgments

The authors would like to acknowledge all who have contributed to
previous ROHC work, and especially to the authors of RFC 3095 [3],
which is the technical basis for this document. Thanks also to the
various individuals who contributed to the RFC 3095 corrections and
clarifications document [6], from which technical contents, when
applicable, have been incorporated into this document. Committed WG
document reviewers were Carl Knutsson and Biplab Sarkar, who reviewed
the document during working group last-call.

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
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 any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.