Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP)
RFC 5827

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

(Lars Eggert) Yes

Magnus Westerlund Yes

(Ron Bonica) No Objection

(Ralph Droms) (was Discuss, No Objection) No Objection

Comment (2010-01-12 for -)
No email
send info
I have cleared my Discuss.  The conversation with the authors has clarified that this specification is intended for experimentation without being "used in operational settings" (Mark Allman).  While I would have been happier with a brief note to this effect in the document itself, I'm not willing to hold up its publication over the issue.

(Adrian Farrel) (was Discuss, No Objection) No Objection

Comment (2010-01-12 for -)
No email
send info
I have reluctantly cleared my Discuss on this document as this sort of issue should not hold up publication. The Discuss position achieved the objective of causing discussion within the IESG and with one of the document authors, and I am now informed that the authors will not make any change to the document.

It seems to me unfortunate that the author is unwilling to include a simple statement that would make the purpose of the document more clear with respect to its Experimental status and with respect the working group's intentions for the protocol work in the future. This would also help the implementer decide between the various choices in the document.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Tim Polk) No Objection

Comment (2009-12-17 for -)
No email
send info
(1)

In sections 2.1 and 2.2 the text for evaluating the conditions is imprecise.  I suggest
the following edits to cover the case where one of (a) or (b) does not hold:

In 2.1

OLD
    When conditions (2.a) and (2.b) do not hold, the transport MUST NOT
    use Early Retransmit, but rather prefer the standard mechanisms,
    including Fast Retransmit and Limited Transmit.
NEW
    If either (or both) condition (2.a) or (2.b) does not hold, the transport MUST NOT
    use Early Retransmit, but rather prefer the standard mechanisms,
    including Fast Retransmit and Limited Transmit.

(There is almost certainly better wording, but hopefully this clarifies this issue.)

A similar fix is need in 2.2.

(2)

Intuitively, I understand that this algorithm should result in retransmission of outstanding
segments.  However, I could not actually find this statement anywhere.  The main audience
probably doesn't need its hand held here, but for the rest of us a clear statement would be
nice.

(Dan Romascanu) No Objection

Comment (2009-12-17 for -)
No email
send info
I agree with Adrian's DISCUSS and Ralph's COMMENT about the need to better define the conditions of the experiment, criteria to assess results, and operational impact of deployment in the Internet.

(Robert Sparks) No Objection