Operational Management of Loop-Free Alternates
draft-ietf-rtgwg-lfa-manageability-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-06-24
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-06-17
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-06-07
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2016-06-03
|
11 | (System) | RFC Editor state changed to AUTH from EDIT |
2016-05-10
|
11 | (System) | RFC Editor state changed to EDIT from MISSREF |
2016-02-01
|
Naveen Khan | Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-rtgwg-lfa-manageability | |
2015-10-14
|
11 | (System) | Notify list changed from "Jeff Tantsura" to (None) |
2015-07-12
|
11 | Alexey Melnikov | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Alexey Melnikov. |
2015-06-30
|
11 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-06-30
|
11 | (System) | RFC Editor state changed to MISSREF |
2015-06-30
|
11 | (System) | Announcement was received by RFC Editor |
2015-06-29
|
11 | (System) | IANA Action state changed to No IC from In Progress |
2015-06-29
|
11 | (System) | IANA Action state changed to In Progress |
2015-06-29
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-06-29
|
11 | Amy Vezza | IESG has approved the document |
2015-06-29
|
11 | Amy Vezza | Closed "Approve" ballot |
2015-06-29
|
11 | Amy Vezza | Ballot approval text was generated |
2015-06-25
|
11 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2015-06-25
|
11 | Jari Arkko | [Ballot comment] Alexey Melnikov's Gen-ART review comments were worth considering. |
2015-06-25
|
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-06-25
|
11 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-11.txt |
2015-06-25
|
10 | Stephane Litkowski | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-06-25
|
10 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-10.txt |
2015-06-25
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-06-24
|
09 | Joel Jaeggli | [Ballot comment] Ron Bonica's Opsdir review. Folks, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents … [Ballot comment] Ron Bonica's Opsdir review. Folks, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document is on the Standards Track. It provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. The document is well-written and nearly ready for publication. Major Issues ---------------- None Minor Issues --------------- - Please run this document through the NIT checker and address the NITS - I am not sure how the sitting IESG feels about the use of lowercase "must", "should" and "may". You may want to check this before the IESG review. Ron Bonica --- example that I would cite as good to all caps 6.1 ... o Per prefixes: prefix protection SHOULD have a better priority compared to interface protection. This means that if a specific prefix must be protected due to a configuration request, LFA must be computed and installed for this prefix even if the primary outgoing interface is not configured for protection. LFA MUST since it's a requirement in most other cases I see a lower cast must what is being described is the logic that draws you to a conclusion, and those are ok. |
2015-06-24
|
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-06-24
|
09 | Deborah Brungard | [Ballot comment] Similar to others, I find the readability/English poor. I think it will be too much for the RFC Editor and the RFC Editor … [Ballot comment] Similar to others, I find the readability/English poor. I think it will be too much for the RFC Editor and the RFC Editor will not catch some of these errors e.g.: - 6.2.4.1 SRLG "preference system" - 6.2.4.2 "Link coloring is a powerful system" I would say (similar to Alvaro's comment on "alert system"), it's not a "system". A better wording would be "technique" or "method". Agree with others, a proof reading pass is really needed. |
2015-06-24
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-06-24
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-06-24
|
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-06-23
|
09 | Ben Campbell | [Ballot comment] I've got nothing that rises to the level of a discuss, but I do have a few comments: *** Substantive Comments: *** -- … [Ballot comment] I've got nothing that rises to the level of a discuss, but I do have a few comments: *** Substantive Comments: *** -- section 4, last paragraph: This is an odd thing to make normative. It seems more a question of business and ecosystem decisions. -- 6.2.4.2: Can you explain the "color" metaphor, or reference an explanation? -- 8: The entirety of the security considerations are of the form of "No new considerations compared to [RFC5286]". Please offer supporting arguments for that. For example, a high-level description of the nature of the changes, new behaviors, or clarifications introduced in this draft, and how those do or do not impact the security considerations. *** Editorial Comments: *** -- General: There are pervasive grammatical errors, especially incorrect use of singular and plural forms, missing articles, and incorrect use of commas. The RFC editor will fix these, but you could save them quite a bit of work by making another proofreading pass. Also, throughout the draft, there are lists of examples in the form of ":A,B,C...". I suggest using the form "A,B,C etc.", or even better "For example , A, B, and C" or "e.g., A, B, and C" -- section 2, first bullet: Last sentence is a fragment. -- 3.1, last paragraph: This seems to say that, in addition to the technical issues mentioned here, service providers simply might not like it. Is that really what you mean to say? -- 4, last bullet: Missing "to" . Otherwise, this renders to "... may be able monitor constantly..." -- 5, first paragraph: "As all FRR mechanism, ..." I think there's one or more missing words. Do you mean "As [in/for] all other FRR mechanisms, ..."? "Depending of the hardware..." s/of/on '... compared to the amount of destinations in RIB." I suggest " ... compared to the number of destinations in the RIB." -- 2nd paragraph " ... permit to compute ... " "Permit" needs a direct object. That is "... permits [something] to compute...". What is the something? (Note: This construction appears several times) -- 6.1, first paragraph: "The granularity of LFA activation should be controlled ..." -- 6.1, last bullet in first list: "... SHOULD have a better priority ... " s/better/higher -- 6.2, item 3 in the numbered list: "... an implementation SHOULD pick only one based on its own decision, as a default behavior." A "default behavior" implies that people might make non-default choices. I suggest striking the phrase", as a default behavior". I'm not sure what that means. -- 2nd paragraph: " ... following criteria:" I suggest s/criteria/granularities (Note: I see quite a bit of the use of the word "criteria" when I think you mean something else. ) -- 6.2.3: What does "enhanced criteria" mean? Also the word "Downstreamness" seems a bit of a stretch, but if the RFC editor lets that get by then more power to you :-) -- 6.2.4.1: Please expand SRLG on first mention. -- 6.2.5.4: 5th paragraph "... it is needed to limit..." perhaps "... implementations need to limit..." -- 9 and 10: Section 9 is out of place (should probably go right before references), and 10 is empty. |
2015-06-23
|
09 | Ben Campbell | Ballot comment text updated for Ben Campbell |
2015-06-23
|
09 | Ben Campbell | [Ballot comment] I've got nothing that rises to the level of a discuss, but I do have a few comments: *** Substantive Comments: *** -- … [Ballot comment] I've got nothing that rises to the level of a discuss, but I do have a few comments: *** Substantive Comments: *** -- section 4, last paragraph: This is an odd thing to make normative. It seems more a question of business and ecosystem decisions. -- 6.2.4.2: Can you explain the "color" metaphor, or reference an explanation? -- 8: The entirety of the security considerations are of the form of "No new considerations compared to [RFC5286]". Please offer supporting arguments for that. For example, a high-level description of the nature of the changes, new behaviors, or clarifications introduced in this draft, and how those do or do not impact the security considerations. *** Editorial Comments: *** -- General: There are pervasive grammatical errors, especially incorrect use of singular and plural forms, missing articles, and incorrect use of commas. The RFC editor will fix these, but you could save them quite a bit of work by making another proofreading pass. Also, throughout the draft, there are lists of examples in the form of ":A,B,C...". I suggest using the form "A,B,C etc.", or even better "For example , A, B, and C" or "e.g., A, B, and C" -- section 2, first bullet: Last sentence is a fragment. -- 3.1, last paragraph: This seems to say that, in addition to the technical issues mentioned here, service providers simply might not like it. Is that really what you mean to say? -- 4, last bullet: Missing "to" . Otherwise, this renders to "... may be able monitor constantly..." -- 5, first paragraph: "As all FRR mechanism, ..." I think there's one or more missing words. Do you mean "As [in/for] all other FRR mechanisms, ..."? "Depending of the hardware..." s/of/on '... compared to the amount of destinations in RIB." I suggest " ... compared to the number of destinations in the RIB." -- 2nd paragraph " ... permit to compute ... " "Permit" needs a direct object. That is "... permits [something] to compute...". What is the something? (Note: This construction appears several times) -- 6.1, first paragraph: "The granularity of LFA activation should be controlled ..." -- 6.1, last bullet in first list: "... SHOULD have a better priority ... " s/better/higher -- 6.2, item 3 in the numbered list: "... an implementation SHOULD pick only one based on its own decision, as a default behavior." A "default behavior" implies that people might make non-default choices. I suggest striking the phrase", as a default behavior". I'm not sure what that means. -- 2nd paragraph: " ... following criteria:" I suggest s/criteria/granularities (Note: I see quite a bit of the use of the word "criteria" when I think you mean something else. ) -- 6.2.3: What does "enhanced criteria" mean? Also the word "Downstreamness" seems a bit of a stretch, but if the RFC editor lets that get by then more power to you :-) -- 6.2.4.1: Please expand SRLG on first mention. -- 6.2.5.4: 5th paragraph "... it is needed to limit..." perhaps "... implementations need to limit..." -- 9 and 10: Section 9 is out of place (should probably go right before references), and 10 is empty. |
2015-06-23
|
09 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-06-23
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Ron Bonica. |
2015-06-22
|
09 | Barry Leiba | [Ballot comment] I only have a few editorial things to add: -- Section 4 -- Implementers SHOULD document their LFA selection algorithms (default … [Ballot comment] I only have a few editorial things to add: -- Section 4 -- Implementers SHOULD document their LFA selection algorithms (default and tuning options) in order to leave possibility for 3rd party modules to model these policy-LFA expressions. I'm not going to whine about this *too* much, but I don't see this as an appropriate use of 2119 key words. I'd be happier if it were changed to not be a 2119 word. That said, there's no need for discussion. Do as you think best. -- Section 6.2 -- 3. If the defined policy does not permit to determine a unique best LFA, The wording here is really awkward English. The verb "permit" needs a direct object here, as in "does not permit to determine ." You can't just omit the . The easiest fix is to change "to determine" to "the determination of". (I would also use "allow" rather than "permit", but that's just a personal wording preference.) -- Section 6.2.4.1 -- When SRLG protection is computed, and implementation SHOULD permit to Same problem here as in 6.2, above, but because of the list the fix isn't as easy. First, "and" should be "an". Second, the fix should probably be like this: NEW When SRLG protection is computed, an implementation SHOULD permit the following: o Exclusion of alternates violating SRLG. o Maintenance of a preference system between alternates based on SRLG violations. [...etc...] END In the first sub-bullet, "Preference based on number of violation," both instances of "violation" should be "violations". -- Section 7.3 -- o MUST be able to display, for every prefixes, the primary next hop as well as the alternate next hop information. "prefixes" should be "prefix". -- Section 7.4 -- When you say "provide an alert system" here, I think you mean "provide an alert", or, perhaps better, "trigger an alert" or "generate an alert". Presumably, in order to do that, an alert system has to be available. But the point here is that you saying when specific alerts should be triggered/generated. |
2015-06-22
|
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-06-22
|
09 | Brian Haberman | [Ballot comment] I agree with Avaro's Comments #2 and #3. |
2015-06-22
|
09 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-06-22
|
09 | Alvaro Retana | [Ballot comment] 1. The abstract mentions a lot of things that this document covers: “provides operational feedback on LFA, highlights some limitations, and proposes a … [Ballot comment] 1. The abstract mentions a lot of things that this document covers: “provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.” The Introduction presents a quick guide to what some sections cover (good idea!), but not all sections are mentioned there. It would be nice to cover all the sections in the “document map” in the introduction. 2. In section 3.1 it may not be clear to all readers why P4 is not an LFA for P8. In all the other cases there is an explicit statement (a sentence or two) that explains and clarifies. 3. In Section 6.2.4.2 the document talks about signaling color information, it includes a set of requirements..and it reads “How signaling is done is out of scope of the document”, but then you go on and point to a specific solution. Even if there might be a high certainty that the solution you point at is moving on in the process, is good, should be used, etc.. I think this document would be better served by just defining the requirements (specially if you’re pointing at the solution as out of scope). You do the same in 6.2.4.4. 4. The IS-IS overload bit is mentioned in several places as important to consider. Are there similar considerations related to the use of the OSPF MaxLinkMetric or the R-bit? If so, please include them..if not, please explain why in the document. [BTW, there is no reference pointing to the OL bit.] |
2015-06-22
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-06-22
|
09 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-06-19
|
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-06-19
|
09 | Alia Atlas | The updated version addresses my AD review concerns. The improvements aren't technical changes, but since they are a bit more than merely editorial, I have … The updated version addresses my AD review concerns. The improvements aren't technical changes, but since they are a bit more than merely editorial, I have asked RTGWG to provide some quick reviews and I intend to hold the draft in AD followup until June 30, unless I hear back positively from RTGWG. |
2015-06-19
|
09 | Alia Atlas | IESG state changed to IESG Evaluation::AD Followup from Waiting for Writeup |
2015-06-19
|
09 | Stephane Litkowski | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-06-19
|
09 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-09.txt |
2015-06-18
|
08 | Alia Atlas | Ballot has been issued |
2015-06-18
|
08 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2015-06-18
|
08 | Alia Atlas | Created "Approve" ballot |
2015-06-18
|
08 | Alia Atlas | Ballot writeup was changed |
2015-06-18
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-06-18
|
08 | Pearl Liang | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-rtgwg-lfa-manageability-08, which is currently in Last Call, and has the following comments: We understand that, upon … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-rtgwg-lfa-manageability-08, 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. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2015-06-18
|
08 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Magnus Nystrom. |
2015-06-18
|
08 | Jeff Tantsura | Changed consensus to Yes from Unknown |
2015-06-18
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-06-11
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2015-06-11
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2015-06-08
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Ron Bonica |
2015-06-08
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Ron Bonica |
2015-06-05
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2015-06-05
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2015-06-04
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2015-06-04
|
08 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Operational management of Loop Free … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Operational management of Loop Free Alternates) to Proposed Standard The IESG has received a request from the Routing Area Working Group WG (rtgwg) to consider the following document: - 'Operational management of Loop Free Alternates' 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 2015-06-18. 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 Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2490/ https://datatracker.ietf.org/ipr/2196/ |
2015-06-04
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested::Revised I-D Needed |
2015-06-04
|
08 | Alia Atlas | Placed on agenda for telechat - 2015-06-25 |
2015-06-04
|
08 | Alia Atlas | Last call was requested |
2015-06-04
|
08 | Alia Atlas | Last call announcement was generated |
2015-06-04
|
08 | Alia Atlas | Ballot approval text was generated |
2015-06-04
|
08 | Alia Atlas | Concerns from my AD Review need to be addressed. |
2015-06-04
|
08 | Alia Atlas | IESG state changed to Last Call Requested::Revised I-D Needed from AD Evaluation |
2015-06-04
|
08 | Alia Atlas | IESG state changed to AD Evaluation from Publication Requested |
2015-05-20
|
08 | Alia Atlas | Ballot writeup was generated |
2015-05-04
|
08 | Jeff Tantsura | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The Intended Status is 'Proposed Standard'. The type of RFC is properly indicated in the title page header. This draft provides operational feedback on LFA, RFC286, (also Standards Track) document. (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 This draft provides operational feedback on LFA (RFC5286), highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. Working Group Summary This draft has been thoroughly discussed in the WG, very good feedback had been provided by SP and vendor community. The draft adoption and progress had received full support from the WG. All comments have been addressed. The draft is ready for publication. Document Quality There are existing implementations and multiple vendors have shown significant interest in the topic. Personnel Jeff Tantsura is the Document Shepherd. Alia Atlas is the Responsible Area Director. (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. The draft has been thoroughly reviewed by the Shepherd. All comments have been addressed. The draft is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (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. N/A (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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A (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. Yes. Every author has confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes. The authors have been asked (and they answered) on the WG list about IPR at every step of the process. There haven't been any concerns raised on the list. (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? The draft adoption and progress had received full support from the WG, As mentioned above, significant discussion (including several vendors and operators) has taken place on the list. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The state of other documents remains unchanged. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This draft has no action for IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (19) 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. N/A |
2015-05-04
|
08 | Jeff Tantsura | Responsible AD changed to Alia Atlas |
2015-05-04
|
08 | Jeff Tantsura | IESG state changed to Publication Requested |
2015-05-04
|
08 | Jeff Tantsura | IESG process started in state Publication Requested |
2015-05-04
|
08 | Jeff Tantsura | Tag Doc Shepherd Follow-up Underway cleared. |
2015-05-04
|
08 | Jeff Tantsura | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2015-05-04
|
08 | Jeff Tantsura | Changed document writeup |
2015-03-05
|
08 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-08.txt |
2015-01-26
|
07 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Hannes Gredler. |
2015-01-26
|
07 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Hannes Gredler |
2015-01-26
|
07 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Hannes Gredler |
2015-01-13
|
07 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-07.txt |
2015-01-11
|
06 | Jeff Tantsura | Tag Doc Shepherd Follow-up Underway set. |
2015-01-11
|
06 | Jeff Tantsura | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2015-01-06
|
06 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-06.txt |
2015-01-06
|
05 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-05.txt |
2014-12-26
|
04 | Jeff Tantsura | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2014-11-24
|
(System) | Posted related IPR disclosure: Juniper's Statement of IPR related to draft-ietf-rtgwg-lfa-manageability-04 | |
2014-11-12
|
04 | Alvaro Retana | Notification list changed to "Jeff Tantsura" <jeff.tantsura@ericsson.com> |
2014-11-12
|
04 | Alvaro Retana | Document shepherd changed to Jeff Tantsura |
2014-11-12
|
04 | Alvaro Retana | IETF WG state changed to In WG Last Call from WG Document |
2014-11-12
|
04 | Alvaro Retana | Intended Status changed to Proposed Standard from None |
2014-08-11
|
04 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-04.txt |
2014-02-12
|
03 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-03.txt |
2014-02-03
|
02 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-02.txt |
2014-01-22
|
01 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-01.txt |
2013-11-11
|
00 | Alvaro Retana | This document now replaces draft-litkowski-rtgwg-lfa-manageability instead of None |
2013-09-16
|
(System) | Posted related IPR disclosure: Cisco's Statement of IPR Related to draft-ietf-rtgwg-lfa-manageability-00 | |
2013-05-13
|
00 | Stephane Litkowski | New version available: draft-ietf-rtgwg-lfa-manageability-00.txt |