Skip to main content

Advertising Node Administrative Tags in IS-IS
draft-ietf-isis-node-admin-tag-11

Yes

(Alia Atlas)

No Objection

(Alexey Melnikov)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Stephen Farrell)
(Suresh Krishnan)
(Terry Manderson)

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

Alia Atlas Former IESG member
Yes
Yes (for -09) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2016-05-03 for -10) Unknown
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?
Alvaro Retana Former IESG member
No Objection
No Objection (2016-05-03 for -10) Unknown
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).
Ben Campbell Former IESG member
No Objection
No Objection (2016-05-03 for -10) Unknown
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 Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2016-05-04 for -10) Unknown
Juergen Schoenwaelder   performed the opsdir review
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -10) Unknown