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

[Schönwälder, Jürgen <[e-mail]>]

On Wed, Nov 06, 2019 at 06:15:25PM +0000, Vladimir Vassilev wrote:
> 
> 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.

The goal was to automate configuration and configuration data used to
be given to operators (and their automation scripts) in a textual
format. I think this is why we favored textual representations (the
data on the wire is encrypted anyway). In the MIB world, we had some
limited ways to define automated conversions between binary data and
their textual representation. This mechanism was good enough for MAC
addresses, but it already falls apart with representation of IPv6
addresses according to RFC 5952.

Yes, it might have been wise to not always tie YANG's 'binary' to
'base64' but this is what we did end up doing (after longer
discussions about this). One argument was that if you want a
hex-string, you can simply define it (as long as you do not care much
about supporting binary encodings - this we did not care much about
back than, likely a mistake if I look back).

Anyway, IETF preferring lowercase characters and IEEE preferring
uppercase characters for some shared types is a non-technological
conflict and I see no easy way to resolve this.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>