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

[戴锦友 <[e-mail]>]

Hi, Kent
{
Section 2 introduces terminology “manager” and “agent” for the NETCONF peers.  I strongly oppose this construct.  
         We will improve the text in order to keep aligned with other NETCONF related RFCs.
Section 3.2.2, says that the idle timeout should be disabled.  Is this actually needed? 
         We can take it as an option meanwhile other options can be added.
}
Thank you!



David Dai
Fiberhome Technologies/CICT
Addr: Gaoxin Road 6#, Wuhan, Hubei, China
Tel:  [phone]-8318
MObile: [phone]
Fax:  [phone]
E-mail: [e-mail]
 
From: Kent Watsen
Date: 2024-08-19 21:58
To: Marc Blanchet
CC: Chongfeng Xie; [e-mail]
Subject: [netconf] Re: Adoption call for quic-netconf-over-quic-06
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?

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].

Section 3.2.2, says that the idle timeout should be disabled.  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.

Lastly, I support adoption of this draft.  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.

Kent // as a contributor




Marc.


Best regards

Chongfeng

From: 【外部账号】Kent Watsen
Date: 2024-08-15 00:51
To: [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]
To unsubscribe send an email to [e-mail]