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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 30 April 2019 09:43 UTC

Return-Path: <rwilton@cisco.com>
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 80666120295 for <netmod@ietfa.amsl.com>; Tue, 30 Apr 2019 02:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 2nDVEjWx0U07 for <netmod@ietfa.amsl.com>; Tue, 30 Apr 2019 02:43:53 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534E212028A for <netmod@ietf.org>; Tue, 30 Apr 2019 02:43:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4343; q=dns/txt; s=iport; t=1556617433; x=1557827033; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=n552VYJ0H/RBZK86x4Tt4g2pUCVpxp6Cb3GXUXZapsM=; b=WHfJPwkxvwHob441/ksenY4hxd36sivi4qtYUvgHlDaD+l3PmXyqJdDS GScaES6POAFTcrjIkKUSK+/TUF2O2K5OE+IRHV93SaThQbPlaTyBBVwuA uwVcf2KiqLnnfXYlexmf2YTh114vFBp4pbISDYMbM8BmGBpy2FCdCouxT A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAATGMhc/4oNJK1jAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIQaVQwKAqMIo0UmFCBew4BASOESgK?= =?us-ascii?q?GMSM0CQ4BAwEBBAEBAgECbRwMhUoBAQQ7PwwCBAEWAgEEAQEBHisXHQkBBA4?= =?us-ascii?q?FCBODCIF7Dw+vXYoyBgWBLQGLSReBQD+EYYJhAoFLNyaFGwSKYCABm38JAoI?= =?us-ascii?q?JAoYSjBwjgg2KIIkAkk+ODgIRFYEwHziBVnAVGiGCbIV+M4ogQTGTGYEhAQE?=
X-IronPort-AV: E=Sophos;i="5.60,413,1549929600"; d="scan'208";a="265305577"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Apr 2019 09:43:52 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x3U9hqor027506 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2019 09:43:52 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Apr 2019 04:43:51 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Tue, 30 Apr 2019 04:43:51 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Ladislav Lhotka <lhotka@nic.cz>, NETMOD WG <netmod@ietf.org>
Thread-Topic: Canonical value representations in typedefs [was RE: [netmod] 6021 ipv4-prefix]
Thread-Index: AdT/N8R2Ht7L6Z6FSL+VKWjK+zxtZg==
Date: Tue, 30 Apr 2019 09:43:51 +0000
Message-ID: <5ccb99db35514088986ff3a396746c7c@XCH-RCD-007.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CtB8Km4LBneM8raCaifTnpXHdYo>
Subject: [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: Tue, 30 Apr 2019 09:43:56 -0000

Forking the thread title to avoid further polluting the original issue, and because these comments really apply to YANG.Next.

> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> Sent: 29 April 2019 18:26
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: Ladislav Lhotka <lhotka@nic.cz>cz>; NETMOD WG <netmod@ietf.org>
> Subject: Re: [netmod] 6021 ipv4-prefix
> 
> On Mon, Apr 29, 2019 at 05:08:41PM +0000, Rob Wilton (rwilton) wrote:
> >
> > If YANG allows a typedef to refine the canonical definition of a base
> > type, then I think that the YANG RFC should be explicit on this (e.g.
> > in YANG Next).  Particularly, because this requires a server
> > implementation to read/understand the description associated with a
> > leaf/typedef in case they have to add specific canonicalization code
> > to implement the leaf/typedef.
> 
> Description statements in general are expected to be read and understood and
> implemented where necessary. But I now see that the fact that this section 9.1 is
> under section 9 which is titled built-in types is causing the confusion. This is,
> indeed, unfortunate.

Yes, OK.

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.

For the second case, I do wonder whether this is much closer to adding new concrete type to the language, just in a slightly backdoor way.  There have been discussions about adding binary representations for some of these types (e.g IPv4 address, IPv6 address ,etc).  Perhaps that would be easier if they were somewhat closer to base types than derived types, and maybe this class of type definitions shouldn't be using typedef at all.

> 
> > I'm not sure that we have really got a simple solution for either clients or
> servers:
> >  1) Clients may use non canonical format on configuration input
> >  2) But clients must still use canonical format for xpath expressions
> >  3) Clients must also handle canonical format being returned on any get
> requests.
> >  4) Servers must perform normalization of any type to a canonical format, as
> defined in the type/typedef/leaf description.
> 
> Exactly. Note that clients only send xpath for filtering (if they want to filter via
> xpath). What is more important is that module authors can predict the format of
> values when they write when or must expressions. And as Lada points out,
> having predictable key values also is kind of desirable.

I wasn't suggesting that we lose uniqueness of list keys, but instead don't allow typedefs to define their own canonical format.  I.e. that would always require IPv6 addresses to be provided in the canonical form.  However, the benefits of this are probably marginal given that a robust server would want to check that the type is in the canonical form anyway, and hence the server still has to write very similar canonicalization code regardless.


> 
> The reality is that there are many different ways to write an IPv6 address and the
> idea was to accept them on input but to subsequently work with the normalized
> canonical representation. And this is in ietf-yang-types and ietf-inet-types since
> day one. But yes, the text in section 9.1 seems to be misplaced.

I've raised https://github.com/netmod-wg/yang-next/issues/83 to clarify the expected YANG behaviour here, and perhaps to also consider whether an extra statement would be beneficial.

Thanks,
Rob


> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>