[GROW] Alvaro Retana's Abstain on draft-ietf-grow-wkc-behavior-07: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-grow-wkc-behavior-07: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?