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

Scott Mansfield <> Wed, 06 November 2019 16:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDED712087B for <>; Wed, 6 Nov 2019 08:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gt1r0bb9sjo9 for <>; Wed, 6 Nov 2019 08:29:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D8D212086A for <>; Wed, 6 Nov 2019 08:29:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=RH/S8X2rY8bLujWIpssk8fta1v5IvsZa2t1DIQ+G5+HH36Bm3frUnByil0z8SwyHlYgSGdkbyjcJTBGEGChDtn4eaS97FrJNPrw3g5jJo4Yp+r0RsIegqrYJhkSFFt703xtjHfMHFLZKTP6LJ+BYSYiykkVdtKLw5oIEzI+cDoM9g+onLp4Kg6dIiBEdFFDHW9e66xRMKzoR7Qe2amXku5bBv5BCyMLpdE62zqgb1LB54XA1RWZgZW2x/5h54tF4Y2yKui5MuqxW6wXbnNV60jD6wOcC782v77lTSbQConjhrKYKa2YR+QqtAnbXh1KH6PAs05TkVHbKUnj3vyvE+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Q3kU2tgiy1l2+MCMq+Ri0yTUwyDsS683e/xFpT6kQY=; b=TCZ3HCFjZCkTqVc9zIWdQiPqRxR6Vw+3rY9c0mxWLY3Zgl2fl96pAAQL8EuQ1HOcMKE5xMAQdoD+HPpdD3zsr0LuBHc1O4dH4mCn4YpSUVgHcnEBDE9ZxSZuolyBE6mh5p1mTbiSCBkiN1TA2dwSc25j5WSbBzcVQlNfJFNvzBYjetROxB/HDjOBSxxq8f1fpint1n82SEEUq5K9icUAncUIGMqAD4644orksb3G/EcbFx48KxJuX2kFDJXOMga0vA6g+SjOQOutPdywjq08Ir55DJVIegK2+7q50hk9i3wlvVOcoTZd3tDsCBcPK82qoVgiXvtF8Exl/hCFzoeyNA==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Q3kU2tgiy1l2+MCMq+Ri0yTUwyDsS683e/xFpT6kQY=; b=faNXDE4P2RuFQSfvFqIBIvSWUSemeYp0H58n534nYEUaWvBM4OxjA7C+4q+/lyE68OXv188KKtmM6BtcyxOQIKp9D2XAUTxLSow+PgQLIkzDRzLo2u6dzDB5dhPP8ZhhxCMctJSmhPNTJCshkNcVSH/TECTji60VqFM5SpZ774o=
Received: from ( by ( 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 16:29:22 +0000
Received: from ([fe80::cc77:ad6:c868:482b]) by ([fe80::cc77:ad6:c868:482b%7]) with mapi id 15.20.2430.020; Wed, 6 Nov 2019 16:29:22 +0000
From: Scott Mansfield <>
To: Vladimir Vassilev <>, tom petch <>, "" <>
Thread-Topic: hex-string as built-in type in future versions of YANG
Thread-Index: AQHVlKY+KWDtjPWkUEerecz0ieqA5ad+UybQ
Date: Wed, 06 Nov 2019 16:29:22 +0000
Message-ID: <>
References: <> <> <00e501d58b52$2bc35b60$> <> <06eb01d58e54$84b43fa0$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ab24c4e0-ba5f-4c56-5c67-08d762d67b2d
x-ms-traffictypediagnostic: SN6PR15MB2317:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39860400002)(376002)(366004)(136003)(129404003)(51444003)(13464003)(174864002)(199004)(189003)(11346002)(486006)(446003)(5660300002)(476003)(52536014)(25786009)(8936002)(81166006)(8676002)(81156014)(256004)(2906002)(5024004)(14444005)(71190400001)(71200400001)(44832011)(6116002)(3846002)(33656002)(561944003)(110136005)(229853002)(966005)(2501003)(316002)(14454004)(6436002)(66066001)(7696005)(76176011)(102836004)(55016002)(6246003)(53546011)(6506007)(6306002)(99936001)(478600001)(99286004)(66946007)(76116006)(7736002)(66446008)(305945005)(64756008)(74316002)(186003)(26005)(86362001)(66476007)(66616009)(66556008)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR15MB2317;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: c4c6CZ9+q4IJjvT5hCPh3uoy7uEobyPVeaq8i+u4Udgw6u77M4PQTxgM92f2QfjlwN0aJhIduV3hU0UU6Ca9qCHdWic4VJzi6KaMcUa+HvtTAAEFuFGyHdMfXVk1pxo4MFm2cdn3WX6KWrrFJ/xnMaIOr/ikQhQBwA0pqBhpKiaJAXDd8aUhhN315S6upncrIF56tpGT7LvfOS/iEVjNK4slsZFIsi8fWs5FdhKPi4scC/diQeqoSb5/6Pmuki1oPx7eNmNrmCfzv+VujifpASRNwhuZpeYCI/GKAohryI7nvWmgE7yfzwxsCmOGlyW5uKDJIGX/5rpAq14TuzBKwu8rlbVepnVuRp2A3kCZ7lPXH6SU4caamo7ycBopvhmTserSvWDTGJLZjkmKIUtUEdKEyUXRMq1fYBxhWKrTJ0wH+whKXWUXQILdqfgmW9wMKszet2VFcEHPrtHC2Yto4g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_01E5_01D59495.6F1C9600"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ab24c4e0-ba5f-4c56-5c67-08d762d67b2d
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 16:29:22.4178 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2suxQvyNu8bDlLoXydblcJnhMGe8aN6fkRKRqn979t82k6EgsA8XH7IjfRx+pIV5x3Nupz3Gi0c7rFet7kuM3MUELXsE97jmSynV2zN1+5M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2317
Archived-At: <>
Subject: Re: [netmod] hex-string as built-in type in future versions of YANG
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Nov 2019 16:29:27 -0000

The licensing information for IEEE YANG models can be found here...  (YANG Catalog's github repository)

If you scroll down there is the text of the file, there you will 

In the Models Directory Structure section:
yang/standard/ieee: standard modules (published or drafts) intended for IEEE 
submission [3]

is this information:
[3] IEEE License:

- All files contained within this sub-directory are considered to be intended 
as IEEE Contributions.

- All issues entered into the trouble ticket system for this directory are 
considered to be intended as IEEE Contributions.

- All pull requests submitted for this directory are considered to be intended 
as IEEE Contributions.

- All contributions to IEEE standards development (whether for an individual 
or entity standard) shall meet the requirements outlined in the IEEE-SA 
Policy (

- Copyright release for YANG modules: Users may freely reproduce the YANG 
modules contained under /standard/ieee/ so that they can be used for their 
intended purpose.

If you really want the official YANG, you can extract the YANG out of the IEEE 
Standard document (yang is included as a txt attachment to pdf).  But the
copyright release is the same.  See for 
a place to freely download 802 Standards.

Hope this helps.


-----Original Message-----
From: netmod <> On Behalf Of Vladimir Vassilev
Sent: Wednesday, November 6, 2019 8:30 AM
To: tom petch <>;
Subject: [netmod] hex-string as built-in type in future versions of YANG

Moving a netmod relevant topic from a thread on the bmwg mailing list

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}";
       "The EtherType value represented in the canonical order defined
       by IEEE 802. The canonical representation uses uppercase
       "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 
(posted the last paragraph of this proposal there).


> Tom Petch
netmod mailing list