Reviewer: Giuseppe Fioccola Review result: Not Ready This document is quite clear for its scope, but I have concerns about the overall organization of the document and I think that its structure can be improved. The mechanism of Multi-part TLVs in IS-IS is useful when the remaining space in the TLV is insufficient to advertise all the other sub-TLVs, considering that the contents of many critical TLVs may exceed the currently supported limit of 255 octets. I'm wondering whether you already considered the possibility for this document to explicitly update the RFCs (e.g. RFC 5120, RFC 5305...) where no extension mechanism has been previously specified. >From an OPSDIR point of view, the document includes a section on "Deployment Considerations" and it is good. In this section, I would provide more operational guidelines to overcome interoperability issues. To improve the document structure, I have the following suggestions: - I think it would be better for a reader to have first the general description of the procedures for advertising and receiving MP-TLVs and then the examples of sections 4.1 and 4.2 which can be placed in a separate section. - Regarding section 5 on "Procedure for Receiving Multi-part TLVs" I would also mention what happens if a node accidentally receives MP-TLVs and does not support it. - Regarding section 7.1 on "Recommended Controls and Alarms" I suggest to provide further details about the possible controls and alarms for the MP-TLVs with actual examples (e.g. NETCONF YANG, YANG Push...). - I think that section 7.2 on "MP-TLV Capability Advertisement" is relevant for the general description of the mechanism and therefore must be moved earlier in this document, e.g. as a subsection of section 4 on "Procedure for Advertising Multi-part TLVs". -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
