RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite
draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06

[Ballot discuss]
The "inferred_ip_v6_length" encoding method compresses the payload
  length field of the IPv6 header down to a size of zero bits, i.e., no
  bits are transmitted in compressed headers for this field.  Using
  this encoding method, the decompressor infers the value of this field
  by counting in octets the length of the entire packet after
  decompression.

The document needs to say something about jumbograms (RFC 2675), because
they would set the payload size differently. Perhaps all that is needed
is an applicability statement that limits ROHC to links with MTU < 64K.

  Specifically, this document defines header compression schemes for:

  o RTP/UDP/IP      : profile 0x0101
  o UDP/IP          : profile 0x0102
  o ESP/IP          : profile 0x0103
  o IP              : profile 0x0104
  o RTP/UDP-Lite/IP : profile 0x0107
  o UDP-Lite/IP    : profile 0x0108

  ROHCv2 compresses the following type of extension headers:

  o  AH [RFC4302]
  o  GRE [RFC2784][RFC2890]
  o  MINE [RFC2004]
  o  IPv6 Destination Options header[RFC2460]
  o  IPv6 Hop-by-hop Options header[RFC2460]
  o  IPv6 Routing header [RFC2460].

Did you mean to say "This document also compresses the following
types of extension headers"? Otherwise I cannot parse what you are
saying here.

[Ballot discuss]
The "inferred_ip_v6_length" encoding method compresses the payload
  length field of the IPv6 header down to a size of zero bits, i.e., no
  bits are transmitted in compressed headers for this field.  Using
  this encoding method, the decompressor infers the value of this field
  by counting in octets the length of the entire packet after
  decompression.

The document needs to say something about jumbograms (RFC 2675), because
they would set the payload size differently. Perhaps all that is needed
is an applicability statement that limits ROHC to links with MTU < 64K.

  UNCOMPRESSED v6 {
    ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
    outer_headers    =:= baseheader_outer_headers    [ VARIABLE ];
    ip_version        =:= uncompressed_value(4, 6)    [  4 ];
    tos_tc                                            [  8 ];
    flow_label                                        [  20 ];
    payload_length    =:= inferred_ip_v6_length        [  16 ];
    next_header                                        [  8 ];
    ttl_hopl                                          [  8 ];
    src_addr                                          [ 128 ];
    dest_addr                                          [ 128 ];
    extension_headers =:= baseheader_extension_headers [ VARIABLE ];
    df    =:= uncompressed_value(0,0)                  [  0 ];
    ip_id =:= uncompressed_value(0,0)                  [  0 ];
  }

What are the last two fields doing in an IPv6 definition? I realize
they are 0 bits long, but still...

  Specifically, this document defines header compression schemes for:

  o RTP/UDP/IP      : profile 0x0101
  o UDP/IP          : profile 0x0102
  o ESP/IP          : profile 0x0103
  o IP              : profile 0x0104
  o RTP/UDP-Lite/IP : profile 0x0107
  o UDP-Lite/IP    : profile 0x0108

  ROHCv2 compresses the following type of extension headers:

  o  AH [RFC4302]
  o  GRE [RFC2784][RFC2890]
  o  MINE [RFC2004]
  o  IPv6 Destination Options header[RFC2460]
  o  IPv6 Hop-by-hop Options header[RFC2460]
  o  IPv6 Routing header [RFC2460].

Did you mean to say "This document also compresses the following
types of extension headers"? Otherwise I cannot parse what you are
saying here.

[Ballot discuss]
ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
  order or byte-swapped) to any IP-ID but the one in the innermost IP
  header, when compressing more than one level of IP headers.  This is
  because only the IP-ID of the innermost IP header is likely to have a
  sufficiently close correlation with the MSN to compress it as a
  sequentially changing field.  Therefore, a compressor MUST assign
  either the constant zero IP-ID or the random IP-ID behavior to
  tunneling headers.

The logic for this escapes me, can you clarify? What basis do we have
predict that any particular nesting level in the tunnel headers
correlates with the MSN?

  The "inferred_ip_v6_length" encoding method compresses the payload
  length field of the IPv6 header down to a size of zero bits, i.e., no
  bits are transmitted in compressed headers for this field.  Using
  this encoding method, the decompressor infers the value of this field
  by counting in octets the length of the entire packet after
  decompression.

The document needs to say something about jumbograms (RFC 2675), because
they would set the payload size differently. Perhaps all that is needed
is an applicability statement that limits ROHC to links with MTU < 64K.

  UNCOMPRESSED v6 {
    ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
    outer_headers    =:= baseheader_outer_headers    [ VARIABLE ];
    ip_version        =:= uncompressed_value(4, 6)    [  4 ];
    tos_tc                                            [  8 ];
    flow_label                                        [  20 ];
    payload_length    =:= inferred_ip_v6_length        [  16 ];
    next_header                                        [  8 ];
    ttl_hopl                                          [  8 ];
    src_addr                                          [ 128 ];
    dest_addr                                          [ 128 ];
    extension_headers =:= baseheader_extension_headers [ VARIABLE ];
    df    =:= uncompressed_value(0,0)                  [  0 ];
    ip_id =:= uncompressed_value(0,0)                  [  0 ];
  }

What are the last two fields doing in an IPv6 definition? I realize
they are 0 bits long, but still...

  Specifically, this document defines header compression schemes for:

  o RTP/UDP/IP      : profile 0x0101
  o UDP/IP          : profile 0x0102
  o ESP/IP          : profile 0x0103
  o IP              : profile 0x0104
  o RTP/UDP-Lite/IP : profile 0x0107
  o UDP-Lite/IP    : profile 0x0108

  ROHCv2 compresses the following type of extension headers:

  o  AH [RFC4302]
  o  GRE [RFC2784][RFC2890]
  o  MINE [RFC2004]
  o  IPv6 Destination Options header[RFC2460]
  o  IPv6 Hop-by-hop Options header[RFC2460]
  o  IPv6 Routing header [RFC2460].

Did you mean to say "This document also compresses the following
types of extension headers"? Otherwise I cannot parse what you are
saying here.

[Ballot discuss]
The ballot says:

  This specification defines a second version of the profiles found in
  RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
  does not obsolete them as ROHC can negotiate them.

I would like to talk about this on the call. Not obsoleting the old
profiles may be the right thing to do, but I am not convinced by the
argument above. We can obsolete specifications even if implementations
of them are still around and even if the old behaviour can be negotiated.
I see the obsoleted/not obsoleted status more as a guidance from the
IETF to the world on whether they should upgrade at some point.

  ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
  order or byte-swapped) to any IP-ID but the one in the innermost IP
  header, when compressing more than one level of IP headers.  This is
  because only the IP-ID of the innermost IP header is likely to have a
  sufficiently close correlation with the MSN to compress it as a
  sequentially changing field.  Therefore, a compressor MUST assign
  either the constant zero IP-ID or the random IP-ID behavior to
  tunneling headers.

The logic for this escapes me, can you clarify? What basis do we have
predict that any particular nesting level in the tunnel headers
correlates with the MSN?

  The "inferred_ip_v6_length" encoding method compresses the payload
  length field of the IPv6 header down to a size of zero bits, i.e., no
  bits are transmitted in compressed headers for this field.  Using
  this encoding method, the decompressor infers the value of this field
  by counting in octets the length of the entire packet after
  decompression.

The document needs to say something about jumbograms (RFC 2675), because
they would set the payload size differently. Perhaps all that is needed
is an applicability statement that limits ROHC to links with MTU < 64K.

  UNCOMPRESSED v6 {
    ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
    outer_headers    =:= baseheader_outer_headers    [ VARIABLE ];
    ip_version        =:= uncompressed_value(4, 6)    [  4 ];
    tos_tc                                            [  8 ];
    flow_label                                        [  20 ];
    payload_length    =:= inferred_ip_v6_length        [  16 ];
    next_header                                        [  8 ];
    ttl_hopl                                          [  8 ];
    src_addr                                          [ 128 ];
    dest_addr                                          [ 128 ];
    extension_headers =:= baseheader_extension_headers [ VARIABLE ];
    df    =:= uncompressed_value(0,0)                  [  0 ];
    ip_id =:= uncompressed_value(0,0)                  [  0 ];
  }

What are the last two fields doing in an IPv6 definition? I realize
they are 0 bits long, but still...

  Specifically, this document defines header compression schemes for:

  o RTP/UDP/IP      : profile 0x0101
  o UDP/IP          : profile 0x0102
  o ESP/IP          : profile 0x0103
  o IP              : profile 0x0104
  o RTP/UDP-Lite/IP : profile 0x0107
  o UDP-Lite/IP    : profile 0x0108

  ROHCv2 compresses the following type of extension headers:

  o  AH [RFC4302]
  o  GRE [RFC2784][RFC2890]
  o  MINE [RFC2004]
  o  IPv6 Destination Options header[RFC2460]
  o  IPv6 Hop-by-hop Options header[RFC2460]
  o  IPv6 Routing header [RFC2460].

Did you mean to say "This document also compresses the following
types of extension headers"? Otherwise I cannot parse what you are
saying here.

[Ballot discuss]
The ballot says:

  This specification defines a second version of the profiles found in
  RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
  does not obsolete them as ROHC can negotiate them.

I would like to talk about this on the call. Not obsoleting the old
profiles may be the right thing to do, but I am not convinced by the
argument above. We can obsolete specifications even if implementations
of them are still around and even if the old behaviour can be negotiated.
I see the obsoleted/not obsoleted status more as a guidance from the
IETF to the world on whether they should upgrade at some point.

  ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
  order or byte-swapped) to any IP-ID but the one in the innermost IP
  header, when compressing more than one level of IP headers.  This is
  because only the IP-ID of the innermost IP header is likely to have a
  sufficiently close correlation with the MSN to compress it as a
  sequentially changing field.  Therefore, a compressor MUST assign
  either the constant zero IP-ID or the random IP-ID behavior to
  tunneling headers.

The logic for this escapes me, can you clarify? What basis do we have
predict that any particular nesting level in the tunnel headers
correlates with the MSN?

  The "inferred_ip_v6_length" encoding method compresses the payload
  length field of the IPv6 header down to a size of zero bits, i.e., no
  bits are transmitted in compressed headers for this field.  Using
  this encoding method, the decompressor infers the value of this field
  by counting in octets the length of the entire packet after
  decompression.

The document needs to say something about jumbograms (RFC 2675), because
they would set the payload size differently. Perhaps all that is needed
is an applicability statement that limits ROHC to links with MTU < 64K.

  UNCOMPRESSED v6 {
    ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
    outer_headers    =:= baseheader_outer_headers    [ VARIABLE ];
    ip_version        =:= uncompressed_value(4, 6)    [  4 ];
    tos_tc                                            [  8 ];
    flow_label                                        [  20 ];
    payload_length    =:= inferred_ip_v6_length        [  16 ];
    next_header                                        [  8 ];
    ttl_hopl                                          [  8 ];
    src_addr                                          [ 128 ];
    dest_addr                                          [ 128 ];
    extension_headers =:= baseheader_extension_headers [ VARIABLE ];
    df    =:= uncompressed_value(0,0)                  [  0 ];
    ip_id =:= uncompressed_value(0,0)                  [  0 ];
  }

What are the last two fields doing in an IPv6 definition? I realize
they are 0 bits long, but still...

[Ballot discuss]
The ballot says:

  This specification defines a second version of the profiles found in
  RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
  does not obsolete them as ROHC can negotiate them.

I would like to talk about this on the call. Not obsoleting the old
profiles may be the right thing to do, but I am not convinced by the
argument above. We can obsolete specifications even if implementations
of them are still around and even if the old behaviour can be negotiated.
I see the obsoleted/not obsoleted status more as a guidance from the
IETF to the world on whether they should upgrade at some point.

  ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
  order or byte-swapped) to any IP-ID but the one in the innermost IP
  header, when compressing more than one level of IP headers.  This is
  because only the IP-ID of the innermost IP header is likely to have a
  sufficiently close correlation with the MSN to compress it as a
  sequentially changing field.  Therefore, a compressor MUST assign
  either the constant zero IP-ID or the random IP-ID behavior to
  tunneling headers.

The logic for this escapes me, can you clarify? What basis do we have
predict that any particular nesting level in the tunnel headers
correlates with the MSN?

  The "inferred_ip_v6_length" encoding method compresses the payload
  length field of the IPv6 header down to a size of zero bits, i.e., no
  bits are transmitted in compressed headers for this field.  Using
  this encoding method, the decompressor infers the value of this field
  by counting in octets the length of the entire packet after
  decompression.

The document needs to say something about jumbograms (RFC 2675), because
they would set the payload size differently. Perhaps all that is needed
is an applicability statement that limits ROHC to links with MTU < 64K.

[Ballot discuss]
The ballot says:

  This specification defines a second version of the profiles found in
  RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
  does not obsolete them as ROHC can negotiate them.

I would like to talk about this on the call. Not obsoleting the old
profiles may be the right thing to do, but I am not convinced by the
argument above. We can obsolete specifications even if implementations
of them are still around and even if the old behaviour can be negotiated.
I see the obsoleted/not obsoleted status more as a guidance from the
IETF to the world on whether they should upgrade at some point.

  ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
  order or byte-swapped) to any IP-ID but the one in the innermost IP
  header, when compressing more than one level of IP headers.  This is
  because only the IP-ID of the innermost IP header is likely to have a
  sufficiently close correlation with the MSN to compress it as a
  sequentially changing field.  Therefore, a compressor MUST assign
  either the constant zero IP-ID or the random IP-ID behavior to
  tunneling headers.

The logic for this escapes me, can you clarify? What basis do we have
predict that any particular nesting level in the tunnel headers
correlates with the MSN?

[Ballot discuss]
The ballot says:

  This specification defines a second version of the profiles found in
  RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
  does not obsolete them as ROHC can negotiate them.

I would like to talk about this on the call. Not obsoleting the old
profiles may be the right thing to do, but I am not convinced by the
argument above. We can obsolete specifications even if implementations
of them are still around and even if the old behaviour can be negotiated.
I see the obsoleted/not obsoleted status more as a guidance from the
IETF to the world on whether they should upgrade at some point.

[Ballot discuss]
INTRODUCTION, paragraph 14:
> This specification defines a second version of the profiles found in
> RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but
> does not obsolete them.

  Discuss-discuss: I don't know what it means to supersede but not
  obsolete in terms of standards categories. Why aren't we obsoleting
  3095, for example, especially given the first paragraph in section
  4.2?

[Ballot discuss]
[This is a discuss discuss.  I am not requesting any change to the document at this point -
just background information.  I will clear or revise into an actionable discuss once I have a
better understanding of this point...]

Both RFC 3095 and RFC 4995 briefly mentioned the idea that rohc discourages
encryption of headers in their security considerations.  For eample, RFC 4995's
security considerations begin as follows:

  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.

This consideration was omitted from this document.  Are there aspects of the
rohcv2 profiles that mitigate this concern, or did the wg decide that this was
not a real security issue?

[Ballot discuss]
The security considerations text talks about corruption due to
malfunctioning/malicious header compressor/decompressor. As was
discovered in ROHCoIPsec work, that's not the only concern. Even if
the compressor and decompressor are working fine, and all packets
between the compressor and decompressor are integrity protected, an
attacker can still cause the decompressor to output a packet that
does not match the original (by selectively dropping and/or
reordering packets between between the compressor and
decompressor). Since this concern is clearly something ROHC adds to
the situation, it needs to be described.

From Stephen Kent's SecDir review:

The document does not have any comment or citation about why the
increased residual error rate is acceptable (when the IPv4 checksum
is removed, and replaced by 7-bit CRC).

[Ballot discuss]
[This is a discuss discuss.  I am not requesting any change to the document at this point -
just background information.  I will clear or revise into an actionable discuss once I have a
better understanding of this point...]

Both RFC 3095 and RFC 4995 briefly mentioned the idea that rohc discourages
encryption of headers in their security considderations.  For eample, RFC 4995's
security considerations begin as follows:

  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.

This consideration was omitted from this document.  Are there aspects of the
rohcv2 profiles that mitigate this concern, or did the wg decide that this was
not a real security issue?

[Ballot comment]
s6.9.2: s/lenght/length/

  s6.9.2: opt_len needs to specify how the value is encoded.

  s6.9.2.4: clock_resolution needs to specify how the value is encoded.
  What happens if the clock resolution is bigger than 255ms?

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in "RObust Header Compression (ROHC) Profile
Identifiers - per [RFC4995]" registry located at
http://www.iana.org/assignments/rohc-pro-ids

Profile Identifier Usage                  Reference
------------------ ---------------------- ---------
0x0101            ROHCv2 RTP [RFC-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt]
0x0102            ROHCv2 UDP [RFC-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt]
0x0103            ROHCv2 ESP [RFC-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt]
0x0104            ROHCv2 IP [RFC-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt]
0x0107            ROHCv2 RTP/UDP-Lite [RFC-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt]
0x0108            ROHCv2 UDP-Lite [RFC-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt]


NOTE:
The ID lists an older version of this registry (with outdated
references). These instructions are being IGNORED.

NOTE:
Due to how the registry allocations are performed, the editors are
proposing the registrations be ordered according to the value of the
last two digits of the of the Protocol Identifier. IANA has no problem
continuing that formatting.

We understand the above to be the only IANA Action for this
document.

Write-up for draft-ietf-rohc-rfc3095bis-rohcv2-profiles:

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Carl Knutsson (ROHC WG chair) is the Document Shepherd, has personally
verified this version of the document, and believes that it is ready
to forward to the IESG for publication.

(1.b)  Has the document had adequate review both from key WG members
      and from key non-WG members?  Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

This draft (and previous versions of the draft) have been well-discussed
on the ROHC mailing list by key WG members as well as persons connected
to 3GPP and 3GPP2 standard bodies. Four active WG participants have
provided comprehensive reviews as Committed Document Reviewers. Newer
WG members have also provided useful review to the document. The
Document Shepherd is confident with the depth and breadth of the reviews.

(1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

No concerns. The draft uses RFC4997 formal notation (FN). The ROHC FN
is somewhat complex, however a large portion of the FN code could be
reused from RFC4996 (ROHC-TCP) with improvements.

The document shepherd expects that the General Area Review Team would
review this document, but no additional review is required.


(1.d) Does the Document Shepherd have any specific concerns or issues
      with this document that the Responsible Area Director and/or the
      IESG should be aware of?  For example, perhaps he or she is
      uncomfortable with certain parts of the document, or has
      concerns whether there really is a need for it.  In any event,
      if the WG has discussed those issues and has indicated that it
      still wishes to advance the document, detail those concerns
      here. Has an IPR disclosure related to this document been
      filed. If so, please include a reference to the disclosure and
      summarize the WG discussion and conclusion on this issue.

The document shepherd does not have specific concerns or issues
with this document.

(1.e)  How solid is the WG consensus behind this document?  Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

The shepherd believes there is a clear WG consensus behind this
document.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

None that the shepherd is aware of.

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

The Document Shepherd has verified that the document satisfies all ID nits.

There are no additional formal review criteria that are applicable to this
document.

(1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state?  If such normative references exist, what is the
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

References are split into normative/informative. There is a
normative reference to the ROHC framework RFC4995. An error has been
found in RFC 4995 that makes piggybacking of feedback impossible.
This is not a key feature and a new draft has already been
created to replace or update RFC4995. Otherwise none pending.

(1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document?  If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries?  Are the IANA registries clearly identified?  If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations?  Does it suggested a
      reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  If the document
      describes an Expert Review process has Shepherd conferred with
      the Responsible Area Director so that the IESG can appoint the
      needed Expert during the IESG Evaluation?

The document has an IANA section, requesting registration of ROHC
profile identifiers for the new ROHCv2 profiles.

(1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

The Document Shepherd has checked and verified the formal notation
(RFC 4997) part of the document. The authors have used an inofficial
non-public automated checker as support to the work. There is however
no complete and publicly available automatic checker for the ROHC
formal notation, however all reviewers including the Document
Shepherd are confident that the formal notation part of the draft
is correct.

(1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup?


Technical Summary

  This document defines RObust Header Compression (ROHC) profiles
  for compression of IP, UDP/IP, ESP/IP, UDP-Lite/IP,
  RTP/UDP-Lite/IP and RTP/UDP/IP packets.

  They represent a second generation of profiles (ROHCv2) to the ROHC
  framework (RFC 4995). ROHCv2 profiles include a number of
  simplifications to the algorithms used to govern the behaviour of
  the compression endpoints. They are designed to efficiently and
  robustly handle long round-trip-times, packet loss and packet
  reordering over the ROHC channel.

  The ROHCv2 profiles supersede but do not obsolete the earlier
  generation of profiles specified in RFC3095, RFC3843 and RFC 4019.


Working Group Summary

  This document has been in the working group for roughly 18 months.
  The document originated from implementation experience gained with
  RFC 3095, from which implementers have outlined its complexity and
  the relevance of defining simpler profiles, as well as from the
  requirement and the need to introduce support against reordering
  between compression endpoints.

  These new profiles were first drafted as an individual submission,
  and the first draft was submitted to the WG in September 2006.
  Initially, there was a relatively large interest for the new
  profiles, but few technical reviews. Since May 2007, the active
  participation in the working group to this draft has accelerated
  and ultimately the document received several comprehensive reviews.
  The general design approach is similar as for ROHC-TCP (RFC 4997),
  and has not changed significantly since it was first introduced
  in the group. The WG have a consensus for the new profiles.

Document Quality

  The document has been reviewed by several individuals, with
  different perspectives and approaches to the reviews. The formal
  notation part was verified manually but also partly validated by
  automated tools.  During WG Last-Call, the document was reviewed by
  the committed WG reviewers Robert Finking, Haipeng Jin, Rohit Kapoor
  and Mark West.  In WG reviews and otherwise, feedback has been
  received from persons active in the ROHC WG as well as in 3GPP and
  3GPP2 standard bodies.

Personnel

  Authors are Kristofer Sandlund and Ghyslain Pelletier. The Document
  Shepherd for this draft is Carl Knutsson, and Magnus Westerlund
  is the responsible Area Director.