Hey Gunter, See one correction below.
> On Apr 16, 2025, at 3:26 AM, Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com> wrote: > > Hi Aijun, > > First, the open DISCUSS items raised by Ketan are actively being addressed > through ongoing discussions between Ketan and the MP-TLV document authors. > The collaboration has been productive, and the conversation is progressing > well toward resolving the identified blocking issues. I see no reason to > return the MP-TLV document to the Working Group at this time. > > Secondly, the procedures used during IESG review are well documented. Let me > repeat what Roman already shared with you on 2 April 2025. > > 1. The document in question is currently scheduled for the 17-May-2025 formal > IESG telechat. You mean April 17, 2025 (tomorrow). The LSR WG has other work to do and this document needs to be progressed without further delay. Thanks, Acee > See https://datatracker.ietf.org/iesg/agenda/documents/ . > > 2. The meeting rules set for the formal IESG telechat can be found at > (https://wiki.ietf.org/group/iesg/StandingMeetings). While the community is > welcome to join without invitation, this meeting (IESG formal telechat) is > not a discussion with the community. > > 3. And finally, any analysis, review, or feedback by the IESG will be > captured in their written ballot and viewable at > https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ballot/. See > https://www.ietf.org/process/process/iesg-ballots/ for more details on the > IESG balloting process. An incomplete summary of this process is that the > IESG’s “analysis and review” could be substantive text or also a balloting > position (e.g., “Yes”, or “No Objection”) with no explanation. Blocking > balloting positions (e.g., “Discuss”) do require an explanation. > > Kind Regards, > Gunter Van de Velde > Routing Area Director > > > -----Original Message----- > From: Aijun Wang <wangai...@tsinghua.org.cn> > Sent: Wednesday, April 16, 2025 5:11 AM > To: 'Jim Guichard' <james.n.guich...@futurewei.com>; 'Ketan Talaulikar' > <ketant.i...@gmail.com>; Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com> > Cc: 'The IESG' <i...@ietf.org>; draft-ietf-lsr-multi-...@ietf.org; > lsr-cha...@ietf.org; lsr@ietf.org; yingzhen.i...@gmail.com > Subject: 答复: [Lsr] Jim Guichard's No Objection on > draft-ietf-lsr-multi-tlv-15: (with COMMENT) > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > 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
