[netmod] Re: [Tsv-art] [Last-Call] draft-ietf-netmod-rfc8407bis-25 ietf last call Tsvart review

["[e-mail]" <[e-mail]>]

Hi, Kent,

> On May 16, 2025, at 9:06 AM, Kent Watsen <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]