Zaheduzzaman Sarker has entered the following ballot position for draft-ietf-pce-pcep-yang-28: Discuss
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-pcep-yang/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for working on this specification, specially for the hard work needed to pull of such a long specifications. Thanks to Mihael for his TSVART review. I have two points I would like to discuss so that we can clarify the specification better ( and it might be also coming from my lack of grasping the long specification ) 1. I saw QUIC (RFC9000) is mentioned to used as secure transport to PCEP communication as par with TLS. What I would like to understand why there is no special considerations posed for 0-RTT data while there is MUST not use restriction for TLS1.3 early data? 2. While the capabolity leafs has entry for TCP-AO, TLS usage, it does not have any capablity to indicate the support of QUIC. How would the PCE elements discover and use QUIC as a secure transport? Both of those above points indicates that the QUIC usage is underspecified to be used as secure transport for this protocol. I would like see that I am incorrect in my assertion in this regard. _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
