[netconf] Re: YANG Groupings for QUIC clients and QUIC servers

[[e-mail]]

Re-,

Please see one comment inline.

Cheers,
Med

> -----Message d'origine-----
> De : Per Andersson <[e-mail]>
> Envoyé : mardi 2 juillet 2024 15:28
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]
> Objet : Re: [netconf] YANG Groupings for QUIC clients and QUIC
> servers
> 
> 
> Hi Med,
> 
> On Tue, Jul 2, 2024 at 6:43 AM <[e-mail]>
> wrote:
> >
> > Hi Per,
> >
> > Thank you for sharing.
> 
> Thank you for reviewing!
> 
> 
> > The current groupings do not include QUIC specifics, which is
> OK for -00 to trigger the discussion.
> 
> That was my intention. :-)
> 
> 
> > If the intent is to document very basic groupings (current -00
> scope), then I see commonalities with schemes where UDP/DTLS is
> used (see for example draft-ietf-netconf-udp-notif). I think that
> it is worth to factorize here rather than having another yet
> document for that specific scope. I tend to suggest the
> following:
> >
> > * Consider updating draft-ietf-netconf-udp-client-server with
> reusable
> > UDP+(D)TLS groupings + define dtls1.2/1.3/quic features
> > * Arrange the DTLS container in draft-ietf-netconf-udp-notif to
> call
> > reusable groupings in draft-ietf-netconf-udp-client-server
> >
> > This is basically about rearranging the content between these
> two documents, but the content is almost there.
> 
> There are specifics that one could want to configure that would
> tie into other work in the NETCONF WG.
> 
> For instance the following are specific to QUIC, but could be
> benefitial for NETCONF, RESTCONF, https-notif, if they opt to use
> QUIC or HTTP/3 as a transport: supported QUIC version, max idle
> timeout, initial max data, various flow control parameters, max
> incoming streams, various other QUIC transport parameters and
> possible extensions.

[Med] These falls more under the spirit of draft-ietf-tcpm-yang-tcp. Other candidate specifics are: PMTU, manage features related to DATAGRAM/STREAM, CID control for load-balancing purposes, CID renewal policy, multipath support, proxing, etc. Not all of these will need to be covered, though.

> 
> I think there are enough QUIC specifics to warrant another
> client-server document with reusable groupings for configuring
> QUIC clients and servers, instead of adding them to udp-client-
> server.

[Med] I was not suggesting to add QUIC specifics to the udp-client-server :-) My proposal was specific to the current groupings in -00 which are not specific to QUIC and can be used for UDP/DTLS schemes as well.

> 
> 
> > If the intent is to define something similar to draft-ietf-
> tcpm-yang-tcp, then there are plenty QUIC specifics that can be
> covered. I suspect that effort should be done with/in QUIC WG.
> 
> I will look into draft-ietf-tcpm-yang-tcp.
> 
> 
> --
> Per
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.