Policy Behavior for Well-Known BGP Communities
draft-ietf-grow-wkc-behavior-08

Consistent behavior is important.  Understanding that behavior to achieve consistent operations is even more important.

However, I believe that this document doesn't provide the substance needed to achieve or guarantee consistency in the future.  Specifically, the Normative content (mostly in §6) doesn't define a specific behavior...instead it basically boils down to "keep doing whatever you're doing...and document it if you want to"...

The language can always be improved, but unless a specific behavior is specified I don't think there is much value is publishing this document as an RFC.  According to the Shepherd, the consensus on this document is solid in the WG.  I then don't expect significant changes, and don't want to delay publication, so I am ABSTAINing.

I do have some specific comments that hopefully may help improve the document.


=======

(1) What is the Update to rfc1997?  Please mention what it is in the Abstract and Introduction.

I don't see a specific update to rfc1997, as in changing the behavior, for example.  But, based on the e-mail archive, it seems that the intent is to point readers of rfc1997 to this document...at least say that.


(2) Document Status 

As others have mentioned, and specially because this document doesn't really specify anything, I don't think it belongs in the Standards Track.  I think that tagging it as an update to rfc1997 is not a great excuse to make it a Proposed Standard.  Unfortunately, we have no other way to point readers of rfc1997 to this document.

I also don't think that BCP is appropriate because it simply points at the fact that inconsistencies exist...  [See more below.]

I think that this document is better suited to be Informational.  Other documents that have addressed the use of communities have been published as Informational; for example rfc1998, rfc8195...


(3) Introduction

   This document recommends specific actions to limit future
   inconsistency, namely BGP implementors MUST NOT create further
   inconsistencies from this point forward.

How can the creation of inconsistencies be Normatively enforced?  I understand that this whole document is about addressing inconsistencies, which I think is a valid use of the rfc2119 keywords...but I don't understand what action is expected out of the statement.   s/MUST NOT/must not

I do think that the Action Items (§6) represent better guidance than the statement above.  


(3) Action Items 

(3a) "Vendors SHOULD clearly document the behavior of "set" directive in their implementations."  Why is MUST not used?  IOW, when it is ok for vendors not to clearly document the behavior?  If the intent is not to mandate what vendors do, then please s/SHOULD/should...but I thought that was the intent in Standards Track documents...

(3b) Given that this document is about addressing inconsistencies, I am sad by this paragraph:

   Vendors MUST ensure that their implementations' "set" directive
   treatment of any specific community does not change if/when that
   community becomes a new Well-Known Community through future
   standardization.  For most implementations, this means that the "set"
   directive MUST continue to remove the community; for those
   implementations where the "set" directive removes no communities,
   that behavior MUST continue.

Note first that "MUST ensure that..."set" directive...does not change" is hard to enforce unless the behavior is clearly documented, but that is not absolutely required...

Second...the text Normatively (MUST) allows for the behavior to remain the way it is.  This makes me sad because I hoped for this document to define a specific behavior...instead it basically boils down to "keep doing whatever you're doing...and document it if you want to"... :-(



(5) Note for Those Writing RFCs for New Community-Like Attributes (§5)

   "...RFC authors should state explicitly how the new attribute is to be handled."

This seems to be the one piece of important information in this document...but it is not mandatory.  Also, based on the rest of the document, I think you explicitly mean more than general handling...but probably mean also what implementations are expected to do in relation to filtering, etc.  If so, please be explicit.

Also, what are "community-like attributes"?  The examples mentioned are also communities... I think that where specific attributes exist, they should be explicitly mentioned: rfc4360, rfc8092...



(6) Nits...

(6a) Table 1: There is one reference (rfc7611) -- or at least it looks like a reference, but there's no corresponding entry in the References section.  Please be consistent: either add references to the Table (and the References section), or not.  I think that in this case you should.

(6b) "On Extreme networks' Brocade NetIron: "set community X" removes all communities and sets X."  Most of the other text in this section makes the point of indicating "all communities, Well-Known or otherwise"...is there a difference in behavior here?