Hi John, Thanks for your comment, we have updated the draft according to your comments, please check. Link: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-optional-11
Thanks, Cheng From: Dhruv Dhody <d...@dhruvdhody.com> Sent: Tuesday, November 19, 2024 5:29 AM To: John Scudder <j...@juniper.net> Cc: The IESG <i...@ietf.org>; draft-ietf-pce-stateful-pce-optio...@ietf.org; pce-cha...@ietf.org; pce@ietf.org Subject: Re: John Scudder's No Objection on draft-ietf-pce-stateful-pce-optional-10: (with COMMENT) Hi John, On Tue, Nov 19, 2024 at 2:59 AM John Scudder via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: John Scudder has entered the following ballot position for draft-ietf-pce-stateful-pce-optional-10: 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-positions/ 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-pce-stateful-pce-optional/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. I have two questions: ### Section 2, why not MUST? ``` When the P flag is set in the PCRpt message received on a PCEP session on which the R bit was set by both peers, the object SHOULD be taken into account by the PCE. ``` Under what circumstances is it OK for the PCE to ignore an object whose P flag is set? In other words, why isn't this a MUST? Dhruv: Good point! Authors/WG - any objection to making it a MUST? [Cheng]Yes, MUST is correct. Also ‘was’=>‘is’ ### Section 4, explicitly set aside ``` As per [RFC8231], it is RECOMMENDED that these PCEP extensions can only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253] as per the recommendations and best current practices in [RFC9325] (unless explicitly set aside in [RFC8253]). ``` I'm curious about the parenthetical comment. Can you provide an example of a recommendation or best current practice that was explicitly set aside in RFC 8253? I did go look at the Security Considerations of RFC 8253 and didn't see anything like that. Dhruv: We have been sticking to this text that had an agreement with past Sec ADs. There are some details in Section 3.4 of RFC 8253 that might not be matching exactly to RFC 9325 - such as MUST for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 in RFC 8253 where as RECOMMENDED in RFC 9325. Thanks! Dhruv (as document shepherd) [Cheng]We can delete this. Please see the diff.
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
