IS-IS Extensions for Advertising Router Information
draft-ietf-isis-rfc4971bis-04

Thank you for addressing my DISCUSS. I hope you can look at addressing comments as well:

1) In Section 4, 1st sentence: how can this specification have requirements on implementation that don't support this extension?

As per Alia:

RFC1195 says
"   Any codes in a received PDU that are not recognised shall be ignored
   and, for those packets which are forwarded (specifically Link State
   Packets), passed on unchanged."

So I think the document should mention RFC 1195 and don't use RFC 2119 keywords for something which is already stated there. For example:

OLD:

Routers that do not support the Router CAPABILITY TLV MUST silently
   ignore the TLV(s) and continue processing other TLVs in the same LSP.

NEW:

As per RFC 1195, routers that do not support the Router CAPABILITY TLV will silently
   ignore the TLV(s) and continue processing other TLVs in the same LSP.

2) It would be helpful if the document gave an example of multiple CAPABILITY TLVs containing non conflicting information and how it is to be handled.

3) Should subTLVs have an IANA registry? Or is there an existing one already?

The first sentence in section 4 says:

   Routers that do not support the Router CAPABILITY TLV MUST silently
   ignore the TLV(s) and continue processing other TLVs in the same LSP.

Is this the authoritative text for a new requirement, or is that preexisting behavior defined elsewhere? If the former, why would we expect an implementation that does not implement this spec (perhaps the implementors haven't read it) to honor this requirement? If the latter, then please state it descriptively (i.e. without 2119 keywords), preferably with a citation.

Ron Bonica performed the opsdir review.

I know this is a bis doc that mainly clarifies one point. However, as there were also other smaller updates, here are some additional comments that could be considered:

1) To me the text in section 2 reads like: if S is not set D should be ignored. Is this correct? If so, it could be spelled out like this. If not, what happens if S is not set but D is?

2) The text says: „Where a receiving system has two copies of a CAPABILITY TLV from the
   same system that have different settings for a given attribute, the
   procedure used to choose which copy shall be used is undefined.“
  Why is there no default given here? Not defining something like this can lead to problems. I would strongly recommend to define a default behavior.

3) Further it says: „How partial support may impact the operation of the
   capabilities advertised within the Router CAPABILITY TLV is outside
   the scope of this document.“
   While it might be true that this is specific to the capability, I would put a MUST requirement in here for future specifiactions: Partial suport MUST be defined in the document that describes the subTLV.

4) On this sentence: „Routers that do not support the Router CAPABILITY TLV MUST silently
   ignore the TLV(s) and continue processing other TLVs in the same LSP.“
   What does "silently" mean here? Is it not allowed to log such an event? I would recommend to either clarify that "silently" means here or remove that word.

5) In this sentence: "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
   TLV MUST be leaked into another level without change even though it
   may contain some sub-TLVs which are unsupported by the Router doing
   the leaking.“
  I would recomend to use the normative language differently to be clear about what it applies to: 
"If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
   TLV MUST NOT change sub-TLVs which are unsupported by the Router doing
   the leaking.“

6) In section 5: „Note that an integrity mechanism, such as the one
   defined in [RFC5304] or [RFC5310], should be applied if there is high
   risk resulting from modification of capability information.“ 
  Why is that a SHOULD and what's a „high risk“?  It should me either "MUST be applied at high risk" and defining what a high risk is, or it should be "SHOULD be applied at (any) risk".

Thanks for addressing my DISCUSS point in version -04.