Peter -
V11 of the draft has been posted.
Thanx again for your review.
Les
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> Sent: Tuesday, March 4, 2025 7:54 AM
> To: Peter Yee <pe...@akayla.com>; gen-...@ietf.org
> Cc: draft-ietf-lsr-multi-tlv....@ietf.org; last-c...@ietf.org; lsr@ietf.org
> Subject: RE: Genart last call review of draft-ietf-lsr-multi-tlv-10
>
> 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 <nore...@ietf.org>
> > Sent: Tuesday, March 4, 2025 2:27 AM
> > To: gen-...@ietf.org
> > Cc: draft-ietf-lsr-multi-tlv....@ietf.org; last-c...@ietf.org; lsr@ietf.org
> > 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”.
> >
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
