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
