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