Hi Joe, Thank you for your TSVART review! :) Regarding if QUIC is already a valid transport, it is the WG's understanding that QUIC is already a valid transport for RESTCONF. From reading [1] very carefully (with a "no lies detected" lens) and looking at [2] (which normatively binds TLS1.3), it does not seem that an RFC needs to be published to explicitly allow RESTCONF to be used over QUIC. Do you agree? FWIW, This was discussed briefly during the IETF 122 with no objections, see the "NETCONF over QUIC" section in the Minutes [3]. But this thread touches on a larger edit being made by the bis. Note that the previous version of this paragraph [4] referenced specific transport-binding documents (e.g., RFC 6242). It was decided that such specific references don't age well and, more generally, are distracting from the primary focus/point of the sentence, which is that all YANG-based management protocols require transports that are both encrypted and have mutual authentication. This sets the stage for the rest of the text in the template. All this to say, even if there were an easy reference to where RESTCONF uses QUIC, the nature of this larger edit would not include it. This is why the current text doesn't include such a reference. Separately, your TSVART review has text "RESTCONF is exclusively defined over HTTP, TCP, and TLS (RFC8200)". RFC 8200 is "Internet Protocol, Version 6 (IPv6) Specification". Did you mean something else? [1] https://www.rfc-editor.org/rfc/rfc8040.html#section-2 [2] https://datatracker.ietf.org/doc/html/rfc9001#section-1 [3] https://datatracker.ietf.org/doc/minutes-122-netconf-202503180600 [4] https://www.rfc-editor.org/rfc/rfc8407.html#section-3.7.1 Thanks, Kent -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
