Les, Perfectly fine by me. That suggestion was something that came up just reading through the abstract and was meant for someone who was reading that paragraph alone. It does become clear later that it must be per TLV based on the main body text. -Peter On 3/4/25, 4:54 PM, "Les Ginsberg (ginsberg)" <ginsberg@xxxxxxxxx <mailto:ginsberg@xxxxxxxxx>> wrote: Peter - Thanx very much for your review. I have made all the suggested editorial changes except one. I will upload V11 of the draft once the submission window reopens on March 16. Regarding your first comment: <snip> > Page 1, Abstract, 1st sentence: I’d append “per TLV” at the end of the sentence > as it wasn’t initially clear to me that the 255-octet limit was on a per TLV > basis and not across all TLVs sent. If this is obvious to most practitioners, > then this change is unnecessary. <end snip> The 255-octet limit arises because the size of the "length" field in a TLV is 8 bits. Therefore, I see no need to make the suggested change. Les > -----Original Message----- > From: Peter Yee via Datatracker <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> > Sent: Tuesday, March 4, 2025 2:27 AM > To: gen-art@xxxxxxxx <mailto:gen-art@xxxxxxxx> > Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx <mailto:draft-ietf-lsr-multi-tlv.all@xxxxxxxx>; last-call@xxxxxxxx <mailto:last-call@xxxxxxxx>; lsr@xxxxxxxx <mailto:lsr@xxxxxxxx> > Subject: Genart last call review of draft-ietf-lsr-multi-tlv-10 > > Reviewer: Peter Yee > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>>. > > Document: draft-ietf-lsr-multi-tlv-10 > Reviewer: Peter Yee > Review Date: 2025-03-04 > IETF LC End Date: 2025-02-25 > IESG Telechat date: 2025-04-17 > > Summary: This draft provides unified support for multi-part TLVs in IS-IS to > allow TLVs to exceed the 255-octet limit by splitting contents between multiple > TLVs. It updates an IANA registry to enumerate which existing TLVs can use the > multi-part mechanism. I did not attempt to validate the MP-TLV column given > in > the updated IANA instructions. I am not sufficiently cognizant of the problems > that might occur with multi-part TLVs to comment on whether there are some > tricky edge cases, but the recommendations given appear appropriate, > particularly the warning against deploying these MP-TLVs in networks that do > not fully understand them. There are some minor nits in the document that > should be fixed prior to publication. [Ready with Nits] > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > Page 1, Abstract, 1st sentence: I’d append “per TLV” at the end of the sentence > as it wasn’t initially clear to me that the 255-octet limit was on a per TLV > basis and not across all TLVs sent. If this is obvious to most practitioners, > then this change is unnecessary. > > Page 3, section 1, 4th paragraph, 1st sentence: chance “occurences” to > “occurrences”. > > Page 3, section 1, 6th paragraph: change “16 bit” to “16-bit”. > > Page 4, section 3.1, 2nd sentence: change “is” to “are”. > > Page 6, 2nd paragraph, last sentence: change “define” to “define(s)” to match > “specification(s)”. > > Page 8, section 7, 2nd paragraph: change “disgnosing” to “diagnosing”. > > Page 9, section 8, 1st sentence: change “interoperablity” to “interoperability”. > > Page 10, section 8.2, 1st paragraph, 2nd sentence: append a comma after > “restrictions”. > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
