[Gen-art] IETF Last Call Gen-Art review of draft-ietf-isis-rfc4971bis-01

[[e-mail] (Dale R. Worley)]

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-rfc4971bis-01
Reviewer: Dale R. Worley
Review Date: 4 August 2016
IETF LC End Date: 15 August 2016
IESG Telechat date: 18 August 2016

Summary:

This draft is basically ready for publication, but has nits that
should be fixed before publication.

* Editorial items

How is "capability TLV" to be capitalized?  I count the following
occurrences of the different capitalizations:

    24 CAPABILITY(IES) TLV(s)
     5 Capability(ies) TLV(s)
     4 capability(ies) TLV(s)

The practice in other RFCs seems to be "Capability TLV".

This also affects two occurrences of "TLV named CAPABILITY".

Abstract

   This document defines a new optional Intermediate System to
   Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
   sub-TLVs, which allows a router to announce its capabilities within
   an IS-IS level or the entire routing domain.

I think s/formed of/containing/ -- the TLV also contains the Router ID
and Flags fields.

2.  IS-IS Router CAPABILITY TLV

   The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type,
   1 octet that specifies the number of bytes in the value field, and a
   variable length value field that starts with 4 octets of Router ID,
   indicating the source of the TLV, and followed by 1 octet of flags.

Should some note be put here that if Capability is used as an extended
TLV, the type and length are increased to 2 bytes?  That is a general
fact about TLVs, of course, but strictly, the above sentence isn't
always correct.  (Or is the "extended" version available only for TLVs
at some higher level of the hierarchy?)

I think s/and followed by/followed by/.  The subject of "followed" is
"4 octets of Router ID", leaving "and" to join "indicating the source
of the TLV" with "followed by 1 octet of flags", which is not a
parallel construction.  Instead, omit "and" to make the construction
"... value field that starts with 4 octets ... followed by ..."

3.  Elements of Procedure

   Router ID sub-TLV [RFC5316] MUST be present in the TLV.  Router
   CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the
   IPv6 TE Router ID sub-TLV present MUST be ignored.

Given that "ignored" is used later to describe processing of unknown
sub-TLVs, which must not be interpreted but which may need to be
leaked, perhaps "ignored" here should be amplified.  Perhaps "ignored,
including not leaked".

      Example: If Level-1 router A generates a Capability TLV and floods
      it to two L1/L2 routers, S and T, they will flood it into the
      Level-2 domain.  Now suppose the Level-1 area partitions, such
      that A and S are in one partition and T is in another.  IP routing
      will still continue to work, but if A now issues a revised version
      of the CAP TLV, or decides to stop advertising it, S will follow
      suit, but T will continue to advertise the old version until the
      LSP times out.

I think you need to expand the last sentence to "... but without the
above prohibition, T would continue ...".  Or otherwise qualify the
entire example with "without the above prohibition".

   Routers in other areas have to choose whether to trust T's copy of
   A's capabilities or S's copy of A's information and, they have no
   reliable way to choose.  By making sure that T stops leaking A's
   information, this removes the possibility that other routers will use
   stale information from A.

This second paragraph is part of the example, and should be indented
the same way as the first paragraph.

Similarly, in the first sentence, s/have to/would have to/.

Remove the comma after "and".

The "this" in the last sentence doesn't have an antecedent.  Change to
"this prohibition".

   How partial support may impact the operation of the
   capabilities advertised within the Router CAPABILITY TLV is outside
   the scope of this document.

Is it worth specifying that the documents that define the sub-TLVs
are responsible for considering the impact of partial support?

   If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
   TLV MUST be leaked into another level even though it may contain some
   of the unsupported sub-TLVs.

I think the final phrase would be better as "... even though it may
contain sub-TLVs that are not supported by the router leaking the
TLV."

6.  IANA Considerations

   IANA assigned a new IS-IS TLV code-point [...]

The usual form is "codepoint".  But perhaps that question is better
left to the RFC Editor.

7.  Acknowledgements

   For the original version of RFC 4971 the authors thanked Jean-Louis
   Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their
   useful comments.

"the original version of RFC 4971" is incorrect.  There are a number
of ways to fix this, but I suggest "the original version of this
document, RFC 4971, ...".

   For this new version the authors would like to thank Kris Michielsen
   for calling the problem associated w an IPv6 only router to our
   attention.

Change "w an IPv6 only" to "with an IPv6-only".

It would be easier to read as "... for calling to our attention the
problem associated ...".

Dale