[netconf] Re: [Tsv-art] UDP default port

[Kent Watsen <[e-mail]>]

> Hi Joe and UDP-Notif Authors,
> 
> It seems that this thread has stalled.  What can we do to move it forward?  
> 
> Kent and Per // NETCONF chairs


A couple thought-provoking questions:

What does "udp-notif" bring that isn’t supported by the "https-notif" draft, assuming the https-notif draft supports the QUIC transport?
If the https-notif draft with QUIC transport is deemed unacceptable, would a "quic-notif” draft work?


PROs:

QUIC is well-defined (RFC 9000) and tooling should prominent.
HTTP/3 is well-defined (RFC 9114) and tooling should prominent. 
QUIC supports reliability on a per frame-type basis, thus muxing both types is possible (see RFC 9221)
Stateful firewalls supporting QUIC will allow the return packets, thus enabling an “encoding-discovery” mechanism.
QUIC is still UDP, and so (I think) continues to support the properties desired by the “distributed-notify” draft.
Anything else?

CONs:

No ability to disable encryption (for “private” networks)
I don’t know how big of a problem this is.
Assuming long-lived connections, the overhead of the asymmetric key handshake is negligible.
The overhead for symmetric-key encryption (e.g., AES) is also pretty negligible
The “overhead” is mostly a concern on the receiver-side, as logging is a many-to-one activity, but it’s easy to scale receivers.
Encryption negates the ability to copy frames directly to persistent storage.  This is unlikely a good idea anymore, but ~20 years ago I designed the binary logging protocol such that the packets could be mmap-ed directly to disk, in their final storage format (note: a post-sweep would build indices).
Anything else?


Kent / contributor