Sorry for the late review. I have been tasked to review this document on behalf of the Ops Directorate. This document defines a new BGP path attribute called the BGP Community Container as well as a Wide Community type. That said, it is not immediately clear from the abstract what this document really does. It isn't until Section 2 where it becomes clearer. While I appreciate Section 7 on operational considerations, it struck me that the statement, "in supporting both standard and BGP Wide Communities, allow for their easy inbound and outbound processing" was not terribly instructive. Perhaps an example of what the authors would consider "easy" in this case would be useful. Some more comments below: Section 4.4.2 s/a list of a Atoms/a list of Atoms/ In the paragraph, "When no exclude targets are required..." does this assume that an empty Exclude Targets TLV is to be ignored? The paragraph states that implementations must be able to accept this, but does not make it clear what to do in that case once it is accepted. While I think you answer this in a later section, is there a need to have a "match none" as well to correspond to the Targets TLV "match all" behavior? My final read of the document says no, but I wanted to be thorough. === Section 4.4.3 s/a list of a Atoms/a list of Atoms/ s/too many or two few/too many or too few/ I have the same comment here as in Section 4.4.2. If the parameters are empty how exactly should the receiving router behave? Why not just make these a strong MUST NOT encode if they are empty to remove any ambiguity? === Section 5 s/Contaners/Containers/ s/removed by BGP Speaker/removed by BGP Speakers/ === Section 5.1 Is the 0xFFFFFFFF AS Atom value the same as leaving off a Targets TLV? === Section 5.2 The last sentence should use the same normative language as in Section 5 (i.e., SHALL be considered malformed) === Section 9.2 s/AS_PATH prepend 4 TIMES TO/AS_PATH prepend 4 times/ Not _sure_ this is correct, but I couldn't quite grok the sentence as written.