Subject: [GROW] Alissa Cooper's No Objection on draft-ietf-grow-wkc-behavior-06: (with COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Mon, 10 Jun 2019 12:28:22 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-grow-wkc-behavior-06: No Objection

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:
----------------------------------------------------------------------

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?).

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jun 2019 13:18:42 -0700

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

more correctly, i think

   not receive special treatment in Cisco IOS XR, and at least one
   specific community on Cisco IOS XR's special treatment list (internet
   == 0:0) is not formally a Well-Known Community as it is not in
   [IANA-WKC]; but taken from the "Reserved" range
   [0x00000000-0x0000FFFF].

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

a klutz at the keyboard

> 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?).

in a vain hope of reciprocity, ops folk are hesitant to tell vendors
MUST unless something will actually break.  will consult with
co-authors.  my guess of outcome is MUST; but i am not a great guesser.

thanks for review!

randy