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

[Gorry Fairhurst <[e-mail]>]

On 03/09/2026 08:15, Marcus Ihlar via Datatracker wrote:
> 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.
>
>
> _______________________________________________
> Tsv-art mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

Thanks Marcus for these review comments!

It agree it would be useful to reflect on the model for abstraction, and 
if this has not yet been done, to discuss the model with the QUIC WG.

Gorry