The Eifel Response Algorithm for TCP
RFC 4015
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
06 | (System) | Notify list changed from <mankin@psg.com>, <jon.peterson@neustar.biz>,<Reiner.Ludwig@ericsson.com> to <mankin@psg.com>, <jon.peterson@neustar.biz> |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Thomas Narten |
|
2005-02-24
|
06 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2005-02-24
|
06 | Amy Vezza | [Note]: 'RFC 4015' added by Amy Vezza |
|
2005-02-18
|
06 | (System) | RFC published |
|
2004-10-08
|
06 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2004-10-07
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2004-10-07
|
06 | Amy Vezza | IESG has approved the document |
|
2004-10-07
|
06 | Amy Vezza | Closed "Approve" ballot |
|
2004-10-07
|
06 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2004-10-07
|
06 | Thomas Narten | [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Discuss by Thomas Narten |
|
2004-09-15
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2004-09-15
|
06 | (System) | New version available: draft-ietf-tsvwg-tcp-eifel-response-06.txt |
|
2004-05-28
|
06 | (System) | Removed from agenda for telechat - 2004-05-27 |
|
2004-05-27
|
06 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from Waiting for Writeup by Amy Vezza |
|
2004-05-27
|
06 | Thomas Narten | [Ballot discuss] > 5. IPR Considerations > > The IETF has been notified of intellectual property rights claimed in > regard to some … [Ballot discuss] > 5. IPR Considerations > > The IETF has been notified of intellectual property rights claimed in > regard to some or all of the specification contained in this > document. For more information consult the online list of claimed > rights at http://www.ietf.org/ipr. I didn't find an IPR statement for this document on the IETF web page. Is there actually IPR associated with this document? If not, the above statement presumably shouldn't be in the document. |
|
2004-05-27
|
06 | Thomas Narten | [Ballot Position Update] Position for Thomas Narten has been changed to Discuss from No Objection by Thomas Narten |
|
2004-05-27
|
06 | Thomas Narten | [Ballot comment] > The Eifel response algorithm relies on a detection algorithm such as > the Eifel detection algorithm defined in [RFC3522 … [Ballot comment] > 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. |
|
2004-05-27
|
06 | Thomas Narten | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten |
|
2004-05-27
|
06 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to Yes from No Objection by Allison Mankin |
|
2004-05-27
|
06 | Allison Mankin | [Ballot comment] Perhaps add Mark Allman with you to the reviewers (in the writeup), since his review in the WG was so significant? |
|
2004-05-27
|
06 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
|
2004-05-27
|
06 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
|
2004-05-27
|
06 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
|
2004-05-27
|
06 | Harald Alvestrand | [Ballot comment] I'm sure this is a beautiful algorithm. But after reading the RFC, I still have no knowledge on whether or not I should … [Ballot comment] 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. |
|
2004-05-27
|
06 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
|
2004-05-26
|
06 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
|
2004-05-26
|
06 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
|
2004-05-26
|
06 | Russ Housley | [Ballot comment] In the security considerations, we learn that the Eifel response algorithm SHOULD only be run together with detection algorithms that are … [Ballot comment] 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." |
|
2004-05-26
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
|
2004-05-26
|
06 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
|
2004-05-25
|
06 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin |
|
2004-05-24
|
06 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie |
|
2004-05-24
|
06 | Ted Hardie | [Ballot comment] In Section 2., the draft says: If the Eifel response algorithm is implemented at the TCP sender, it MUST be implemented … [Ballot comment] 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? |
|
2004-05-24
|
06 | Ted Hardie | [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie |
|
2004-05-24
|
06 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
|
2004-05-21
|
06 | Jon Peterson | Placed on agenda for telechat - 2004-05-27 by Jon Peterson |
|
2004-05-21
|
06 | Jon Peterson | [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson |
|
2004-05-21
|
06 | Jon Peterson | Ballot has been issued by Jon Peterson |
|
2004-05-21
|
06 | Jon Peterson | Created "Approve" ballot |
|
2004-05-06
|
06 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2004-04-22
|
06 | Amy Vezza | Last call sent |
|
2004-04-22
|
06 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2004-04-21
|
06 | Jon Peterson | Last Call was requested by Jon Peterson |
|
2004-04-21
|
06 | (System) | Ballot writeup text was added |
|
2004-04-21
|
06 | (System) | Last call text was added |
|
2004-04-21
|
06 | (System) | Ballot approval text was added |
|
2004-04-21
|
06 | Jon Peterson | State Changes to Last Call Requested from AD Evaluation by Jon Peterson |
|
2004-04-05
|
06 | Jon Peterson | State Changes to AD Evaluation from Publication Requested by Jon Peterson |
|
2004-04-05
|
06 | Jon Peterson | State Changes to Publication Requested from AD is watching by Jon Peterson |
|
2004-04-05
|
06 | Jon Peterson | [Note]: 'Responsible: Working Group' has been cleared by Jon Peterson |
|
2004-04-05
|
06 | Jon Peterson | State Change Notice email list have been change to <mankin@psg.com>, <jon.peterson@neustar.biz>,<Reiner.Ludwig@ericsson.com> from <mankin@psg.com>, <jon.peterson@neustar.biz> |
|
2004-04-05
|
06 | Jon Peterson | Intended Status has been changed to Proposed Standard from None |
|
2004-03-18
|
05 | (System) | New version available: draft-ietf-tsvwg-tcp-eifel-response-05.txt |
|
2003-10-30
|
04 | (System) | New version available: draft-ietf-tsvwg-tcp-eifel-response-04.txt |
|
2003-03-29
|
06 | Jon Peterson | Shepherding AD has been changed to Peterson, Jon from Bradner, Scott |
|
2003-03-04
|
03 | (System) | New version available: draft-ietf-tsvwg-tcp-eifel-response-03.txt |
|
2002-12-09
|
02 | (System) | New version available: draft-ietf-tsvwg-tcp-eifel-response-02.txt |
|
2002-11-04
|
01 | (System) | New version available: draft-ietf-tsvwg-tcp-eifel-response-01.txt |
|
2002-08-31
|
06 | Scott Bradner | Draft Added by sob |
|
2002-08-15
|
00 | (System) | New version available: draft-ietf-tsvwg-tcp-eifel-response-00.txt |