Document: draft-ietf-idr-bgp-model-20.txt This document contains 9 normative YANG modules defined in 17 YANG files: 1) iana-bgp-afi-safi-types@2026-06-24.yang 2) iana-bgp-capabilities@2026-06-24.yang 3) iana-bgp-community-types@2026-06-24.yang 4) iana-bgp-notification@2026-06-24.yang G 5) iana-bgp-rib-types@2026-06-24.yang 6) ietf-bgp@2026-06-24.yang 6a) ietf-bgp-capabilities@2026-06-24.yang 6b) ietf-bgp-common@2026-06-24.yang 6c) ietf-bgp-common-errors@2026-06-24.yang 6d) ietf-bgp-common-multiprotocol@2026-06-24.yang 6e) ietf-bgp-neighbor@2026-06-24.yang 6f) ietf-bgp-rib@2026-06-24.yang 6g) ietf-bgp-rib-attributes@2026-06-24.yang 6h) ietf-bgp-rib-tables@2026-06-24.yang 7) ietf-bgp-community-types@2026-06-24.yang 8) ietf-bgp-policy@2026-06-24.yang 9) ietf-bgp-types@2026-06-24.yang # Summary Review focused only on issues with RFC 7950 and RFC 9907. Major Issues: none Minor Issues: # 1) iana-bgp-afi-safi-types@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues There is an rfcstrip issue with this draft: - module and code block defined in sec 7.6 - module and code block duplicated in Appendix I. This causes the extracted file to contain the module twice. Suggestion: remove the code block from Appendix I and just refer to the one in sec 7.6. # 2) iana-bgp-capabilities@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues There is an rfcstrip issue with this draft: - module and code block defined in sec 7.5 - module and code block duplicated in Appendix H. This causes the extracted file to contain the module twice. Suggestion: remove the code block from Appendix H and just refer to the one in sec 7.5. # 3) iana-bgp-community-types@2026-06-24.yang - RFC 7950 issues The import statements for these modules should be removed: - warning: imported module "ietf-inet-types" not used - warning: imported module "ietf-yang-types" not used The bgp-ipv6-ext-community-type and bgp-ext-community-type typedefs contain comments that should be part of the YANG module. Suggestion: Create a separate typedef for each of the 'string' types in each union, so the description and reference statements can be used. - no RFC 9907 issues There is an rfcstrip issue with this draft: - module and code block defined in sec 7.2 - module and code block duplicated in Appendix J. This causes the extracted file to contain the module twice. Suggestion: remove the code block from Appendix J and just refer to the one in sec 7.2. # 4) iana-bgp-notification@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues There is an rfcstrip issue with this draft: - module and code block defined in sec 7.4 - module and code block duplicated in Appendix G. This causes the extracted file to contain the module twice. Suggestion: remove the code block from Appendix G and just refer to the one in sec 7.4. # 5) iana-bgp-rib-types@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues There is a document structure issue with this draft: - There is no module definition and code block defined in sec 7 - module and code block are only defined in Appendix K. Suggestion: Move the code block to section 7, and make a reference to it in Appendix K. # 6) ietf-bgp@2026-06-24.yang - RFC 7950 issues - no RFC 9907 issues Issue: use of submodules There is no text at all in either RFC 7950 or 9907 that would suggest that submodules should not be used, but their use is no longer considered 'best current practice' and they may be removed from YANG 2.0. The conventional approach would be to make these submodules their own modules, or include the groupings in the main module. It is difficult to comprehend the data model spread over 9 YANG files. It may also be difficult to read one large module. Suggestion: consider getting rid of the submodules Pros: - It would be easier to find groupings when a 'uses' statement is encountered. - Client YANG library processing is more complex if submodules must be retrieved from the server (e.g., using the NETCONF operation). - Submodules are not usable in any way as separate components. They provide no modularity, and are not hierarchical. Users are often confused, thinking submodules have the same properties as modules. Cons: - Disruptive and could introduce errors making changes # 6a) ietf-bgp-capabilities@2026-06-24.yang - no RFC 7950 issues - RFC 9907 issues There are some list and leaf-list names that use a plural form. - list afi-safis - list advertised-capabilities - list received-capabilities - leaf-list negotiated-capabilities This is very minor and not worth a name change at this late date. # 6b) ietf-bgp-common@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues # 6c) ietf-bgp-common-errors@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues # 6d) ietf-bgp-common-multiprotocol@2026-06-24.yang - no RFC 7950 issues - RFC 9907 issues The grouping mp-all-afi-safi-list-contents contains several comments that look like they should be in a description-stmt // import and export policy included for the afi/safi uses rt-pol:apply-policy-group; Suggestion: uses rt-pol:apply-policy-group { description "Import and export policy included for the afi/safi"; } The 'placeholder' comments are a bit confusing for a published module. Perhaps they should be moved to a description-stmt. The grouping mp-afi-safi-config 'name' leaf should have a complete sentence in the description-stmt. leaf name { ... description "AFI,SAFI"; } # 6e) ietf-bgp-neighbor@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues # 6f) ietf-bgp-rib@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues # 6g) ietf-bgp-rib-attributes@2026-06-24.yang - no RFC 7950 issues - RFC 9907 issues The comment should be moved into the description-stmt. leaf-list ext-community-raw { type string { // raw with 8 octets leaf-list ipv6-ext-community-raw { // raw with 20 octets # 6h) ietf-bgp-rib-tables@2026-06-24.yang - no RFC 7950 issues - no RFC 9907 issues # 7) ietf-bgp-community-types@2026-06-24.yang - no RFC 7950 issues - RFC 9907 issues It is unusual to define features in a module without any accessible objects. In this case, more description and a reference-stmt is needed. feature send-communities { description "Enable the propagation of communities."; } Suggestion: add reference sub-statement The 'semver' module is not imported in this module. The 'ysv:version statement is not present in the revision-stmt. Suggestion: add this text similar to all other modules. # 8) ietf-bgp-policy@2026-06-24.yang - no RFC 7950 issues - RFC 9907 issues There is a leaf-list name that uses a plural form. - leaf-list communities This is very minor and not worth a name change at this late date. # 9) ietf-bgp-types@2026-06-24.yang It is unusual to define features in a module without any accessible objects. In this case, more description and a reference-stmt is needed. - feature clear-neighbors - feature clear-routes - feature clear-statistics - feature damping - feature distance - feature graceful-restart Suggestion: add a reference sub-statement in each feature-stmt