Bidirectional Forwarding Detection (BFD)
RFC 5880
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-01-21 |
11 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
2019-02-04 |
Jenny Bui | Posted related IPR disclosure: Juniper's Statement about IPR related to draft-ietf-bfd-base | |
2015-10-14 |
11 | (System) | Notify list changed from bfd-chairs@ietf.org, draft-ietf-bfd-base@ietf.org to (None) |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Alexey Melnikov |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the Yes position for Adrian Farrel |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Ross Callon |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2010-10-06 |
(System) | Posted related IPR disclosure: Tellabs Oy's Statement about IPR related to RFC 5880, RFC 5881, RFC 5882, RFC 5883, and RFC 5884 | |
2010-06-01 |
11 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2010-06-01 |
11 | Cindy Morgan | [Note]: 'RFC 5880' added by Cindy Morgan |
2010-06-01 |
11 | (System) | RFC published |
2010-03-30 |
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2010-03-30 |
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2010-03-30 |
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-03-30 |
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-03-23 |
11 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-03-23 |
11 | (System) | IANA Action state changed to In Progress |
2010-03-23 |
11 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-03-23 |
11 | Amy Vezza | IESG has approved the document |
2010-03-23 |
11 | Amy Vezza | Closed "Approve" ballot |
2010-03-23 |
11 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2010-03-21 |
11 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from No Objection by Adrian Farrel |
2010-03-21 |
11 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel |
2010-03-12 |
11 | Ross Callon | [Ballot Position Update] Position for Ross Callon has been changed to No Objection from Discuss by Ross Callon |
2010-02-04 |
(System) | Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-bfd-base-11 | |
2010-02-04 |
(System) | Posted related IPR disclosure: Cisco's Statement of IPR relating to draft-ietf-bfd-base-11 | |
2010-01-25 |
11 | Adrian Farrel | [Ballot discuss] This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross … [Ballot discuss] This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross notes in his Discuss. It appears that there are two related disclosures in the system https://datatracker.ietf.org/ipr/516/ (Nortel 2005-01-06) https://datatracker.ietf.org/ipr/1143/ (Juniper 2009-05-07) The first of these was in place when working group and IETF last calls were held, but does not appear to have been flagged. The second is more recent. It is my intention to pursue the disclosures Ross refers to and then to ensure that the WG and the wider community are consulted. |
2010-01-25 |
11 | Adrian Farrel | [Ballot discuss] This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross … [Ballot discuss] This Discuss is a place holder to ensure that process is completed with respect to all IPR disclosures not just those that Ross notes in his Discuss. It appears that there are two related disclosures in the system https://datatracker.ietf.org/ipr/516/ (Nortel 2005-01-06) https://datatracker.ietf.org/ipr/1143/ (Juniper 2009-05-07) The first of these was in place when working group and IETF last calls were held, but does not appear to have been flagged. The second is more recent. It is my intention to pursue the disclosures Ross refers to and then to ensure that the WG and the wider community are consulted. |
2010-01-25 |
11 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to Discuss from Yes by Adrian Farrel |
2010-01-25 |
11 | Ross Callon | [Ballot discuss] It is possible that there might be an IPR statement forthcoming. This discuss is just here until this is cleared up (one way … [Ballot discuss] It is possible that there might be an IPR statement forthcoming. This discuss is just here until this is cleared up (one way or another). |
2010-01-25 |
11 | Ross Callon | [Ballot Position Update] Position for Ross Callon has been changed to Discuss from Yes by Ross Callon |
2010-01-15 |
11 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded by Adrian Farrel |
2010-01-15 |
11 | Adrian Farrel | [Note]: 'Adrian has taken over as responsible AD to avoid a single company having an excessive presence with this I-D' added by Adrian Farrel |
2010-01-15 |
11 | Adrian Farrel | Responsible AD has been changed to Adrian Farrel from Ross Callon |
2010-01-15 |
11 | Pasi Eronen | [Ballot comment] |
2010-01-15 |
11 | Pasi Eronen | [Ballot discuss] The "secret-suffix" (or "append-only") method for authenticated MD5/SHA1 has known problems, and that's why most IETF protocols use HMAC. However, the security requirements … [Ballot discuss] The "secret-suffix" (or "append-only") method for authenticated MD5/SHA1 has known problems, and that's why most IETF protocols use HMAC. However, the security requirements for this protocol are rather unusual, since we're basically interested in "liveness" rather than authentication of some content (and loss of packets moves us to "down" state) -- so having a weak MAC construction could be acceptable (but there needs to be text describing why it was done this way). It would help if the security considerations section had slightly more text about the threats, and what threats are mitigated by the security mechanisms (authentication section and GTSM), and what threats still exist (this is probably quite obvious to the authors -- but in that case, writing it down should be easy). Also, the Echo function should be mentioned somewhere here. |
2010-01-15 |
11 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2010-01-14 |
11 | (System) | New version available: draft-ietf-bfd-base-11.txt |
2010-01-07 |
11 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2010-01-06 |
11 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov |
2010-01-05 |
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-01-05 |
10 | (System) | New version available: draft-ietf-bfd-base-10.txt |
2009-05-07 |
(System) | Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-bfd-base-08 | |
2009-04-08 |
11 | Alexey Melnikov | [Ballot discuss] Carrying over DISCUSS from Chris Newman: Section 4.2 If password is human enterred text string, you need to state a charset and any … [Ballot discuss] Carrying over DISCUSS from Chris Newman: Section 4.2 If password is human enterred text string, you need to state a charset and any sort of mandatory-to-implement preparation. BCP 18 mandates use of UTF-8 unless you request a variance (that we require a restart of IETF last call). We have two choices on the standards track for mandatory-to-implement preparation of human enterred text used for this sort of security purposes (e.g. SASLprep / RFC 4013 or Net-Unicode / RFC 5198). We do not have a BCP that requires preparation so I'm not going to hold a discuss over the preparation issue but I recommend you fix it. There is not likely to be a significant change to net unicode, but there may be a significant change to SASLprep in the future. However, SASLprep will have someone better interoperability for non-ASCII password characters. While you could make the password binary so charset issues do not apply, that's only reasonable if there's a way to bootstrap the binary password. If it really is human enterred, as it is with WEP and WPA, then the WPA approach (where it's a human enterred password rather than a human enterred hex string -- but some implementations found that user hostile and invented a non-interoperable string-to-key as a result) has proved to be more interoperable in practice, IMHO. Section 4.3, 4.4 You need to define the key management for these keys. Are they passwords configured by humans into config files? If so, the charset and canonicalization issues apply. |
2009-04-08 |
11 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov |
2009-03-20 |
11 | Ross Callon | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon |
2009-03-06 |
11 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2009-03-05 |
11 | Cullen Jennings | [Ballot comment] support Lars discuss |
2009-03-05 |
11 | Chris Newman | [Ballot discuss] Version 09 did not add new text to address the first issue (charset of password). New text was added about key management ruling … [Ballot discuss] Version 09 did not add new text to address the first issue (charset of password). New text was added about key management ruling it out-of-scope. That, by itself, is not sufficient for interoperability. If keys in an unspecified format which may or may not be textual, need to be provisioned in an unspecified fashion, I'm unsure how this will interoperate. 40-bit WEP took this approach and we got non-interoperable UIs on different platforms (some require 0x prefix, some support a text-to-binary on a password, some do not). --- Section 4.2 If password is human enterred text string, you need to state a charset and any sort of mandatory-to-implement preparation. BCP 18 mandates use of UTF-8 unless you request a variance (that we require a restart of IETF last call). We have two choices on the standards track for mandatory-to-implement preparation of human enterred text used for this sort of security purposes (e.g. SASLprep / RFC 4013 or Net-Unicode / RFC 5198). We do not have a BCP that requires preparation so I'm not going to hold a discuss over the preparation issue but I recommend you fix it. There is not likely to be a significant change to net unicode, but there may be a significant change to SASLprep in the future. However, SASLprep will have someone better interoperability for non-ASCII password characters. While you could make the password binary so charset issues do not apply, that's only reasonable if there's a way to bootstrap the binary password. If it really is human enterred, as it is with WEP and WPA, then the WPA approach (where it's a human enterred password rather than a human enterred hex string -- but some implementations found that user hostile and invented a non-interoperable string-to-key as a result) has proved to be more interoperable in practice, IMHO. Section 4.3, 4.4 You need to define the key management for these keys. Are they passwords configured by humans into config files? If so, the charset and canonicalization issues apply. |
2009-02-12 |
11 | Pasi Eronen | [Ballot discuss] The "secret-suffix" (or "append-only") method for authenticated MD5/SHA1 has known problems, and that's why most IETF protocols use HMAC. However, the security requirements … [Ballot discuss] The "secret-suffix" (or "append-only") method for authenticated MD5/SHA1 has known problems, and that's why most IETF protocols use HMAC. However, the security requirements for this protocol are rather unusual, since we're basically interested in "liveness" rather than authentication of some content (and loss of packets moves us to "down" state) -- so having a weak MAC construction could be acceptable (but there needs to be text describing why it was done this way). It would help if the security considerations section had slightly more text about the threats, and what threats are mitigated by the security mechanisms (authentication section and GTSM), and what threats still exist (this is probably quite obvious to the authors -- but in that case, writing it down should be easy). Also, the Echo function should be mentioned somewhere here. |
2009-02-12 |
11 | Pasi Eronen | [Ballot comment] In Section 8, values 9-31 (for diagnostic code) and 6-255 (for authentication types) should be marked as "unassigned", not "reserved". Section 8, the … [Ballot comment] In Section 8, values 9-31 (for diagnostic code) and 6-255 (for authentication types) should be marked as "unassigned", not "reserved". Section 8, the table of BFD Authentication Types still talks about diagnostic codes in the column header. Section 10.2: RFC 2434 has been obsoleted by 5226 |
2009-02-05 |
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-02-05 |
09 | (System) | New version available: draft-ietf-bfd-base-09.txt |
2008-06-05 |
11 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2008-06-05 |
11 | Pasi Eronen | [Ballot discuss] The "secret-suffix" (or "append-only") method for authenticated MD5/SHA1 has known problems, and that's why most IETF protocols use HMAC. However, the security requirements … [Ballot discuss] The "secret-suffix" (or "append-only") method for authenticated MD5/SHA1 has known problems, and that's why most IETF protocols use HMAC. However, the security requirements for this protocol are rather unusual, since we're basically interested in "liveness" rather than authentication of some content (and loss of packets moves us to "down" state) -- so having a weak MAC construction could be acceptable (but there needs to be text describing why it was done this way). It would help if the security considerations section had slightly more text about the threats, and what threats are mitigated by the security mechanisms (authentication section and GTSM), and what threats still exist (this is probably quite obvious to the authors -- but in that case, writing it down should be easy). Also, the Echo function should be mentioned somewhere here. The protocol has several fields where new values could be allocated in the future, but no description about how that's done (e.g. by IANA or otherwise) or what the requirements are (e.g. standards track or first come first served). From Alexey Melnikov's SecDir review: The document should explicitly say that the key for MD5 (SHA1) must be exactly 128 (160) bits (there's no padding or truncation) -- or if this is not true, describe how padding/truncation/whatever is done. |
2008-06-05 |
11 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-06-05 |
11 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-06-05 |
11 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-06-05 |
11 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-06-05 |
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2008-06-05 |
11 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2008-06-05 |
11 | Chris Newman | [Ballot discuss] Section 4.2 If password is human enterred text string, you need to state a charset and any sort of mandatory-to-implement preparation. BCP 18 … [Ballot discuss] Section 4.2 If password is human enterred text string, you need to state a charset and any sort of mandatory-to-implement preparation. BCP 18 mandates use of UTF-8 unless you request a variance (that we require a restart of IETF last call). We have two choices on the standards track for mandatory-to-implement preparation of human enterred text used for this sort of security purposes (e.g. SASLprep / RFC 4013 or Net-Unicode / RFC 5198). We do not have a BCP that requires preparation so I'm not going to hold a discuss over the preparation issue but I recommend you fix it. There is not likely to be a significant change to net unicode, but there may be a significant change to SASLprep in the future. However, SASLprep will have someone better interoperability for non-ASCII password characters. While you could make the password binary so charset issues do not apply, that's only reasonable if there's a way to bootstrap the binary password. If it really is human enterred, as it is with WEP and WPA, then the WPA approach (where it's a human enterred password rather than a human enterred hex string -- but some implementations found that user hostile and invented a non-interoperable string-to-key as a result) has proved to be more interoperable in practice, IMHO. Section 4.3, 4.4 You need to define the key management for these keys. Are they passwords configured by humans into config files? If so, the charset and canonicalization issues apply. |
2008-06-05 |
11 | Chris Newman | [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman |
2008-06-04 |
11 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-06-04 |
11 | Lars Eggert | [Ballot comment] INTRODUCTION, paragraph 10: > Comments on this draft should be directed to rtg-bfd@ietf.org. Remove this sentence. |
2008-06-04 |
11 | Lars Eggert | [Ballot discuss] Section 6.8.3., paragraph 0: > 6.8.3. Timer Manipulation DISCUSS: BFD is congestion-unresponsive, i.e., it doesn't react to loss by taking load … [Ballot discuss] Section 6.8.3., paragraph 0: > 6.8.3. Timer Manipulation DISCUSS: BFD is congestion-unresponsive, i.e., it doesn't react to loss by taking load off the path. For many uses of BFD, especially ones that it seems to have been specifically designed for, I don't have an issue with this approach. For example, using BFD to monitor liveness of directly adjacent routers connected through a single link can probably be safely achieved by configuring timers based on knowledge of the link capacity and delays, such that BFD will not consume significant resources. (An addition to the applicability text, by the way, that discusses guidelines for this configuration would be very helpful IMO.) But BFD aims to be a generic protocol to detect the liveness between components that can be connected via arbitrary means, over paths with many hops and unknown traffic loads. When used for such purposes, BFD cannot simply punt on congestion control (see RFC2914). I see two ways forward: significantly restrict the scope of applicability for BFD, or describe a scheme that adapts transmission intervals (= transmission rates) based on RTTs and loss rates. (After writing this, I saw Jari's DISCUSS and I realize we raise similar issues.) |
2008-06-04 |
11 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2008-06-04 |
11 | Russ Housley | [Ballot comment] The title page header should indicate that the intended status for this document: Proposed Standard. Section 4.3 says: > … [Ballot comment] The title page header should indicate that the intended status for this document: Proposed Standard. Section 4.3 says: > > Reserved > > This byte must be set to zero on transmit, and ignored on > receipt. > As Spencer Dawkins raised in his Gen-ART Review: s/must/MUST/ Section 6.6 includes: > > Note that this mechanism requires that the Detection Time negotiated > is greater than the round trip time between the two systems, or the > Poll mechanism will always fail. Enforcement of this requirement is > outside the scope of this specification. > Based on the discussion of the Gen-ART Review by Spencer Dawkins, it might be better to say "Enforcing the requirement to meet the constraint ...". |
2008-06-04 |
11 | Russ Housley | [Ballot discuss] IANA has questions: - Shouldn't you have a registry of Diagnostic codes (section 4.1)? - Shouldn't you have a registry of … [Ballot discuss] IANA has questions: - Shouldn't you have a registry of Diagnostic codes (section 4.1)? - Shouldn't you have a registry of Auth Types (section 4.1)? If the answer to both questions is "no," we understand this document to have NO IANA Actions. I'll clear this DISCUSS position when IANA's questions are resolved. |
2008-06-04 |
11 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2008-06-03 |
11 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Undefined by Lisa Dusseault |
2008-06-03 |
11 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to Undefined from No Objection by Lisa Dusseault |
2008-06-03 |
11 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2008-06-03 |
11 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-06-02 |
11 | David Ward | [Ballot Position Update] New position, Recuse, has been recorded by David Ward |
2008-06-01 |
11 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
2008-06-01 |
11 | Ross Callon | Ballot has been issued by Ross Callon |
2008-06-01 |
11 | Ross Callon | Created "Approve" ballot |
2008-06-01 |
11 | Ross Callon | Proto writeup by Dave Ward (as WG co-chair and author): 1. Have the chairs personally reviewed this version of the Internet Draft (ID), … Proto writeup by Dave Ward (as WG co-chair and author): 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes 2. Has the document had adequate review from both key WG members and key non-WG members? Yes. BT had brought together multiple vendors and implementors a year before publishing the docs to make sure every issue was cleared up and intention documented. Do you have any concerns about the depth or breadth of the reviews that have been performed? No. 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No concerns 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It represents strong consensus of a large group of implementors. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. No 7. Have the chairs verified that the document adheres to all of the ID Checklist items ? Yes 8. Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Yes, No 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary: BFD and the corollary documents define a mechanism for layer 3 forwarding plane failure detection. There are multiple modes (async, echo, demand) for different circumstances. One interesting aspect of BFD is that it has adaptive timers thus, parameters can be modified without tearing down adjacencies. In addition, the amount of BW and overhead incurred by the network and network nodes is completely under the control of the operator. * Working Group Summary There was no opposition to this document. * Protocol Quality The protocol is widely implemented and deployed and has become part of default deployments on the internet. The drafts reflect the lessons learned from the deployed and operation. |
2008-05-30 |
11 | Ross Callon | Telechat date was changed to 2008-06-05 from 2008-06-19 by Ross Callon |
2008-05-30 |
11 | Ross Callon | Telechat date was changed to 2008-06-19 from 2008-06-05 by Ross Callon |
2008-05-22 |
11 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Alexey Melnikov. |
2008-05-15 |
11 | Ross Callon | State Changes to IESG Evaluation from DNP-waiting for AD note by Ross Callon |
2008-05-15 |
11 | Ross Callon | State Changes to DNP-waiting for AD note from IESG Evaluation by Ross Callon |
2008-05-15 |
11 | Ross Callon | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon |
2008-05-15 |
11 | Ross Callon | Placed on agenda for telechat - 2008-06-05 by Ross Callon |
2008-05-07 |
11 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-05-02 |
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Alexey Melnikov |
2008-05-02 |
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Alexey Melnikov |
2008-05-01 |
11 | Amanda Baber | IANA Last Call comments: IANA has questions: - Shouldn't you have a registry of Diagnostic codes (section 4.1)? - Shouldn't you have a registry of … IANA Last Call comments: IANA has questions: - Shouldn't you have a registry of Diagnostic codes (section 4.1)? - Shouldn't you have a registry of Auth Types (section 4.1)? If the answer to both questions is "no," we understand this document to have NO IANA Actions. |
2008-04-23 |
11 | Cindy Morgan | Last call sent |
2008-04-23 |
11 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2008-04-23 |
11 | Ross Callon | Last Call was requested by Ross Callon |
2008-04-23 |
11 | Ross Callon | State Changes to Last Call Requested from Publication Requested by Ross Callon |
2008-04-23 |
11 | (System) | Ballot writeup text was added |
2008-04-23 |
11 | (System) | Last call text was added |
2008-04-23 |
11 | (System) | Ballot approval text was added |
2008-04-16 |
11 | Ross Callon | Draft Added by Ross Callon in state Publication Requested |
2008-03-24 |
08 | (System) | New version available: draft-ietf-bfd-base-08.txt |
2008-01-16 |
07 | (System) | New version available: draft-ietf-bfd-base-07.txt |
2007-03-07 |
06 | (System) | New version available: draft-ietf-bfd-base-06.txt |
2006-06-14 |
05 | (System) | New version available: draft-ietf-bfd-base-05.txt |
2005-10-24 |
04 | (System) | New version available: draft-ietf-bfd-base-04.txt |
2005-07-12 |
03 | (System) | New version available: draft-ietf-bfd-base-03.txt |
2005-03-22 |
02 | (System) | New version available: draft-ietf-bfd-base-02.txt |
2005-02-22 |
01 | (System) | New version available: draft-ietf-bfd-base-01.txt |
2005-01-06 |
(System) | Posted related IPR disclosure: Nortel Networks Statement about IPR claimed in draft-ietf-bfd-base | |
2004-07-13 |
00 | (System) | New version available: draft-ietf-bfd-base-00.txt |