Giuseppe - Now that IESG appeal has been resolved, we are resuming work on this document. Thanx for your patience in waiting for a response to your comments. V7 has been published. Sections 3 and 4 have been rewritten and reordered to hopefully make a clearer presentation. Some responses to specific points inline. > -----Original Message----- > From: Giuseppe Fioccola via Datatracker <noreply@xxxxxxxx> > Sent: Friday, November 15, 2024 3:30 AM > To: ops-dir@xxxxxxxx > Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx > Subject: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 > > 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. [LES:] Every codepoint which is impacted is explicitly listed in Section 9.2 where we specify an additional column to indicate MP-TLV applicability in the appropriate IANA registry. If you examine those registries, you will see they already contain a link to the RFC which defines the associated codepoint. I think this suffices as an explicit list of the documents which would be considered as updated - and is more accurate than any arbitrary listing would be. > > 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. > [LES:] Section 5 and 6, as well as Section 8 already provide such information. > 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. > [LES:] The reordering/revision of Sections 3 and 4 is aimed at accomplishing this. > - 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. > [LES:] Section 4 discusses this - and Section 8.1 discusses an associated alarm. > - 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...). > [LES:] There is no plan to define a YANG model for MP-TLV because it isn’t a global feature - it is a per codepoint feature. As an offshoot of this work, several Protocol Implementaton Conformance Statement (PICS) YANG models have been initiated as we believe that is the appropriate context in which to provide management information. See https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-pics-yang/ and https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-pics-srmpls-yang/ . To fully cover all aspects of the protocol, many more such documents will be required. > - 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". > [LES:] I do not agree. The new sub-TLV is an optional extension (though support for it is encouraged) and its value is only informational i.e., MP-TLV support can be present even in the absence of the advertisement of the new sub-TLV. I think its placement in the document is appropriate. Les > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
