I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-isis-node-admin-tag-08 Status: Ready with issues I think the document is mostly clear but I have a number of little issues that I think should be fixed. Abstract What is an _operational_ capability? Perhaps the word 'operational' does not mean anything in the context and can be removed? If it means something, then the text is not clear to me. 2. Per-Node Administrative Tags "An administrative Tag is a 32-bit integer" - is this a signed or an unsigned integer value? Since it is used as a tag, it might be considered an unsigned integer but the text does not tell me. 8. Manageability Considerations This is not quite right: YANG data definition language is the latest model to describe and define configuration for network devices. A language is not a model. Perhaps something like this: Per-node administrative tags are configured and managed using routing policy enhancements. YANG [RFC6020] is a data modeling language used to specify configuration data models. The IS-IS YANG data model is described in [I-D.ietf-isis-yang-isis-cfg] and the routing policy configuration model is described in [I-D.ietf-rtgwg-policy-model]. These two documents need to be enhanced to include the node administrative tag related configurations. 9. IANA Considerations I am not sure these are clear enough. I looked at http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml and it was unclear to me where exactly a codepoint is to be allocated. Please make sure the instructions are clear to IANA. 11. References Why is RFC7490 normative? It is only cited in a non-normative section. General: - Some references and dates etc. seem to be meanwhile outdated - Clearer instructions for the RFC editor might be helpful instead of just 'TBA' (Figure 1) Editorial: - s/to both to/to both/ - consider to expand TLV on first usage (there is an expansion in section 3.1 but thats perhaps a bit late) - consider to expand PE and P on first usage - s/adminsitrative/administrative/ - Is the grammar correct in the first sentence in section 5 item 3? I found this sentence / paragraph / item difficult to parse in general (a couple of missing articles and such things) - First sentence in section 5 item 4: "The topology ... usually adopts ring topology" sounds weird. I suggest to split the sentence instead of using "and it" since it is unclear what 'it' refers to. For example: Mobile back-haul networks are often divided into an aggregate network and an access network. These networks usually use ring topologies to save fiber resources. (I am unsure whether the more popular term is aggregate network or aggregation network in this context.) - Consider to use subsections in section 5 instead of a long itemized list crossing several pages. This also makes it easier to refer to the application defined in section 5.X. - s/invloves/involves/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/ >