Hi, Kent, > On May 16, 2025, at 9:06 AM, Kent Watsen <[email protected]> wrote: > > 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].
There’s a difference between whether an RFC is *required* vs. whether a document exists that provides an example, notably a standards track one. That doc exists - the draft - and not citing it is a disservice to the reader. You and others do a lot of tap-dancing to justify the omission of a citation that costs you nothing to include. > 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. Sorry, but if your point is “RFC citations don’t age well”, I encourage you to withdraw this contribution. ALL RFC citations don’t age well. URLs don’t age well. RFCs themselves don’t age well. This doc is best CURRENT practice. Nothing CURRENT ages well. > 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. Again, a story isn’t what I asked for, nor what will help when someone reading the doc COULD have benefitted from the citation. > 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? I didn’t intent to include any citation; please ignore that. I withdraw my conclusion about TCP in that set - TLS does include “TCP” in one place, but it’s sufficiently generic that I agree that RESTCONF can run over TCP without updating the RESTCONF RFC. Joe > > [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 > > > _______________________________________________ > Tsv-art mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
