[Gen-art] Gen-ART review of draft-ietf-isis-te-metric-extensions-07

[Christer Holmberg <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
Document:                                                  draft-ietf-isis-te-metric-extensions-07.txt
Reviewer:                                                   Christer Holmberg
Review Date:                                               19 January 2016
IETF LC End Date:                                          30 December 2015
IETF Telechat Date:                                       21 January 2016
Summary:           The document is well written, and is almost ready for publication. However, there are some editorial issues that I ask the authors to address.
Major Issues: None
Minor Issues: None
Editorial Issues:

GENERAL:
--------------

Q_GEN_1:

In section 1, you say that the extension is hereafter called "IS-IS TE Metric Extensions".

However, you then refer to it as e.g. "TE Metric Extensions" and "ISIS TE Metric Extensions".

Please use consistent terminology.


Q_GEN_2:

Sometimes the text says "sub-TLV", sometimes "SubTLV", and sometimes "Sub TLV". Please use consistent terminology.


SECTION 1:
--------------

Q_1_1:

I suggest to rewrite:

"This document describes extensions to IS-IS Extended Reachability TLV
defined in [RFC5305] (hereafter called "IS-IS TE Metric Extensions"),..."

...to:

"This document describes extensions (hereafter called "IS-IS TE Metric Extensions")
to IS-IS Extended Reachability TLV defined in [RFC5305],..."

... to make it more clear that "IS-IS TE Metric Extensions" refers to the extensions, and not to the TLV.


SECTION 2:
--------------

Q_2_1:

I have some difficulties to follow the A,B,C bullet list logic.

I think it would be more clear to structure it e.g. like:

"From an  MPLS perspective, the intent of the A bit is to permit LSP ingress
nodes to determine whether the link referenced in the sub-TLV affects any
of the LSPs for which it is ingress.

If any of the LSPs are affected, the receiving node shall determine whether
those LSPs still meet end-to-end performance objectives. If the objectives
are not met the receiving node could conceivably move affected traffic to a pre-
established protection LSP or establish a new LSP and place the traffic in it."