Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​ http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Early Review/Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-idr-wide-bgp-communities-07 - BGP Community Container Attribute Reviewer: Acee Lindem Review Date: 5/16/2022 IETF LC End Date: N/A Intended Status: Proposed Standard Summary: This document defines an extendible framework for future BGP community definition. It defines a common BGP Community Container attribute header and TLV encodings for BGP wide communities. The BGP Wide Community definition is quite flexible and the onus is put on future documents to precisely define the semantics of specific BGP Wide Communities. The document is well written - especially given the complex encodings. I have some minor concerns about this document that I think should be resolved before publication. Major Issues: None Minor Issues: 1. The definition of local BGP wide communities implies either that operator are using their own custom BGP implementations in their domains or that implementations provide a set of APIs and/or a powerful BGP Wide Community policy language. Should the draft provide some non-normative guidance or at least point this out and state that it is out of scope? 2. It wasn't clear to me why undefined Atoms are ignored and the BGP Wide Community is still used. Similarly, undefined parameters result in the BGP Wide Community being ignored. I think the draft should explain impetus for the three error actions – ignore Atom only, ignore BGP Wide Community, and treat as malformed. 3. Should sections 6 and 10.1 include BGP Large Communities where standard and extended communities are referenced? 4. In the example in Section 9, please define what the argument (2-8) means on first use. I'm assuming it means the number of AS prepends? 5. Remove the Change History in section 12. Nits: See diffs attached to Email. These changes are suggested to both correct some minor errors and improve readability. Thanks, Acee