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

[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 netmod agenda posted

[Kent Watsen]

Could all the presenters please have a slide on their module's NMDA
compatibility status?  Things to consider:

 - is the operational state of configured values important?
 - is there is a need to support system generated entries?
 - note: if yes to either, the module SHOULD be NMDA-compatible.
 is it? - is there a "-state" tree in the Appendix?

Thanks,
Kent // co-chair


--

The draft agenda for the NETMOD sessions at IETF 99 has been posted:

  https://datatracker.ietf.org/meeting/99/agenda/netmod/

Please let us know if any adjustments are needed.

Thanks,
NETMOD WG Chairs



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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Kent Watsen]

I think that there might be a paragraph or two in the nmda-guidelines draft 
that could be
used as source material, but by and large, I'm imagine new text being needed.  
If none of
my co-authors step forward, I'll pen up some proposal text for Section 6.23 
myself, but it
may be awhile, with IETF-week coming on strong now (I'm sure you relate).

Don't worry about timing. The urgency to get 6087bis out with 7950 has 
subsided.  But
we do need to ensure that 6087bis dovetails nicely with the NMDA.

Kent  // shepherd


On 7/11/17, 4:44 PM, "Andy Bierman" 
> wrote:

Hi,

Do you have text from your that that should be pasted into section 6.23?

I think there were other issues, such as changing the terminology to reference 
RD.
There were comments opposing that idea because the definition for 
'configuration'
including everything that could possibly change the behavior of the device.


Andy


On Tue, Jul 11, 2017 at 1:31 PM, Kent Watsen 
> wrote:
Hi Andy,

I confirmed with Lou and Benoit that we want 6.23 to have the normative text 
within it,
as we're both unsure about if the nmda-guidelines draft will progress and also 
believe
that the text could be written more helpfully for the 6087bis audience.

Would it help if one of the nmda-guidelines authors wrote the section for you?

Thanks,
Kent   // co-chair


On 6/20/17, 11:27 AM, "Andy Bierman" 
> wrote:

Hi,

I rewrote 6.23 and it points at the NMDA guidelines.
The drafts will get published together so the references will
be to RFCs, not I-Ds.  That is usually what is meant by the comment below I 
think




> I don't expect the guidelines doc is going to progress independently.

Agreed.

Andy

On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen 
> wrote:


Regarding the suggestion to add this text:

> Guidelines for
>  moving existing data modules to the NMDA are defined in
>  [I-D.dsdt-nmda-guidelines].

I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis can 
just state what people should do, without providing a formula for transitioning.

I thought 6087bis is supposed to point people to the NMDA guidelines.
That is why 6087bis has been held back for so long, even though it was
supposed to be published with YANG 1.1.

We waste a lot of time refactoring drafts and re-reviewing them.
IMO the RD guidelines should be in the RD draft.


 I thought that this was settled before (maybe not): 
https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q






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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Andy Bierman]

Hi,

Do you have text from your that that should be pasted into section 6.23?

I think there were other issues, such as changing the terminology to
reference RD.
There were comments opposing that idea because the definition for
'configuration'
including everything that could possibly change the behavior of the device.


Andy


On Tue, Jul 11, 2017 at 1:31 PM, Kent Watsen  wrote:

> Hi Andy,
>
>
>
> I confirmed with Lou and Benoit that we want 6.23 to have the normative
> text within it,
>
> as we're both unsure about if the nmda-guidelines draft will progress and
> also believe
>
> that the text could be written more helpfully for the 6087bis audience.
>
>
>
> Would it help if one of the nmda-guidelines authors wrote the section for
> you?
>
>
>
> Thanks,
>
> Kent   // co-chair
>
>
>
>
>
> On 6/20/17, 11:27 AM, "Andy Bierman"  wrote:
>
>
>
> Hi,
>
>
>
> I rewrote 6.23 and it points at the NMDA guidelines.
>
> The drafts will get published together so the references will
>
> be to RFCs, not I-Ds.  That is usually what is meant by the comment below
> I think
>
>
>
>
>
> > I don't expect the guidelines doc is going to progress independently.
>
> Agreed.
>
>
>
> Andy
>
>
>
> On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen  wrote:
>
>
>
>
>
> Regarding the suggestion to add this text:
>
> > Guidelines for
> >  moving existing data modules to the NMDA are defined in
> >  [I-D.dsdt-nmda-guidelines].
>
> I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis
> can just state what people should do, without providing a formula for
> transitioning.
>
>
>
> I thought 6087bis is supposed to point people to the NMDA guidelines.
> That is why 6087bis has been held back for so long, even though it was
>
> supposed to be published with YANG 1.1.
>
>
>
> We waste a lot of time refactoring drafts and re-reviewing them.
>
> IMO the RD guidelines should be in the RD draft.
>
>
>
>
>
>  I thought that this was settled before (maybe not):
> https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q
>
>
>
>
>
>
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-13.txt

[Kent Watsen]

Hi Andy,

I confirmed with Lou and Benoit that we want 6.23 to have the normative text 
within it,
as we're both unsure about if the nmda-guidelines draft will progress and also 
believe
that the text could be written more helpfully for the 6087bis audience.

Would it help if one of the nmda-guidelines authors wrote the section for you?

Thanks,
Kent   // co-chair


On 6/20/17, 11:27 AM, "Andy Bierman" 
> wrote:

Hi,

I rewrote 6.23 and it points at the NMDA guidelines.
The drafts will get published together so the references will
be to RFCs, not I-Ds.  That is usually what is meant by the comment below I 
think




> I don't expect the guidelines doc is going to progress independently.

Agreed.

Andy

On Tue, Jun 20, 2017 at 8:20 AM, Kent Watsen 
> wrote:


Regarding the suggestion to add this text:

> Guidelines for
>  moving existing data modules to the NMDA are defined in
>  [I-D.dsdt-nmda-guidelines].

I'm hoping that we do not progress the guidelines doc.  Ideally 6087bis can 
just state what people should do, without providing a formula for transitioning.

I thought 6087bis is supposed to point people to the NMDA guidelines.
That is why 6087bis has been held back for so long, even though it was
supposed to be published with YANG 1.1.

We waste a lot of time refactoring drafts and re-reviewing them.
IMO the RD guidelines should be in the RD draft.


 I thought that this was settled before (maybe not): 
https://mailarchive.ietf.org/arch/msg/netmod/pDLDm8gdIBwwyGyfa_acVKHtu_Q





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

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

[Acee Lindem (acee)]

Mahesh,

From: Mahesh Jethanandani 
>
Date: Tuesday, July 11, 2017 at 3:21 PM
To: Acee Lindem >
Cc: "Benoit Claise (bclaise)" >, 
Marc Holness >, Glenn Parsons 
>, NetMod WG 
>, 
"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) 
> 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 > on 
behalf of Mahesh Jethanandani 
>
Date: Tuesday, July 11, 2017 at 11:55 AM
To: "Benoit Claise (bclaise)" >
Cc: Marc Holness >, Glenn Parsons 
>, NetMod WG 
>
Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

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.

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

[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)  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 > on 
> behalf of Mahesh Jethanandani  >
> Date: Tuesday, July 11, 2017 at 11:55 AM
> To: "Benoit Claise (bclaise)" >
> Cc: Marc Holness >, Glenn 
> Parsons >, 
> NetMod WG >
> Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3
> 
> 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 

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

[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 > on 
behalf of Mahesh Jethanandani 
>
Date: Tuesday, July 11, 2017 at 11:55 AM
To: "Benoit Claise (bclaise)" >
Cc: Marc Holness >, Glenn Parsons 
>, NetMod WG 
>
Subject: Re: [netmod] draft-ietf-netmod-acl-model-11 issue #3

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.orghttps://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

[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

[netmod] draft-ietf-netmod-revised-datastores-03 feedback

[Benoit Claise]

Dear all,

Good job on this document.

Some comments below.

-

OLD:

   o  learned configuration: Configuration that has been learned via
  protocol interactions with other systems that is not conventional
  or dynamic configuration.

NEW (is this what wou want to say?):
   o  learned configuration: Configuration that has been learned via dynamic 
configuration
  or protocol interactions with other systems that is not conventional

Thinking some more about this definition. Let's come back to it.

-
 
   o  dynamic datastore: A datastore holding data obtained dynamically

  during the operation of a device through interaction with other
  systems, rather than through one of the conventional configuration
  datastores.


Should the dynamic datastore should say:
   o  dynamic datastore: A datastore holding configuration data obtained 
dynamically ...


Background:
Reading this definition:
  o  system state: The additional data on a system that is not
  configuration, such as read-only status information and collected
  statistics.  System state is transient and modified by
  interactions with internal components or other systems.  System
  state is modeled in YANG using "config false" nodes.

I guessed that the system states don't include the content from the dynamic 
datastore.
It's not obvious with the current definitions.


- This figure and section 4.7 text.

 +-+ +---+
 |  | |  |
 |  (ct, rw)   |<---+   +--->| (ct, rw)  |
 +-+|   |+---+
|   |   |   |
| +---+ |
+>|  |<+
  | (ct, rw)  |
  +---+
|
|// configuration transformations,
|// e.g., removal of "inactive"
|// nodes, expansion of templates
v
  ++
  |  | // subject to validation
  | (ct, ro)   |
  ++
|// changes applied, subject to
|// local factors, e.g., missing
|// resources, delays
|
|   + learned configuration
   dynamic  |   + system configuration
   datastores -+|   + default configuration
   ||   |
   vv   v
+---+
|  | <-- system state
| (ct + cf, ro) |
+---+



  Section 4.7

contains system state and all configuration actually
   used by the system.  This includes all applied configuration from
   , system-provided configuration, and default values defined
   by any supported data models.  In addition,  also
   contains applied data from dynamic datastores.

What about "learned configuration"

- Section 3.
The important question is whether the section 2 "datastore" and 
"configuration datastore" definitions are aligned with previous 
definitions or not.

I guess not. If this is the case, it should be clearly mentioned.

- Section 4.5
No need to repeat what's in the terminology section.

- Section 4.7

OLD:

   In the original NETCONF model the operational
   state only had "config false" nodes.

OLD:

   In the original NETCONF model (RFC6241 or section 3.1) the operational
   state only had "config false" nodes.


- Security Considerations.
You might want to stress that, even if this document contains YANG 
modules, those modules have no read or read/write leaves: only 
identities and a metadata. Hence "YANG module security guidelines" don't 
apply.

Now, there surely exist some security considerations anyway.

- Is appendix A normative?
Should it move to the document core?

Regards, Benoit













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

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

[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] netmod documents

[Benoit Claise]

Dear all,

In preparation for our meetings next week.

Regards, Benoit

$ wgstatus -s netmod
Getting IETF document states
Getting IETF docs for netmod
Getting IETF RFCs for netmod
Getting history for draft-ietf-netmod-syslog-model
Getting history for draft-ietf-netmod-yang-tree-diagrams
Getting history for draft-ietf-netmod-sub-intf-vlan-model
Getting history for draft-ietf-netmod-schema-mount
Getting history for draft-ietf-netmod-revised-datastores
Getting history for draft-ietf-netmod-acl-model
Getting history for draft-ietf-netmod-intf-ext-yang
Getting history for draft-ietf-netmod-yang-model-classification
Getting history for draft-ietf-netmod-rfc6087bis
Getting history for draft-openconfig-netmod-model-catalog
Getting history for draft-clemm-netmod-mount
Getting history for draft-vallin-netmod-alarm-module

# Document Status Since IETF-98 in Chicago (2017-03-26)

## Docs in IESG
draft-ietf-netmod-rfc6087bisActive,WG Document,AD Evaluation
draft-ietf-netmod-yang-model-classification Active,Version Changed - 
Review Needed,No IC,Submitted to IESG for Publication,EDIT,RFC Ed Queue


## New WG Docs
draft-ietf-netmod-yang-tree-diagrams Active,WG Document

## Updated WG Docs
draft-ietf-netmod-acl-model   Active,WG Document
draft-ietf-netmod-intf-ext-yang   Active,WG Document
draft-ietf-netmod-revised-datastores  Active,WG Document
draft-ietf-netmod-schema-mountActive,WG Document
draft-ietf-netmod-sub-intf-vlan-model Active,WG Document
draft-ietf-netmod-syslog-modelActive,WG Document
draft-ietf-netmod-yang-tree-diagrams  Active,WG Document

## Existing WG Docs
draft-ietf-netmod-entity Active,WG Document

## New Individual Docs
draft-bierman-netmod-yang-data-ext   Active
draft-chin-netmod-iana-af-numbersActive
draft-clacla-netmod-model-catalogActive
draft-wang-netmod-cfm-yang   Active
draft-wilton-netmod-interface-properties Active

## Updated Individual Docs
draft-clemm-netmod-mount  Active
draft-openconfig-netmod-model-catalog Active,Candidate for WG Adoption
draft-vallin-netmod-alarm-module  Active

## Existing Individual Docs
draft-bertz-netmod-commonaugment  Active
draft-bjorklund-netmod-yang-tree-diagrams Active
draft-faq-netmod-cpe-yang-profile Active
draft-han-netmod-intf-ext-ppp-yangActive
draft-hares-netmod-i2rs-yang  Active
draft-lengyel-netmod-schema-annotationActive
draft-lhotka-netmod-yang-markup   Active
draft-liu-netmod-yang-scheduleActive
draft-rtgyangdt-netmod-module-tagsActive
draft-zhuang-netmod-yang-poe-management   Active



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