Last Call Review of draft-ietf-isis-node-admin-tag-08
review-ietf-isis-node-admin-tag-08-opsdir-lc-schoenwaelder-2016-04-23-00

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/

>