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

Vladimir Vassilev <vladimir@lightside-instruments.com> Wed, 06 November 2019 18:15 UTC

Return-Path: <vladimir@lightside-instruments.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 F057E120818 for <netmod@ietfa.amsl.com>; Wed, 6 Nov 2019 10:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft4991094.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 VWiB3gC7y-R9 for <netmod@ietfa.amsl.com>; Wed, 6 Nov 2019 10:15:28 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60045.outbound.protection.outlook.com [40.107.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B590B120846 for <netmod@ietf.org>; Wed, 6 Nov 2019 10:15:27 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CFytvyJFkpQ0gTFqiCdYQXYTo1zcOmnj3X1fOg96YDXd5JfNUjq5rEAcKZPFeGdwC1qTQZG248bUv8BKeF0yS/9rQ/JECALIo4HPxOOWLWiy2xul4CH9EKjET9a5q7iOYvMRNbK9ynGuJ7DlQ6kQiEG1UHomOtaibWSPoSkWcSVwW9aEHIj4ZHjLAvBeYwezfryybuC/qZ0WkgxiyE0j/ckovZQrzGbzmf1psURbtfa2lrEEe8AHgh6Vv/KEapdmuf5d9Z9LpsnOa5x+FHuclmo+ALYmtAqR12lsCb8liY4TJn9+F8BY5rwCIYXJXupHAKRr2zH2BRF96dm5l4trpA==
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=+7vhJsgl7J7eXXkCEGEk7fuGUTnKCqv3K4tw6PU2DVw=; b=W+Abp0jrQbnw64UsIQufgrC/yYqrBNCYO6aWxMCiwoEWV+QGSSdGXlCNEHPhlWZXydhR/TO19kTD0hBwoMJvcir8BM0PX7m9YOGlIotRq6/AOPZ0U2LiFP81HwrEmi+6m5lPblwDNqCm9SZPiHl0Dl3GEeOeRcQ0pX9IcNEi0XtiGcIwWSMlkXflb6cPC6PTw4i/adHIq3UAJRCb/ozgWi4vR5vEkkPfHWls42ZeIzkaDv8wF3bdQom9itQwLdaKqOh+gyrEjlvdUoHQoYGa6/q4VrNVE01kF2XaKCKsJS3dloe9UKMlqkFZbWV5Do67hwUki3nSJcjsmbclO9+Chw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lightside-instruments.com; dmarc=pass action=none header.from=lightside-instruments.com; dkim=pass header.d=lightside-instruments.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT4991094.onmicrosoft.com; s=selector2-NETORGFT4991094-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+7vhJsgl7J7eXXkCEGEk7fuGUTnKCqv3K4tw6PU2DVw=; b=iizWSYTDSb/HAdBXmnGS8ZE6UIMJkTyGaFW5yvueNBMkhj33QBnMfO2vBUilrfOgA6GE4Z/PVzOlqS1dvl0twx4bykDjuvI8CBvNfsj5V81SVdO/jGle/h6OnzKJOFMs5/u/5MaSatQVGz8ZegLh92TeQi9Rn1Sv8iJ0y2WFoRA=
Received: from AM0PR08MB4369.eurprd08.prod.outlook.com (20.179.33.207) by AM0PR08MB3378.eurprd08.prod.outlook.com (20.177.109.78) 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 18:15:25 +0000
Received: from AM0PR08MB4369.eurprd08.prod.outlook.com ([fe80::74d2:19a5:44e3:6641]) by AM0PR08MB4369.eurprd08.prod.outlook.com ([fe80::74d2:19a5:44e3:6641%3]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 18:15:25 +0000
From: Vladimir Vassilev <vladimir@lightside-instruments.com>
To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
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/h7k1YMOLgk+Jf2JSa16yyad+LrWAgABETQA=
Date: Wed, 06 Nov 2019 18:15:25 +0000
Message-ID: <41b664d0-961a-1974-2f3b-60f0bbf3bd26@lightside-instruments.com>
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> <20191106141054.zgqtaroekbthad72@anna.jacobs.jacobs-university.de>
In-Reply-To: <20191106141054.zgqtaroekbthad72@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: PR0P264CA0132.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1a::24) To AM0PR08MB4369.eurprd08.prod.outlook.com (2603:10a6:208:13e::15)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=vladimir@lightside-instruments.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:840:4b0b:1337:c68e:8fff:fef3:82a7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 232f5908-e572-4e4f-5662-08d762e54b9b
x-ms-traffictypediagnostic: AM0PR08MB3378:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <AM0PR08MB3378B2DCEF86060502E41C829B790@AM0PR08MB3378.eurprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(396003)(376002)(136003)(366004)(346002)(199004)(189003)(561944003)(71190400001)(102836004)(25786009)(2906002)(31696002)(36756003)(6436002)(52116002)(71200400001)(6306002)(6512007)(2616005)(7736002)(229853002)(14444005)(8936002)(256004)(8676002)(476003)(305945005)(54906003)(66574012)(14454004)(66476007)(31686004)(81166006)(6486002)(316002)(4326008)(486006)(81156014)(46003)(186003)(5660300002)(6916009)(6246003)(66446008)(508600001)(76176011)(446003)(99286004)(66946007)(6116002)(86362001)(11346002)(966005)(6506007)(66556008)(386003)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB3378; H:AM0PR08MB4369.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: lightside-instruments.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GrZDTiomKw9jEpg+1Lr86OgfW8iKoBs7ZYWTA1MkiG0srmzlNbp5st1KlOl3DgC2UjQ/mwk3VZF1M2HVZdTXR1SLekk4HGhg957xBxbjrDyBRAi2Mxrb1B3QQu3CgTEdeHgYPPs7/WMdjP6s4cuBXaxH4Za6xfPe7YE6sB0HDEoTeg/NLHEF5YTcLWCBHZFQhlI9HkWxQH3xUmiocUcIJC1QEfH5KdqULii8N5sZL6dd00gpohCMW5r5iAmfrA4viXBKRlOH1zchQrueMoE6rgo+u66ih/qz+jpyrVGFUsb6HCjd25x02QJ5kC5b3bXQ2MHZVn74ovkaUt0P0J7K6KQJKisvtJxDvsNt9msH/y4UFqOycxEh8lS1cut+l6RmgqzYK0MaooyxAWTsXp+a8S4LUekfYI7lCRWhOtY8xdH38u1lVKxfnW0alMvawXJRyKhl7QOsWUgl+ZJDpuwoMWBSgrap5zM8yVdLUqoN7SY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <54FEE7E716144949947752EA2BAC4481@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: lightside-instruments.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 232f5908-e572-4e4f-5662-08d762e54b9b
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 18:15:25.3127 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c0326317-f373-4461-a96f-7946e0abb603
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: K614b9db9Dmz5K1yrfiBAzz8mvjAjYgj0/4qpFVUwXsWMa+K73LaxSpUW0wQB8hzFByJ4vBzi6VNa++GVNJ03pcusieAoclC7yJnDPPxKnvV1TEW6pvQolJURpkZRZIa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3378
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/DSNN3K0dP6k4Ex4tmlWUU1BckeE>
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 18:15:36 -0000

On 06/11/2019 15.10, Schönwälder, Jürgen wrote:
> 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. ;-)


There is no technical reason at all to have MAC addresses represented as 
pattern constrained strings and not "binary" of length 6 (as it was in 
SMIv2 MIBs) either. There is no technical reason for ethertype to be 
represented as pattern constrained string and not "binary" of length 2 
or "uint16". It is likely done because of the sane lexical 
representation requirement derived from NETCONF design requirement to be 
human readable on the wire and this is not the case when the data is 
base64 encoded or in the better case represented as decimal when humans 
are used to its hex-string representation.

This is what this proposed type offers - readable and writable 
representation (more readable and writable by humans then the base64 
representation of binary).

That said defining new uint* and binary built-in sub-statement 
{lexical-representation hex-string;} enabling alternative lexical 
representation might be the right solution:

typedef mac-address {
   type binary {
     length 6;
     lexical-representation hex-string;
   }
}

typedef ether-type {
   type uint16 {
     lexical-representation hex-string;
   }
}

/Vladimir


>
> /js
>