Giuseppe - V8 has been posted. It addresses the two open points we have discussed.
Les > -----Original Message----- > From: Giuseppe Fioccola <[email protected]> > Sent: Wednesday, February 12, 2025 1:06 AM > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: RE: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 > > Hi Les, > Please see inline [GF]. > > Regards, > > Giuseppe > > -----Original Message----- > From: Les Ginsberg (ginsberg) <[email protected]> > Sent: Tuesday, February 11, 2025 6:02 PM > To: Giuseppe Fioccola <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: RE: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 > > Giuseppe - > > Thanx very much for the prompt response. > I think we are in agreement on most things. > > [GF]: Agree. > > Some responses inline. Look for {LES2:]. > > > -----Original Message----- > > From: Giuseppe Fioccola > > <[email protected]> > > Sent: Tuesday, February 11, 2025 12:34 AM > > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] > > Cc: [email protected]; [email protected]; > > [email protected] > > Subject: RE: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 > > > > Hi Les, > > Thank you for considering my comments. > > Please see my replies inline as [GF] > > > > Regards, > > > > Giuseppe > > > > -----Original Message----- > > From: Les Ginsberg (ginsberg) <[email protected]> > > Sent: Monday, February 10, 2025 6:39 AM > > To: Giuseppe Fioccola <[email protected]>; [email protected] > > Cc: [email protected]; [email protected]; > > [email protected] > > Subject: RE: Opsdir last call review of draft-ietf-lsr-multi-tlv-06 > > > > 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. > > > > [GF]: Good! > > > > Some responses to specific points inline. > > > > > > > -----Original Message----- > > > From: Giuseppe Fioccola via Datatracker <[email protected]> > > > Sent: Friday, November 15, 2024 3:30 AM > > > To: [email protected] > > > Cc: [email protected]; [email protected]; > > > [email protected] > > > 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. > > > > [GF]: Thank you for the explanation. I just meant the possibility to > > include the updated RFCs in the header of the document too. But I > > understand your choice. > > > > > > > > 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. > > > > [GF]: Ok, maybe you can consider to add a pointer to the relevant > > sections so that the reader can easily find such information. > > [LES2:] I think that Section 5 is really talking about deployment > considerations. > I would be fine with incorporating that text into Section 8. > Section 6 is describing the correct way for an implementation to process MP- > TLVs when received. This isn't a deployment consideration - it is necessary > for > correct processing of the information received - so I think it isn’t > logically linked > to Section 8 and should remain as is. > > If this makes sense to you, I will make the necessary changes. > > [GF]: I would incorporate some text into section 8, but I leave it to you. > > > > > > 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. > > > > [GF]: Thanks! > > > > > - 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. > > > > [GF]: Ok, I see. > > > > > - 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. > > > > [GF]: Thank you for the references. > > > > > - 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. > > > > [GF]: I suggested the change because, as a reader of v-06, this > > section clarified a question about the capability advertisement that > > comes to my mind earlier in the document. The organization of v-07 > > improved this aspect. But, in any case, I see the current section 8.2 > > on "MP-TLV Capability Advertisement" more as part of the TLV > > definition than a subsection under "Deployment Considerations". For > > example, it could also be a separate section before section 8. > > > [LES2:] It is currently in the Deployment Considerations Section because it > is an > optional advertisement which is not used by the protocol itself. It is > provided > only as an informational aid to operators. > But, I see your point. If you think it would be helpful to make this a > separate > section (preceding current Section 8) I think that would be fine. > > [GF]: I think it would be good to make it a separate section even if it is an > optional feature. > > Les > > > Les > > > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
