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

[Ballot comment]
Hi,

thank you for this document.

I'm not clear about something and would like to better understand.

I read this:
  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.
as saying "do not change your implementation behaviour for the existing WKC, and also apply that same behaviour to any future WKC that might be defined".

If this reading is correct, I am under the impression that:
  When establishing new [RFC1997]-like attributes (large communities,
  wide communities, etc.), RFC authors should state explicitly how the
  > new attribute is to be handled.
is in conflict with the above.
I know it's not a 2119/8174 keyword, but still, this seems to allow authors to specify how a future WKC should be treated by 'set' or 'delete *:*' and thus, for some implementations, that behavioral requirement will be in conflict with their current behaviour (which must not change).

Thank you

[Ballot comment]
Hi,

thank you for this document.

I'm not clear about something and would like to better understand.
I read this:
  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.
as saying do not change your implementation behaviour for the existing WKC and also apply that same behaviour to any furture WKC th

[Ballot comment]
While I noted other reviews were questioning PS status, I think it is appropriate.

I would have preferred a stronger statement for the following:
Vendors SHOULD clearly document/s/Vendors MUST clearly document

[Ballot comment]
I found the documentation of the various set community behaviors interesting and useful.

* Section 5

It is unclear what this section is recommending to RFC authors. What exactly should they state explicitly? Can you please clarify and expand a bit.

  When establishing new [RFC1997]-like attributes (large communities,
  wide communities, etc.), RFC authors should state explicitly how the
  > new attribute is to be handled.

[Ballot comment]
(1) How this draft updates RFC1997 isn’t clear to me.  I also don’t see how it is a standards track document.  Excluding the helpful enumeration of how the user interfaces of various implementations work, the draft appears to prescribe:

-- Section 5: when new attributes are defined in protocol spec they should be clear in their expected behavior

-- Section 6, Paragraph 3: vendors should document their implementations (and I agree with Alissa and Alvaro who recommended this be MUST)

-- Section 6, Paragraph 4:  vendors must continue to implement the same behavior for the user interface of the “set” directive 

For me these summarize to document what you are doing; and keep doing whatever you have done before (perhaps more precisely, continue to do in the future what you have done in the past).  This doesn’t seem like new or clarifying behavior.

(2) A few editorial nits:
-- Abstract.  Editorial Nit.
s/Well-Known BGP Communities are manipulated differently across various current implementations/
Well-Known BGP Communities are manipulated differently in current implementations/

-- Abstract. Editorial. s/.././

-- Section 5.  Each line in this section appears to start with a “>” as if cut and paste from an email.

[Ballot comment]
(1) How this draft updates RFC1997 isn’t clear to me.  I also don’t see how it is a standards track document.  Excluding the helpful enumeration of how the user interfaces of various implementations work, the draft appears to prescribe:
-- Section 5: when new attributes are defined in protocol spec they should be clear in their expected behavior
-- Section 6, Paragraph 3: vendors should document their implementations (and I agree with Alissa and Alvaro who recommended this be MUST)
-- Section 6, Paragraph 4:  vendors must continue to implement the same behavior for the user interface of the “set” directive 

For me these summarize to document what you are doing; and keep doing whatever you have done before (perhaps more precisely, continue to do in the future what you have done in the past).  This doesn’t seem like new or clarifying behavior.

(2) A few editorial nits:
-- Abstract.  Editorial Nit.
s/Well-Known BGP Communities are manipulated differently across various current implementations/
Well-Known BGP Communities are manipulated differently in current implementations/

-- Abstract. Editorial. s/.././

-- Section 5.  Each line in this section appears to start with a “>” as if cut and paste from an email.

[Ballot 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?

[Ballot comment]
Requirements language:

Please use the RFC 8174 boilerplate.

Section 4.1:

s/is not really on IANA's list/is not individually named on IANA's list/

Section 5:

I'm not sure what the '>' character indicates.

Section 6:

"Vendors SHOULD clearly document the behavior of "set" directive in their implementations." I'm not sure normative language makes sense here (otherwise, what is the rationale for not using MUST?).

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-grow-wkc-behavior-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about the IANA Considerations section of this document.

--> IANA Question: regarding section 4.1 of the current document, does this mean that a reference to the new [ RFC-to-be ] (or, alternatively a note) should be added to the registry of Well-Known Communities which is published at:

https://www.iana.org/assignments/bgp-well-known-communities/

If a reference should be added, a note should be added to the IANA Considerations section.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Michelle Cotton
IANA Services

The following Last Call announcement was sent out (ends 2019-05-13):

From: The IESG
To: IETF-Announce
CC: Job Snijders , draft-ietf-grow-wkc-behavior@ietf.org, grow@ietf.org, grow-chairs@ietf.org, job@ntt.net, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Well-Known Community Policy Behavior) to Proposed Standard


The IESG has received a request from the Global Routing Operations WG (grow)
to consider the following document: - 'Well-Known Community Policy Behavior'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-05-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Well-Known BGP Communities are manipulated inconsistently by current
  implementations.  This results in difficulties for operators.
  Network operators are encouraged to deploy consistent community
  handling across their networks, taking the inconsistent behaviors
  from the various BGP implementations they operate into consideration.
  Also, BGP implementors are expected to not create any further
  inconsistencies from this point forward.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary
==========

Job Snijders is the document sheperd and GROW working group chair. Warren
Kumari is the responsible Area Director.

This document describes an implementation inconsistency in how BGP communities
are handled bewteen commonly deployed BGP implementations. The document is on
the Standards Track because it explicitly prescribes how future versions of BGP
implementations are expected to behave to overcome this inconsistency.

2. Review and Consensus
=======================

Over the course of multiple months a fair representation of the GROW working
group community reviewed this document before and during WGLC. There was active
discussion and consensus that the documented inconsistency is an operational
issue. While there was no controversy, there was decent discussion on how to
rigidly and precisely formulate the normative paragraphs to maybe prevent more
inconsistent behaviour in implementations. Consensus was solid.

3. Intellectual Property
========================

In October 2018, before WGLC, all four authors indicated they are not aware of
about potential disclosures about intellectual property rights in conformance
with BCPs 78 and 79.

4. Other Points
===============

No appeals to the IESG are expected, no signs of bad feeling in the WG. No
requests for IANA, no informative references. No additional technical review
required.

1. Summary
==========

Job Snijders is the document sheperd and GROW working group chair. Warren
Kumari is the responsible Area Director.

This document describes an implementation inconsistency in how BGP communities
are handled bewteen commonly deployed BGP implementations. The document is on
the Standards Track because it explicitly prescribes how future versions of BGP
implementations are expected to behave to overcome this inconsistency.

2. Review and Consensus
=======================

Over the course of multiple months a fair representation of the GROW working
group community reviewed this document before and during WGLC. There was active
discussion and consensus that the documented inconsistency is an operational
issue. While there was no controversy, there was decent discussion on how to
rigidly and precisely formulate the normative paragraphs to maybe prevent more
inconsistent behaviour in implementations. Consensus was solid.

3. Intellectual Property
========================

In October 2018, before WGLC, all four authors indicated they are not aware of
about potential disclosures about intellectual property rights in conformance
with BCPs 78 and 79.

4. Other Points
===============

No appeals to the IESG are expected, no signs of bad feeling in the WG. No
requests for IANA, no informative references. No additional technical review
required.