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 ieee802-dot1q-ty...@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.
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. ;-)
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
