I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-isis-prefix-attributes-03
Reviewer: Paul Kyzivat
Review Date: 2015-12-28
IETF LC End Date: 2016-01-01
IESG Telechat date: 2016-01-07

Summary:

This draft is on the right track but has open issues, described in the 
review.

Major: 0
Minor: 4
Nits:  1

(1) Minor:

   The abstract and introduction both seem to assume that the
   reader has a lot of context about the intended scope of this
   document. For instance:

   - the abstract starts with "This document introduces new sub-TLVs",
     without any mention of to what they are subordinate;

   - the intro starts with "There are existing use cases in which
     knowing additional attributes of a prefix is useful." The
     uninitiated reader is left to figure out what sort of prefix
     (in this case network prefix) is being discussed.

   It would be helpful to state more of the context. Adding one or more
   references to the Introduction would also help. Keep in mind that
   once this is published as an RFC many people may see only the RFC
   number and the abstract, without even knowing that this is about
   routing. (And when looking at the title a different meaning of "ISIS"
   might first come to mind.)

   (Once I had the proper mind set, and had reviewed some of the related
   drafts and the relevant IANA registries, the draft finally made sense
   to me.)

(2) Minor / meta-editorial:

   I found it disconcerting that TLVs are referenced by their numeric
   type value rather than a name. And in this case the new sub-TLVs ar
   defined in a table that applies jointly to several different TLVs. I
   think it would be clearer if a name was given to this collection of
   TLVs, and used to discuss things that apply to all of them. (But,
   while I bring this up, I don't really expect that it makes sense to
   address it in the context of this draft. It it perhaps something
   better saved for a BIS to the entire IS-IS family.)

(3) Minor:

   The IANA considerations section says:

    This document adds the following new sub-TLVs to the registry of sub-
    TLVs for TLVs 135, 235, 236, 237.

   It doesn't explicitly indicate which registry this is. I suggest:

    This document adds the following new sub-TLVs to the "Sub-TLVs for
    TLVs 135, 235, 236, 237" table within the "IS-IS TLV Codepoints"
    registry.

   (Or some other wording recommended by IANA.) To their credit, IANA
   seems to have figured this out, since they already have placeholders
   in the table.

(4) Minor:

   Also in IANA considerations, in the definition of the new bit flags
   table,

   - the document ought to explicitly state the name it would like
     assigned to the new registry;

   - the name given in the IANA considerations section only includes the
     long name from section 2.1 (e.g., External Prefix Flag), not the
     short mnemonic name (e.g., X-Flag). Someone reading the IANA table
     might want to see the short name.

(5) Nit:

   And finally a typo in this section: "registery" should be "registry".