Hi Christer, thanks for your comments. I fixed most of them however, regarding the last comment (Q_2_1), we tried to keep both OSPF (now RFC7471) and IS-IS drafts aligned even in the descriptions.
The text you pointed out is in fact the same in RFC7471. I’d like to keep both protocols completely aligned and would prefer to keep the text as is. Thanks. s. > On Jan 19, 2016, at 2:54 PM, Christer Holmberg > <[email protected]> wrote: > > 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.” _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
