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