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 [email protected]
>>
>> 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
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
