Re: [netmod] Feedback on ietf-access-control-list

[Joe Clarke]

On 19 Jul 2017, at 1:42, Mahesh Jethanandani wrote:


Joe,


On Jul 17, 2017, at 6:02 PM, Joe Clarke  wrote:

I’ve read the latest -11 draft, and I have three comments.  I’ve 
been trying to follow the schema changes and make sure I can properly 
get my head around them in order to spot any obvious shortcomings.  
The example in the draft is helpful (as most examples are).  However, 
in the latest draft, it seems that the example has drifted from what 
the model specifies.


Noted. We will fix it.


Thanks.  So my understanding is correct.

While I see in the appendix uses for acl-oper-data, it is not clear 
from the model or main draft text what this would be used for.  
Again, I inferred what the appendix did, but perhaps there could be 
some main draft text that speaks to this container explicitly.


Gathering of statistics has been identified as an open issue, opened 
in GitHub and a separate thread started on netmod. Will identify the 
solution we are looking for in that thread.


Understood.  Thanks for the update.

Joe

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

Re: [netmod] ACL draft defines ether-type as a string

[Robert Wilton]

I like the union approach.

I'm not sure that we really want IEEE to have to define an enum entry 
for every possible Ethertype value.   This just means that 
implementations probably ends up with another large mapping table where 
99% of it is just noise.  So I would suggest that 'named ethertypes' are 
restricted to the set of current ones in standard use that people care 
about, and allow vendors to request that their specific ones be added if 
required.


+1 to the description describing the canonical format.

Thanks,
Rob


On 19/07/2017 07:50, Juergen Schoenwaelder wrote:

It may even mean that they plan to change ether-type-0x to foo
once 0x is allocated to foo, which would be a problem. It seems
a union of a uint16 and an enum can be more robust.

  type union {
type uint16;
type enumeration {
  enum ipv4 {
value 0x0800;
description
  "Internet Protocol version 4 (IPv4)";
reference
  "RFC 791: Internet Protocol"
  }
}
  }

A caveat is that the canonical representation of a uint16 is decimal
(and YANG today has no way to control that), which may be a bit
inconvenient here. Perhaps the description clause should overwrite
this. There is probably also a need to remember implementors that the
canonical representation of the union retains the notation, that is,
if I write a numeric value (i.e., if I write '0x800' I get back the
numeric value 2048 but if I write the enum value 'ipv4' I get back the
enum 'ipv4' and not a numeric value.

I have also found a definition in [1] that uses a string with a
pattern to match a different notation for ether type numeric values.

   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
   "IEEE 802-2014 Clause 9.2";
   }

While this may be more compliant to IEEE 802-2014 Clause 9.2, having
some type that easily resolves to a number may be more desirable in
practice.

[1] 
https://github.com/YangModels/yang/blob/master/standard/ieee/802.1/draft/ieee802-dot1q-types.yang

/js

PS: Writing definitions for seemingly simple types can be fun.

On Tue, Jul 18, 2017 at 10:29:40PM +, Alex Campbell 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  on behalf of Mahesh Jethanandani 

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-0x where 0x 
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



___
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

Re: [netmod] revised-datastores-03: duplicate list entry from conventional + dynamic

[Robert Wilton]

I think that it was in the discussion of priorities later on, where all 
configuration in  is effectively assigned a single priority by 
I2RS so that it can be compared with any incoming I2RS config events.


If the incoming I2RS config is higher priority then any other I2RS 
config, and it is higher than the intended config priority then it 
effectively overwrites the current configuration.  If I2RS config is 
displaced then the appropriate I2RS client is notified that their config 
has been removed, so that they an take action if required.


But if the incoming I2RS config is lower then either intended or other 
I2RS config then the config operation fails and is rejected.


IIRC (from previous discussions), incoming intended configuration will 
always overwrite any conflicting I2RS configuration (regardless of 
priority), with the I2RS client notified that the config has been removed.


All of this should be explained in whichever I2RS draft defines their 
I2RS specific dynamic datastore.


I don't think that we can anything about this in the revised datatstores 
draft because I don't think that the config resolution between dynamic 
and intended is necessarily always the same - the behaviour depends on 
the specific definition of the dynamic datastore.  All the datastores 
draft can state is that when a dynamic datastore is defined it should 
also define how the config merges in, which is covered by appendix 
section A.3 of the draft.


Thanks,
Rob


On 19/07/2017 00:10, Sterne, Jason (Nokia - CA/Ottawa) wrote:


Thx for the quick thoughts Rob.

I2RS has defined that a ‘set’ would fail within the dynamic DS but 
they didn’t really consider/specify that a ‘set’ to the dynamic DS 
could actually fail due to the existence of something in the 
conventional DSes.  I suppose a custom DS (like the i2rs ephemeral) 
can in theory define whatever behavior they want but it may be odd 
that something written to the dynamic DS fails when there isn’t 
something higher prio in the dynamic DS itself.


But someone can sort that out if they ever propose a model that is 
supported both in a dynamic DS and in a conventional DS (assuming we 
don’t want to propose guidelines for that behavior in the revised DS 
draft).


Rgds,

Jason

*From:*Robert Wilton [mailto:rwil...@cisco.com]
*Sent:* Tuesday, July 18, 2017 23:11
*To:* Sterne, Jason (Nokia - CA/Ottawa) ; 
netmod@ietf.org
*Subject:* Re: [netmod] revised-datastores-03: duplicate list entry 
from conventional + dynamic


Hi Jason,

Some thoughts inline ...

On 18/07/2017 22:46, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi all,

The discussions about dynamic datastores in I2RS today made me
wonder about a scenario: What if a data model is supported in both
conventional datastores and in a dynamic datastore (as well as
being readable from the operational datastore), and the same list
entry (e.g. interface abc, but with some different parms in the
dynamic entry vs the config entry) has been created in both the
running and the dynamic DS.

Only one of them can appear when reading the operational DS.

Yes.


I presume that it is up to the specification document of the
dynamic DS to define the collision resolution between dynamic &
conventional.

Yes.


But based on the revised DS draft I believe it would be necessary
for the system to keep/store both copies of ‘interface abc’ so
that a  with source=dynamic would return the dynamic
version of interface abc while a  (or ) with
source=running would return the conventional version of interface
abc.  Do I have that correct ?

Definitely yes for running.  For dynamic, it would depend on the 
definition of the specific dynamic datastore, but likely yes.



I think that also implies that removing one of the copies could
cause the ‘re-installation’ of the other (down to the app layer).

This would also depend on the definition of the specific dynamic 
datastore.


Most likely, if the dynamic entry is removed, then the conventional 
configured value should be re-instated. However, I don't think that 
the reverse is necessarily true.  E.g. in the dynamic datastore is 
I2RS then the initial config event would have failed if it was lower 
priority that conventional.



This concept of storing multiple copies and re-installation is
something I2RS wants to avoid.

This is perhaps more related to multiple I2RS clients rather than 
between I2RS and the conventional datastores.



  But since they have declared that their scope only includes the
use of their models in the dynamic (ephemeral) DS, they won’t have
that behavior.

Rgds,

Jason


Thanks,
Rob





___

netmod mailing list

netmod@ietf.org 

https://www.ietf.org/mailman/listinfo/netmod



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

Re: [netmod] ACL draft defines ether-type as a string

[Juergen Schoenwaelder]

It may even mean that they plan to change ether-type-0x to foo
once 0x is allocated to foo, which would be a problem. It seems
a union of a uint16 and an enum can be more robust.

 type union {
   type uint16;
   type enumeration {
 enum ipv4 {
   value 0x0800;
   description
 "Internet Protocol version 4 (IPv4)";
   reference
 "RFC 791: Internet Protocol"
 }
   }
 }

A caveat is that the canonical representation of a uint16 is decimal
(and YANG today has no way to control that), which may be a bit
inconvenient here. Perhaps the description clause should overwrite
this. There is probably also a need to remember implementors that the
canonical representation of the union retains the notation, that is,
if I write a numeric value (i.e., if I write '0x800' I get back the
numeric value 2048 but if I write the enum value 'ipv4' I get back the
enum 'ipv4' and not a numeric value.

I have also found a definition in [1] that uses a string with a
pattern to match a different notation for ether type numeric values.

  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
  "IEEE 802-2014 Clause 9.2";
  }

While this may be more compliant to IEEE 802-2014 Clause 9.2, having
some type that easily resolves to a number may be more desirable in
practice.

[1] 
https://github.com/YangModels/yang/blob/master/standard/ieee/802.1/draft/ieee802-dot1q-types.yang

/js

PS: Writing definitions for seemingly simple types can be fun.

On Tue, Jul 18, 2017 at 10:29:40PM +, Alex Campbell 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  on behalf of Mahesh Jethanandani 
> 
> 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-0x where 
> 0x 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
> 
> 
> 

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


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Feedback on ietf-access-control-list

[Mahesh Jethanandani]

Joe,

> On Jul 17, 2017, at 6:02 PM, Joe Clarke  wrote:
> 
> I’ve read the latest -11 draft, and I have three comments.  I’ve been trying 
> to follow the schema changes and make sure I can properly get my head around 
> them in order to spot any obvious shortcomings.  The example in the draft is 
> helpful (as most examples are).  However, in the latest draft, it seems that 
> the example has drifted from what the model specifies.

Noted. We will fix it.

> 
> I want to make sure I’m not missing something.  The current example text is:
> 
> 
> 
>   
> 
>   sample-ipv4-acl
>   ipv4
>   
> 
>   rule1
>   
> 
>   10.10.10.1/24
> 
> 
>   11.11.11.1/24
> 
>   
>   
> 
>   
>   
>tcp
>   
> 
>   
> 
>   
> 
> 
> But I believe in the current model, it should be:
> 
> 
> 
>   
> 
>   sample-ipv4-acl
>   ipv4-acl
>   
> 
>   rule1
>   
> 
>   
> 10.10.10.1/24
>   
>   
> 11.11.11.1/24
>   
>   
> tcp
>   
> 
>   
>   
> 
>   
> 
>   
> 
>   
> 
> 
> Based on the presentation, this helps with the typing, and this makes sense 
> to me.
> 
> ===
> 
> Should there be a default for “logging”?  Currently, it’s defined to be an 
> optional boolean without a default.  One could infer that if it’s not 
> present, logging is disabled, but the text does not make that explicit.  I 
> think it would be good to make this default false.

Agreed. Will add default and update the description.

> 
> ===
> 
> While I see in the appendix uses for acl-oper-data, it is not clear from the 
> model or main draft text what this would be used for.  Again, I inferred what 
> the appendix did, but perhaps there could be some main draft text that speaks 
> to this container explicitly.

Gathering of statistics has been identified as an open issue, opened in GitHub 
and a separate thread started on netmod. Will identify the solution we are 
looking for in that thread.

Thanks.

> 
> Joe
> 
> ___
> 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] ACL draft defines ether-type as a string

[Mahesh Jethanandani]

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)  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  
> 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  on behalf of Mahesh Jethanandani 
> 
> 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-0x where 
> 0x 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 
> 
> 
> 
> 

Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] ACL draft defines ether-type as a string

[Alex Campbell]

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  on behalf of Mahesh Jethanandani 

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-0x where 0x 
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



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

Re: [netmod] revised-datastores-03: duplicate list entry from conventional + dynamic

[Sterne, Jason (Nokia - CA/Ottawa)]

Thx for the quick thoughts Rob.

I2RS has defined that a 'set' would fail within the dynamic DS but they didn't 
really consider/specify that a 'set' to the dynamic DS could actually fail due 
to the existence of something in the conventional DSes.  I suppose a custom DS 
(like the i2rs ephemeral) can in theory define whatever behavior they want but 
it may be odd that something written to the dynamic DS fails when there isn't 
something higher prio in the dynamic DS itself.

But someone can sort that out if they ever propose a model that is supported 
both in a dynamic DS and in a conventional DS (assuming we don't want to 
propose guidelines for that behavior in the revised DS draft).

Rgds,
Jason

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Tuesday, July 18, 2017 23:11
To: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf.org
Subject: Re: [netmod] revised-datastores-03: duplicate list entry from 
conventional + dynamic


Hi Jason,

Some thoughts inline ...

On 18/07/2017 22:46, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Hi all,

The discussions about dynamic datastores in I2RS today made me wonder about a 
scenario:  What if a data model is supported in both conventional datastores 
and in a dynamic datastore (as well as being readable from the operational 
datastore), and the same list entry (e.g. interface abc, but with some 
different parms in the dynamic entry vs the config entry) has been created in 
both the running and the dynamic DS.

Only one of them can appear when reading the operational DS.
Yes.



I presume that it is up to the specification document of the dynamic DS to 
define the collision resolution between dynamic & conventional.
Yes.



But based on the revised DS draft I believe it would be necessary for the 
system to keep/store both copies of 'interface abc' so that a  with 
source=dynamic would return the dynamic version of interface abc while a 
 (or ) with source=running would return the conventional 
version of interface abc.  Do I have that correct ?
Definitely yes for running.  For dynamic, it would depend on the definition of 
the specific dynamic datastore, but likely yes.



I think that also implies that removing one of the copies could cause the 
're-installation' of the other (down to the app layer).
This would also depend on the definition of the specific dynamic datastore.

Most likely, if the dynamic entry is removed, then the conventional configured 
value should be re-instated.  However, I don't think that the reverse is 
necessarily true.  E.g. in the dynamic datastore is I2RS then the initial 
config event would have failed if it was lower priority that conventional.



This concept of storing multiple copies and re-installation is something I2RS 
wants to avoid.
This is perhaps more related to multiple I2RS clients rather than between I2RS 
and the conventional datastores.


  But since they have declared that their scope only includes the use of their 
models in the dynamic (ephemeral) DS, they won't have that behavior.

Rgds,
Jason

Thanks,
Rob






___

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

Re: [netmod] revised-datastores-03: duplicate list entry from conventional + dynamic

[Robert Wilton]

Hi Jason,

Some thoughts inline ...


On 18/07/2017 22:46, Sterne, Jason (Nokia - CA/Ottawa) wrote:


Hi all,

The discussions about dynamic datastores in I2RS today made me wonder 
about a scenario:  What if a data model is supported in both 
conventional datastores and in a dynamic datastore (as well as being 
readable from the operational datastore), and the same list entry 
(e.g. interface abc, but with some different parms in the dynamic 
entry vs the config entry) has been created in both the running and 
the dynamic DS.


Only one of them can appear when reading the operational DS.


Yes.

I presume that it is up to the specification document of the dynamic 
DS to define the collision resolution between dynamic & conventional.



Yes.

But based on the revised DS draft I believe it would be necessary for 
the system to keep/store both copies of ‘interface abc’ so that a 
 with source=dynamic would return the dynamic version of 
interface abc while a  (or ) with source=running 
would return the conventional version of interface abc.  Do I have 
that correct ?


Definitely yes for running.  For dynamic, it would depend on the 
definition of the specific dynamic datastore, but likely yes.


I think that also implies that removing one of the copies could cause 
the ‘re-installation’ of the other (down to the app layer).



This would also depend on the definition of the specific dynamic datastore.

Most likely, if the dynamic entry is removed, then the conventional 
configured value should be re-instated.  However, I don't think that the 
reverse is necessarily true.  E.g. in the dynamic datastore is I2RS then 
the initial config event would have failed if it was lower priority that 
conventional.


This concept of storing multiple copies and re-installation is 
something I2RS wants to avoid.


This is perhaps more related to multiple I2RS clients rather than 
between I2RS and the conventional datastores.


  But since they have declared that their scope only includes the use 
of their models in the dynamic (ephemeral) DS, they won’t have that 
behavior.


Rgds,

Jason



Thanks,
Rob




___
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] revised-datastores-03: duplicate list entry from conventional + dynamic

[Sterne, Jason (Nokia - CA/Ottawa)]

Hi all,

The discussions about dynamic datastores in I2RS today made me wonder about a 
scenario:  What if a data model is supported in both conventional datastores 
and in a dynamic datastore (as well as being readable from the operational 
datastore), and the same list entry (e.g. interface abc, but with some 
different parms in the dynamic entry vs the config entry) has been created in 
both the running and the dynamic DS.

Only one of them can appear when reading the operational DS.

I presume that it is up to the specification document of the dynamic DS to 
define the collision resolution between dynamic & conventional.

But based on the revised DS draft I believe it would be necessary for the 
system to keep/store both copies of 'interface abc' so that a  with 
source=dynamic would return the dynamic version of interface abc while a 
 (or ) with source=running would return the conventional 
version of interface abc.  Do I have that correct ?

I think that also implies that removing one of the copies could cause the 
're-installation' of the other (down to the app layer).

This concept of storing multiple copies and re-installation is something I2RS 
wants to avoid.  But since they have declared that their scope only includes 
the use of their models in the dynamic (ephemeral) DS, they won't have that 
behavior.

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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Clyde Wildes (cwildes)]

Juergen and Alex,

The choice of Posix 1003.2 regular expressions was because of multiple vendors 
who supported same and asked for model support:
http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/syslog-edit-system.html
http://www.rsyslog.com/doc/v8-stable/configuration/filters.html
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/esm/command/esm-cr-book/esm-cr-a1.html#wp1888787448
https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93-0071-10-01/7750_SR_OS_System_Management_Guide/Logcli.html#1030840

Posix 1003.2 regular expressions support Unicode characters using the notation: 
\u or \x{}.

I will insert a normative reference to POSIX 1003.2 in the next revision of the 
draft.

Thanks,

Clyde

On 7/18/17, 1:26 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

On Mon, Jul 17, 2017 at 11:20:40PM +, Alex Campbell wrote:
> I am considering to implement the data model in this draft. (dependent on 
business priorities of course)
> I have reviewed this draft and found the following issues.
> 
> * I see pattern-match is specified to use POSIX 1003.2 regular 
expressions. This is presumably for compatibility with existing 
implementations; however it is inconsistent with most of YANG (which is 
specified to use XPath regular expressions) - unless these are the same.

The fact that the schema language uses a different regular expression
language than the data model is by itself not a problem I think. What
is potentially a problem is that RFC 5424 syslog messages are UTF-8
and hence the regular expression language adopted should be able to
match on unicode characters. Does POSIX 1003.2 do that? (There also
needs to be a normative reference to POSIX 1003.2 or whatever is
finally adopted.)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
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

Re: [netmod] NMDA indication of value "in use" vs. defaults

[Juergen Schoenwaelder]

On Tue, Jul 18, 2017 at 04:50:19PM +0200, David Lamparter wrote:
> Let me rephrase/develop my suggestion.
> 
> - don't send anything for a value that's not in use.
> - specify that if a client can't find an origin attribute, e.g. because
>   the entire tag is missing, it MUST assume "not-in-use"
> This implies:
> - data that actually is in use MUST always have an origin attribute,
>   otherwise the client will go "not-in-use"
> 
> This kinda forces people to do the right thing not only for not-in-use
> signaling, but also for the origin metadata.  No easy way out in just
> not sending it, if you don't know you have to own up your amnesia and
> admit to "unknown".
> 
> ... and with the current wording in the draft, it already suggests a
> value in all cases, since the last paragraph in in 4.7.3 is:
>In the case that a device cannot provide an accurate origin for a
>particular data node then it should use the origin "unknown".
> 
> I'm just saying that to determine whether a value is in use, the
> data's consumer must look at the origin attribute (including its
> absence), not at the fact whether there is some value.

This is the relevant current text:

   Requests to retrieve nodes from  always return the value
   in use if the node exists, regardless of any default value specified
   in the YANG module.  If no value is returned for a given node, then
   this implies that the node is not used by the device.

I am still unsure why the presence of an origin attribute adds value
here. The last sentence clearly says 'if no value is returned for a
given node, then this implies that the node is not used by the
device.'

FYI: There is another ongoing discussion whether origin metadata for
config false nodes makes sense at all and one option considered right
now is to have origin metadata only on config true nodes. If so, you
can't overload the presence of origin metadata with another meaning.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] NMDA indication of value "in use" vs. defaults

[David Lamparter]

On Tue, Jul 18, 2017 at 02:50:12PM +0200, Juergen Schoenwaelder wrote:
> On Tue, Jul 18, 2017 at 10:57:11AM +0200, David Lamparter wrote:
> > My understanding is that the NMDA design wants to communicate this
> > single bit of information to the client that retrieves data from the
> > operational datastore.
> 
> Yes, 'in use' <=> 'there is a value' in  (the conceptual
> datastore).
>  
> > I'm arguing that this single bit of information should not be
> > transported as "is the value present or absent?", because defaults
> > specified in the model can interfere with the absence of values.
> 
> They interfere (i) if you make them interfere or (ii) you have
> intermediaries that mess around with the data without telling you that
> they did so. We are trying to resolve (i) by definition of semantics
> and (ii) seems outside of what specifications can deal with.

Well, I don't want to give people the rope to hang themselves with; I
fully understand your position and it's correct by the letter, yet I
uphold my objection rooted on philosopohical differences in design
practice ;)

> > > > If this is implemented in an older NETCONF server that does this
> > > > unconditionally, this effectively breaks operational state retrieval
> > > > even if the system software does provide correct data with or without
> > > > defaults.  The NETCONF server would just (validly) remove all values
> > > > that are the same as the model's default -- which then the client would
> > > > interpret as "these values are not in use".
> > > 
> > > RFC 6243 was written before  did exist and we propose
> > > that  always reports the values in use (regardless
> > > whether they match defaults or not).
> > 
> > Yes, you can make this work if you specify that the NETCONF server MUST
> > NOT make any additions or removals regarding defaults for operational
> > requests.  I'm just saying this won't be robust.
> 
> This is what we are trying to specify.
> 
> > > > This, for me, lends the conclusion that this would be massively fragile,
> > > > even if a specific combination could make it work.  My position hence
> > > > changes from "this doesn't work" to "please don't do this, even if it
> > > > may work."
> > > 
> > > Always reporting the value in use should be fine. If libraries mess up
> > > the data it seems a library issue. Libraries should not mess around
> > > with  data. The data in  data is the ground
> > > truth of what the device is really doing, messing around with it
> > > before passing it to an application is not recommended.
> > 
> > Sure -- I'm not concerned about the value.  I'm concerned I won't be
> > able to tell whether the value is "in use".  This is 2 error cases:
> > 
> > - the value in use is equal to the model's default, and due to mangling
> >   it's misrepresented as "there is no value" / "the value is not in use"
> > - the value is not in use, and due to mangling it's misrepresented as
> >   "the value in use happens to be the default value"
> 
> I do not think server randomly mangle data. I am concerned about
> reporting 'fake' values for not in use leafs with metadata that such
> leafs are not in use. This seems pretty costly (there usually is lots
> of stuff not in use).

I'm not suggesting you make up fake values.  [See below.]

> > > > The solution I would suggest would be to have "is the value in use?" as
> > > > metadata just like the origin.  It can either be a new value on the
> > > > "datastore" identity (=> if a value is not in use, there is no way to
> > > > report what datastore it came from), or alternatively it can be a
> > > > separate metadata annotation (=> you can report not-in-use and still
> > > > have the value and its origin - if that makes sense, which...)
> > > > 
> > > > (I'm leaning towards adding "not-in-use" on the origin metadata
> > > > annotation, as opposed to a separate boolean metadata annotation.)
> > > 
> > > But if something is not in use, it may not even have a value. So I end
> > > up reporting fake values for things that are not is use decorated with
> > > metadata that these fake values are not in use? Does not sound very
> > > efficient to me.
> > 
> > I would actually suggest that the default for the _origin_metadata_ is
> > "not-in-use", so you can in fact leave it out of the reply, and the
> > client knows reliably that it's not in use -- even if something in the
> > data path processes/interferes with defaults.
> 
> In XML, metadata is encoded as XML attributes so I need to ship an XML
> element to ship the XML attribute and hence I need a value (and an
> empty value might violate the YANG data type contract, so I need a
> fake value). This does not seem a good proposal to me.

Let me rephrase/develop my suggestion.

- don't send anything for a value that's not in use.
- specify that if a client can't find an origin attribute, e.g. because
  the entire tag is missing, it MUST assume "not-in-use"
This implies:
- data that actually is in use MUST always have an origin attr

Re: [netmod] NMDA indication of value "in use" vs. defaults

[Juergen Schoenwaelder]

On Tue, Jul 18, 2017 at 10:57:11AM +0200, David Lamparter wrote:
> Jürgen,
> 
> 
> On Mon, Jul 17, 2017 at 11:51:49PM +0200, Juergen Schoenwaelder wrote:
> > I am still not sure what the problem is. We proposed that the
> >  datastore always reports the values that are in use,
> > whatever their origin is. This seems simple and clear if you want to
> > troubleshoot something.
> 
> This is not about the value - this is about the separate single bit of
> information that answers the question "is this value in use?"
> 
> My understanding is that the NMDA design wants to communicate this
> single bit of information to the client that retrieves data from the
> operational datastore.

Yes, 'in use' <=> 'there is a value' in  (the conceptual
datastore).
 
> I'm arguing that this single bit of information should not be
> transported as "is the value present or absent?", because defaults
> specified in the model can interfere with the absence of values.

They interfere (i) if you make them interfere or (ii) you have
intermediaries that mess around with the data without telling you that
they did so. We are trying to resolve (i) by definition of semantics
and (ii) seems outside of what specifications can deal with.

> > > If this is implemented in an older NETCONF server that does this
> > > unconditionally, this effectively breaks operational state retrieval
> > > even if the system software does provide correct data with or without
> > > defaults.  The NETCONF server would just (validly) remove all values
> > > that are the same as the model's default -- which then the client would
> > > interpret as "these values are not in use".
> > 
> > RFC 6243 was written before  did exist and we propose
> > that  always reports the values in use (regardless
> > whether they match defaults or not).
> 
> Yes, you can make this work if you specify that the NETCONF server MUST
> NOT make any additions or removals regarding defaults for operational
> requests.  I'm just saying this won't be robust.

This is what we are trying to specify.

> > > This, for me, lends the conclusion that this would be massively fragile,
> > > even if a specific combination could make it work.  My position hence
> > > changes from "this doesn't work" to "please don't do this, even if it
> > > may work."
> > 
> > Always reporting the value in use should be fine. If libraries mess up
> > the data it seems a library issue. Libraries should not mess around
> > with  data. The data in  data is the ground
> > truth of what the device is really doing, messing around with it
> > before passing it to an application is not recommended.
> 
> Sure -- I'm not concerned about the value.  I'm concerned I won't be
> able to tell whether the value is "in use".  This is 2 error cases:
> 
> - the value in use is equal to the model's default, and due to mangling
>   it's misrepresented as "there is no value" / "the value is not in use"
> - the value is not in use, and due to mangling it's misrepresented as
>   "the value in use happens to be the default value"

I do not think server randomly mangle data. I am concerned about
reporting 'fake' values for not in use leafs with metadata that such
leafs are not in use. This seems pretty costly (there usually is lots
of stuff not in use).

> > > The solution I would suggest would be to have "is the value in use?" as
> > > metadata just like the origin.  It can either be a new value on the
> > > "datastore" identity (=> if a value is not in use, there is no way to
> > > report what datastore it came from), or alternatively it can be a
> > > separate metadata annotation (=> you can report not-in-use and still
> > > have the value and its origin - if that makes sense, which...)
> > > 
> > > (I'm leaning towards adding "not-in-use" on the origin metadata
> > > annotation, as opposed to a separate boolean metadata annotation.)
> > 
> > But if something is not in use, it may not even have a value. So I end
> > up reporting fake values for things that are not is use decorated with
> > metadata that these fake values are not in use? Does not sound very
> > efficient to me.
> 
> I would actually suggest that the default for the _origin_metadata_ is
> "not-in-use", so you can in fact leave it out of the reply, and the
> client knows reliably that it's not in use -- even if something in the
> data path processes/interferes with defaults.

In XML, metadata is encoded as XML attributes so I need to ship an XML
element to ship the XML attribute and hence I need a value (and an
empty value might violate the YANG data type contract, so I need a
fake value). This does not seem a good proposal to me.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] NMDA indication of value "in use" vs. defaults

[David Lamparter]

Jürgen,


On Mon, Jul 17, 2017 at 11:51:49PM +0200, Juergen Schoenwaelder wrote:
> I am still not sure what the problem is. We proposed that the
>  datastore always reports the values that are in use,
> whatever their origin is. This seems simple and clear if you want to
> troubleshoot something.

This is not about the value - this is about the separate single bit of
information that answers the question "is this value in use?"

My understanding is that the NMDA design wants to communicate this
single bit of information to the client that retrieves data from the
operational datastore.

I'm arguing that this single bit of information should not be
transported as "is the value present or absent?", because defaults
specified in the model can interfere with the absence of values.

> > If this is implemented in an older NETCONF server that does this
> > unconditionally, this effectively breaks operational state retrieval
> > even if the system software does provide correct data with or without
> > defaults.  The NETCONF server would just (validly) remove all values
> > that are the same as the model's default -- which then the client would
> > interpret as "these values are not in use".
> 
> RFC 6243 was written before  did exist and we propose
> that  always reports the values in use (regardless
> whether they match defaults or not).

Yes, you can make this work if you specify that the NETCONF server MUST
NOT make any additions or removals regarding defaults for operational
requests.  I'm just saying this won't be robust.

> > This, for me, lends the conclusion that this would be massively fragile,
> > even if a specific combination could make it work.  My position hence
> > changes from "this doesn't work" to "please don't do this, even if it
> > may work."
> 
> Always reporting the value in use should be fine. If libraries mess up
> the data it seems a library issue. Libraries should not mess around
> with  data. The data in  data is the ground
> truth of what the device is really doing, messing around with it
> before passing it to an application is not recommended.

Sure -- I'm not concerned about the value.  I'm concerned I won't be
able to tell whether the value is "in use".  This is 2 error cases:

- the value in use is equal to the model's default, and due to mangling
  it's misrepresented as "there is no value" / "the value is not in use"
- the value is not in use, and due to mangling it's misrepresented as
  "the value in use happens to be the default value"

> > The solution I would suggest would be to have "is the value in use?" as
> > metadata just like the origin.  It can either be a new value on the
> > "datastore" identity (=> if a value is not in use, there is no way to
> > report what datastore it came from), or alternatively it can be a
> > separate metadata annotation (=> you can report not-in-use and still
> > have the value and its origin - if that makes sense, which...)
> > 
> > (I'm leaning towards adding "not-in-use" on the origin metadata
> > annotation, as opposed to a separate boolean metadata annotation.)
> 
> But if something is not in use, it may not even have a value. So I end
> up reporting fake values for things that are not is use decorated with
> metadata that these fake values are not in use? Does not sound very
> efficient to me.

I would actually suggest that the default for the _origin_metadata_ is
"not-in-use", so you can in fact leave it out of the reply, and the
client knows reliably that it's not in use -- even if something in the
data path processes/interferes with defaults.

Cheers,


-David

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

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15

[Juergen Schoenwaelder]

On Mon, Jul 17, 2017 at 11:20:40PM +, Alex Campbell wrote:
> I am considering to implement the data model in this draft. (dependent on 
> business priorities of course)
> I have reviewed this draft and found the following issues.
> 
> * I see pattern-match is specified to use POSIX 1003.2 regular expressions. 
> This is presumably for compatibility with existing implementations; however 
> it is inconsistent with most of YANG (which is specified to use XPath regular 
> expressions) - unless these are the same.

The fact that the schema language uses a different regular expression
language than the data model is by itself not a problem I think. What
is potentially a problem is that RFC 5424 syslog messages are UTF-8
and hence the regular expression language adopted should be able to
match on unicode characters. Does POSIX 1003.2 do that? (There also
needs to be a normative reference to POSIX 1003.2 or whatever is
finally adopted.)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] ACL draft defines ether-type as a string

[William Lupton]

Editorial: ethertype (no hyphen) seems to be more common than ether-type (28 
versus 11 matches in the YANG catalog, plus IEEE seem to use the no-hyphen 
version).

Also (even more editorial), I don’t see the need for the rather distracting 
‘0x’ in the name, so would suggest ethertype- (yes, I realise that this 
decision is in the IEEE bailiwick).

William

> On 18 Jul 2017, at 08:21, Mahesh Jethanandani  wrote:
> 
> 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-0x where 
> 0x 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.";
>   }

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

Re: [netmod] nmda-guidelines-01: value space for config vs state

[Mahesh Jethanandani]

Jason,

Following on the example I gave on the other thread here is what I see for the 
admin/oper leafs.

> On Jul 17, 2017, at 12:22 PM, Sterne, Jason (Nokia - CA/Ottawa) 
>  wrote:
> 
> Hi all,
>  
> A note in Rob Wilton’s presentation today in rtgwg mentioned something about 
> consistency in the value space for config vs state leafs.  The NMDA approach 
> results in the same leaf for both config & state in many cases (at least for 
> the cases where the separate config & state leafs were only there to 
> represent intended vs applied config).
>  
> But aren’t there some cases where the value space for state will be different 
> than the value space for config ?  I’m thinking of the basic admin/oper state 
> for interfaces for example where config may allow enable/disable but state 
> may have additional values like ‘testing’.  If the config & state value 
> spaces aren’t 100% the same, are module designers recommended to create a 
> separate state leaf ?

leaf administrative-state {
  type boolean {
description
  “When set to true, the interface is set to be
administratively up. The actual state of the
interface is reflected in the corresponding
operational-state leaf.”;
  }
}

leaf operational-state {
  config false;
  type enumeration {
enum up;
enum down;
enum testing;
enum negotiating;
  }
}

>  
> Rgds,
> Jason
> ___
> 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] Clarification Question on draft-dsdt-nmda-guidelines-01

[Mahesh Jethanandani]

Jason,

> On Jul 17, 2017, at 11:38 AM, Sterne, Jason (Nokia - CA/Ottawa) 
>  wrote:
> 
> Hi guys,
> 
> This is something that could use further clarification in the draft.  i.e. 
> examples and guidelines of when to create a separate "config false" leaf (vs 
> the more typical case of just having a single "config true" leaf).   There is 
> an example in there currently but I personally found it confusing:
> 
>"An example would be the speed
>of an interface, where the configured value may not be the value that
>is currently used.”

It turns out that the example I had in mind does not create a separate ‘config 
false’ leaf. Instead, I see two leafs defined as:

leaf auto-negotiation {
  type boolean {
description
  “When set to true, the interface will auto negotiate for speed.
   When set to false, a separate leaf called ‘speed’ will define
   the desired speed.”;
  }
}

leaf speed {
  type enumeration {
enum 10M;
….
enum 10G;
  }
}

Notice, I have not defined speed as a ‘config false’ leaf, because it could be 
used if auto-negotiation is set to false to manually set the speed of the 
interface.

But I see the interface name as a ‘config false’ leaf, because the name of the 
interface is assigned by the system, and cannot be changed by the user.

leaf interface-name {
  config false;
  type string {
description
  “Name of the interface as assigned by the system. This could 
   include information of which line card the interface is on. 
   Example, GigabitEthernet 0/0/0/0”;
  }
}

Does this help?

> 
> I wasn't sure if that example referred to the same issue as you guys are 
> discussing below.  Perhaps as a minimum we could grab some of the details for 
> the example below and incorporate them into the draft ?
> 
> Rgds,
> Jason
> 
>> -Original Message-
>> From: netmod [mailto:netmod-boun...@ietf.org 
>> ] On Behalf Of Robert Wilton
>> Sent: Wednesday, June 14, 2017 17:54
>> To: Mahesh Jethanandani > >
>> Cc: Xufeng Liu mailto:xufeng_...@jabil.com>>; 
>> netmod@ietf.org ; draft-dsdt-nmda-
>> guideli...@ietf.org 
>> Subject: Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01
>> 
>> 
>> 
>> On 14/06/2017 16:23, Mahesh Jethanandani wrote:
 On Jun 14, 2017, at 8:10 AM, Robert Wilton  wrote:
 
 Hi Xufeng,
 
 
 On 14/06/2017 14:01, Xufeng Liu wrote:
> Hi Juergen,
> 
> Thanks for the confirmation.
> As for the distinction between applied configuration and operational, I
>> think that it has been determined to be useful in some use cases. We can
>> create a separate leaf in such a case.
 Yes, I think that this is exactly the right approach.
 
 In the general case, a single leaf for applied configuration and the
>> operational value is normally sufficient.
 
 But in some cases (e.g. where a value could be configured and/or
>> negotiated via protocol) then it sometimes useful to both see the input into 
>> the
>> protocol negotiation and also the resultant output value.
 
 Here, there is a choice to be made to decide whether the extra config false
>> leaf represents the input value into the negotiation, or the output value.  I
>> think that the decision probably depends on the protocol semantics, but all
>> things being equal, there is a benefit if the configured value and actual
>> operational value end up being represented by the same leaf/path (since this 
>> in
>> the case in the mainline case where extra config false leaves are not 
>> required).
>>> Another way to look at it is whether the input value is truly different 
>>> from the
>> output value. For example, if the input value is auto-negotiation, a 
>> boolean, but
>> the output value is a speed of 10/100/1000/1, a uint32, then a separate
>> leaf makes sense.
>> Yes, agreed.
>> 
>> For cases like these (e.g. Ethernet auto-negotiation) a good approach seem to
>> be to model the leaf "enabling auto" as a separate leaf from the explicitly
>> configured/operational value.
>> 
>> Thanks,
>> Rob
>> 
>> 
>>> 
 Thanks,
 Rob
 
 
> Regards,
> - Xufeng
> 
>> -Original Message-
>> From: Juergen Schoenwaelder
>> [mailto:j.schoenwael...@jacobs-university.de]
>> Sent: Tuesday, June 13, 2017 4:10 PM
>> To: Xufeng Liu 
>> Cc: draft-dsdt-nmda-guideli...@ietf.org; netmod@ietf.org
>> Subject: Re: Clarification Question on
>> draft-dsdt-nmda-guidelines-01
>> 
>> Hi,
>> 
>> the typical -state tree consists of config false nodes and hence it
>> represents operational state. This is not a transitioning period
>> question, this is how -state trees were designed. Note also that
>> the applied configuration is part of the operational state in NMDA
>> - for config true objects, there is no difference between the