The Eifel Response Algorithm for TCP
RFC 4015

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

(Allison Mankin) (was No Objection) Yes

Comment (2004-05-27 for -)
No email
send info
Perhaps add Mark Allman with you to the reviewers (in the writeup), since his review in the 
WG was so significant?

(Jon Peterson) Yes

(Harald Alvestrand) No Objection

Comment (2004-05-27 for -)
No email
send info
I'm sure this is a beautiful algorithm.
But after reading the RFC, I still have no knowledge on whether or not I should be interested in adding this to my TCP implementation.
- Always?
- Only when I am in an environment where non-congestion loss is common?
- Only if I like having more code in my TCP?
- Other criteria?
This is not worth braking the progress of the document for. But I miss it.

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-05-24 for -)
No email
send info
In Section 2., the draft says:

   If the Eifel response algorithm is implemented at the TCP sender, it
   MUST be implemented together with a detection algorithm that is
   specified in an RFC.

Is there any expectation of specific RFC categories?

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

Comment (2004-05-26 for -)
No email
send info
  In the security considerations, we learn that the Eifel
  response algorithm SHOULD only be run together with detection
  algorithms that are known to be safe against such "ACK spoofing
  attacks."  Are there other characteristics of detection algorithms
  that ought to be considered?  I would like to see the section 1
  list the characteristics of an "appropriate detection algorithm."

(David Kessens) No Objection

(Thomas Narten) (was Discuss, No Objection) No Objection

Comment (2004-05-27)
No email
send info
>    The Eifel response algorithm relies on a detection algorithm such as
>    the Eifel detection algorithm defined in [RFC3522]. That document
>    discusses the relevant background and motivation that also applies to
>    this document. Hence, the reader is expected to be familiar with
>    [RFC3522]. Note that alternative response algorithms have been

seems like a normative reference to 3522 (experimental). This text
itself seems to argue that the text is normative (i.e, by saying
"reader is expected to be familiar with"). Does this need to be
normative?

>       (DET)   This is a placeholder for a detection algorithm that must
>               be executed at this point. In case [RFC3522] is used as
>               the detection algorithm, steps (1) - (6) of that algorithm
>               go here.

What does this step do, in terms of what _this_ spec needs to know?
Does it produce a results that says "spurius retransmit detected,
execute step 7"? (that is kind of what I would think, since the
response would presumbaly only be executed when needed...) It would be
good to make this more clear.

(Bert Wijnen) No Objection

(Alex Zinin) No Objection