Hi Aijun, Thanks for the quick turnaround.
I didn’t have time to do a full review but I notice you appear to have done a global search-and-replace of “should” with “SHOULD”. This has led to a new problem; Roman dropped his old DISCUSS (thanks for that) but entered a new one based on the new use of SHOULD. I imagine a review comment triggered the global replacement. I haven’t found the comment, however I doubt the ask was to do a global replacement! I suggest reverting the global change, which would (I believe) fix Roman’s new DISCUSS. Then we can consider if there is a need for other should/SHOULD changes on a case-by-case basis. If you agree to revert the should/SHOULD change, I encourage you to publish the new version right away; I would rather review the 34->36 diff than the rather noisy 34->35 diff. On a related topic, Zahed’s COMMENT asks about two SHOULD clauses in the 34 version (i.e. they are not affected by the global change). I’m not sure what your answer is, but I suggest changing those two to MUST unless you think there is some reason not to (in which case please help us understand). Thanks! —John On Aug 22, 2024, at 4:41 AM, Aijun Wang <wangai...@tsinghua.org.cn> wrote: Hi, Roman, John and Dhruv: I have updated the document according to your following suggestions: 1) Add the normative reference to draft-ietf-pce-iana-update, as John suggested. Wish we can forward “draft-ietf-pce-iana-update” in fast track. 2) Add the suggested descriptions from Dhruv for the “Experimental Status” of this document as one new subsection “section 2.2 Experimental Status Consideration” I will upload the updated document later, together with other expert’s review. Thanks all your efforts for the suggestions! Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> [mailto:forwardingalgori...@ietf.org] 代表 Roman Danyliw 发送时间: 2024年8月22日 8:50 收件人: John Scudder <j...@juniper.net<mailto:j...@juniper.net>>; Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> 抄送: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-pce-pcep-extension-native...@ietf.org<mailto:draft-ietf-pce-pcep-extension-native...@ietf.org>; pce-chairs <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org> 主题: [Pce] Re: Roman Danyliw's Discuss on draft-ietf-pce-pcep-extension-native-ip-34: (with DISCUSS and COMMENT) Hi! From: John Scudder <j...@juniper.net<mailto:j...@juniper.net>> Sent: Wednesday, August 21, 2024 8:37 PM To: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>; Roman Danyliw <r...@cert.org<mailto:r...@cert.org>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-pce-pcep-extension-native...@ietf.org<mailto:draft-ietf-pce-pcep-extension-native...@ietf.org>; pce-chairs <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>;pce@ietf.org<mailto:pce@ietf.org> Subject: Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-pcep-extension-native-ip-34: (with DISCUSS and COMMENT) Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe. Hi All, On Aug 20, 2024, at 3:21 PM, John Scudder <j...@juniper.net<mailto:j...@juniper.net>> wrote: To add to what Dhruv wrote, On Aug 20, 2024, at 1:16 PM, Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> wrote: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Section 14.2. 14.2. PCECC-CAPABILITY sub-TLV's Flag field [RFC9050] created a sub-registry within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the value of the PCECC- CAPABILITY sub-TLV's 32-bit Flag field. IANA is requested to allocate a new bit position within this registry, as follows: The registration policy of PCECC-CAPABILITY sub-TLV (https://www.iana.org/assignments/pcep/pcep.xhtml#pcecc-capability<https://urldefense.com/v3/__https:/www.iana.org/assignments/pcep/pcep.xhtml*pcecc-capability__;Iw!!NEt6yMaO-gk!B5PLFQZKBPmXYlwyMLc8dKsZAHy4c44OJGkxvAvngU6q_uyvvDK6tLmHr5iCB7dAiMekXL_kprM$>) is “Standards Action”. This document has experimental status and does not qualify for registration. Dhruv: We have a document in the PCE WG to fix it - https://datatracker.ietf.org/doc/draft-ietf-pce-iana-update/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-pce-iana-update/__;!!NEt6yMaO-gk!B5PLFQZKBPmXYlwyMLc8dKsZAHy4c44OJGkxvAvngU6q_uyvvDK6tLmHr5iCB7dAiMekFueWoGw$> The document is being fast tracked by the WG. Note that this code point has already been allocated through the temporary allocation process and doesn’t expire until 2025-08-14. I anticipate that draft-ietf-pce-iana-update will have been progressed well before then, at which point the code point can be made permanent. It subsequently occurred to me that if draft-ietf-pce-pcep-extension-native-ip adds a normative reference to draft-ietf-pce-iana-update then we should be all set — draft-ietf-pce-pcep-extension-native-ip can enter the RFC Editor's queue and they can start work on it, but those concerned about the registration policy issue can rest assured that it won’t be issued as an RFC until draft-ietf-pce-iana-update is also published (it’ll be a cluster, because of the normative ref). Q.E.D., the problem will be resolved by or before the time the RFC is issued. Work for everyone? [Roman] Yes. That works for me. Roman
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
