[Tsv-art] Re: [netconf] Re: draft-ietf-netconf-over-quic-04 early Tsvart review

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

Hi，Martin,
Thank you for your comment.
The illustration from my side can be seen in the in-line bolded text.
Best regards!



David Dai
Fiberhome Technologies/CICT
Addr: Gaoxin Road 6#, Wuhan, Hubei, China
Tel:  [phone]-8318
MObile: [phone]
Fax:  [phone]
E-mail: [e-mail]
 
From: Martin Duke
Date: 2025-11-14 04:51
To: Per Andersson
CC: tsv-art; draft-ietf-netconf-over-quic.all; netconf
Subject: [netconf] Re: draft-ietf-netconf-over-quic-04 early Tsvart review
Broadly, no, draft-05 does not address the concerns.

Please remove the description of the codepoint for the various stream types in Section 4. This is not robust to new QUIC versions and is not important to the application.
     I think it is at least harmless and somehowbeneficial to keep the code point there. If you hold the opinion to strike out them, I think it is better
     to dicuss with you first.  Because the codepoints are defined in a published RFC and there is not a need to change them , I really have no idea why we should modified
     those codepoint in the future.  
    After discussion, If we think it is necessary to remove those code point, I'll do it soon.

4.1 This is still self-contradictory:

"The messages used to exchange configuration data MUST be mapped into one or more bidirectional streams"
Replace "one or more bidirectional streams" with "one bidirectional streams". (The reason is that we got 
several options that can work. and at the 124 meeting, we decided to use one of them)

"Since RPC processing is serialized and ordered within a session ([RFC6241] section 4.5), a bidirectional stream MUST MUST be used for each NETCONF session"

So is it "one" (because it's serialized and ordered) or "one or more"?

BTW: s/MUST MUST/MUST (YES, this is a typo, we will modify it)


4.3 I don't understand subscription mechanics. 4.2 says all notifications are over one uni stream. 4.3. says there is one uni stream per subscription. I don't understand how the client initiates subscriptions if they don't go over the bidi stream (4.2) and all the other streams are unidirectional in the server->client direction.
That's is  to say, after the initiation of a subscription, there is one uni stream per subscription

Section 9 still refers to a section 2.1 that doesn't exist.
We'll fix the typo

The draft still does not clarify that closing the bidi stream is an error.
We'll add necessary errors.


On Fri, Oct 17, 2025 at 4:08 AM Per Andersson <[e-mail]> wrote:
Hi Martin,

A new revision has been published.

Realizing now that your point on error codes is missing.

Can you let us know if it addresses your other concerns.


--
Per



On Fri, Jun 13, 2025 at 11:52 PM Martin Duke via Datatracker
<[e-mail]> wrote:
>
> Document: draft-ietf-netconf-over-quic
> Title: NETCONF over QUIC
> Reviewer: Martin Duke
> Review result: Not Ready
>
> The document proposes to run NETCONF directly over QUIC, but I found the
> details of the mapping hard to discern.
>
> I have little to no knowledge of NETCONF itself, but am qualified to review a
> QUIC mapping.
>
> 1. Mapping sessions to QUIC connections
>
> The most obvious way to do this is to have one QUIC connection per NETCONF
> session. But having application-level termination in <close-session> and
> <kill-session> messages be totally distinct from QUIC Connection Close leaves a
> possible zombie state where the connection lives but the session is dead. It is
> not 100% clear to me, in this document, if a client could re-use a QUIC
> connection for a second session, as the normative requirement to close the
> connection is a SHOULD. There is text that suggests this is possible. Is this
> the intent?
>
> IIUC, both close-session and kill-session involve an RPC reply to cleanly close
> things. But if the receiver of close-session and kill-session immediately send
> CONNECTION_CLOSE, any reply may be lost. Is that OK, or should the receiver of
> the RPC reply actually be the one to send CONNECTION_CLOSE?
>
> Or could you simply get away with using CONNECTION_CLOSE and not send these
> RPCs over the wire?
>
> 2. Stream mapping
>
> The stream mapping instructions are contradictory. Sec 4.1 says there are "one
> *or more* bidirectional streams", but also "Since RPC processing is serialized
> and ordered within a session ([RFC6241] section 4.5), a bidirectional stream
> MUST be used for each NETCONF session." Again, I'm wondering if multiple
> sessions are allowed to be on a single connection. But can there be more than
> one bidirectional stream or not? If not, there is still head-of-line blocking
> of RPC traffic despite the motivation in Section 1.
>
> Similarly, in 4.2, notifications "SHOULD" be on a single unidirectional stream.
> Under what conditions SHOULD this be true? Does Head of Line blocking not
> matter? Why would an application choose one stream over multiple ones? Allowing
> either makes it much harder to implement and test a client.
>
> 3. Error codes
>
> I would expect any application mapping to QUIC to provide a registry of
> Application errors for CONNECTION_CLOSE frames and stream errors for
> RESET_STREAM and STOP_SENDING frames.
>
> 4. Stream errors
>
> Are any streams mandatory to remain open, or is it a session error if the RPC
> and notification streams are closed for any reason?
>
> 5. Security considerations
>
> The delimiter reference in Section 8 does not correspond to a section 2.1 here
> or in RFC 6241.
>
> How can an attacker inject arbitrary data into a QUIC stream? Please elaborate
> or provide a reference.
>
> Nits:
> - Section 7 has several "FIXME" comments, which I would not expect in the final
> version of this document.
>
> - You do not need to present Table 1 and talk about specific stream ID
> suffixes. This is not robust to future QUIC versions. Just refer to
> client-initiated bidirectional streams and server-initiated unidirectional
> streams. The text in 4.3 is pretty good; just make it clear that the use case
> has the NETCONF client as the QUIC server and vice versa.
>
>