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? ### 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. _______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
