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.