RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
draft-ietf-rohc-tcp-16

[Ballot comment]
While I think the description of what to do when ECN is present is probably sufficiently clear to
get the correct implementation, I did not understand the design rational as presented.  The
document says:

6.1.3.  Explicit Congestion Notification (ECN)

  When ECN [RFC3168] is used once on a flow, the ECN bits could change
  quite often.  ROHC-TCP maintains a control field in the context to
  indicate if ECN is used or not.  This control field is transmitted in
  the dynamic chain of the TCP header, and its value can be updated
  using specific compressed headers carrying a 7-bit CRC.

  When this control field indicates that ECN is being used, items of IP
  and TCP headers in the irregular chain include bits used for ECN.  To
  preserve octet-alignment, all of the TCP reserved bits are
  transmitted and, for outer IP headers, the entire TOS/TC field is
  included in the irregular chain.

  The design rationale behind this is the possible use of the "full-
  functionality option" of section 9.1 of [RFC3168].

Section 9.1 of RFC 3168 discusses how ECN interacts with IP tunnels.  The
two different behaviors are described there as: 

  The result is that there are two viable options for the behavior of
  ECN-capable connections over an IP tunnel, including IPsec tunnels:

      * A limited-functionality option in which ECN is preserved in the
        inner header, but disabled in the outer header.  The only
        mechanism available for signaling congestion occurring within
        the tunnel in this case is dropped packets.

      * A full-functionality option that supports ECN in both the inner
        and outer headers, and propagates congestion warnings from nodes
        within the tunnel to endpoints.:

Does the author intend to make a parallel here between ROHC and IP
tunnels, or is there an aspect of the design rational that needs further
discussion?

IANA Last Call Comments:

Action #1:
Upon approval of this document, the IANA will make the
following assignments in the "RObust Header Compression
(ROHC) Profile Identifiers "

registry located at http://www.iana.org/assignments/rohc-pro-ids

0x00006 ROHC TCP []
0xnnn06 Reserved []

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

PROTO Write-up

(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?

I (Lars-Erik Jonsson) am the Document Sheperd for this document,
and I have personally reviewed this version of the document, which
I believe is ready 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?

The document has been reviewed by both key WG members and by key non-
WG members, and I am 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!

(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.

No concerns!

(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?

There is strong consensus behind this document within the ROHC WG.

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

No!

(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?

I have reviewed the document, and believe it satisfies all criterias.

(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 pending
normative reference to the ROHC Framework, which has just passed IETF
last-call. There is also a pending normative reference to a companion
document, the ROHC Formal Notation, which is submitted along with
this document.

(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 appropriate IANA section, requesting registration
of a ROHC profile identifier for the profile it specifies.

(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?

Reviewers have confirmed the correctness of the formal specifications.

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



Technical Summary

  This document specifies a ROHC (RObust Header Compression) profile
  for compression of TCP/IP packets. The profile, called ROHC-TCP,
  provides efficient and robust compression of TCP headers, including
  frequently used TCP options such as SACK (Selective Acknowledgments)
  and Timestamps. ROHC-TCP works well when used over links with
  significant error rates and long round-trip times. For many
  bandwidth-limited links where header compression is essential, such
  characteristics are common.

Working Group Summary

  This document has been in the workings for several years. It first
  appeared as an official WG draft in January 2002, and has since then
  changed shape a couple of times. It has now been rather stable for a
  long time, it has been carefully reviewed by both the WG and
  externals, and there is WG consensus that the document should now be
  published as an RFC.

Document Quality

  The document has been both manually reviewed by several parties with
  different perspectives, and checked by automated tools. During WGLC,
  the document was reviewed by the committed WG reviewers Joe Touch
  and Ted Faber, as well as by Sally Floyd, who provided a review at
  the request of the Transport Area Directorate.
 
Personnel
       
  Document Sheperd for this document is Lars-Erik Jonsson, and Magnus
  Westerlund is the Responsible Area Director.