Benoit, Precisely. I did start in yangcatalog.com with the search for ether-type and found that it was defined as a string. It was helpful to get rid of the duplicate definition we had in the ACL draft. But that raised the question of whether it should be defined as a string, when ether-types are well known types.
Is there a IETF-IEEE co-ordination meeting planned in Prague? > On Jul 11, 2017, at 3:25 AM, Benoit Claise <bcla...@cisco.com> wrote: > > Hi, > > In order to look at what has been done already, the advice is to look at YANG > search <https://www.yangcatalog.org/yang-search/yang-search.php>. > I searched on "ether.type" with the regex flag. > <gidfollnniceccif.png> Don't pay attention to the last entry, this will be > fixed. > > However, specifically pay attention to the second entry, the IEEE one. > It points to > https://www.yangcatalog.org/yang-search/show_node.php?module=ieee802-dot1q-types&path=%2Fdot1q-types%3Aether-type&revision=2016-09-22 > > <https://www.yangcatalog.org/yang-search/show_node.php?module=ieee802-dot1q-types&path=%2Fdot1q-types%3Aether-type&revision=2016-09-22> > > Regards, Benoit >> Created issue #3 in github <https://github.com/netmod-wg/acl-model/issues/3> >> as "The model defines 'ether-type' node as a string.” with the following >> description. >> >> The model defines 'ether-type' node as a string. Ideally, this should be a >> well defined list of all Ethernet Types assigned by IEEE. This requires >> collaborating with IEEE. >> >> One suggestion was to define ether-type as identities. That works for when >> the identities themselves are distributed and need to be made extensible. >> >> But Ethernet Types are doled out in IEEE by Registration Authority Committee >> (RAC), so they could choose to centrally define it as an enum and give each >> hex string a name that could be used by models. If a user wants to configure >> a particular ether-type, the server must import a version of the IEEE 8021q >> model that has that enumeration. >> >> Alternatively, as @mbj4668 <https://github.com/mbj4668> has suggested, it >> could also be a typedef like this: >> >> typedef ether-type { >> type union { >> type ieee-ether-type:ether-type-enum; >> type uint16; // or a hex-based number >> } >> } >> Finally, the suggestion is to have ether-type defined as a number (or hex >> based). This is flexible, but requires users/operators to read and write >> numbers which are harder to remember than symbolic names. >> >> My personal preference would be for IEEE to define and publish the YANG >> model with the definitions. >> >> Mahesh Jethanandani >> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org <mailto:netmod@ietf.org> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://www.ietf.org/mailman/listinfo/netmod> > Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
