Making Route Flap Damping Usable
draft-ietf-idr-rfd-usable-04
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-05-16
|
04 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-03-31
|
04 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-03-31
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-03-07
|
04 | Adrian Farrel | Shepherding AD changed to Alia Atlas |
2014-02-11
|
04 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-02-11
|
04 | (System) | RFC Editor state changed to EDIT |
2014-02-11
|
04 | (System) | Announcement was received by RFC Editor |
2014-02-10
|
04 | (System) | IANA Action state changed to No IC from In Progress |
2014-02-10
|
04 | (System) | IANA Action state changed to In Progress |
2014-02-10
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-02-10
|
04 | Amy Vezza | IESG has approved the document |
2014-02-10
|
04 | Amy Vezza | Closed "Approve" ballot |
2014-02-10
|
04 | Amy Vezza | Ballot approval text was generated |
2014-02-06
|
04 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2014-02-06
|
04 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2014-02-06
|
04 | Stewart Bryant | Ballot writeup was changed |
2014-02-06
|
04 | Barry Leiba | [Ballot comment] Moved to a comment... UPDATED after the IESG telechat: In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up … [Ballot comment] Moved to a comment... UPDATED after the IESG telechat: In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up what it was that I didn't understand, and in figuring out how to resolve it. Section 3 looks like general recommendations of default values, and Section 6 looks like it's telling everyone to use those default values. The combination is confusing because it appears at the same time to be specific to two vendors, and yet perhaps to tell other vendors what values to use. And I'm not sure what to do if I'm a new vendor aiming to support this. Section 3 needs to make it clear what the purpose of the table is -- the text that's there is too minimal for anyone to understand the intent. On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended: OLD (version -03) The following RFD parameters are common to all implementations. Some may be tuned by the operator, some not. NEW This table shows key parameters for RFD implementations, and lists some existing default settings for those parameters. Some may be tuned by the operator, some not. There is currently no consensus on a single set of default values. END The part of Section 6 that talks about default configurable parameters needs to make it clear that it's not talking just to Cisco and Juniper, and that it's not telling other vendors to use the specific values in Table 1 (and how could it, as the values differ between the two vendors listed). On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended: OLD (version -03) Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations SHOULD NOT change the default values in Table 1. NEW Default Configurable Parameters: In order not to break existing operational configurations, deployed BGP implementations SHOULD NOT change their default values for the parameters listed in Table 1. END |
2014-02-06
|
04 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to Abstain from Discuss |
2014-02-06
|
04 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2014-02-05
|
04 | Spencer Dawkins | [Ballot comment] Still No-Objection, but I support the Barry/Benoit Discusses. Looking back, I said that in previous e-mail on those Discusses but never added it … [Ballot comment] Still No-Objection, but I support the Barry/Benoit Discusses. Looking back, I said that in previous e-mail on those Discusses but never added it to my ballot position - sorry. |
2014-02-05
|
04 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2014-02-05
|
04 | Stewart Bryant | Telechat date has been changed to 2014-02-06 from 2013-10-10 |
2014-02-05
|
04 | Stewart Bryant | [Ballot comment] Benoit and Barry agree on the text change, so I am looking using Barry's proposed text. As far as I can see the … [Ballot comment] Benoit and Barry agree on the text change, so I am looking using Barry's proposed text. As far as I can see the text used by the authors is semantically equivalent and this is a matter of style, which is outside the DISCUSS criteria. Because I am unable to see the difference I am unable to explain the difference to the authors, and am therefore unwilling to force a text change on them. OLD (version -03) The following RFD parameters are common to all implementations. Some may be tuned by the operator, some not. NEW This table shows key parameters for RFD implementations, and lists some existing default settings for those parameters. Some may be tuned by the operator, some not. There is currently no consensus on a single set of default values. END The text in -04 actually says: "The following RFD parameters are common to all implementations. Some may be tuned by the operator, some not. There is currently no consensus on a single set of default values." The title of Table 1 is "Default RFD Paramaters of Juniper and Cisco" which were the implementations studied. ======= OLD (version -03) Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations SHOULD NOT change the default values in Table 1. NEW Default Configurable Parameters: In order not to break existing operational configurations, deployed BGP implementations SHOULD NOT change their default values for the parameters listed in Table 1. END The text in -04 says: "Default Configurable Parameters: In order not to break existing operational configurations, existing BGP implementations including, the examples in Table 1, SHOULD NOT change their default values." The only significant difference seems to be s/deployed/existing/ which are semantically the same and i/including, the examples in Table 1/ which is a subset of the statement requested by the discuss holders. |
2014-02-05
|
04 | Stewart Bryant | Ballot comment text updated for Stewart Bryant |
2013-10-15
|
04 | Benoît Claise | [Ballot discuss] See Barrry's DISCUSS for the latest proposed changes, as agreed during the IESG telechat; This would solve my DISCUSS. Below is my initial … [Ballot discuss] See Barrry's DISCUSS for the latest proposed changes, as agreed during the IESG telechat; This would solve my DISCUSS. Below is my initial DISCUSS text. Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations SHOULD NOT change the default values in Table 1. Table 1 mentions +-------------------------+----------+-------+---------+ | Parameter | Tunable? | Cisco | Juniper | +-------------------------+----------+-------+---------+ | Withdrawal | No | 1000 | 1000 | | Re-Advertisement | No | 0 | 1000 | It's fine to say that Cisco and Juniper SHOULD NOT change their default values, but you also have to say what another new vendor must be doing for the Re-Advertisment parameter. The choices are: 1. 0 as default value 2. 1000 as default value 3. 0 or 1000 as default value Let's not forget that this is a Standards Track document, to which all vendors want to be compliant. Proposal: Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations SHOULD NOT change the default values in Table 1. New implementations MUST select either 0 or 1000 for the Re-Advertisment parameter default value. |
2013-10-15
|
04 | Benoît Claise | Ballot discuss text updated for Benoit Claise |
2013-10-14
|
04 | Barry Leiba | [Ballot discuss] UPDATED after the IESG telechat: In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up what it was that … [Ballot discuss] UPDATED after the IESG telechat: In the telechat discussion, Joel's explanation and Adrian's analysis were significant in clearing up what it was that I didn't understand, and in figuring out how to resolve it. Section 3 looks like general recommendations of default values, and Section 6 looks like it's telling everyone to use those default values. The combination is confusing because it appears at the same time to be specific to two vendors, and yet perhaps to tell other vendors what values to use. And I'm not sure what to do if I'm a new vendor aiming to support this. Section 3 needs to make it clear what the purpose of the table is -- the text that's there is too minimal for anyone to understand the intent. On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended: OLD (version -03) The following RFD parameters are common to all implementations. Some may be tuned by the operator, some not. NEW This table shows key parameters for RFD implementations, and lists some existing default settings for those parameters. Some may be tuned by the operator, some not. There is currently no consensus on a single set of default values. END The part of Section 6 that talks about default configurable parameters needs to make it clear that it's not talking just to Cisco and Juniper, and that it's not telling other vendors to use the specific values in Table 1 (and how could it, as the values differ between the two vendors listed). On the telechat, we agreed that the following text is clear, and the RTG ADs thought it correctly reflects what's intended: OLD (version -03) Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations SHOULD NOT change the default values in Table 1. NEW Default Configurable Parameters: In order not to break existing operational configurations, deployed BGP implementations SHOULD NOT change their default values for the parameters listed in Table 1. END |
2013-10-14
|
04 | Barry Leiba | Ballot discuss text updated for Barry Leiba |
2013-10-10
|
04 | Randy Bush | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2013-10-10
|
04 | Randy Bush | New version available: draft-ietf-idr-rfd-usable-04.txt |
2013-10-10
|
03 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-10-10
|
03 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Ben Laurie. |
2013-10-10
|
03 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-10-09
|
03 | Joel Jaeggli | [Ballot comment] riff on benoit's comment Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations … [Ballot comment] riff on benoit's comment Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations SHOULD NOT change the default values in Table 1. This is what I'd call the phenomena of least surprise. e.g. don't change unspecifed (and therefore default values). I'd personally prefer that it say something like: Default Configurable Parameters: In order not to break existing operational configurations, existing BGP implementations inclusive of the examples in Table 1 SHOULD NOT change default values. other than that I'm an un-equivocal yes to this. |
2013-10-09
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-10-09
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-10-08
|
03 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-10-08
|
03 | Benoît Claise | [Ballot discuss] Along the same lines as Barrry's DISCUSS... Default Configurable Parameters: In order not to break existing operational configurations, BGP … [Ballot discuss] Along the same lines as Barrry's DISCUSS... Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations SHOULD NOT change the default values in Table 1. Table 1 mentions +-------------------------+----------+-------+---------+ | Parameter | Tunable? | Cisco | Juniper | +-------------------------+----------+-------+---------+ | Withdrawal | No | 1000 | 1000 | | Re-Advertisement | No | 0 | 1000 | It's fine to say that Cisco and Juniper SHOULD NOT change their default values, but you also have to say what another new vendor must be doing for the Re-Advertisment parameter. The choices are: 1. 0 as default value 2. 1000 as default value 3. 0 or 1000 as default value Let's not forget that this is a Standards Track document, to which all vendors want to be compliant. Proposal: Default Configurable Parameters: In order not to break existing operational configurations, BGP implementations SHOULD NOT change the default values in Table 1. New implementations MUST select either 0 or 1000 for the Re-Advertisment parameter default value. |
2013-10-08
|
03 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2013-10-08
|
03 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-10-08
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-10-07
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-10-07
|
03 | Sean Turner | [Ballot Position Update] New position, Yes, has been recorded for Sean Turner |
2013-10-07
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-10-04
|
03 | Barry Leiba | [Ballot discuss] This is surely an issue of my barely knowing how to spell BGP and RFD, much less fully understand them, and so perhaps … [Ballot discuss] This is surely an issue of my barely knowing how to spell BGP and RFD, much less fully understand them, and so perhaps this just requires a little education: 1. Where are the RFD parameters in Table 1 in Section 3 defined? Where can I find their meanings? They aren't mentioned in RFC 2439 (nor in 4271, but I didn't expect to find them there). The mao2002 and pelsser2011 references have similar tables, but also don't define these parameters. 2. Section 6 says that implementations SHOULD NOT change the default values in Table 1. But the default value for Re-Advertisement is vastly different, depending upon whether I get my router from Cisco or from Juniper. I don't understand what this SHOULD NOT is telling me. If I'm someone else building a router, am I supposed to use 0 for Re-Advertisement, or 1000? |
2013-10-04
|
03 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-10-04
|
03 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2013-10-03
|
03 | Ted Lemon | [Ballot comment] False flap attack? Groan. |
2013-10-03
|
03 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2013-10-03
|
03 | Ted Lemon | [Ballot comment] False flap attack? Ouch. |
2013-10-03
|
03 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-10-02
|
03 | Stewart Bryant | Ballot writeup was changed |
2013-10-01
|
03 | Stewart Bryant | Ballot writeup was changed |
2013-09-30
|
03 | Adrian Farrel | [Ballot comment] Thanks for this simple and sensible document. I'm an insufferable pedant :-( In Section 6 you say "The following changes are recommended" I … [Ballot comment] Thanks for this simple and sensible document. I'm an insufferable pedant :-( In Section 6 you say "The following changes are recommended" I don't think it matters whether these are changes or not. Maybe "The use of the following values is recommended." |
2013-09-30
|
03 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2013-09-30
|
03 | Stewart Bryant | Placed on agenda for telechat - 2013-10-10 |
2013-09-30
|
03 | Stewart Bryant | State changed to IESG Evaluation from Waiting for Writeup |
2013-09-30
|
03 | Stewart Bryant | Ballot has been issued |
2013-09-30
|
03 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2013-09-30
|
03 | Stewart Bryant | Created "Approve" ballot |
2013-09-30
|
03 | Stewart Bryant | Ballot writeup was changed |
2013-09-23
|
03 | (System) | State changed to Waiting for Writeup from In Last Call (ends 2013-09-23) |
2013-09-16
|
03 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2013-09-16
|
03 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-idr-rfd-usable-03, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-idr-rfd-usable-03, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication. If this assessment is not accurate, please respond as soon as possible. |
2013-09-06
|
03 | Vijay Gurbani | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Vijay Gurbani. |
2013-09-05
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2013-09-05
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2013-09-05
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2013-09-05
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ben Laurie |
2013-09-03
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-09-03
|
03 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Making Route Flap Damping Usable) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Making Route Flap Damping Usable) to Proposed Standard The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Making Route Flap Damping Usable' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-rfd-usable/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-09-03
|
03 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-09-02
|
03 | Stewart Bryant | Last call was requested |
2013-09-02
|
03 | Stewart Bryant | Ballot approval text was generated |
2013-09-02
|
03 | Stewart Bryant | Ballot writeup was generated |
2013-09-02
|
03 | Stewart Bryant | State changed to Last Call Requested from Publication Requested |
2013-09-02
|
03 | Stewart Bryant | Last call announcement was changed |
2013-09-02
|
03 | Stewart Bryant | Last call announcement was generated |
2013-08-21
|
03 | Cindy Morgan | (1)What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why? It modifies a proposed standard RFC2439 … (1)What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard Why? It modifies a proposed standard RFC2439. Is it proper? RFC2439 specifies an algorithm implemented in BGP for timing of error messages and retransmissions. Is this type of RFC indicated in the title page header? Yes. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: ------ BGP Route Flap damping seeks to reduce the BGP churn in routers. First described in operators forms (RIPE, [ripe178]) and RFC2430 it was harsh penalizing sites for being well-connected because topology riches amplified the number of updates. Therefore, many operators turned it off [ripe378]. However, now because new measurements f[plesser2011] indicates a different suppression hold (6000) BGP update rate can be reduced by 19%. Ripe, a European Operator forum, has endorse these new settings [ripe580]. The Japanese operators have reported their use of the new RFD and their desires for implementation [shishio-grow-isp-rfd-implement-survey]. Working Group Summary: --------- WG Group had consensus over the last call. During the last call, a suggestion for addition features was made. The chairs/WG suggested this would be a follow-on draft rather than an addition to the current draft. Document Quality: Existing implementation of RFD exist in Juniper and Cisco. Protocol deployments [shishio-grow-isp-rfd-implement-survey] found bugs which have been fixed. The Japanese operator and RIPE operator community have reviewed these documents, and the Japanese operator community given the response in [shishio-grow-isp-rfd-implement-survey]. Since these are changes to existing features with existing configurations, some of the features were tunable via configuration and some not (see table 1 in document). Since BGP configuration via MIB is not widely deployed, a specific MIB review or information model for this specific draft is not warranted. However, this draft will be added by the chairs to drafts to be examined by NM/OPS groups for BGP configuration. Personnel: Shepherd: Susan Hares (WG chair), AD: Stewart Bryant (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Reviewed of technical input: Read Draft, Grow draft, referenced documents (4)Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The Shepherd has read all referenced document. (5)Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Yes. It was looked at by 3 major BGP Communities: US, Japan, and Europe. (6)Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? This document may be followed up with a configuration drafts regarding this topic, but this is a good thing. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? IPR is unlikely, but authors have been (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure has been filed. (9) 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? Has anyone threatened an appeal or otherwise indicated extreme discomfort? The operator community seems to be active although silent on the list. Therefore, the document shepherd suggests the community is agreeable but silent. No indication of an appeal. (10) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). This nits have found something. However, it appears the ID-NITS are wrong. Boilerplate checks are not enough; this check needs to be thorough. (11)Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No MIB, no media talk, URI type reviews. (12) Have all references within this document been identified as either normative or informative? Yes – all references are normative or informative. (13) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No. (14)Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (15) Will publication of this document change the status of any existing RFCs? yes, it will limits suggested by RFC2439 (Modification) (16) IANA a. No considerations – The specification only changes implementation knobs. b. No new registries (17) No XML or BNF or MB (18) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. - not applicable [Note: Japan/US Time is why draft is 8/22 and write-up is 8/21.] |
2013-08-21
|
03 | Cindy Morgan | IESG process started in state Publication Requested |
2013-08-21
|
03 | Susan Hares | Changed document writeup |
2013-08-21
|
03 | Susan Hares | Changed document writeup |
2013-08-21
|
03 | Susan Hares | Changed consensus to Yes from Unknown |
2013-08-21
|
03 | Susan Hares | consensus call completed. Shepherd's write-up done. NITS in tracker are broken ID-HIDS problem. Expe |
2013-08-21
|
03 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2013-08-21
|
03 | Susan Hares | modifies a standard |
2013-08-21
|
03 | Susan Hares | Intended Status changed to Proposed Standard from None |
2013-08-21
|
03 | Susan Hares | Changed document writeup |
2013-08-21
|
03 | Randy Bush | New version available: draft-ietf-idr-rfd-usable-03.txt |
2013-03-13
|
02 | John Scudder | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2013-03-11
|
02 | Randy Bush | New version available: draft-ietf-idr-rfd-usable-02.txt |
2013-02-21
|
01 | Susan Hares | Changed shepherd to Susan Hares |
2012-12-17
|
01 | Randy Bush | New version available: draft-ietf-idr-rfd-usable-01.txt |
2012-06-18
|
00 | Randy Bush | New version available: draft-ietf-idr-rfd-usable-00.txt |