SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol
RFC 7053

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

(Spencer Dawkins) Yes

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

Comment (2013-09-11)
No email
send info
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.

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

Comment (2013-09-11)
No email
send info
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.

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Pete Resnick) No Objection

Comment (2013-09-10)
No email
send info
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.

(Sean Turner) No Objection