Reviewer: Adrian Farrel Review result: Has Issues 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 Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-grow-wkc-behavior-03.txt Reviewer: Adrian Farrel Review Date: 2019-05-09 IETF LC End Date: 2019-05-13 Intended Status: Proposed Standard Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Thanks for this document which is short and simple to read. I thought that the main (most substantive and actionble) message is actually hidden as the last paragraph of Section 6: Network operators are encouraged to limit their use of the "set" directive (within reason), to improve the readability of their configurations and hopefully to achieve behavioral consistency across platforms. That message could be placed more prominently and so increase the value of the document. ==Minor Issues== In section 4 you have some inconsistent language in describing how different implementations behave. Sometime you talk about removing "all received communities" and sometimes about "all communities". This appears to imply a difference. Similarly, sometimes you have "all received communities, Well-Known or otherwise" and sometimes all received communities". I suggest it may help clarify behaviors if you carefully use identical language for identical behavior. --- I am confused by the wording in Section 4.1. The IANA registry is purely a list of Well-Known Communities. It makes no statement about how those Communities are supposed to be handled. I think that the issue you raise is not hat IOS XR has a list of well-known communities that differs from that in the registry. I think the issue you raise is that IOS XR's "set community" command does not act uniformly on all well-known communities. It looks to me that you have already made this point in Table 1, and if you wanted to you could strengthen the point in text there. But I think that bringing IANA into it and making it appear that IOS XR has a divergence from the registry is misleading. --- Section 5 makes a good and firm point, but... :-( "Care should be taken" is a doubly ambiguous statement: - Care should be taken by whom? Do you mean care by protocol specifiers, (so this is a directive to other working groups), or do you mean care by implementers? - What care are you advising, specifically? For specifications it might be to state how the new community attribute is to be handled. For implementations it might be to ensure that the new community attribute is handled in a specific way. Specifically to conform with the statement in section 6 that.. Vendors SHOULD clearly document the behavior of "set" directive in their implementations. ==Nits== You should move the 2119 boilerplate down to its own section (1.1 would work) to be consistent with the current RFC Editor style guide. Also, you really should use the more recent boilerplate that looks like: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. --- You have some inconsistency between "Well-Known" and "well-known". ==Pedant-alert== Abstract has Well-Known BGP Communities are manipulated inconsistently by current implementations. I presume you mean that there is inconsistency between how different implementations manipulate BGP communities, not that individual implementations are inconsistent in how they manipulate BGP communities. ==Questions== Does (or might) error handling of Community Attributes differ between implementations? I raise this specifically because RFC 7606 section 7.8 calls out two processing steps.
