Jim -
Thanx for the review.
I have posted V16 with the sentence you highlighted removed from the abstract.
It indeed was referring to RFC 7356.
Les
> -----Original Message-----
> From: Jim Guichard via Datatracker <nore...@ietf.org>
> Sent: Tuesday, April 15, 2025 8:46 AM
> To: The IESG <i...@ietf.org>
> Cc: draft-ietf-lsr-multi-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org;
> yingzhen.i...@gmail.com; yingzhen.i...@gmail.com
> Subject: Jim Guichard's No Objection on draft-ietf-lsr-multi-tlv-15: (with
> COMMENT)
>
> Jim Guichard has entered the following ballot position for
> draft-ietf-lsr-multi-tlv-15: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to the authors for this document, and a special thank you to the
> document shepherd for a very thorough review with pointers to much of the
> relevant WG discussion around specific points of contention. Most of my
> comments were nits that have been addressed by other reviewers ballots so I
> will not repeat them here. This leaves me with just a single comment on the
> abstract:
>
> Abstract#
>
> The sentence "Extensions exist that require significant IS-IS changes that
> could help address the problem, but a less drastic solution would be
> beneficial" implies that this document provides a pragmatic solution rather
> than a more intrusive update to the IS-IS protocol. This leaves me wondering
> what these extensions are, and I see no discussion around this further into
> the
> document (unless the text around [RFC7356] is what the authors were
> alluding
> too), or whether deployment of the solution in this document would allow for
> future extensions to be backwards compatible should the need arise to
> further
> define these "Extensions" in the future. Practically speaking I see no reasons
> why this should be a problem given that "significant IS-IS changes" could have
> implications far beyond MP-TLV so I am wondering if this sentence should just
> be removed as it does not really provide any value.
>
>
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
