[Tsv-art] draft-ietf-netconf-quic-client-server-08 early Tsvart review

[Marcus Ihlar via Datatracker <[e-mail]>]

Document: draft-ietf-netconf-quic-client-server
Title: YANG Groupings for QUIC clients and QUIC servers
Reviewer: Marcus Ihlar
Review result: Not Ready

This model does not have sufficiently well-defined semantics to serve as a
generic QUIC configuration model.

The main problem is the transport-parameter leaf-list. It is a bag of registry
identifiers without any defined meaning. The document does not say what
including or omitting an identifier means. Does it declare support, enable a
feature, or configure behavior? The registry contains parameters with
fundamentally different semantics that cannot be expressed by a simple
leaf-list of names. Valued parameters such as
initial_max_stream_data_bidi_local and max_idle_timeout carry integers, but the
model has no field for a value. Section 5 warns about "changing
max_idle_timeout to a too low value", but that is not something that can be
expressed using this model (from my understanding). There are parameters that
are restricted by role or direction, such as stateless_reset_token: it is
generated by a server and MUST NOT be sent by a client. What does its presence
in a server configuration mean? What does it mean in a client configuration?
Parameters such as original_destination_connection_id and
initial_source_connection_id make no sense to configure through a model of this
kind.

These are just some examples.

There is a related problem with independently shadowing the QUIC Versions and
QUIC Transport Parameters registries. QUIC v1 and v2 happen to share most
transport-parameter semantics, but there is no requirement that future,
experimental, or non-standard versions do so. From my reading, the model allows
arbitrary combinations of registered versions and registered transport
parameters without defining how mismatches are detected or rejected.

Having the model automatically shadow the IANA registries does not seem
maintainable to me. A different abstraction might be more appropriate. For
instance, model the behaviors that an operator can configure and let the
implementation map them to the appropriate protocol mechanisms. Alternatively,
scope transport-parameter modeling to specific QUIC versions, or use a common
model with version- and extension-specific augmentations.

Finally, has this document been discussed with the QUIC Working Group? The
intended semantics of these elements, and their applicability across QUIC
versions and extensions, are fundamentally QUIC transport questions. I strongly
suggest having that discussion before the document progresses.