Hi John, On Tue, Nov 19, 2024 at 2:59 AM John Scudder via Datatracker < 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? > ### 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)
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
