RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
draft-sandlund-rfc4996bis-02
Yes
(Martin Stiemerling)
(Wesley Eddy)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
Abstain
Note: This ballot was opened for revision 02 and is now closed.
Martin Stiemerling Former IESG member
Yes
Yes
()
Unknown
Wesley Eddy Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2012-07-17)
Unknown
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 IESG member
No Objection
No Objection
(2012-07-16)
Unknown
- 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 IESG member
No Objection
No Objection
(2012-07-19)
Unknown
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 IESG member
(was Discuss)
Abstain
Abstain
(2012-09-24)
Unknown
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.