On Wed, Dec 18, 2024 at 4:02 PM Dhruv Dhody <d...@dhruvdhody.com> wrote:
> Hi Zahed, > > On Wed, Dec 18, 2024 at 8:15 PM Zaheduzzaman Sarker via Datatracker < > nore...@ietf.org> wrote: > >> 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? >> >> > Dhruv: The only reference to QUIC is in security consideration, the text > is as per the updated security consideration template for YANG at > https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-21.html#section-3.7.1 > This is not about PCEP using QUIC, instead it is about NETCONF and > RESTCONF using QUIC. > Thanks Dhrub for this clarification, this was the source of confusion for me. I didn't read the sentence in the security consideration section only applicable to NETCONF and RESTCONF. > > Regarding 0-RTT for TLS 1.3, we have it handled in - > https://datatracker.ietf.org/doc/draft-ietf-netconf-over-tls13/ (in RFC > Editor Queue) > This means the QUIC 0-RTT related observation still holds if we run netconf over QUIC, as mentioned in the security section. > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ (PCEP also > handles it, also in RFC Editor Queue) > And this is for pceps over TLSs, so I would expect if we have QUIC for PCEP then that would cover the =-RTT data handling. > > > >> 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? >> >> > Dhruv: Though there is an individual draft that proposes QUIC for PCEP, it > has not been adopted yet and thus it is premature to add it to YANG. > OK > > > >> 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. >> >> >> > Dhruv: I hope I have answered these to your satisfaction. > Well, I am OK for now and would follow how QUIC for PCEP progresses. Thanks. //Zahed > > Thanks! > Dhruv > > >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
