RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
RFC 6846

Note: This ballot was opened for revision 02 and is now closed.

(Wesley Eddy) Yes

(Martin Stiemerling) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-07-19)
No email
send info
As Sean says it would be useful to have the differences more visible at the front of the document. A forward reference in the Introduction would in my view be an acceptable way to achieve this.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-07-16)
No email
send info
- The new text in the intro, 2nd para, says something "must
be supported." Is that a 2119 MUST? If so, does it need to be
elsewhere as well if you're avoiding 2119 terms in the intro?
I didn't spot that when looking at the diff vs. 4996, so
where is the relevant 2119 language for that new(?) "must"?

- In the same intro text it might be better to s/may
not/cannot/ just to avoid 2119-like terms.

- In section 3, 2nd last para, you've taken out compression
of NULL-encrypted ESP headers (rfc 4303). Wouldn't it be nice
to call that out explicitly so that someone updating code
might more easily spot it without having to diff vs. RFC
4996? Similar comment on the list on p22 and p35. I realise
you point this out in 9.1, but it might be nice to also
note it in the places from which its been removed. (Note
that this is just a "nice-to-have" kind of comment, I've
no problem at all if you'd rather not change.)

(Brian Haberman) No Objection

Barry Leiba No Objection

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2012-07-17)
No email
send info
I think it would be better if the changes were nearer the front of the draft.  I suggest moving s9 to s1.1 (again this is only a suggestion).

(Russ Housley) (was Discuss) Abstain

Comment (2012-09-24)
No email
send info
I think this should be addressed, but there is no appetite to do so:

  The issue below is the same as the one raised in the Gen-ART Review
  by Joel Halpern on 16-July-2012.

  Section 5.2.2.2 on negative acknowledgments includes the following:
  >
  > ... unless it has confidence that information sent after the packet
  > being acknowledged already provides a suitable response ...
  >
  This deals with a specific response to the NACK, it is unclear what
  constitutes confidence.  Other places in this document that refer to
  gaining confidence provide specific descriptions of how it is gained.
  The primary methods for gaining confidence are receiving acks or
  sufficient transmissions.  If all that is meant here is sufficient
  transmissions, please say so.