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

Ladislav Lhotka <lhotka@nic.cz> Fri, 03 May 2019 08:02 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10A8120052 for <netmod@ietfa.amsl.com>; Fri, 3 May 2019 01:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSy7rlxWonT9 for <netmod@ietfa.amsl.com>; Fri, 3 May 2019 01:02:39 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E812E1200C4 for <netmod@ietf.org>; Fri, 3 May 2019 01:02:37 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id D519A182044E; Fri, 3 May 2019 10:02:09 +0200 (CEST)
Received: from localhost (nat-1.nic.cz [217.31.205.1]) by trail.lhotka.name (Postfix) with ESMTPSA id C63F11820045; Fri, 3 May 2019 10:02:06 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Robert Varga <nite@hq.sk>, "Rob Wilton \(rwilton\)" <rwilton@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NETMOD WG <netmod@ietf.org>
In-Reply-To: <a593b53e-6bb4-c3ce-2fe0-ec5421d2c2f3@hq.sk>
References: <5ccb99db35514088986ff3a396746c7c@XCH-RCD-007.cisco.com> <87sgtx57ad.fsf@nic.cz> <a593b53e-6bb4-c3ce-2fe0-ec5421d2c2f3@hq.sk>
Mail-Followup-To: Robert Varga <nite@hq.sk>, "Rob Wilton \(rwilton\)" <rwilton@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NETMOD WG <netmod@ietf.org>
Date: Fri, 03 May 2019 10:02:32 +0200
Message-ID: <87sgtwq82v.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-caNykWc5A-lvEDXIJ6eWclkO-0>
Subject: Re: [netmod] Canonical value representations in typedefs [was RE: 6021 ipv4-prefix]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2019 08:02:43 -0000

Robert Varga <nite@hq.sk> 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
format.

>
> 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:

https://slideplayer.com/slide/15172219/

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

Lada

>
> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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