SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol
RFC 7053
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
(Martin Stiemerling; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I have no objection to the publication of this document. Curiously, after reading it I cam to enter this position and found two other ADs had already made the point I wanted to make. Clearly, if the receiver is a legacy implementation, it will ignore the I bit, and perhaps this is the point. Since this document updates 4960, the behaviour on receipt of the I bit becomes normative, so making the behaviour somewhat optional (via SHOULD) seems a good way to get off the hook. However, the wording in section 5.2 does leave this all a bit ambiguous.
(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
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
Section 5.2 invites the question: Why shouldn't the receiver delay and, more importantly, under what circumstances is it reasonable for the receiver to delay and when is it not reasonable? Might be handy to give some advice here.
(Richard Barnes; former steering group member) No Objection
I had the same reaction to Pete. Under what circumstances would the receiver choose to delay (i.e., not obey the SHOULD)? If none exist, then it should be a MUST.
(Sean Turner; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection