Alex,
One of the suggestions to deal with that came from Martin in trying to define
it as:
typedef ethertype {
type union {
type ieee-ethertype:ethertype-enum;
type uint16; // or a hex-based number
}
}
where ieee-ethertype would be defined by IEEE as suggested below. But Acee felt
that would delay the deployment of the ieee-types model.
> On Jul 11, 2017, at 9:28 PM, Acee Lindem (acee) <a...@cisco.com> wrote:
> This would work but it would delay completion on definition of the ieee-types
> model.
Is that what folks want?
> On Jul 19, 2017, at 12:29 AM, Alex Campbell <alex.campb...@aviatnet.com>
> wrote:
>
> Doesn't this mean that if a new protocol is defined, then it won't be usable
> in ACLs until the server's data model is upgraded? (And with many devices,
> that is quite likely never)
>
> From: netmod <netmod-boun...@ietf.org> on behalf of Mahesh Jethanandani
> <mjethanand...@gmail.com>
> Sent: Tuesday, 18 July 2017 6:21 p.m.
> To: NetMod WG
> Subject: [netmod] ACL draft defines ether-type as a string
>
> The issue of ether-type defined as a string was discussed with participants
> from IEEE in IETF. It was generally agreed that since ether-types are well
> known values, and centrally managed, that they be defined as enumerations.
> There was some clarification sought by IEEE on which values need to be
> published. It was suggested that ether-types that are either private or do
> not have a protocol identified would be named as ether-type-0xXXXX where
> 0xXXXX represents the value assigned. All the remaining ether-types will be
> defined as enums with the well known names.
>
> As far as the impact of that on the ACL draft is concerned, it will be to
> remove all local definitions for ether-type from the draft, such as the one
> below and instead use the definition from IEEE, whenever that is done. It
> does however put a dependency on the IEEE model.
>
> leaf ether-type {
> type string {
> pattern '[0-9a-fA-F]{4}';
> }
> description
> "The Ethernet Type (or Length) value represented
> in the canonical order defined by IEEE 802.
> The canonical representation uses lowercase
> characters.
>
> Note: This is not the most ideal way to define
> ether-types. Ether-types are well known types
> and are registered with RAC in IEEE. So they
> should well defined types with values. For now
> this model is defining it as a string.
> There is a note out to IEEE that needs to be
> turned into a liaison statement asking them to
> define all ether-types for the industry to use.";
> reference
> "IEEE 802-2014 Clause 9.2";
> }
> reference
> "IEEE 802: IEEE Standard for Local and Metropolitan
> Area Networks: Overview and Architecture.";
> }
>
> Mahesh Jethanandani
> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
>
>
>
>
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
