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

[Benoit Claise <[e-mail]>]

Dear all,

On 8/19/2024 2:58 PM, Kent Watsen wrote:
> 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.
And a big +1 on my side.

Regards, Benoit
> 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 <mailto:[e-mail]>
>>>     *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 [e-mail]
>>
>
>
> _______________________________________________
> netconf mailing list [e-mail]
> To unsubscribe send an email [e-mail]