Re: [netmod] hex-string as built-in type in future versions of YANG

Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Wed, 06 November 2019 14:11 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
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 C0FEE1208A5 for <netmod@ietfa.amsl.com>; Wed, 6 Nov 2019 06:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.onmicrosoft.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 eJBOpOfBpg0r for <netmod@ietfa.amsl.com>; Wed, 6 Nov 2019 06:10:58 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10050.outbound.protection.outlook.com [40.107.1.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB0212087E for <netmod@ietf.org>; Wed, 6 Nov 2019 06:10:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R8RWf8ayA8MzfBchXt/SNMIsFmqgHPzjhDbS8fuvLeEZ5XsfhIQOt73e+CPAupXxRO8PM010F6uLq5M8nT4wE3Ynd+ExuvH5H39xMFAecCeg/KCT81l17t5Kfr1AFLx3XfL0pti8l44GOygquH3rgXp77gbnOmF1gI7xLXAX3T8AilXFCLKEVF+yocZ8emdlrrd0tjTZlkGqcbm6se88XQwOHVCL/lyErjFkdLtY9N3OeY6TBufaI1fsIbh3rBGeGQoqrKyxHmK8STmvm/L82gjPaya3ziIukhOu/DWag/S8jaio6iQAajdzAZm47uGhfv6zmcYweY8DJ3a5Btj6Wg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9QsdjxqXx1Uze/wpMz18RD2Ce6QGILjNMxqwv2CAmE=; b=iXG4Y3wa5v36umyzrCPkNqpLPSzr3GLAN8yGuLJYOIrl03qAOy4Uc08LCkCfdoel6KmKrQto64TsvDHKp7cMcQZT8kQyJCTNVRdYShYPTkrQ+IMlbVU/bw8l6d/bfFra2qxXmgkyHxvk3Wug9N80QyTEVw1YAEPU2QSF+R+tuj9aedK9J5Q4h8EnRkpwc9CbTZWjiPfucIGoNBb6hOFLoavKabwuI+o/Y3cgkdPBj8vZPTgSbNvpVgXbnKrnelhz39wfqnOo4PDHqHURBeQXU4XSiUpXu3Xgxu9PzWxL9uwpIA/JdkM12p35oyGYBFVRdUIi6Go7UZGjlGLBvQVP9Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9QsdjxqXx1Uze/wpMz18RD2Ce6QGILjNMxqwv2CAmE=; b=riDsL36PRBXTSCm6jHN8yQAMvlqGkPyTTITjzF0S82RlqYep6Nd2kJ/lFUaxDRZQpFu3QJ4qwc+I8qU+Gcej/aGOugMNOiWmgd5qzbJI+rLfIOyZ+tdn1lWPOfCiX7hCJw22Lf9hjzkPIeyxhoSBa1WDPoyw+CjPTfSlzDSPs7A=
Received: from AM5P190MB0482.EURP190.PROD.OUTLOOK.COM (10.161.65.11) by AM5P190MB0276.EURP190.PROD.OUTLOOK.COM (10.161.81.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Wed, 6 Nov 2019 14:10:55 +0000
Received: from AM5P190MB0482.EURP190.PROD.OUTLOOK.COM ([fe80::6c6c:2cd2:11dd:2aff]) by AM5P190MB0482.EURP190.PROD.OUTLOOK.COM ([fe80::6c6c:2cd2:11dd:2aff%5]) with mapi id 15.20.2408.024; Wed, 6 Nov 2019 14:10:55 +0000
From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= <J.Schoenwaelder@jacobs-university.de>
To: Vladimir Vassilev <vladimir@lightside-instruments.com>
CC: tom petch <ietfa@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] hex-string as built-in type in future versions of YANG
Thread-Index: AQHVlKY+KWDtjPWkUEerecz0ieqA5ad+LrQA
Date: Wed, 6 Nov 2019 14:10:55 +0000
Message-ID: <20191106141054.zgqtaroekbthad72@anna.jacobs.jacobs-university.de>
References: <157053706777.17066.5329202935752721411.idtracker@ietfa.amsl.com> <e6e439e6-5e39-9155-7924-59e8ecde72bd@lightside-instruments.com> <00e501d58b52$2bc35b60$4001a8c0@gateway.2wire.net> <a44c75d7-123f-3d7b-e95f-f21715eba22a@lightside-instruments.com> <06eb01d58e54$84b43fa0$4001a8c0@gateway.2wire.net> <41a2a04d-a9bd-5c2d-678e-0e416a1dd556@lightside-instruments.com>
In-Reply-To: <41a2a04d-a9bd-5c2d-678e-0e416a1dd556@lightside-instruments.com>
Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: AM0PR02CA0037.eurprd02.prod.outlook.com (2603:10a6:208:d2::14) To AM5P190MB0482.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:1d::11)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:638:709:5::7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1638f5d5-1fed-4849-36bc-08d762c323b7
x-ms-traffictypediagnostic: AM5P190MB0276:
x-ms-exchange-purlcount: 3
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM5P190MB02768CA6DFED070234857054DE790@AM5P190MB0276.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39850400004)(136003)(396003)(346002)(189003)(199004)(11346002)(45776006)(6436002)(476003)(71200400001)(1076003)(446003)(71190400001)(316002)(43066004)(99286004)(7736002)(786003)(54906003)(81166006)(81156014)(6116002)(2906002)(6916009)(6486002)(66556008)(478600001)(66946007)(6512007)(6306002)(8676002)(305945005)(229853002)(186003)(46003)(8936002)(3450700001)(66476007)(66446008)(6246003)(14444005)(86362001)(256004)(386003)(52116002)(5660300002)(966005)(14454004)(6506007)(561944003)(4326008)(76176011)(102836004)(25786009)(64756008)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P190MB0276; H:AM5P190MB0482.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OxYBp08lRPzehGugEUOdYT3poYdtOx3yLBpNoPk9KpMqvhm/tq2U7F6/1egQ9CK1DwAFLWGk0pTR4hHwH15HH5zgqipfX2wAc0lUBcwtnpI5hnT6Epfw7WPCTjEweQCHslAPEhpVsVtX5NbI+iLbyq6WQqCs1bLAgJtproGW9uslEA/BA4pgkRxcxDbM8xjgK1H2seUcq8gk395OADd1Sl9+tkx4P40Ku9oQ5zzaQ5IFvY+0D0A5GuKLab3bo872EHjQlRB7HztIXUikUhPA7xZ7rPIi3d+o9UYPpSAvvtAsXteiqAPha5R/dAr0wTKLGsHZkkOUGFsYTaNUsmkzVXpfiir3YddWTygLb20QgIwO/2n3m698tiQuUMAIfEqhm7M1yHOu2dQLmITDaCf8oKnrXzkHQGFA1buBWQHOGvWndNxbQfPUYsv8Jkok0hmkS8ZuUL+3V1V6NBECeVBKG/mWthvpFsKdyERsxzW6gr0=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <EB878A0BA1A5104D9AF8FF6CDF3B80EC@EURP190.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 1638f5d5-1fed-4849-36bc-08d762c323b7
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 14:10:55.5767 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XT6NXHvxUyuWuUBDiI+/P7KfchpcfEsEOSBzfcZDVkiox7Xz6qbfa44q5lMX7OPqjmnaDWqSjpXH9IKF6piG1vju+Rte8+twIFNkGMtaY6M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0276
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/afBr15BJCYYWDx0zdUC2WZxmJ9U>
Subject: Re: [netmod] hex-string as built-in type in future versions of YANG
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: Wed, 06 Nov 2019 14:11:02 -0000

On Wed, Nov 06, 2019 at 01:29:41PM +0000, Vladimir Vassilev wrote:
> 
> [2] Some of the types are based on strings with complex lexical 
> representation with canonical form specified in description statement 
> which is neither scalable nor automation friendly. For example the 
> "ethertype-type" type (just getting started):
> 
> ... from ieee802-dot1q-types@2018-03-07.yang
> 
>    typedef ethertype-type {
>      type string {
>        pattern "[0-9a-fA-F]{2}-[0-9a-fA-F]{2}";
>      }
>      description
>        "The EtherType value represented in the canonical order defined
>        by IEEE 802. The canonical representation uses uppercase
>        characters.";
>      reference
>        "9.2 of IEEE Std 802-2014";
>    }
> ...
> 
> IMO typedefs (not types) with constrains specified in a description 
> statement especially if they are not part of ietf-yang-types (RFC6991) 
> should be avoided. Those types are bad enough even when they are defined 
> in ietf-yang-types e.g. "mac-address" AA:BB:CC:DD:EE:FF which is valid 
> for rpc "input" data has to be treated as aa:bb:cc:dd:ee:ff (which is 
> the canonical representation). The difference comes from the fact that 
> "mac-address" is seamlessly converted to lowercase in many tools (not 
> all). Those tools do not support the types defined in 
> ieee802-dot1q-types in the same way. So there is no "to uppercase" 
> seamless conversion for ethertype-type and "aB-cD" and "AA-CD" are 
> treated as different values and you will have to figure out how your 
> implementation can fix this on your own.

     typedef mac-address {
       type string {
         pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
       }
       description
        "The mac-address type represents an IEEE 802 MAC address.
         The canonical representation uses lowercase characters.

         In the value set and its semantics, this type is equivalent
         to the MacAddress textual convention of the SMIv2.";
       reference
        "IEEE 802: IEEE Standard for Local and Metropolitan Area
                   Networks: Overview and Architecture
         RFC 2579: Textual Conventions for SMIv2";
     }

The problem here is that two organizations have rather different
preferences when it comes to uppercase and lowercase letters.
 
> IMO ietf-yang-types:mac-address (and many others 
> ieee802-dot1q-types:ethertype-type included) can be derived from 
> ietf-yang-types:hex-string instead of string. It would be even better if 
> "hex-string" is defined as a new built-in type in YANG next with an 
> optional "width" sub-statement constraining the number of bits represented.
> 
> There are relevant discussions in 
> https://github.com/netmod-wg/yang-next/issues/19  and 
> https://github.com/netmod-wg/yang-next/issues/46 (posted the last 
> paragraph of this proposal there).

Creating a hex-string built-in type in order to settle the debate
lowercase vs. uppercase? Note sure this is a strong technical reason
for creating a new built-in type. ;-)

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