Thank you Les for the information!
Regards,
Giuseppe
-----Original Message-----
From: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>
Sent: Monday, November 18, 2024 5:02 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 -
Thanx for the review.
A WG member has filed an appeal to the IESG regarding WG last call consensus on this document.
Authors have decided to wait for that appeal process to complete before resuming work on the document.
Once that process completes, we will (if still appropriate) resume work on the document - at which time we will review and respond to your comments.
Thanx very much for your patience.
Les
> -----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.
>
> 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
