Hi, Gunter: Kegan’s DISCUSS is one additional issue raised during the IESG review.
Other additional issues, for example, the unlimited boundaries is also unsolved until now. Together also the most important ‘key’ issue that you don’t want to step in, and the LSR chairs think they are already solved but can’t answer the question explicitly(the example is described also by the authors but there is no any expert can give the response, just called/declared they are solved) If any expert declare they are solved, please give the pointer). I will wait for the final evaluation of IESG on this document and would like to ask one question: If the IESG doesn’t return this work to LSR WG, or ANANDON it directly, what’s the other mean/procedure to achieve such goal then? IETF shouldn’t hurry to pass such fraught with problems document. Aijun Wang China Telecom > On Apr 16, 2025, at 18:49, Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com> wrote: > > Yes, 17 April 2025 (tomorrow). Good catch. It was a typo. > > G/ > > -----Original Message----- > From: Acee Lindem <acee.i...@gmail.com> > Sent: Wednesday, April 16, 2025 12:46 PM > To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> > Cc: Aijun Wang <wangai...@tsinghua.org.cn>; Jim Guichard > <james.n.guich...@futurewei.com>; Ketan Talaulikar <ketant.i...@gmail.com>; > The IESG <i...@ietf.org>; draft-ietf-lsr-multi-...@ietf.org; > lsr-cha...@ietf.org; lsr <lsr@ietf.org>; yingzhen.i...@gmail.com > Subject: Re: [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. > > > > 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-posi >> tions/ 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 _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
