Hi, Jim, Ketan and Gunter: Until now, all the ADs of routing area have finished the review of this document, but leave the unsolved challenges untouched, which are more important to the future deployment of such proposal. Ketan raised the new, undiscussed " the nested encapsulation of the current MP-TLV proposal " in "DISCUSS" status, which is also unsolved and can't be solved for such proposal.
In previous response from our chair of IESG for such arguments (https://mailarchive.ietf.org/arch/msg/lsr/DbgM2i0AVLeeQsU2AtrDUzgEdww/), Roman states: 'The IESG notes, however, that the path to publication is not complete and there remain gates through which the document must pass prior to publication, such as IETF Last Call and IESG Evaluation, and these are points at which this and any other post-WGLC feedback will need to be addressed.' But until now, even the ADs of the routing area didn't touch these ambiguous, unsolved technical points, I can't expect other Ads will step in to solve them. It seems there is one loop here: 1) If the WGLC can't solve the challenges, then we can expect them to be solved in IESG Last call, or IESG review. 2) In IESG Last call/IESG review, such challenges should be solved, discussed within WG itself, not at this later stage. To break the above loop or dilemma, and provide the IETF community chaos-free proposal, should this document be returned to the LSR WG for further refinement and comparing/competing with other new proposal? Aijun Wang China Telecom -----邮件原件----- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Jim Guichard via Datatracker 发送时间: 2025年4月15日 23:46 收件人: The IESG <i...@ietf.org> 抄送: draft-ietf-lsr-multi-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; yingzhen.i...@gmail.com 主题: [Lsr] 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 _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
