Thanx Giuseppe.
I do note, however, that the status of your review indicates "Not ready".
Are there still open issues or do you just need to update the status?
Thanx.
Les
> -----Original Message-----
> From: Giuseppe Fioccola <giuseppe.fioccola=40huawei.com@xxxxxxxxxxxxxx>
> Sent: Thursday, February 13, 2025 2:21 AM
> To: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>; 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 addressing my suggestions. I just checked the new revision.
>
> Regards,
>
> Giuseppe
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
> Sent: Wednesday, February 12, 2025 6:59 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 -
>
> 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
