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