Speaking as WG Co-Chair: Hi Les, There are many opinions in the IETF and I don’t see why the authors can’t respond to the OPS review while a appeal is in progress. Thanks, Acee > On Nov 17, 2024, at 23:02, Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> wrote: > > 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
