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

Vladimir Vassilev <vladimir@lightside-instruments.com> Wed, 06 November 2019 13:29 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 1932D12010C for <netmod@ietfa.amsl.com>; Wed, 6 Nov 2019 05:29:48 -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 NLpWE8wM2CvP for <netmod@ietfa.amsl.com>; Wed, 6 Nov 2019 05:29:45 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80045.outbound.protection.outlook.com [40.107.8.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 EA3A112087E for <netmod@ietf.org>; Wed, 6 Nov 2019 05:29:44 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HaXWsV6q677i4YkK13hLeG4s1B7mzfvZOSv/rP5ZXkjfccjTdjYh9DXv2I12lXqJ2DsmA+Q4ctDLzFoQ0V6xL/KCsDlKCbMhitO9stk+oLkF5N2juaDlMO37JCu8ykHvDv1coUCRfgwKPUnTWBHysAZdc5XUCxMz2dbrrkvmP517agVGNbZpq1nRm5UqukSv954kPNKejjWdFrBFWSLlo0jUSWuuWmL+7hBi+uZm8WK+p67u8m3cuKtR9zSZI5EHmAlTp/9uHkH6lC3N8GRLSDHTD0n/jtT+grHwZnAD2DGqKV+KDh/Y64wh6a48sSb+LJP7muCiw0pP2adVAQXcIg==
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=AhAFvjH/wAKMwixUdCW3XltSHSdtX0teOqUEXfTqtaY=; b=VYU0creitxjq3urRWNDah8BmbVe63D+UrIk5tEa8CJHN7tZ2TMjn68+gPrZTQnRX6aXWhjGAJW7TD+25RGGFwVjdM/BZAzsOdedZMxlMLeTh6IxNP5t98iXKy8neBAOsVHienzFoAk587mhw1J4Qmz04qmb+4wRYfqGHRupQOgsVYuEeE2kLteV4PQY0OGO0ulhBDP7S+FnwnkIM1mHdjAERE3L81X+svFCpxENoN0DDnyjG6dagkAksaMKTWhMNsL/c0roksnoZJ4aNSH89dg8w7Yvsrd5eWKoZWxbEPE0aKXwDc5AXd0lfTowuj8fSMX3DVVZQWVf0Ml6wu+4D1g==
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=AhAFvjH/wAKMwixUdCW3XltSHSdtX0teOqUEXfTqtaY=; b=nDk3gGCDmqC8AzlY8Z84imhNlGomZgQ+MnxL5gnttTwvRzj3cFC1pDqGZxZ4Y7O1XUu3SHi5QpxV/5cNsAoXIZf2nVK3KhwrLkJkBGFts6rSr2atoVnNT1JBkAlgiUOIg8Wn/Ko7+ouqR6rKsOdkWy8O2/BRH9NwG/hekK+Of1U=
Received: from AM0PR08MB4369.eurprd08.prod.outlook.com (20.179.33.207) by AM0PR08MB5012.eurprd08.prod.outlook.com (10.255.29.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.22; Wed, 6 Nov 2019 13:29:42 +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 13:29:42 +0000
From: Vladimir Vassilev <vladimir@lightside-instruments.com>
To: tom petch <ietfa@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: hex-string as built-in type in future versions of YANG
Thread-Index: AQHVlKY+KWDtjPWkUEerecz0ieqA5Q==
Date: Wed, 6 Nov 2019 13:29:41 +0000
Message-ID: <41a2a04d-a9bd-5c2d-678e-0e416a1dd556@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>
In-Reply-To: <06eb01d58e54$84b43fa0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: PR0P264CA0025.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1::13) 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: 62807237-fa5c-4038-4620-08d762bd6159
x-ms-traffictypediagnostic: AM0PR08MB5012:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <AM0PR08MB5012DDC5340305638B16AAA89B790@AM0PR08MB5012.eurprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39830400003)(376002)(136003)(396003)(199004)(51444003)(189003)(81156014)(486006)(6486002)(476003)(2616005)(11346002)(46003)(256004)(186003)(6436002)(446003)(14444005)(102836004)(52116002)(508600001)(6306002)(6512007)(31686004)(2906002)(76176011)(6506007)(386003)(7736002)(25786009)(8676002)(99286004)(36756003)(5660300002)(86362001)(305945005)(8936002)(31696002)(561944003)(110136005)(14454004)(71190400001)(66476007)(66446008)(66556008)(966005)(66946007)(64756008)(316002)(2501003)(6116002)(71200400001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB5012; 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: 3JiWvv92/4MAqzOlswjdsWuYVz65E4GEWQ1m6MNBeUxqG76qThNLdIJ7Yu7RBucoJGnXoJai36gnxwRMXtAPmhc8l/fyKZDBgQ0CsIizheDyeUkc1sNpLUAqYJla0GQG9eYuczcSUnPnF8ymr7rg9s3QtVeNsSvPzbdaZ9Xm4eZ3k47zZY9jCJwPNeIIjwTAXaoCTaQmuvLKgczdb5mSmD4cxnLKAgSBleIUNZAZ8Yi6uooi0BcgSL1hogo4e1qDc0dG98j1cINvUxxGmxbYQ+yqtS19SmHoYBjT35cEH2QYQE9tR1sRDTCKQlqfDzu7q2fzG+ars5Kl7A++CAFqUzvsgXqmX8qoLn7rydbayzp6qKRHhCkUUOsVS/cx9P50tLuPo7cSITs3VL+hnffwxjltcwbeMxlpb0dlLklRcCjfDGwTHyxoasqJCVBLO8rc4iyrZCih7I9H+YFlCD2vnq4mIoaiRtYSIKi9snMADg0=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <672533A7D49B2142A2F2DE5ACE0F960F@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: lightside-instruments.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 62807237-fa5c-4038-4620-08d762bd6159
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 13:29:41.9375 (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: LFn1d5FpMTfRq4YTQm5iNAdIom7c4dU2An2h44GiDRSYfus51+ugrseWlvWHOLk7+YLdgWhAnd8ABIGZa53Y0ZX4Cyr7s3ghxF0nZT1mY9fT5fKpc8ziiKu43y9t9xgB
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5012
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1O8MRLXH5pYuXzOeyIrm2f8GfLo>
Subject: [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 13:29:48 -0000

Moving a netmod relevant topic from a thread on the bmwg mailing list 
https://mailarchive.ietf.org/arch/msg/bmwg/GwkVykKmOX7DFokCFynJVy_ZwZ8

On 29/10/2019 13.32, tom petch wrote:
> Picking up the point below about vlan, this is where the IETF is not
> doing the job it might.  'vlan' appears in many YANG modules with
> several flavours thereof; yes, we might get a better resolution on the
> netmod list but really, apart from our IEEE liaison, I do not know where
> to go for the best advice on this.  I saw this issue surface recently on
> I2RS which, thinking about it, makes sense and there, the outcome was
>       import ieee802-dot1q-types {...      reference
>          "IEEE Std 802.1Qcp-2018: Bridges and Bridged
>           Networks - Amendment: YANG Data Model.";
> i.e. anything vlan we import from the IEEE module.  I did query making
> an IETF module normatively dependent on an IEEE module and the ADs said
> that that was fine so that is the direction in which I think that the
> IETF should go.

I can think of at least 2 issues with importing ieee802-dot1q-types.yang 
in IETF modules. 1. the unclear license under which third party 
organizations can distribute it. 2. Its design

[1] The IETF has liaison with IEEE but the IETF modules are distributed 
under Simplified BSD License while the IEEE ones are not.  It is not 
clear to me what is the effective IEEE license for third party 
organizations that need to distribute the IEEE modules together with the 
importing IETF ones. If the cost of the 5 simple ethernet frame field 
types - ethertype, vlanid, tpid, pcp, cfi is embedding dependency on the 
conservative IEEE licensing policies I think the cost is too high.

[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.

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).

/Vladimir

>
> Tom Petch