[GROW] Rtgdir last call review of draft-ietf-grow-wkc-behavior-03

[Adrian Farrel via Datatracker <[e-mail]>]

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.