Re: [netmod] Canonical value representations in typedefs [was RE: 6021 ipv4-prefix]

Ladislav Lhotka <> Fri, 03 May 2019 08:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D10A8120052 for <>; Fri, 3 May 2019 01:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oSy7rlxWonT9 for <>; Fri, 3 May 2019 01:02:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E812E1200C4 for <>; Fri, 3 May 2019 01:02:37 -0700 (PDT)
Received: by (Postfix, from userid 109) id D519A182044E; Fri, 3 May 2019 10:02:09 +0200 (CEST)
Received: from localhost ( []) by (Postfix) with ESMTPSA id C63F11820045; Fri, 3 May 2019 10:02:06 +0200 (CEST)
From: Ladislav Lhotka <>
To: Robert Varga <>, "Rob Wilton \(rwilton\)" <>, Juergen Schoenwaelder <>, NETMOD WG <>
In-Reply-To: <>
References: <> <> <>
Mail-Followup-To: Robert Varga <>, "Rob Wilton \(rwilton\)" <>, Juergen Schoenwaelder <>, NETMOD WG <>
Date: Fri, 03 May 2019 10:02:32 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [netmod] Canonical value representations in typedefs [was RE: 6021 ipv4-prefix]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 May 2019 08:02:43 -0000

Robert Varga <> writes:

> On 02/05/2019 15:12, Ladislav Lhotka wrote:
>>> But this really means that YANG has two sorts of typedefs:
>>> (i) A regular typedef which is just an alias for a base type, perhaps with some additional refinements that can all be handled automatically (e.g. pattern statements, etc).  In this scenario, I think that a compiler can ignore the description, and process the typedef automatically.
>>> (ii) An enhanced typedef that has additional semantics embedded into the description statement that requires custom implementation of the typedef.
>>> Being able to distinguish these two cases in a programmatic way seems
>>> useful to me, but perhaps it is just unnecessary noise.
>> YANG assumes "powerful" descriptions in general. An option would be to find a way for specifying the canonical
>> format in a machine-readable form.
> The way I understand typedefs (and use of restricted types in
> leaf/leaf-list) as that the first such use defines a value domain and
> any further references must strictly refer to a subset of that domain.
> Notably it does not seem to be sane to redefine the canonical format
> once it has been set.
> I think the entire canonical format problem comes from the fact
> ipv4-address is, unlike case (i), only a representation of a value
> domain which is semantically 32 bits.
> That value domain has two functions that are different from plain old
> string:
> - equality
> - total ordering
> Canonical representation deals with the first one, while also providing
> interoperability with XPath. There is no current mechanism to address
> the second one.

Yes. XML schema languages use the concept of lexical vs. value space,
it is more general and more robust that the concept of canonical

> I find having a machine-readable marker (such as an extension) that a
> value domain is being defined immediately useful -- it allows the
> compiler to warn that a specific typedef needs additional work to get it
> working as intended. This one's really easy.
> Having some (other) machine-readable marker of how a canonical value
> looks like (i.e. similar to pattern) is also useful: it allows the
> runtime to check if an incoming value is in canonical format and accept
> it irrespective whether specific value domain support (from above) is
> present or not. This one is moderately hard.
> Finally, some third marker, which would describe how to transform a
> non-canonical string into a canonical string would obviously be awesome,
> as now the runtime can work automatically. This one is really hard,
> especially since the operations probably involve operating not on a
> string, but some other representation.

I liked the idea developed by Jeni Tennison for DSDL:

(tl;dr: see slide 33). It seems though that this idea didn't materialize.


> As in implementer, I really care about the first two -- they are easy to
> do and provide immense value in making things work 'out of the box' and
> automatically catching cases when they do not.
> Regards,
> Robert
> _______________________________________________
> netmod mailing list

Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67