BGP Bestpath Selection Criteria Enhancement
draft-ietf-idr-bgp-bestpath-selection-criteria-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-01-10
|
12 | (System) | Document has expired |
2020-01-10
|
12 | (System) | IESG state changed to Dead from AD is watching |
2020-01-09
|
12 | Alvaro Retana | I am returning this document to the WG for further discussion. https://mailarchive.ietf.org/arch/msg/idr/gvMuPQQU29-5VLLLOiNJlYcAOK4 |
2020-01-09
|
12 | Alvaro Retana | Tags Awaiting Expert Review/Resolution of Issues Raised, Revised I-D Needed - Issue raised by AD, Other - see Comment Log set. |
2020-01-09
|
12 | Alvaro Retana | IETF WG state changed to WG Document from Submitted to IESG for Publication |
2020-01-09
|
12 | Alvaro Retana | I am returning this document to the WG for further discussion. https://mailarchive.ietf.org/arch/msg/idr/gvMuPQQU29-5VLLLOiNJlYcAOK4 |
2020-01-09
|
12 | Alvaro Retana | IESG state changed to AD is watching from AD Evaluation::Revised I-D Needed |
2019-07-17
|
12 | Alvaro Retana | === AD Review of draft-ietf-idr-bgp-bestpath-selection-criteria-12 === https://mailarchive.ietf.org/arch/msg/idr/85qTCgN4k6oAbSlKmpyi8stxZz0 |
2019-07-17
|
12 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-06-28
|
12 | Alvaro Retana | Notification list changed to Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com from Susan Hares <shares@ndzh.com> |
2019-06-28
|
12 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2019-06-07
|
12 | Susan Hares | Write-up-version: 2/24/2012 status: 6/7/2019 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (2) The … Write-up-version: 2/24/2012 status: 6/7/2019 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (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 specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. Working Group Summary The chairs/shepherds lost this draft. It was approved 9 years ago and there was not an implementation of the draft. Due to IDR multiple interoperable implementations, this draft is now resurfacing. One reminder was here: https://mailarchive.ietf.org/arch/msg/idr/yQKUi3SR3IPPPEWUzi2O55v6-v0 3 implementations: The implementation report is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Currently there are 3 separate implementations (Cisco IOS-XR, Cisco IOS-XE, and Juniper) The chairs announced announced at IETF 103, interim (replacing IETF 104 meeting), and IETF 105 regarding the 2 cisco implementations being counted as unique. The WG accepted this work. A question was indicated because it updates RFC4271 on the following: https://mailarchive.ietf.org/arch/msg/idr/okJNyUYoXgGc7tKun_QhUuy9GZ4 Initial Draft adoption: https://mailarchive.ietf.org/arch/msg/idr/mW8ALqoY0U-1KVaNNjgn-nSq3qQ WG LC: https://mailarchive.ietf.org/arch/msg/idr/VyT0mdLcbDaq4NZ-48Dnentn-b0 Document Quality Are there existing implementations of the protocol? 3 implementations: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Last Shepherd report: https://mailarchive.ietf.org/arch/msg/idr/erF9If0OABv-K4iQFZ3U01XmOI4 with follow up: https://mailarchive.ietf.org/arch/msg/idr/wr_SVGr30xvEmldqleSqqaHNnp8 Personnel original document shepherd: John Scudder current document Shepherd: Susan Hares responsible AD: Alvaro Retana (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. John Scudder worked on this draft 6 years ago, but got lost. Susan Hares sought out implementation reports (see email links), review, and finalized the shepherd's review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? A current routing directorate review has not been made of this draft due to its age. It will be sent through routing-directorate. The routing-directorate reviewer should be aware of the current implementations and if changes need to be made indicate how implementations need to change. (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. OPS directorate should review this draft as part of WG LC. It is implemented in 2 major vendors and deployed so the if OPS-DIR has issues, they should address how operators should handle it. (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 draft passed WG LC in 2009, but it has been waiting for implementations. The security section requirements since 2009 have been increased, so the shepherd requested additional changes to that section. These changes have been made in -12.txt version. Please note that the (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. Rajiv Asati https://mailarchive.ietf.org/arch/msg/idr/iqSdivHFPrFvdXyhN97gwjhWsZQ (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 Statements made. (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? Solid in 2009. As time goes on waiting for implementation reports, the memory of those days weakens. However, since 2 major vendors have implemented and deployed this RFC - the solid WG support from 2009 has been validated. (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.) Nope. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://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. Not needed. (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? All documents are read for advancement. One of the RFC reference requires additional comments since the IESG may be revewing draft-ietf-tunnel-encaps-12.txt at the same time as this draft. RFC5512 has been revised in draft-ietf-tunnel-encaps-12 due to a lack of implementation support for the BGP SAFI. draft-ietf-tunnel-encaps-12.txt will obsolete RFC5512. After the IESG approves the RFC publication, the IDR or BESS WG will prepare updates to a group of RFCs that depend on RFC5512. Since this draft is implemented with RFC5512 referenced, it is appropriate to publish it as provided by the -12.txt IDR alignment with IETF mantra of "rough consensus and running code" means that 2 implementations are required for publication. The same will be true of the updates of draft-ietf-tunnel-encaps-12.txt. I have tried to be detailed in this portion of the shepherd's report instead of brief. Please let me know if you have questions. (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 - see #14 for details. (16) Will publication of this document change the status of any existing RFCs? Yes - this is linked to an optional update to RFC4271. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? The RFC4271 is listed in the abstract. (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). No IANA considerations. (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. none required. (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. no automated changes. |
2019-06-07
|
12 | Susan Hares | Responsible AD changed to Alvaro Retana |
2019-06-07
|
12 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from Waiting for Implementation |
2019-06-07
|
12 | Susan Hares | IESG state changed to Publication Requested from I-D Exists |
2019-06-07
|
12 | Susan Hares | IESG process started in state Publication Requested |
2019-06-07
|
12 | Susan Hares | Changed consensus to Yes from Unknown |
2019-06-07
|
12 | Susan Hares | Intended Status changed to Proposed Standard from None |
2019-06-07
|
12 | Susan Hares | Tag Doc Shepherd Follow-up Underway cleared. |
2019-06-07
|
12 | Susan Hares | Write-up-version: 2/24/2012 status: 6/7/2019 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (2) The … Write-up-version: 2/24/2012 status: 6/7/2019 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (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 specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. Working Group Summary The chairs/shepherds lost this draft. It was approved 9 years ago and there was not an implementation of the draft. Due to IDR multiple interoperable implementations, this draft is now resurfacing. One reminder was here: https://mailarchive.ietf.org/arch/msg/idr/yQKUi3SR3IPPPEWUzi2O55v6-v0 3 implementations: The implementation report is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Currently there are 3 separate implementations (Cisco IOS-XR, Cisco IOS-XE, and Juniper) The chairs announced announced at IETF 103, interim (replacing IETF 104 meeting), and IETF 105 regarding the 2 cisco implementations being counted as unique. The WG accepted this work. A question was indicated because it updates RFC4271 on the following: https://mailarchive.ietf.org/arch/msg/idr/okJNyUYoXgGc7tKun_QhUuy9GZ4 Initial Draft adoption: https://mailarchive.ietf.org/arch/msg/idr/mW8ALqoY0U-1KVaNNjgn-nSq3qQ WG LC: https://mailarchive.ietf.org/arch/msg/idr/VyT0mdLcbDaq4NZ-48Dnentn-b0 Document Quality Are there existing implementations of the protocol? 3 implementations: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Last Shepherd report: https://mailarchive.ietf.org/arch/msg/idr/erF9If0OABv-K4iQFZ3U01XmOI4 with follow up: https://mailarchive.ietf.org/arch/msg/idr/wr_SVGr30xvEmldqleSqqaHNnp8 Personnel original document shepherd: John Scudder current document Shepherd: Susan Hares responsible AD: Alvaro Retana (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. John Scudder worked on this draft 6 years ago, but got lost. Susan Hares sought out implementation reports (see email links), review, and finalized the shepherd's review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? A current routing directorate review has not been made of this draft due to its age. It will be sent through routing-directorate. The routing-directorate reviewer should be aware of the current implementations and if changes need to be made indicate how implementations need to change. (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. OPS directorate should review this draft as part of WG LC. It is implemented in 2 major vendors and deployed so the if OPS-DIR has issues, they should address how operators should handle it. (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 draft passed WG LC in 2009, but it has been waiting for implementations. The security section requirements since 2009 have been increased, so the shepherd requested additional changes to that section. These changes have been made in -12.txt version. Please note that the (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. Rajiv Asati https://mailarchive.ietf.org/arch/msg/idr/iqSdivHFPrFvdXyhN97gwjhWsZQ (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 Statements made. (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? Solid in 2009. As time goes on waiting for implementation reports, the memory of those days weakens. However, since 2 major vendors have implemented and deployed this RFC - the solid WG support from 2009 has been validated. (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.) Nope. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://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. Not needed. (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? All documents are read for advancement. One of the RFC reference requires additional comments since the IESG may be revewing draft-ietf-tunnel-encaps-12.txt at the same time as this draft. RFC5512 has been revised in draft-ietf-tunnel-encaps-12 due to a lack of implementation support for the BGP SAFI. draft-ietf-tunnel-encaps-12.txt will obsolete RFC5512. After the IESG approves the RFC publication, the IDR or BESS WG will prepare updates to a group of RFCs that depend on RFC5512. Since this draft is implemented with RFC5512 referenced, it is appropriate to publish it as provided by the -12.txt IDR alignment with IETF mantra of "rough consensus and running code" means that 2 implementations are required for publication. The same will be true of the updates of draft-ietf-tunnel-encaps-12.txt. I have tried to be detailed in this portion of the shepherd's report instead of brief. Please let me know if you have questions. (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 - see #14 for details. (16) Will publication of this document change the status of any existing RFCs? Yes - this is linked to an optional update to RFC4271. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? The RFC4271 is listed in the abstract. (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). No IANA considerations. (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. none required. (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. no automated changes. |
2019-06-07
|
12 | Susan Hares | Write-up-version: 2/24/2012 status: 6/7/2019 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (2) The … Write-up-version: 2/24/2012 status: 6/7/2019 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (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 specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. Working Group Summary The chairs/shepherds lost this draft. It was approved 9 years ago and there was not an implementation of the draft. Due to IDR multiple interoperable implementations, this draft is now resurfacing. One reminder was here: https://mailarchive.ietf.org/arch/msg/idr/yQKUi3SR3IPPPEWUzi2O55v6-v0 3 implementations: The implementation report is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Currently there are 3 separate implementations (Cisco IOS-XR, Cisco IOS-XE, and Juniper) The chairs announced announced at IETF 103, interim (replacing IETF 104 meeting), and IETF 105 regarding the 2 cisco implementations being counted as unique. The WG accepted this work. A question was indicated because it updates RFC4271 on the following: https://mailarchive.ietf.org/arch/msg/idr/okJNyUYoXgGc7tKun_QhUuy9GZ4 Initial Draft adoption: https://mailarchive.ietf.org/arch/msg/idr/mW8ALqoY0U-1KVaNNjgn-nSq3qQ WG LC: https://mailarchive.ietf.org/arch/msg/idr/VyT0mdLcbDaq4NZ-48Dnentn-b0 Document Quality Are there existing implementations of the protocol? 3 implementations: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Last Shepherd report: https://mailarchive.ietf.org/arch/msg/idr/erF9If0OABv-K4iQFZ3U01XmOI4 with follow up: https://mailarchive.ietf.org/arch/msg/idr/wr_SVGr30xvEmldqleSqqaHNnp8 Personnel original document shepherd: John Scudder current document Shepherd: Susan Hares responsible AD: Alvaro Retana (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. John Scudder worked on this draft 6 years ago, but got lost. Susan Hares sought out implementation reports (see email links), review, and finalized the shepherd's review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? A current routing directorate review has not been made of this draft due to its age. It will be sent through routing-directorate. The routing-directorate reviewer should be aware of the current implementations, and if changes need to be made indicate how implementations need to change. (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. OPS directorate should review this draft as part of WG LC. It is implemented in 2 major vendors and deployed so the if OPS-DIR has issues, they should address how operators should handle it. (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 draft passed WG LC in 2009, but it has been waiting for implementations. The security section requirements since 2009 have been increased, so the shepherd requested additional changes to that section. These changes have been made in -12.txt version. Please note that the (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. Rajiv Asati https://mailarchive.ietf.org/arch/msg/idr/iqSdivHFPrFvdXyhN97gwjhWsZQ (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 Statements made. (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? Solid in 2009. As time goes on waiting for implementation reports, the memory of those days weakens. However, since 2 major vendors have implemented and deployed this RFC - the solid WG support from 2009 has been validated. (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.) Nope. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://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. Not needed. (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? All documents are read for advancement. The RFC5512 has been revised in draft-ietf-tunnel-encaps-12 due to a lack of implementation support for the BGP SAFI. draft-ietf-tunnel-encaps-12.txt will obsolete RFC5512. After the IESG approves the RFC publication, the IDR or BESS WG will prepare updates to a group of RFCs that depend on that RFC. Since this draft is implemented with RFC5512 referenced, it is appropriate to publish it as provided by the text. IDR alignment with IETF mantra of "rough consensus and running code" means that 2 implementations are required for publication. The same will be true of the updates of draft-ietf-tunnel-encaps-12.txt. I have tried to be detailed in this portion of the shepherd's report instead of brief. Please let me know if you have questions. (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 - see #14 for details. (16) Will publication of this document change the status of any existing RFCs? No. This only optionally augments the BGP next hop resolution in the base BGP specification (RFC4271) to active paths. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? The RFC4271 is listed in the abstract. (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). No IANA considerations. (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. none required. (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. no automated changes. |
2019-06-07
|
12 | Susan Hares | Write-up-version: 2/24/2012 status: 6/7/2019 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (2) The … Write-up-version: 2/24/2012 status: 6/7/2019 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (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 specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. Working Group Summary The chairs/shepherds lost this draft. It was approved 9 years ago and there was not an implementation of the draft. Due to IDR multiple interoperable implementations, this draft is now resurfacing. One reminder was here: https://mailarchive.ietf.org/arch/msg/idr/yQKUi3SR3IPPPEWUzi2O55v6-v0 3 implementations: The implementation report is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Currently there are 3 separate implementations (Cisco IOS-XR, Cisco IOS-XE, and Juniper) The chairs announced announced at IETF 103, interim (replacing IETF 104 meeting), and IETF 105 regarding the 2 cisco implementations being counted as unique. The WG accepted this work. A question was indicated because it updates RFC4271 on the following: https://mailarchive.ietf.org/arch/msg/idr/okJNyUYoXgGc7tKun_QhUuy9GZ4 Initial Draft adoption: https://mailarchive.ietf.org/arch/msg/idr/mW8ALqoY0U-1KVaNNjgn-nSq3qQ WG LC: https://mailarchive.ietf.org/arch/msg/idr/VyT0mdLcbDaq4NZ-48Dnentn-b0 Document Quality Are there existing implementations of the protocol? 3 implementations: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Last Shepherd report: https://mailarchive.ietf.org/arch/msg/idr/erF9If0OABv-K4iQFZ3U01XmOI4 with follow up: https://mailarchive.ietf.org/arch/msg/idr/wr_SVGr30xvEmldqleSqqaHNnp8 Personnel original document shepherd: John Scudder current document Shepherd: Susan Hares responsible AD: Alvaro Retana (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. John Scudder worked on this draft 6 years ago, but got lost. Susan Hares sought out implementation reports (see email links), review (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? A current routing directorate review has not been made of this draft due to its age. It will be sent through routing-directorate in October 2018. (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. OPS directorate should review this draft as part of WG LC. It is implemented in 2 major vendors and deployed so the if OPS-DIR has issues, they should address how operators should handle it. (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 draft passed WG LC in 2009, but it has been waiting for implementations. The security section requirements since 2009 have been increased, so the shepherd requested additional changes to that section. (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. [Susan Hares] have found no record of IPR statements for this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Rajiv Asati https://mailarchive.ietf.org/arch/msg/idr/iqSdivHFPrFvdXyhN97gwjhWsZQ (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? Solid in 2009. As time goes on waiting for implementation reports, the memory of those days weakens. However, since 2 major vendors have implemented and deployed this RFC - the solid WG support from 2009 has been validated. (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.) Nope. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://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. not needed. (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? The RFC5512 has been revised in draft-ietf-tunnel-encaps due to a lack of implementation support for the BGP SAFI. [add text after -12.txt is submitted, fix this portion] (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? No. This only optionally augments the BGP next hop resolution in the base BGP specification (RFC4271) to active paths. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? The RFC4271 is listed in the abstract. (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). No IANA considerations. (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. none required. (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. no automated changes. |
2019-06-05
|
12 | Rajiv Asati | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-12.txt |
2019-06-05
|
12 | (System) | New version approved |
2019-06-05
|
12 | (System) | Request for posting confirmation emailed to previous authors: Rajiv Asati |
2019-06-05
|
12 | Rajiv Asati | Uploaded new revision |
2019-06-04
|
11 | Susan Hares | Write-up-version: 2/24/2012 status: 6/3/2019 - awaiting version 12 with security section update, then fix section 14. (1) What type of RFC is being requested (BCP, … Write-up-version: 2/24/2012 status: 6/3/2019 - awaiting version 12 with security section update, then fix section 14. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (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 specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. Working Group Summary The chairs/shepherds lost this draft. It was approved 9 years ago and there was not an implementation of the draft. Due to IDR multiple interoperable implementations, this draft is now resurfacing. One reminder was here: https://mailarchive.ietf.org/arch/msg/idr/yQKUi3SR3IPPPEWUzi2O55v6-v0 3 implementations: The implementation report is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Currently there are 3 separate implementations (Cisco IOS-XR, Cisco IOS-XE, and Juniper) The chairs announced announced at IETF 103, interim (replacing IETF 104 meeting), and IETF 105 regarding the 2 cisco implementations being counted as unique. The WG accepted this work. A question was indicated because it updates RFC4271 on the following: https://mailarchive.ietf.org/arch/msg/idr/okJNyUYoXgGc7tKun_QhUuy9GZ4 Initial Draft adoption: https://mailarchive.ietf.org/arch/msg/idr/mW8ALqoY0U-1KVaNNjgn-nSq3qQ WG LC: https://mailarchive.ietf.org/arch/msg/idr/VyT0mdLcbDaq4NZ-48Dnentn-b0 Document Quality Are there existing implementations of the protocol? 3 implementations: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Last Shepherd report: https://mailarchive.ietf.org/arch/msg/idr/erF9If0OABv-K4iQFZ3U01XmOI4 with follow up: https://mailarchive.ietf.org/arch/msg/idr/wr_SVGr30xvEmldqleSqqaHNnp8 Personnel original document shepherd: John Scudder current document Shepherd: Susan Hares responsible AD: Alvaro Retana (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. John Scudder worked on this draft 6 years ago, but got lost. Susan Hares sought out implementation reports (see email links), review (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? A current routing directorate review has not been made of this draft due to its age. It will be sent through routing-directorate in October 2018. (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. OPS directorate should review this draft as part of WG LC. It is implemented in 2 major vendors and deployed so the if OPS-DIR has issues, they should address how operators should handle it. (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 draft passed WG LC in 2009, but it has been waiting for implementations. The security section requirements since 2009 have been increased, so the shepherd requested additional changes to that section. (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. [Susan Hares] have found no record of IPR statements for this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Rajiv Asati https://mailarchive.ietf.org/arch/msg/idr/iqSdivHFPrFvdXyhN97gwjhWsZQ (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? Solid in 2009. As time goes on waiting for implementation reports, the memory of those days weakens. However, since 2 major vendors have implemented and deployed this RFC - the solid WG support from 2009 has been validated. (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.) Nope. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://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. not needed. (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? The RFC5512 has been revised in draft-ietf-tunnel-encaps due to a lack of implementation support for the BGP SAFI. [add text after -12.txt is submitted, fix this portion] (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? No. This only optionally augments the BGP next hop resolution in the base BGP specification (RFC4271) to active paths. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? The RFC4271 is listed in the abstract. (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). No IANA considerations. (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. none required. (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. no automated changes. |
2019-06-04
|
11 | Susan Hares | Write-up-version: 2/24/2012 status: 6/3/2019 - awaiting version 12 with security section update, then fix section 14. (1) What type of RFC is being requested (BCP, … Write-up-version: 2/24/2012 status: 6/3/2019 - awaiting version 12 with security section update, then fix section 14. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (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 specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. Working Group Summary The chairs/shepherds lost this draft. It was approved 9 years ago and there was not an implementation of the draft. Due to IDR multiple interoperable implementations, this draft is now resurfacing. One reminder was here: https://mailarchive.ietf.org/arch/msg/idr/yQKUi3SR3IPPPEWUzi2O55v6-v0 3 implementations: The implementation report is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Currently there are 3 separate implementations (Cisco IOS-XR, Cisco IOS-XE, and Juniper) The chairs announced announced at IETF 103, interim (replacing IETF 104 meeting), and IETF 105 regarding the 2 cisco implementations being counted as unique. The WG accepted this work. A question was indicated because it updates RFC4271 on the following: https://mailarchive.ietf.org/arch/msg/idr/okJNyUYoXgGc7tKun_QhUuy9GZ4 Initial Draft adoption: https://mailarchive.ietf.org/arch/msg/idr/mW8ALqoY0U-1KVaNNjgn-nSq3qQ WG LC: https://mailarchive.ietf.org/arch/msg/idr/VyT0mdLcbDaq4NZ-48Dnentn-b0 Document Quality Are there existing implementations of the protocol? 3 implementations: https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Personnel original document shepherd: John Scudder current document Shepherd: Susan Hares responsible AD: Alvaro Retana (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. John Scudder worked on this draft 6 years ago, but got lost. Susan Hares sought out implementation reports (see email links), review (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? A current routing directorate review has not been made of this draft due to its age. It will be sent through routing-directorate in October 2018. (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. OPS directorate should review this draft as part of WG LC. It is implemented in 2 major vendors and deployed so the if OPS-DIR has issues, they should address how operators should handle it. (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 draft passed WG LC in 2009, but it has been waiting for implementations. The security section requirements since 2009 have been increased, so the shepherd requested additional changes to that section. (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. [Susan Hares] have found no record of IPR statements for this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Rajiv Asati https://mailarchive.ietf.org/arch/msg/idr/iqSdivHFPrFvdXyhN97gwjhWsZQ (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? Solid in 2009. As time goes on waiting for implementation reports, the memory of those days weakens. However, since 2 major vendors have implemented and deployed this RFC - the solid WG support from 2009 has been validated. (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.) Nope. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://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. not needed. (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? The RFC5512 has been revised in draft-ietf-tunnel-encaps due to a lack of implementation support for the BGP SAFI. [add text after -12.txt is submitted, fix this portion] (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? No. This only optionally augments the BGP next hop resolution in the base BGP specification (RFC4271) to active paths. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? The RFC4271 is listed in the abstract. (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). No IANA considerations. (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. none required. (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. no automated changes. |
2019-06-03
|
11 | Rajiv Asati | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-11.txt |
2019-06-03
|
11 | (System) | New version approved |
2019-06-03
|
11 | (System) | Request for posting confirmation emailed to previous authors: Rajiv Asati |
2019-06-03
|
11 | Rajiv Asati | Uploaded new revision |
2019-06-03
|
10 | Susan Hares | Write-up-version: 2/24/2012 status: 10/26/2018 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (2) The … Write-up-version: 2/24/2012 status: 10/26/2018 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard (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 specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. Working Group Summary The chairs/shepherds lost this draft. It was approved 9 years ago and there was not an implementation of the draft. One reminder was here: https://mailarchive.ietf.org/arch/msg/idr/yQKUi3SR3IPPPEWUzi2O55v6-v0 A question was indicated because it updates RFC4271 on the following: https://mailarchive.ietf.org/arch/msg/idr/okJNyUYoXgGc7tKun_QhUuy9GZ4 Initial Draft adoption: https://mailarchive.ietf.org/arch/msg/idr/mW8ALqoY0U-1KVaNNjgn-nSq3qQ WG LC: https://mailarchive.ietf.org/arch/msg/idr/VyT0mdLcbDaq4NZ-48Dnentn-b0 Document Quality Are there existing implementations of the protocol? https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-bestpath-selection-criteria Have a significant number of vendors indicated their plan to implement the specification? No Personnel original document shepherd: John Scudder current document Shepherd: Susan Hares responsible AD: Alvaro Retana (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. John Scudder worked on this draft 6 years ago, but got lost in a shpeher. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? A current routing directorate review has not been made of this draft due to its age. It will be sent through routing-directorate in October 2018. (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. BGP operators should review this draft. This draft will be sent to grows for a review. (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 draft passed WG LC in 2009, but it has been waiting for implementations. (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. [Susan Hares] have found no record of IPR statements for this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (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? (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.) (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (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? (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. (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. (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). (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. (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. |
2018-12-05
|
10 | Rajiv Asati | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-10.txt |
2018-12-05
|
10 | (System) | New version approved |
2018-12-05
|
10 | (System) | Request for posting confirmation emailed to previous authors: Rajiv Asati |
2018-12-05
|
10 | Rajiv Asati | Uploaded new revision |
2018-11-05
|
09 | Susan Hares | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-11-05
|
09 | Susan Hares | This draft awaits oline IPR statements and IPR calls. No implementations exists at this time. |
2018-11-05
|
09 | Susan Hares | Tags Revised I-D Needed - Issue raised by WGLC, Doc Shepherd Follow-up Underway set. |
2018-11-05
|
09 | Susan Hares | IETF WG state changed to Waiting for Implementation from WG Consensus: Waiting for Write-Up |
2018-11-05
|
09 | Susan Hares | Changed document writeup |
2018-10-21
|
09 | Susan Hares | Changed document writeup |
2018-10-04
|
09 | Susan Hares | Changed document writeup |
2018-10-04
|
09 | Susan Hares | Notification list changed to Susan Hares <shares@ndzh.com> |
2018-10-04
|
09 | Susan Hares | Document shepherd changed to Susan Hares |
2018-10-04
|
09 | Susan Hares | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-06-05
|
09 | Rajiv Asati | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-09.txt |
2018-06-05
|
09 | (System) | New version approved |
2018-06-05
|
09 | (System) | Request for posting confirmation emailed to previous authors: Rajiv Asati |
2018-06-05
|
09 | Rajiv Asati | Uploaded new revision |
2018-04-19
|
08 | (System) | Document has expired |
2017-10-10
|
08 | Rajiv Asati | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-08.txt |
2017-10-10
|
08 | (System) | New version approved |
2017-10-10
|
08 | (System) | Request for posting confirmation emailed to previous authors: Rajiv Asati |
2017-10-10
|
08 | Rajiv Asati | Uploaded new revision |
2017-10-07
|
07 | (System) | Document has expired |
2017-04-05
|
07 | Rajiv Asati | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-07.txt |
2017-04-05
|
07 | (System) | New version approved |
2017-04-05
|
07 | (System) | Request for posting confirmation emailed to previous authors: Rajiv Asati |
2017-04-05
|
07 | Rajiv Asati | Uploaded new revision |
2013-02-25
|
06 | Rajiv Asati | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-06.txt |
2012-02-24
|
05 | (System) | Document has expired |
2011-08-23
|
05 | (System) | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-05.txt |
2011-08-17
|
04 | (System) | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-04.txt |
2011-07-26
|
03 | (System) | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-03.txt |
2011-05-06
|
02 | (System) | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-02.txt |
2009-08-28
|
01 | (System) | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt |
2009-08-28
|
00 | (System) | New version available: draft-ietf-idr-bgp-bestpath-selection-criteria-00.txt |