Early Review of draft-ietf-netconf-over-quic-04
review-ietf-netconf-over-quic-04-tsvart-early-duke-2025-06-13-00

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.