[netconf] Re: Adoption call for quic-netconf-over-quic-06

[Marc Blanchet <[e-mail]>]

> Le 19 août 2024 à 09:58, Kent Watsen <[e-mail]> a écrit :
> 
> Hi Marc, authors, WG,
> 
>>> The abstract mentions that "This document describes  how to use NETCONF over the QUIC transport protocol, named NETCONFoQUIC."  But in section 7,  NETCONFoQUIC is shown as one type of protocol.  So my question is that whether NETCONFoQUIC is a kind of new protocol? If yes, what't the relationship of NETCONFoQUIC with NETCONF?
>> 
>> From TLS point of view, it is another protocol, therefore it is registered as an ALPN. All protocols over QUIC do the same.
> 
> Thanks for this context.  The TLS-perspective is noteworthy but, from a NETCONF-protocol perspective, QUIC is just another transport.   “NETCONF” is the protocol.  It may necessary to register “NETCONFoQUIC”, but calling the protocol “NETCONFoQUIC” seems wrong.  Is it possible to relegate the use of “NETCONFoQUIC" in the draft to, e.g., just the IANA Considerations section?

Fine by me! Will discuss with the co-authors.

> 
> More comments:
> 
> Section 2 introduces terminology “manager” and “agent” for the NETCONF peers.  I strongly oppose this construct.  Since 2006, the terms “client” and “server” have been used for NETCONF (formally in RFC 6241).  I understand that QUIC also uses the terms “client” and “server”.   To disambiguate, I recommend using "<protocol>-<roll>" everywhere  (like I did in RFC 8071), e.g.: [quic/netconf/tls]-[client/server].

Agreed on my side. Will discuss with the co-authors.

> 
> Section 3.2.2, says that the idle timeout should be disabled.

Well, the whole paragraph is:
"   When a NETCONF session is implemented based on a QUIC connection, the
   idle timeout should be disabled or the QUIC max_idle_timeout should
   be set appropriately in order to keep the QUIC connection persistent
   even if the NETCONF session is idle.
« 

>  Is this actually needed?  AFIAK, none of the other NETCONF transport drafts have such provision.   Rather the NETCONF WG focus has been to encourage the use of keepalives to ensure aliveness.   I’m not saying this is wrong to disable max_idle_timeout, but just that is seems different, and it would be good to know how different and adjust from there.  FWIW, the strings “idle”, “time” and “keep” do not appear in RFC 7589.

Maybe the wording (of disabled) is too strong? Would below work?

"   When a NETCONF session is implemented based on a QUIC connection, the
   idle timeout should be set appropriately in order to keep the QUIC connection persistent
   even if the NETCONF session is idle. In some cases, disabling it may be a possible option.
« 

> 
> Lastly, I support adoption of this draft.

great.

>  It seems prudent to add QUIC as a transport for NETCONF (QUIC is already a transport for RESTCONF).   I hope that my comments above will be considered if this I-D is adopted.

Thanks, Marc.

> 
> Kent // as a contributor
> 
> 
> 
>> 
>> Marc.
>> 
>>> 
>>> Best regards
>>> 
>>> Chongfeng
>>> 
>>> From: 【外部账号】Kent Watsen <mailto:[e-mail]>
>>> Date: 2024-08-15 00:51
>>> To: [e-mail] <mailto:[e-mail]>
>>> Subject: [netconf] Adoption call for quic-netconf-over-quic-06
>>> NETCONF WG,
>>> 
>>> This message starts a two week poll on adopting the following document:
>>> 
>>> 	Using NETCONF over QUIC connection
>>> 	https://datatracker.ietf.org/doc/html/draft-dai-netconf-quic-netconf-over-quic-06
>>> 
>>> The poll ends August 28.
>>> 
>>> Please send email to the list indicating "yes/support” or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.
>>> 
>>> FWIW, no IPR is known for this document:
>>> 
>>> 	https://mailarchive.ietf.org/arch/msg/netconf/L9a1nQFdNuGH0rXZyEbd_RaN-UQ/
>>> 
>>> Kent  // as NETCONF WG chair
>>> 
>>> _______________________________________________
>>> netconf mailing list -- [e-mail] <mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>