Giuseppe -
V8 has been posted.
It addresses the two open points we have discussed.
Les
> -----Original Message-----
> From: Giuseppe Fioccola <giuseppe.fioccola=40huawei.com@xxxxxxxxxxxxxx>
> Sent: Wednesday, February 12, 2025 1:06 AM
> To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; ops-dir@xxxxxxxx
> Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
> 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) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
> Sent: Tuesday, February 11, 2025 6:02 PM
> To: Giuseppe Fioccola <giuseppe.fioccola@xxxxxxxxxx>; ops-dir@xxxxxxxx
> Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
> 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
> > <giuseppe.fioccola=40huawei.com@xxxxxxxxxxxxxx>
> > Sent: Tuesday, February 11, 2025 12:34 AM
> > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; ops-dir@xxxxxxxx
> > Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx;
> > lsr@xxxxxxxx
> > 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) <ginsberg@xxxxxxxxx>
> > Sent: Monday, February 10, 2025 6:39 AM
> > To: Giuseppe Fioccola <giuseppe.fioccola@xxxxxxxxxx>; ops-dir@xxxxxxxx
> > Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx;
> > lsr@xxxxxxxx
> > 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 <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.
> >
> > [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
> >
> > >
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
