Early Review of draft-ietf-netconf-over-quic-04
review-ietf-netconf-over-quic-04-yangdoctors-early-schoenwaelder-2025-06-16-00

- The abstract talks about "encryption properties" and "privacy
  properties". Perhaps this should be "security properties" since
  other security aspects such as authentication and integrity are
  important as well. And eliminating TCP head-of-line blocking issues
  depends on how QUIC streams are used. I would rewrite the abstract
  as follows:

    This document specifies how to use QUIC as a secure transport for
    exchanging Network Configuration Protocol (NETCONF) messages.
    NETCONF over QUIC allows to take advantage of QUIC streams, for
    example, to eliminate some TCP head-of-line blocking issues.
    NETCONF over QUIC provides security properties similar to NETCONF
    over TLS.

  The idea is to say what it is, why one might consider it, and what
  roughly the security implications are.

- Section 3.1. says "QUIC support is indicated by selecting the ALPN
  token as listed in Section 9 in the cryptographic handshake." I was
  not sure which section 9 was referenced here. Section 9 of RFC is
  about connection migration, so I assume this is section 9 of this
  document, the IANA considerations.  Perhaps the intention was "QUIC
  support is indicated by selecting the ALNP token registered for
  NETCONF over QUIC (see Section 9) in the cryptographic handshake."

- It is unclear to me how NC sessions related to QUIC streams and this
  may have impact on the connection termination section. I think this
  deserves to be clarified early on as this impacts some of the
  following text. Right now, section 3.2.2 reads as if there is a 1:1
  relation between NETCONF sessions and QUIC connections. If so, say
  this explicitly. If not, well, perhaps the text needs more work.

- Avoid starting sentences with "[RFC6241] ..." (perhaps the RFC
  editor fixes such editorial issues).

- Avoid "above table" and instead use an explicit reference like
  "Table 1".

- "So the messages used to exchange configuration data SHOULD be
   mapped into one unidirectional stream whose stream type is 0x3
   according to the above table." This seems to be plain wrong, I
   guess you mean "notification data" and not "configuration data".  I
   also find "notification data exchanged between client and server"
   potentially misleading since it is really "notification data sent
   from the client to the server" (stress that it is directional).

- I am unsure whether section 4.3 covers all details necessary for an
  interoperable call home implementation over QUIC, in particular also
  in view of section 5 which talks about servers and clients (without
  being very clear how this relates to the NC notion of server and
  clients or the QUIC notion of server and clients.

- The YANG module is rather straight forward since the real details
  are defined generically in ietf-netconf-quic-client-server-01.txt.
  That document, however, does not seem	to be ready yet. (I will post
  comments to the list).

- Note: /* FIXME seems pyang don't support this augment */
  It is unclear what the intention and purpose of these augments is.

- Security considerations: In which sense is RFC 7589 relevant here?
  If the algorithm defined in RFC 7589 is applicable here, I would
  have expected this to be documented in the main part of the
  document.

- The document is silent about message framing. But then the security
  considerations warn about attacks via inserted delimiter sequences.
  Given that this is a new transport mapping, why not require chunked
  framing everywhere, which avoids this problem?

- Why do you refer to RFC 6242 (NC over SSH)? How does this help to
  understand the security of NC over QUIC?