Sounds good. I’ll look for the new version. Barring any further last minute notes, it sounds like it should be ready to be sent to the RFC Editor. :-)
—John > On Aug 28, 2024, at 3:52 AM, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > [External Email. Be cautious of content] > > > Hi, John: > > Thanks! Yes, it should be the default preference and leave the flexibility > for the operator to maneuver it. > > I have changed the text and will upload it later together with other comments > from the IANA, or RFC editors. > > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 > 【外部账号】 John Scudder > 发送时间: 2024年8月27日 21:59 > 收件人: Aijun Wang <wangai...@tsinghua.org.cn> > 抄送: draft-ietf-pce-pcep-extension-native...@ietf.org; The IESG > <i...@ietf.org>; pce-chairs <pce-cha...@ietf.org>; pce@ietf.org; Murray > Kucherawy <superu...@gmail.com> > 主题: Re: [Pce] Murray Kucherawy's No Objection on > draft-ietf-pce-pcep-extension-native-ip-34: (with COMMENT) > > Hi Aijun, > > Thanks for the update. I have one note on this revised paragraph: > > The path established by this object MUST have higher priority than > the other paths calculated by dynamic IGP protocol, and MUST have > lower priority than the static route configured by manual or NETCONF > or any other static means. > > IMO MUST without any qualification is too strong here, because generally in > my experience, routing implementations let the operator configure the > sorting/priority order of different protocols. Would it be correct to add “by > default” here, as in, > > NEW: > By default, > the path established by this object MUST have higher priority than > the other paths calculated by dynamic IGP protocol, and MUST have > lower priority than the static route configured by manual or NETCONF > or any other static means. > > Thanks, > > —John > >> On Aug 27, 2024, at 3:22 AM, Aijun Wang <wangai...@tsinghua.org.cn> wrote: >> >> [External Email. Be cautious of content] >> >> >> Hi, John: >> >> Thanks for your remind. >> I upload again the updated version to solve Murray's comments on this >> document. >> The usage of "SHOULD" is decreased at it is replaced with non-RFC2119 work, >> or enhanced with the replace of "MUST“. >> >> The updates covers the section 10 and section 7.3 that Murray mentioned, and >> also the section 7.2 and 7.4 for the similar descriptions. >> >> Wish they can address the concerns that raised by Murray. >> It seems after the several round changes, the mode for the >> "SHOULD/MUST" has fallen back to the version 34 in some extents, as >> you have suggested :) >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----邮件原件----- >> 发件人: forwardingalgori...@ietf.org >> [mailto:forwardingalgori...@ietf.org] 代表 John Scudder >> 发送时间: 2024年8月27日 2:34 >> 收件人: draft-ietf-pce-pcep-extension-native...@ietf.org >> 抄送: The IESG <i...@ietf.org>; pce-chairs <pce-cha...@ietf.org>; >> pce@ietf.org; Murray Kucherawy <superu...@gmail.com> >> 主题: [Pce] Re: Murray Kucherawy's No Objection on >> draft-ietf-pce-pcep-extension-native-ip-34: (with COMMENT) >> >> Hi Authors, >> >> I think you might have overlooked replying to Murray’s question. >> >> —John >> >>>> On Aug 22, 2024, at 2:39 AM, Murray Kucherawy via Datatracker >>>> <nore...@ietf.org> wrote: >>> >>> >>> Murray Kucherawy has entered the following ballot position for >>> draft-ietf-pce-pcep-extension-native-ip-34: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/st >>> a >>> tements/handling-ballot-positions/__;!!NEt6yMaO-gk!CB1o2jlxBvTh_Pxjyz >>> g _DCX1oY1AUsUhpAhzalTBCr84oba8fUeDGriejxGLpyCDl4PbiJ1u4pva$ >>> for more information about how to handle DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie >>> t >>> f-pce-pcep-extension-native-ip/__;!!NEt6yMaO-gk!CB1o2jlxBvTh_Pxjyzg_D >>> C X1oY1AUsUhpAhzalTBCr84oba8fUeDGriejxGLpyCDl4PbiLZbCgGX$ >>> >>> >>> >>> --------------------------------------------------------------------- >>> - >>> COMMENT: >>> --------------------------------------------------------------------- >>> - >>> >>> The SHOULD in Section 10 and the RECOMMENDED in Section 7.3 seem to >>> be unsupported. Why might an implementer choose not to do what they say? >>> What's the impact to interoperability? >>> >>> I echo Roman's question about the document's status. >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list -- pce@ietf.org >>> To unsubscribe send an email to pce-le...@ietf.org >> >> _______________________________________________ >> Pce mailing list -- pce@ietf.org >> To unsubscribe send an email to pce-le...@ietf.org >> > > _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
