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

[Vladimir Vassilev <[e-mail]>]

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 [e-mail]

   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