Advertising Node Administrative Tags in IS-IS
RFC 7917

Note: This ballot was opened for revision 09 and is now closed.

(Alia Atlas) Yes

(Jari Arkko) (was Discuss) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

Comment (2016-05-03 for -10)
No email
send info
Just a couple of nits:

- 4.1, last paragraph: "Each tag SHOULD be treated as an independent identifier that MAY be
   used in policy to perform a policy action."

I think the MAY may be spurious. It seems to be a statement of fact about the tag, rather than an implementation choice. (But this is a borderline case of spuriousness).

- 8: In addition to Alvaro and Alissa's comments, remember that RFCs live forever. Statements that other work needs to happen will (hopefully) become dated. Some qualifier like "At the time of this writing..." can help.

(Benoît Claise) No Objection

(Alissa Cooper) No Objection

Comment (2016-05-03 for -10)
No email
send info
Agree with Alvaro's point #4. This seems like a bit of a weird statement to make in an RFC; if updates to the other documents are expected then maybe this document should say that?

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Comment (2016-05-04 for -10)
No email
send info
Juergen Schoenwaelder   performed the opsdir review

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Comment (2016-05-03 for -10)
No email
send info
Just some minor comments:

1. Section 1. (Introduction)

1.a "This document provides mechanisms to advertise node administrative tags in IS-IS for route and path selection."  While route and path selection is an application, that is not what this document does -- that is just one application.

1.b "…the new TLV for carrying node administrative tags…"  It's a sub-TLV.

2. Section 2. (Node Administrative Tags): "An IS-IS router SHOULD advertise the set of groups it is part of in the specific IS-IS level."  Do you really want to use "SHOULD"?  Given that this extension is optional and that configuring the tags is also optional, and that even the CAPABILITY TLV is optional, I think "SHOULD" is too strong.  s/SHOULD/MAY or even s/SHOULD/should

3. s/diiferent/different

4. Section 8. (Manageability Considerations): "…[I-D.ietf-isis-yang-isis-cfg]…[I-D.ietf-rtgwg-policy-model]…These two documents need to be enhanced to include the node administrative tag related configurations."  I hope that this text means that someone (maybe one of the authors) will work to enhance those other documents before publication (and not later write separate extension documents).