Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

2017-07-11 Thread Benoit Claise 

On 7/11/2017 5:55 PM, Mahesh Jethanandani wrote:

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?

Yes, Saturday afternoon.

regards, B.


On Jul 11, 2017, at 3:25 AM, Benoit Claise > wrote:


Hi,

In order to look at what has been done already, the advice is to look 
at YANG search .

I searched on "ether.type" with the regex flag.
 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=%2Fdot1q-types%3Aether-type=2016-09-22


Regards, Benoit
Created issue #3 in github 
 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  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 





___
netmod mailing list
netmod@ietf.org
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

Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

2017-07-11 Thread Acee Lindem (acee) 
Mahesh,

From: Mahesh Jethanandani 
<mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>
Date: Tuesday, July 11, 2017 at 3:21 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "Benoit Claise (bclaise)" <bcla...@cisco.com<mailto:bcla...@cisco.com>>, 
Marc Holness <mholn...@ciena.com<mailto:mholn...@ciena.com>>, Glenn Parsons 
<glenn.pars...@ericsson.com<mailto:glenn.pars...@ericsson.com>>, NetMod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>, 
"draft-ietf-netmod-acl-mo...@ietf.org<mailto:draft-ietf-netmod-acl-mo...@ietf.org>"
 
<draft-ietf-netmod-acl-mo...@ietf.org<mailto:draft-ietf-netmod-acl-mo...@ietf.org>>
Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

Acee,

There are couple of arguments in favor of why ether-type should be an well 
define enum, even if we choose to document the public ones.

- operators know and associate names better than numbers for different 
ether-types.
- if ether-type was a distributed registry and had to made extensible, it would 
make sense to define them as identities. ether-types are centrally defined and 
maintained by IEEE RAC.

The layer-2 ACL function needs to the uint16 mappings to be complete.


Alternatively, as suggested by Martin, the definition could be thus:


typedef ether-type {
  type union {
type ieee-ether-type:ether-type-enum;
type uint16; // or a hex-based number
  }
}

where we allow for read/write of the hex-based number while IEEE works up the 
definition of the enums.

This would work but it would delay completion on definition of the ieee-types 
model.

Thanks,
Acee

On Jul 11, 2017, at 10:32 AM, Acee Lindem (acee) 
<a...@cisco.com<mailto:a...@cisco.com>> wrote:

Hi Mahesh, Benoit, Draft Authors,

In terms of a layer-2 ACL, I’d want to be able to match ether-type against any 
2-octet number. Hence, I think a string is a very poor choice here.

In support of the above statement, one only needs to look at the existing IEEE 
registry for ether type.

https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries

There are about 3700+ registered ether-types and most of them are private. This 
is hardly something that we’d want to represent as a YANG enum or even a set of 
identities.

However, if we are talking about future YANG enhancements, it would be nice to 
have an identity that could reference a YANG type as a base rather than another 
identify. That way the base type could be uint16 or some other 2-octet type and 
well-known ether-types could be represented by YANG identities referencing the 
base identity of type unit16.

Thanks,
Acee

From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Mahesh Jethanandani 
<mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>
Date: Tuesday, July 11, 2017 at 11:55 AM
To: "Benoit Claise (bclaise)" <bcla...@cisco.com<mailto:bcla...@cisco.com>>
Cc: Marc Holness <mholn...@ciena.com<mailto:mholn...@ciena.com>>, Glenn Parsons 
<glenn.pars...@ericsson.com<mailto:glenn.pars...@ericsson.com>>, NetMod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

Benoit,

Precisely. I did start in yangcatalog.com<http://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<mailto: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.
 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=%2Fdot1q-types%3Aether-type=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

Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

2017-07-11 Thread Mahesh Jethanandani 
Acee,

There are couple of arguments in favor of why ether-type should be an well 
define enum, even if we choose to document the public ones.

- operators know and associate names better than numbers for different 
ether-types.
- if ether-type was a distributed registry and had to made extensible, it would 
make sense to define them as identities. ether-types are centrally defined and 
maintained by IEEE RAC.

Alternatively, as suggested by Martin, the definition could be thus:

typedef ether-type {
  type union {
type ieee-ether-type:ether-type-enum;
type uint16; // or a hex-based number
  }
}
where we allow for read/write of the hex-based number while IEEE works up the 
definition of the enums.

> On Jul 11, 2017, at 10:32 AM, Acee Lindem (acee) <a...@cisco.com> wrote:
> 
> Hi Mahesh, Benoit, Draft Authors, 
> 
> In terms of a layer-2 ACL, I’d want to be able to match ether-type against 
> any 2-octet number. Hence, I think a string is a very poor choice here. 
> 
> In support of the above statement, one only needs to look at the existing 
> IEEE registry for ether type. 
> 
> https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries 
> <https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries>
> 
> There are about 3700+ registered ether-types and most of them are private. 
> This is hardly something that we’d want to represent as a YANG enum or even a 
> set of identities. 
> 
> However, if we are talking about future YANG enhancements, it would be nice 
> to have an identity that could reference a YANG type as a base rather than 
> another identify. That way the base type could be uint16 or some other 
> 2-octet type and well-known ether-types could be represented by YANG 
> identities referencing the base identity of type unit16.  
> 
> Thanks,
> Acee 
> 
> From: netmod <netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org>> on 
> behalf of Mahesh Jethanandani <mjethanand...@gmail.com 
> <mailto:mjethanand...@gmail.com>>
> Date: Tuesday, July 11, 2017 at 11:55 AM
> To: "Benoit Claise (bclaise)" <bcla...@cisco.com <mailto:bcla...@cisco.com>>
> Cc: Marc Holness <mholn...@ciena.com <mailto:mholn...@ciena.com>>, Glenn 
> Parsons <glenn.pars...@ericsson.com <mailto:glenn.pars...@ericsson.com>>, 
> NetMod WG <netmod@ietf.org <mailto:netmod@ietf.org>>
> Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3
> 
> Benoit,
> 
> Precisely. I did start in yangcatalog.com <http://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 
>> <mailto: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.
>>  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=%2Fdot1q-types%3Aether-type=2016-09-22
>>  
>> <https://www.yangcatalog.org/yang-search/show_node.php?module=ieee802-dot1q-types=%2Fdot1q-types%3Aether-type=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 
&g

Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

2017-07-11 Thread Acee Lindem (acee) 
Hi Mahesh, Benoit, Draft Authors,

In terms of a layer-2 ACL, I’d want to be able to match ether-type against any 
2-octet number. Hence, I think a string is a very poor choice here.

In support of the above statement, one only needs to look at the existing IEEE 
registry for ether type.

https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries

There are about 3700+ registered ether-types and most of them are private. This 
is hardly something that we’d want to represent as a YANG enum or even a set of 
identities.

However, if we are talking about future YANG enhancements, it would be nice to 
have an identity that could reference a YANG type as a base rather than another 
identify. That way the base type could be uint16 or some other 2-octet type and 
well-known ether-types could be represented by YANG identities referencing the 
base identity of type unit16.

Thanks,
Acee

From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> on 
behalf of Mahesh Jethanandani 
<mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>
Date: Tuesday, July 11, 2017 at 11:55 AM
To: "Benoit Claise (bclaise)" <bcla...@cisco.com<mailto:bcla...@cisco.com>>
Cc: Marc Holness <mholn...@ciena.com<mailto:mholn...@ciena.com>>, Glenn Parsons 
<glenn.pars...@ericsson.com<mailto:glenn.pars...@ericsson.com>>, NetMod WG 
<netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

Benoit,

Precisely. I did start in yangcatalog.com<http://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<mailto: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.
 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=%2Fdot1q-types%3Aether-type=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


Mahesh Jethanandani
mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

2017-07-11 Thread Mahesh Jethanandani 
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  wrote:
> 
> Hi,
> 
> In order to look at what has been done already, the advice is to look at YANG 
> search .
> I searched on "ether.type" with the regex flag.
>  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=%2Fdot1q-types%3Aether-type=2016-09-22
>  
> 
> 
> Regards, Benoit
>> Created issue #3 in github  
>> 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  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 
>> 
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org 
>> 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

Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

2017-07-11 Thread Benoit Claise 

Hi,

In order to look at what has been done already, the advice is to look at 
YANG search .

I searched on "ether.type" with the regex flag.
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=%2Fdot1q-types%3Aether-type=2016-09-22


Regards, Benoit
Created issue #3 in github 
 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  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 





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft-ietf-netmod-acl-model-11 issue #3

2017-07-07 Thread Mahesh Jethanandani 
Created issue #3 in github  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  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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod