RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
draft-sandlund-rfc4996bis-02

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

(Martin Stiemerling; former steering group member) Yes

(Wesley Eddy; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Barry Leiba; former steering group member) No Objection

(Benoît Claise; former steering group member) No Objection

(Brian Haberman; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) No Objection

(Pete Resnick; former steering group member) No Objection

(Ralph Droms; former steering group member) No Objection

(Robert Sparks; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Sean Turner; former steering group member) No Objection

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

(Stephen Farrell; former steering group member) No Objection

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

(Stewart Bryant; former steering group member) No Objection

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.

(Russ Housley; former steering group member) (was Discuss) Abstain

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.