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
