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>
> Sent: Tuesday, March 4, 2025 2:27 AM
> To: gen-art@xxxxxxxx
> Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; 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>.
>
> 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
