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

Reply via email to