Re: [netmod] Canonical value representations in typedefs [was RE: 6021 ipv4-prefix]
Robert Varga <nite@hq.sk> Thu, 02 May 2019 15:42 UTC
Return-Path: <nite@hq.sk>
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 BB3E8120417 for <netmod@ietfa.amsl.com>; Thu, 2 May 2019 08:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 yqc2FZ1Xda2Y for <netmod@ietfa.amsl.com>; Thu, 2 May 2019 08:42:52 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3213012042D for <netmod@ietf.org>; Thu, 2 May 2019 08:42:37 -0700 (PDT)
Received: from nitebug.nitenet.local (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 9466E240363; Thu, 2 May 2019 17:42:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1556811754; bh=0JFf3y4DUZe5VgYeCH6PonbBbK7cxuTg0GNpEyHkONE=; h=Subject:To:References:From:Date:In-Reply-To; b=tgbqaUeLrEm0992nztP2OpfGf1XmTUV2ZNx30d/+t9ty9G1lkRfaiW99CX0rKEXld gEr7CQPvygWY9WP+DtGYCCuVI87vs4Y4nm0tGqI+yIoXOYVu1d6jxlyEDf1ITOEyR9 vXhipnXcOcyWpWmjudA85dwho3RajhAIxwI2Q+0E=
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NETMOD WG <netmod@ietf.org>
References: <5ccb99db35514088986ff3a396746c7c@XCH-RCD-007.cisco.com> <87sgtx57ad.fsf@nic.cz>
From: Robert Varga <nite@hq.sk>
Openpgp: preference=signencrypt
Message-ID: <a593b53e-6bb4-c3ce-2fe0-ec5421d2c2f3@hq.sk>
Date: Thu, 02 May 2019 17:42:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <87sgtx57ad.fsf@nic.cz>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="v0TEOIcBj1huRvMXagMrLlYCGaM9V9m0N"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/kUU9QLfYOuugp8V2JUpJtmfUgO8>
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: Thu, 02 May 2019 15:42:55 -0000
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. 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. 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] Canonical value representations in typed… Rob Wilton (rwilton)
- Re: [netmod] Canonical value representations in t… Ladislav Lhotka
- Re: [netmod] Canonical value representations in t… Robert Varga
- Re: [netmod] Canonical value representations in t… Ladislav Lhotka