[Pce] Re: Murray Kucherawy's No Objection on draft-ietf-pce-pcep-extension-native-ip-34: (with COMMENT)

[John Scudder <[e-mail]>]

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 <[e-mail]> 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
> 
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 【外部账号】 John Scudder
> 发送时间: 2024年8月27日 21:59
> 收件人: Aijun Wang <[e-mail]>
> 抄送: [e-mail]; The IESG <[e-mail]>; pce-chairs <[e-mail]>; [e-mail]; Murray Kucherawy <[e-mail]>
> 主题: 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 <[e-mail]> 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
>> 
>> -----邮件原件-----
>> 发件人: [e-mail]
>> [mailto:[e-mail]] 代表 John Scudder
>> 发送时间: 2024年8月27日 2:34
>> 收件人: [e-mail]
>> 抄送: The IESG <[e-mail]>; pce-chairs <[e-mail]>;
>> [e-mail]; Murray Kucherawy <[e-mail]>
>> 主题: [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 <[e-mail]> 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 -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> 
>> _______________________________________________
>> Pce mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>> 
> 
>