Re: [Uri-review] [art] Alternative representation of URIs in YANG

On Dec 2, 2025, at 11:29 AM, Kent Watsen <kent+ietf@watsen.net> wrote:
> 
> The document previously used the "ietf-inet:uri" typedef from RFC 6991 (previously RFC 6021).  The WG complained that the unstructured format did not good exhibit YANG-fu (best practice), making it hard to apply/validate defaults and constraints on individual fields.  From a YANG-outlook perspective, the "ietf-inet:uri" typedef is likely to be rarely used.

I think it is fairly important that the IETF publish specifications that are
consistent, particularly when referencing STD66. Their YANG-fu is a lot less
important than their technical accuracy.

draft-ietf-netconf-http-client-server-30 states that a host is required.
That is wrong. It isn't even true for HTTP servers, which are fully capable
of receiving a URN in a request-target and respond appropriately. And when
a host is present, the host isn't limited to a DNS name or IP address.

More to the point, configurations are usually not applied to a whole URI.
Hosts are configured by a set of registered names and IP addresses.
Schemes are usually provided by protocol availability/enablement.
Paths are delegated to multiple subsystems that only have one thing
in common -- they don't share the same delegation name.

Hence, unless they are incredibly simple, server configurations do not use
a URI structure to configure things. A server's URI structure normally
emerges from the result of what has been configured. A proxy is configured
by providing the URI for that proxy (i.e., no additional info is needed).

A single HTTP server instance can configure a set of schemes, each serving
a potentially empty set of names/origins, each serving a set of potential
paths or subnames, some of which might accept query parameters and potential
values. Some of those configuration items will be global, some will apply
to all of a certain scheme, some will apply to certain paths or subnames,
and some will only apply to a cross-section of certain schemes and
paths that match a given regular expression or filename extension.

Configurations are complicated.

Unfortunately, the spec has picked up a few random configuration parameters
and presents them as HTTP server and client modules. These are not types.
Configurations are lists of named parameters that need no other structure.

Protocol versioning and TLS are normally a combination of deployed base
capabilities, context (e.g., why does it exist), and negotiation with the
other side of a connection. They have a habit of changing over time.
They are not types. They use special operands like "this version or better"
and "not this version" on values that aren't strictly ordered lexically.

My URI and HTTP advice would be to limit this spec to a real use case:
configuring a proxy or instant server for one specific URI string
(no structure needed) or for a list of such strings.

The software interpreting that configuration will, of course, have to parse the URI
according to RFC3986. If the URI only contains an origin form (no path or query)
then the paths are configured elsewhere; otherwise, only that one exact URI is
configured for service. All other config parameters are a list of name/value pairs.

And, yes, I realize that this is hard advice to receive at draft 30.
That's what happens when working groups try to subsume other standards
without actually using them as standardized.

....Roy

Received on Monday, 8 December 2025 22:14:26 UTC