BGP Extended Community Registries Update
draft-ietf-idr-bgp-ext-com-registry-05

[Ballot comment]
Thank you for the work put into this document, which probably addresses incoherent decision made in the past. So, thank you Christoph and IDR WG for fixing it.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Susan Hares for the shepherd's write-up including the section about the WG consensus.

While I am not aware of the history about the use of those "experimental" code points and while I am aware that changing the code points in running code is an impossible endeavour, I wonder how those code points were used in production networks (my guess) while keeping the status of 'experimental'. I.e., the code points 0x81 and 0x82 are noted as 'experimental' but RFC 8955 is standard track. I am balloting ABSTAIN as I miss the history.

***Bottom line for IANA/IESG: what can we learn from this apparent "mess" (I am afraid that my limited English vocabulary is unable to find a more positive word)?***

Regards,

-éric

In "The primary use for those types and sub-type registries is non experimental" should a "now" be inserted before the "non" ?

I also wonder why "0x80-0x82 | First Come First Served" since this document confirms the allocation ? What am I missing here ?

Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat in 1 day (deadline was yesterday). No need anymore for a review (still welcome by the authors probably).

[Ballot comment]
Thank you for the work on this document.

I agree with Ben that it would be good to write something about the "0x0c-0x7f Unassigned" range: I would suggest to split that into the 0x0c-0x3f Unassigned and 0x40-0x7f Reserved (with a pointer to the BGP Non-Transitive Extended Community Types registry). And then, to be thorough, it would be good to do the same type of split in the BGP Non-Transitive Extended Community Types registry.

I understand this was not the meaning of this document (hence the non-blocking comment), but since we are fixing things, I believe this would be an improvement to the current registries.

Francesca

[Ballot comment]
Section 2

Should we also ask IANA to update the entry for the Unassigned range
starting at 0x0c in the "BGP Transitive Extended Community Types"?  It
currently shows as "0x0c-0x7f  Unassigned", but 0x40-0x7f are not
controlled by this (transitive) registry, and are rather in the
non-transitive EC types registry.

Section 5.2

I would probably put RFC 8955 as normative now that we're Updating it,
but it's a pretty fine hair to split.

[Ballot comment]
Alvaro assures me that the plan is to follow what I described in my DISCUSS, so I am removing that DISCUSS.

Original text:
I'm having trouble seeing how we got here; this registry architecture is hard to understand, and past actions appear to violate RFC 3692.

1. RFC7153 designated 0x80-0x8f as experimental and then immediately defines 0x80 as the gateway to a further subregistry of FCFS/IETF review codepoints. This does not appear to be "Reserved for Experimental Use" in the RFC 3692 sense, in that it is not meant to be used only by explicit experiments. (It's a standards track document).

2. RFC8955 compounds it by taking another 2 (of 15 remaining!) experimental codepoints in a standards-track document, for a similar purpose.

I agree with this draft's reclassification of the 3 codepoints, as it recognizes reality that they are apparently no longer safe for RFC 3692 experiments. But I would also like to verify that this behavior will not continue: future standards-track allocations, including those pointing to more subtypes ("Part 4", etc), will draw from the FCFS range, not Experimental.

Furthermore, experiments (with a draft or not) that use one of these experimental codepoints should be reassigned a FCFS codepoint if they move to Standards track.

[Ballot discuss]
I'm having trouble seeing how we got here; this registry architecture is hard to understand, and past actions appear to violate RFC 3692.

1. RFC7153 designated 0x80-0x8f as experimental and then immediately defines 0x80 as the gateway to a further subregistry of FCFS/IETF review codepoints. This does not appear to be "Reserved for Experimental Use" in the RFC 3692 sense, in that it is not meant to be used only by explicit experiments. (It's a standards track document).

2. RFC8955 compounds it by taking another 2 (of 15 remaining!) experimental codepoints in a standards-track document, for a similar purpose.

I agree with this draft's reclassification of the 3 codepoints, as it recognizes reality that they are apparently no longer safe for RFC 3692 experiments. But I would also like to verify that this behavior will not continue: future standards-track allocations, including those pointing to more subtypes ("Part 4", etc), will draw from the FCFS range, not Experimental.

Furthermore, experiments (with a draft or not) that use one of these experimental codepoints should be reassigned a FCFS codepoint if they move to Standards track.

[Ballot discuss]
Hi,

Thank you for your work.
Maybe I'm missing something obvious, but why doesn't this document update 8955 just like it updates 7153?
I'm asking because your document modifies the allocation policy of the 0x80-0x8F range, as well as the names of 0x80, 0x81, 0x82 (and of their sub-types registries), and at the same time it seems to me that 7153 covers the allocation policy of the 0x80-0x8F range but only 0x80 (and its sub-type registry), while it's 8955 which seems to cover 0x81 and 0x82 (and their sub-types registries).

Thank you

[Ballot discuss]
Hi,

Thank you for your work.
Maybe I'm missing something obvious, but why doesn't this document update 8955 just like it updates 7153?
I'm asking because your document modifies the allocation policy of the 0x80-0x8F range, as well as the names of 0x80, 0x81, 0x82 (and of sub-types registries) but at the same time it seems to me that 7153 only covers the allocation policy of the 0x80-0x8F range and 0x80 (and its sub-type registry), while it's 7674/8955 which seems to cover 0x81 and 0x82 (and their sub-types registries).

Thank you

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-ext-com-registry-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the BGP Transitive Extended Community Types registry located on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

three existing registrations (types 0x80, 0x81 and 0x82) will have the names of the types values changed and [ RFC-to-be ] added to the references. The names are to be:

0x80: Generic Transitive Extended Community (Sub-Types are defined in the "Generic Transitive Extended Community Sub-Types" Registry)

0x81: Generic Transitive Extended Community Part 2 (Sub-Types are defined in the "Generic ransitive Extended Community Part 2 Sub-Types" Registry)

0x82: Generic Transitive Extended Community Part 3 (Sub-Types are defined in the "Generic Transitive Extended Community Part 3 Sub-Types" Registry)

In addition, the registration rules for this registry will be changed for Type Values 0x80 thru 0x82 to First Come First Served as defined in RFC8126.

Second, for the Generic Transitive Experimental Use Extended Community Sub-Types registry also located on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the registry title will be changed to:

Generic Transitive Extended Community Sub-Types

Third, for the Generic Transitive Experimental Use Extended Community Part 2 Sub-Types registry also located on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the registry title will be changed to:

Generic Transitive Extended Community Part 2 Sub-Types

Fourth, for the Generic Transitive Experimental Use Extended Community Part 3 Sub-Types registry also located on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities/

the registry title will be changed to:

Generic Transitive Extended Community Part 3 Sub-Types

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-10-26):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-idr-bgp-ext-com-registry@ietf.org, idr-chairs@ietf.org, idr@ietf.org, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BGP Extended Community Registries Update) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'BGP Extended Community Registries Update'
  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
last-call@ietf.org mailing lists by 2021-10-26. 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


  This document updates several BGP Extended Community registries in
  order to replace the "Experimental Use" registration procedure in
  some entries, since their use is clearly not experimental and thus
  misleading.

  This document updates RFC7153.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ext-com-registry/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, Verson: 11/1/2019.

(1) What type of RFC?  Proposed Standard: 
Why: Updates the registration procedures defined in RFC7153/

(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 document updates several BGP Extended Community registries in
  order to replace the "Experimental Use" registration procedure in
  some entries, since their use is clearly not experimental and thus
  misleading.

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Working group had solid consensus on this document which specifies
change of registration procedures for RFC7153. 

Document Quality:

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

Early review from IANA requested.

Personnel:
document Shepherd:  Susan Hares
AD: Alvaro Retana.


(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Read through Registries and checked against IANA
2) IDNits
3) IPR checks

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No - WG review was adequate. 

(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.

No.

(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.

No concerns.

(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?
Christoph Loibl
https://mailarchive.ietf.org/arch/msg/idr/lx9WhkXcU_8HJJTzej4W7yVCQO8/

(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

(9) How solid is the WG consensus behind this document?

Solid discussion on options.

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

(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 discontent.

(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 ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional review process

(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.

yes - it updates RFC7153.  It is noted on the front page

(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 8126).

This updates RFC7153 - which deals with BGP registry procedures.
Early IANA Review requested. 

(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.

No 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, YANG modules, etc.

none needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

None

As required by RFC 4858, Verson: 11/1/2019.

(1) What type of RFC?  Proposed Standard: 
Why: Updates RFC7153 on

(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 document updates several BGP Extended Community registries in
  order to replace the "Experimental Use" registration procedure in
  some entries, since their use is clearly not experimental and thus
  misleading.

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Working group had solid consensus on this document which specifies
change of registration procedures for RFC7153. 

Document Quality:

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

Early review from IANA requested.

Personnel:
document Shepherd:  Susan Hares
AD: Alvaro Retana.


(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Read through Registries and checked against IANA
2) IDNits
3) IPR checks

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No - WG review was adequate. 

(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.

No.

(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.

No concerns.

(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?
Christoph Loibl
https://mailarchive.ietf.org/arch/msg/idr/lx9WhkXcU_8HJJTzej4W7yVCQO8/

(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

(9) How solid is the WG consensus behind this document?

Solid discussion on options.

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

(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 discontent.

(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 ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional review process

(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.

yes - it updates RFC7153.  It is noted on the front page

(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 8126).

This updates RFC7153 - which deals with BGP registry procedures.
Early IANA Review requested. 

(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.

No new registries. 

IANA Experts suggested are IDR chairs, Alvaro Retana, Christoph Loibl, John Scudder.

(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, YANG modules, etc.

none needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

None

As required by RFC 4858, Verson: 11/1/2019.

(1) What type of RFC?  Proposed Standard: 
Why: Updates RFC7153 on

(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 document updates several BGP Extended Community registries in
  order to replace the "Experimental Use" registration procedure in
  some entries, since their use is clearly not experimental and thus
  misleading.

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Working group had solid consensus on this document which specifies
change of registration procedures for RFC7153. 

Document Quality:

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

Early review from IANA requested.

Personnel:
document Shepherd:  Susan Hares
AD: Alvaro Retana.


(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Read through Registries and checked against IANA
2) IDNits
3) IPR checks

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No - WG review was adequate. 

(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.

No.

(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.

No concerns.

(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?
Christoph Loibl
https://mailarchive.ietf.org/arch/msg/idr/lx9WhkXcU_8HJJTzej4W7yVCQO8/

(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

(9) How solid is the WG consensus behind this document?

Solid discussion on options.

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

(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 discontent.

(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 ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional review process

(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.

yes - it updates RFC7153.  It is noted on the front page

(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 8126).

This updates RFC7153 - which deals with BGP registry procedures.
Early IANA Review requested. 

(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.

No new registries. 

IANA Experts suggested are IDR chairs, Alvaro Retana, Christoph Loibl, John Scudder.

(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, YANG modules, etc.

none needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

None

Christoph - need to change RFC5575 to RFC8955.
========
As required by RFC 4858, Verson: 11/1/2019.

(1) What type of RFC?  Proposed Standard: 
Why: Updates RFC7153 on

(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 document updates several BGP Extended Community registries in
  order to replace the "Experimental Use" registration procedure in
  some entries, since their use is clearly not experimental and thus
  misleading.

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Working group had solid consensus on this document which specifies
change of registration procedures for RFC7153. 

Document Quality:

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

Early review from IANA requested.

Personnel:
document Shepherd:  Susan Hares
AD: Alvaro Retana.


(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Read through Registries and checked against IANA
2) IDNits
3) IPR checks

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No - WG review was adequate. 

(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.

No.

(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.

No concerns.

(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?
Christoph Loibl
https://mailarchive.ietf.org/arch/msg/idr/lx9WhkXcU_8HJJTzej4W7yVCQO8/

(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

(9) How solid is the WG consensus behind this document?

Solid discussion on options.

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

(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 discontent.

(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 ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional review process

(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.

yes - it updates RFC7153.  It is noted on the front page

(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 8126).

This updates RFC7153 - which deals with BGP registry procedures.
Early IANA Review requested. 

(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.

No new registries. 

IANA Experts suggested are IDR chairs, Alvaro Retana, Christoph Loibl, John Scudder.

(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, YANG modules, etc.

none needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

None

As required by RFC 4858, Verson: 11/1/2019.

(1) What type of RFC?  Proposed Standard: 
Why: Updates RFC7153 on

(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 document updates several BGP Extended Community registries in
  order to replace the "Experimental Use" registration procedure in
  some entries, since their use is clearly not experimental and thus
  misleading.

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Working group had solid consensus on this document which specifies
change of registration procedures for RFC7153. 

Document Quality:

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

Early review from IANA requested.

Personnel:
document Shepherd:  Susan Hares
AD: Alvaro Retana.


(3) Briefly describe the review of this document that was performed by the Document Shepherd.

1) Read through Registries and checked against IANA
2) IDNits
3) IPR checks

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No - WG review was adequate. 

(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.

No.

(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.

No concerns.

(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?
Christoph Loibl
https://mailarchive.ietf.org/arch/msg/idr/lx9WhkXcU_8HJJTzej4W7yVCQO8/

(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

(9) How solid is the WG consensus behind this document?

Solid discussion on options.

first discussion on IDR list:
https://mailarchive.ietf.org/arch/msg/idr/kzJ7lGSC33xoaTrq1mRWjJ_6-DA/

Last Call Discussion:
https://mailarchive.ietf.org/arch/msg/idr/awDBL0NbPILwkCxjJQo5XEVq5_k/

(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 discontent.

(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 ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
no additional review process

(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.

yes - it updates RFC7153.  It is noted on the front page

(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 8126).

This updates RFC7153 - which deals with BGP registry procedures.
Early IANA Review requested. 

(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.

No new registries. 

IANA Experts suggested are IDR chairs, Alvaro Retana, Christoph Loibl, John Scudder.

(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, YANG modules, etc.

none needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

None