Re: [netmod] OpsState and Schema-Mount

[Ladislav Lhotka]

> On 10 Aug 2016, at 23:54, Alex Campbell <alex.campb...@aviatnet.com> wrote:
> 
> I think in this case it would make sense to implement both the hypothetical 
> standard module's state data (which would be device-agnostic, such as a 
> boolean value indicating whether each configured rule is active) and also a 
> device-specific module providing access to the more detailed internal state.

Right, that's one option, but for smaller devices (which could be, e.g., 
OpenWRT routers) it may be an overkill.

If standard state data are in a separate module, an implementor can choose to 
implement them or not.

Lada

> 
> 
> From: netmod <netmod-boun...@ietf.org> on behalf of Ladislav Lhotka 
> <lho...@nic.cz>
> Sent: Wednesday, 10 August 2016 11:39 p.m.
> To: Andy Bierman; Robert Wilton
> Cc: netmod WG
> Subject: Re: [netmod] OpsState and Schema-Mount
> 
> Andy Bierman <a...@yumaworks.com> writes:
> 
>> On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton <rwil...@cisco.com> wrote:
>> 
>>> Hi Andy,
>>> I don't properly understand the points that you are making, please see
>>> clarifying comments/questions inline ...
>>> 
>>> On 08/08/2016 22:51, Andy Bierman wrote:
>>> 
>>> 
>>> 
>>> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <kwat...@juniper.net> wrote:
>>> 
>>>> Acee writes:
>>>>>   Then I see no YANG language barriers in collapsing config and state
>>>> trees
>>>>>   - the model root just needs to be “config true”.
>>>> 
>>>> Great, I think we’re all agreed.  Can we now discuss the text I proposed
>>>> for 6087bis?  - here’s the link to my proposal:
>>>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>>>> 
>>>> 
>>> IMO this effort to avoid 2 containers is not well thought out.
>>> Some concerns:
>>> 
>>> 1) modularity
>>>placing the monitoring objects within the configuration means the
>>> monitoring
>>>cannot be used on its own
>>> 
>>> If it is one module with two top level augments (foo and foo-state) then
>>> this problem still exists.  Hence, please can you clarify why converging
>>> them on a single root node means that monitoring cannot be used on it own?
>>> Wouldn't a device need to use deviations in both cases to strip out the
>>> config nodes that they are not supporting?
>>> 
>>> 
>> Before the "rule" I can choose to place monitoring in its own module
>> without any reliance on other modules.  If the monitoring does not
>> share indexing, what value is there in putting it in the config tree?
>> I see none except a poor attempt at model classification.
> 
> Sometimes it may indeed make sense to keep configuration and state data
> schemas in different modules. For instance, it may be useful (or even
> necessary) to have common configuration but different state data for
> different implementations, e.g. when devices use vastly different
> internal architectures.
> 
> One example are packet filters: while it may be possible to have a
> common configuration for Linux nftables and Cisco ACLs, monitoring or
> debugging either implementation requires access to what the system is
> doing under the hood, i.e. system-specific state data and counters.
> 
> Lada
> 
>> 
>> 
>> 
>>> 
>>> 
>>> 2) access control
>>>placing the monitoring data within configuration means the
>>> monitoring-only clients
>>>need write permission turned on for the nodes they can access for
>>> read-only
>>>This relies on granular and complex NACM rules which require regular
>>> maintenance.
>>> 
>>> Again, I don't quite follow this, in the specific example that I have
>>> regarding putting a RIB under a config true NP container, I would have
>>> thought that NACM read access would have been sufficient for a
>>> monitoring-only client.  Is that not the case?
>>> 
>> 
>> 
>> If the monitoring is rooting under config=true nodes, then those config=true
>> nodes need to be created somehow.  A client with write access is probably
>> required.
>> 
>> 
>> 
>>> 
>>> 
>>> 3) YANG conformance
>>>placing the monitoring data inside the configuration means the
>>> configuration
>>>will be required for conformance; it is not likely to be just 1 NP
>>> container.
>>> 
>&

Re: [netmod] OpsState and Schema-Mount

[Alex Campbell]

I think in this case it would make sense to implement both the hypothetical 
standard module's state data (which would be device-agnostic, such as a boolean 
value indicating whether each configured rule is active) and also a 
device-specific module providing access to the more detailed internal state.


From: netmod <netmod-boun...@ietf.org> on behalf of Ladislav Lhotka 
<lho...@nic.cz>
Sent: Wednesday, 10 August 2016 11:39 p.m.
To: Andy Bierman; Robert Wilton
Cc: netmod WG
Subject: Re: [netmod] OpsState and Schema-Mount

Andy Bierman <a...@yumaworks.com> writes:

> On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton <rwil...@cisco.com> wrote:
>
>> Hi Andy,
>> I don't properly understand the points that you are making, please see
>> clarifying comments/questions inline ...
>>
>> On 08/08/2016 22:51, Andy Bierman wrote:
>>
>>
>>
>> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <kwat...@juniper.net> wrote:
>>
>>> Acee writes:
>>> >Then I see no YANG language barriers in collapsing config and state
>>> trees
>>> >- the model root just needs to be “config true”.
>>>
>>> Great, I think we’re all agreed.  Can we now discuss the text I proposed
>>> for 6087bis?  - here’s the link to my proposal:
>>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>>>
>>>
>> IMO this effort to avoid 2 containers is not well thought out.
>> Some concerns:
>>
>> 1) modularity
>> placing the monitoring objects within the configuration means the
>> monitoring
>> cannot be used on its own
>>
>> If it is one module with two top level augments (foo and foo-state) then
>> this problem still exists.  Hence, please can you clarify why converging
>> them on a single root node means that monitoring cannot be used on it own?
>> Wouldn't a device need to use deviations in both cases to strip out the
>> config nodes that they are not supporting?
>>
>>
> Before the "rule" I can choose to place monitoring in its own module
> without any reliance on other modules.  If the monitoring does not
> share indexing, what value is there in putting it in the config tree?
> I see none except a poor attempt at model classification.

Sometimes it may indeed make sense to keep configuration and state data
schemas in different modules. For instance, it may be useful (or even
necessary) to have common configuration but different state data for
different implementations, e.g. when devices use vastly different
internal architectures.

One example are packet filters: while it may be possible to have a
common configuration for Linux nftables and Cisco ACLs, monitoring or
debugging either implementation requires access to what the system is
doing under the hood, i.e. system-specific state data and counters.

Lada

>
>
>
>>
>>
>> 2) access control
>> placing the monitoring data within configuration means the
>> monitoring-only clients
>> need write permission turned on for the nodes they can access for
>> read-only
>> This relies on granular and complex NACM rules which require regular
>> maintenance.
>>
>> Again, I don't quite follow this, in the specific example that I have
>> regarding putting a RIB under a config true NP container, I would have
>> thought that NACM read access would have been sufficient for a
>> monitoring-only client.  Is that not the case?
>>
>
>
> If the monitoring is rooting under config=true nodes, then those config=true
> nodes need to be created somehow.  A client with write access is probably
> required.
>
>
>
>>
>>
>> 3) YANG conformance
>> placing the monitoring data inside the configuration means the
>> configuration
>> will be required for conformance; it is not likely to be just 1 NP
>> container.
>>
>> Similar to my response to the first question, I thought that conformance
>> was done on a per module base, not a per sub-tree basis.  So even if you
>> have top level 'foo' and 'foo-state' as part of the same module don't you
>> run into the same conformance problem?
>>
>>
>>
> Much easier to solve the conformance since /foo-state does not need any
> objects from /foo
> to exist first.  Creating the /foo container means that all config=true
> requirements for
> that container must be implemented (or complex deviations used)
>
>
>>
>> 4) pointless;
>>given that new RPC operations are needed to access applied config, the
>> only data not
>>affected (and moved under the config c

Re: [netmod] OpsState and Schema-Mount

[Ladislav Lhotka]

Andy Bierman  writes:

> On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>> I don't properly understand the points that you are making, please see
>> clarifying comments/questions inline ...
>>
>> On 08/08/2016 22:51, Andy Bierman wrote:
>>
>>
>>
>> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:
>>
>>> Acee writes:
>>> >Then I see no YANG language barriers in collapsing config and state
>>> trees
>>> >- the model root just needs to be “config true”.
>>>
>>> Great, I think we’re all agreed.  Can we now discuss the text I proposed
>>> for 6087bis?  - here’s the link to my proposal:
>>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>>>
>>>
>> IMO this effort to avoid 2 containers is not well thought out.
>> Some concerns:
>>
>> 1) modularity
>> placing the monitoring objects within the configuration means the
>> monitoring
>> cannot be used on its own
>>
>> If it is one module with two top level augments (foo and foo-state) then
>> this problem still exists.  Hence, please can you clarify why converging
>> them on a single root node means that monitoring cannot be used on it own?
>> Wouldn't a device need to use deviations in both cases to strip out the
>> config nodes that they are not supporting?
>>
>>
> Before the "rule" I can choose to place monitoring in its own module
> without any reliance on other modules.  If the monitoring does not
> share indexing, what value is there in putting it in the config tree?
> I see none except a poor attempt at model classification.

Sometimes it may indeed make sense to keep configuration and state data
schemas in different modules. For instance, it may be useful (or even
necessary) to have common configuration but different state data for
different implementations, e.g. when devices use vastly different
internal architectures.

One example are packet filters: while it may be possible to have a
common configuration for Linux nftables and Cisco ACLs, monitoring or
debugging either implementation requires access to what the system is
doing under the hood, i.e. system-specific state data and counters.

Lada

>
>
>
>>
>>
>> 2) access control
>> placing the monitoring data within configuration means the
>> monitoring-only clients
>> need write permission turned on for the nodes they can access for
>> read-only
>> This relies on granular and complex NACM rules which require regular
>> maintenance.
>>
>> Again, I don't quite follow this, in the specific example that I have
>> regarding putting a RIB under a config true NP container, I would have
>> thought that NACM read access would have been sufficient for a
>> monitoring-only client.  Is that not the case?
>>
>
>
> If the monitoring is rooting under config=true nodes, then those config=true
> nodes need to be created somehow.  A client with write access is probably
> required.
>
>
>
>>
>>
>> 3) YANG conformance
>> placing the monitoring data inside the configuration means the
>> configuration
>> will be required for conformance; it is not likely to be just 1 NP
>> container.
>>
>> Similar to my response to the first question, I thought that conformance
>> was done on a per module base, not a per sub-tree basis.  So even if you
>> have top level 'foo' and 'foo-state' as part of the same module don't you
>> run into the same conformance problem?
>>
>>
>>
> Much easier to solve the conformance since /foo-state does not need any
> objects from /foo
> to exist first.  Creating the /foo container means that all config=true
> requirements for
> that container must be implemented (or complex deviations used)
>
>
>>
>> 4) pointless;
>>given that new RPC operations are needed to access applied config, the
>> only data not
>>affected (and moved under the config container anyway) is stuff that
>> does not share
>>the same indexing, or counters which are not part of the opstate
>> problem.
>>
>> Sorry, I don't really follow this one.  The original opstate draft put
>> forward by OpenConfig was asking for both applied-configuration and derived
>> state (e.g. statistics and other state) to be co-located under the same
>> structures.  The original discussions focused on applied configuration, but
>> when this was being discussed more recently the desire for a solution to
>> the co-located derived state was also discussed - which is why both
>> draft-schoenw-netmod-revised-datastores-01 and
>> draft-wilton-netmod-refined-datastores-01 propose solutions to this
>> problem.
>>
>
>
>> There are also benefits to merging this data:
>>
>> 1) Having co-located config and state data means that clients can easily
>> request config and state for a related object in a single request
>> 1b) Having co-located config and state makes it easier for clients to code
>> - they don't need to unify data across two (potentially different
>> structures/indexes).
>> 1c) Having a single structure, means 

Re: [netmod] OpsState and Schema-Mount

[Andy Bierman]

Hi,

I do not see any justification to RECOMMEND a combined tree.
I do not think 6087bis should give guidelines based on speculation
about a new holistic architecture in the future,

I agree with Juergen that the pros and cons of different approaches
should be discussed, and designers can decide which trade-offs
work best for them.


Andy


On Tue, Aug 9, 2016 at 2:31 PM, Kent Watsen <kwat...@juniper.net> wrote:

> Juergen, Andy,
>
>
>
> I think that my proposed text for 6087bis clearly articulates what
> protocols can do today and tomorrow, while making a *very subtle*
> recommendation for today’s model designers to future-proof their models.
>
>
>
> Please focus on the proposal, consistent with the Lou’s chair-request (
> https://mailarchive.ietf.org/arch/msg/netmod/NK864oXvIfeAYoCUTK40wn2Kw-8).
>
>
>
> Kent // as a contributor
>
>
>
>
>
> *From: *Andy Bierman <a...@yumaworks.com>
> *Date: *Tuesday, August 9, 2016 at 5:01 PM
> *To: *Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>,
> Robert Wilton <rwil...@cisco.com>, Andy Bierman <a...@yumaworks.com>,
> Kent Watsen <kwat...@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
> *Subject: *Re: [netmod] OpsState and Schema-Mount
>
>
>
>
>
>
>
> On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
> >
> > In particular, I think that the guideline would be along the lines:
> > If a given module "foo" only contains state and no configuration, then
> > having a single top-level "foo" config false node is fine, but if a given
> > module contains both config and state then the recommendation is to put
> that
> > under a config=true "foo" top-level node.  Refining that slightly, If the
> > state data is relevant even if "foo" hasn't been enabled then make the
> top
> > level "foo" an NP container.  If "foo" has to be enabled on the system
> for
> > the state data to be relevant then make "foo" a P container (or give it a
> > separate foo/enable leaf).  In summary, I would suggest that the foo
> state
> > data should be pushed as far down the combined config/state tree as
> > possible.  It should be sited below (or adjacent to) whichever config
> node
> > is required to make that state data relevant.
> >
> > If config and state are in the same tree then it is easy to return all
> the
> > data in one RPC, or have separate RPC operations that just return
> > configuration (e.g. ), or just return "state + containing
> > hieararchy" (e.g. a newly defined , or equivalent).
> >
> > Having separate foo vs foo-state trees at the top level is always going
> to
> > make it harder to return and manage a combined view of the config and
> state
> > data.
>
> I think it is crucial to separate (a) what protocols do today and (b)
> what protocols might do at some time in the future.
>
> The current protocol reality, that is (a), paired with the reality of
> network interfaces has lead to the (/interfaces, /interfaces-state)
> design pattern and until we have (b) in place I do not think we have
> really an alternative for the (/interfaces, /interfaces-state)
> design pattern.
>
> If you have config and state are in the same tree, you simply can't
> represent certain things that exist in reality. A single tree may look
> 'simpler' but in several cases also simply 'unusable'. We did not
> particularly like the (/interfaces, /interfaces-state) design but it
> was the only solution that seemed to work for all cases given the
> protocol reality we were in.
>
>
>
> +1
>
>
>
> IMO the suggestion of using YANG extensions to associate data from
> different subtrees
>
> was the most practical approach so far.  Moving objects and overloading
> object location
>
> semantics will have a big impact on existing code.  Adding metadata and
> RPC operations
>
> will not be disruptive, and it allows more complex associations to be
> expressed.
>
>
>
> If the config needs to exist in order for the opstate and statistics to be
> relevant,
>
> then of course put them in the config subtree.  But if they can be
> relevant without config,
>
> then the config data model has to be more complex to distinguish bogus
> entries from real ones.
>
> The YANG validation has to know the difference as well, adding hacks to
> that code.
>
> The access model needs to account for creation of bogus entries vs. real
> ones,
>
&g

Re: [netmod] OpsState and Schema-Mount

[Kent Watsen]

Juergen, Andy,

I think that my proposed text for 6087bis clearly articulates what protocols 
can do today and tomorrow, while making a *very subtle* recommendation for 
today’s model designers to future-proof their models.

Please focus on the proposal, consistent with the Lou’s chair-request 
(https://mailarchive.ietf.org/arch/msg/netmod/NK864oXvIfeAYoCUTK40wn2Kw-8).

Kent // as a contributor


From: Andy Bierman <a...@yumaworks.com>
Date: Tuesday, August 9, 2016 at 5:01 PM
To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>, Robert Wilton 
<rwil...@cisco.com>, Andy Bierman <a...@yumaworks.com>, Kent Watsen 
<kwat...@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] OpsState and Schema-Mount



On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder 
<j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>
 wrote:
On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
>
> In particular, I think that the guideline would be along the lines:
> If a given module "foo" only contains state and no configuration, then
> having a single top-level "foo" config false node is fine, but if a given
> module contains both config and state then the recommendation is to put that
> under a config=true "foo" top-level node.  Refining that slightly, If the
> state data is relevant even if "foo" hasn't been enabled then make the top
> level "foo" an NP container.  If "foo" has to be enabled on the system for
> the state data to be relevant then make "foo" a P container (or give it a
> separate foo/enable leaf).  In summary, I would suggest that the foo state
> data should be pushed as far down the combined config/state tree as
> possible.  It should be sited below (or adjacent to) whichever config node
> is required to make that state data relevant.
>
> If config and state are in the same tree then it is easy to return all the
> data in one RPC, or have separate RPC operations that just return
> configuration (e.g. ), or just return "state + containing
> hieararchy" (e.g. a newly defined , or equivalent).
>
> Having separate foo vs foo-state trees at the top level is always going to
> make it harder to return and manage a combined view of the config and state
> data.

I think it is crucial to separate (a) what protocols do today and (b)
what protocols might do at some time in the future.

The current protocol reality, that is (a), paired with the reality of
network interfaces has lead to the (/interfaces, /interfaces-state)
design pattern and until we have (b) in place I do not think we have
really an alternative for the (/interfaces, /interfaces-state)
design pattern.

If you have config and state are in the same tree, you simply can't
represent certain things that exist in reality. A single tree may look
'simpler' but in several cases also simply 'unusable'. We did not
particularly like the (/interfaces, /interfaces-state) design but it
was the only solution that seemed to work for all cases given the
protocol reality we were in.

+1

IMO the suggestion of using YANG extensions to associate data from different 
subtrees
was the most practical approach so far.  Moving objects and overloading object 
location
semantics will have a big impact on existing code.  Adding metadata and RPC 
operations
will not be disruptive, and it allows more complex associations to be expressed.

If the config needs to exist in order for the opstate and statistics to be 
relevant,
then of course put them in the config subtree.  But if they can be relevant 
without config,
then the config data model has to be more complex to distinguish bogus entries 
from real ones.
The YANG validation has to know the difference as well, adding hacks to that 
code.
The access model needs to account for creation of bogus entries vs. real ones,
adding an operational cost to this solution approach.

The YANG to use depends on the requirements.
The /foo-state tree can be considered "always on".
If this is not desired then a better design is to use a P-container:

   container foo {
 presence "Indicates foo counters are being collected";
 container foo-stats {
config false;
/...
 }
   }

This combination of config and state has a use-case.
I don't see a use-case for NP-container though.






/js


Andy


--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>

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

Re: [netmod] OpsState and Schema-Mount

[Andy Bierman]

On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
> >
> > In particular, I think that the guideline would be along the lines:
> > If a given module "foo" only contains state and no configuration, then
> > having a single top-level "foo" config false node is fine, but if a given
> > module contains both config and state then the recommendation is to put
> that
> > under a config=true "foo" top-level node.  Refining that slightly, If the
> > state data is relevant even if "foo" hasn't been enabled then make the
> top
> > level "foo" an NP container.  If "foo" has to be enabled on the system
> for
> > the state data to be relevant then make "foo" a P container (or give it a
> > separate foo/enable leaf).  In summary, I would suggest that the foo
> state
> > data should be pushed as far down the combined config/state tree as
> > possible.  It should be sited below (or adjacent to) whichever config
> node
> > is required to make that state data relevant.
> >
> > If config and state are in the same tree then it is easy to return all
> the
> > data in one RPC, or have separate RPC operations that just return
> > configuration (e.g. ), or just return "state + containing
> > hieararchy" (e.g. a newly defined , or equivalent).
> >
> > Having separate foo vs foo-state trees at the top level is always going
> to
> > make it harder to return and manage a combined view of the config and
> state
> > data.
>
> I think it is crucial to separate (a) what protocols do today and (b)
> what protocols might do at some time in the future.
>
> The current protocol reality, that is (a), paired with the reality of
> network interfaces has lead to the (/interfaces, /interfaces-state)
> design pattern and until we have (b) in place I do not think we have
> really an alternative for the (/interfaces, /interfaces-state)
> design pattern.
>
> If you have config and state are in the same tree, you simply can't
> represent certain things that exist in reality. A single tree may look
> 'simpler' but in several cases also simply 'unusable'. We did not
> particularly like the (/interfaces, /interfaces-state) design but it
> was the only solution that seemed to work for all cases given the
> protocol reality we were in.
>
>
+1

IMO the suggestion of using YANG extensions to associate data from
different subtrees
was the most practical approach so far.  Moving objects and overloading
object location
semantics will have a big impact on existing code.  Adding metadata and RPC
operations
will not be disruptive, and it allows more complex associations to be
expressed.

If the config needs to exist in order for the opstate and statistics to be
relevant,
then of course put them in the config subtree.  But if they can be relevant
without config,
then the config data model has to be more complex to distinguish bogus
entries from real ones.
The YANG validation has to know the difference as well, adding hacks to
that code.
The access model needs to account for creation of bogus entries vs. real
ones,
adding an operational cost to this solution approach.

The YANG to use depends on the requirements.
The /foo-state tree can be considered "always on".
If this is not desired then a better design is to use a P-container:

   container foo {
 presence "Indicates foo counters are being collected";
 container foo-stats {
config false;
/...
 }
   }

This combination of config and state has a use-case.
I don't see a use-case for NP-container though.






/js
>


Andy


>
> --
> 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] OpsState and Schema-Mount

[Kent Watsen]

Before the "rule" I can choose to place monitoring in its own module
without any reliance on other modules.  If the monitoring does not share 
indexing,
what value is there in putting it in the config tree?  I see none except a poor
attempt at model classification.

[KENT] from opstate-reqs:

4. Ability to relate configuration with its corresponding
   operational state.
   A.  Ability to relate intended config nodes to corresponding
  applied config nodes
B.  Ability to relate intended config nodes to associated derived
  state nodes
C.  The relationships need to be programmatically consumable



If the monitoring is rooting under config=true nodes, then those config=true
nodes need to be created somehow.  A client with write access is probably 
required.

[KENT] yes, but those config true ancestor nodes could be created by another 
client that has write-access, similar to POSIX filesystem.



Much easier to solve the conformance since /foo-state does not need any objects 
from /foo
to exist first.  Creating the /foo container means that all config=true 
requirements for
that container must be implemented (or complex deviations used)

[KENT] seems like an implementation detail.  The conceptual model is fine.   
 and new  can have different views.   should 
maintain the view of the config false nodes returned not including 
system-generated objects (e.g., interfaces), whereas  can also 
return system-generated objects, some of which may require also returning 
config true ancestor nodes.




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

Re: [netmod] OpsState and Schema-Mount

[Ladislav Lhotka]

> On 09 Aug 2016, at 15:38, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
>> 
>> In particular, I think that the guideline would be along the lines:
>> If a given module "foo" only contains state and no configuration, then
>> having a single top-level "foo" config false node is fine, but if a given
>> module contains both config and state then the recommendation is to put that
>> under a config=true "foo" top-level node.  Refining that slightly, If the
>> state data is relevant even if "foo" hasn't been enabled then make the top
>> level "foo" an NP container.  If "foo" has to be enabled on the system for
>> the state data to be relevant then make "foo" a P container (or give it a
>> separate foo/enable leaf).  In summary, I would suggest that the foo state
>> data should be pushed as far down the combined config/state tree as
>> possible.  It should be sited below (or adjacent to) whichever config node
>> is required to make that state data relevant.
>> 
>> If config and state are in the same tree then it is easy to return all the
>> data in one RPC, or have separate RPC operations that just return
>> configuration (e.g. ), or just return "state + containing
>> hieararchy" (e.g. a newly defined , or equivalent).
>> 
>> Having separate foo vs foo-state trees at the top level is always going to
>> make it harder to return and manage a combined view of the config and state
>> data.
> 
> I think it is crucial to separate (a) what protocols do today and (b)
> what protocols might do at some time in the future.
> 
> The current protocol reality, that is (a), paired with the reality of
> network interfaces has lead to the (/interfaces, /interfaces-state)
> design pattern and until we have (b) in place I do not think we have
> really an alternative for the (/interfaces, /interfaces-state)
> design pattern.

I would also add that some aspects of YANG (config true/false dichotomy, 
validation rules) make everything else difficult. 

> 
> If you have config and state are in the same tree, you simply can't
> represent certain things that exist in reality. A single tree may look
> 'simpler' but in several cases also simply 'unusable'. We did not
> particularly like the (/interfaces, /interfaces-state) design but it
> was the only solution that seemed to work for all cases given the
> protocol reality we were in.

Right. We have tried hard to find something more elegant, and some attempts 
(for example [1]) were quite similar to the current OpState proposals, but we 
eventually realised that our shortcuts only work in simple examples and break 
down in more complex situations.

That said, I don't claim that a more elegant solution is impossible (and Randy 
Presuhn would probably note that it was already available 25 years ago:-) but 
IMO it is not a low-hanging fruit given what we currently have (YANG and the 
protocols).

Lada

[1] https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00

> 
> /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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] OpsState and Schema-Mount

[Andy Bierman]

On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton  wrote:

> Hi Andy,
> I don't properly understand the points that you are making, please see
> clarifying comments/questions inline ...
>
> On 08/08/2016 22:51, Andy Bierman wrote:
>
>
>
> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:
>
>> Acee writes:
>> >Then I see no YANG language barriers in collapsing config and state
>> trees
>> >- the model root just needs to be “config true”.
>>
>> Great, I think we’re all agreed.  Can we now discuss the text I proposed
>> for 6087bis?  - here’s the link to my proposal:
>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>>
>>
> IMO this effort to avoid 2 containers is not well thought out.
> Some concerns:
>
> 1) modularity
> placing the monitoring objects within the configuration means the
> monitoring
> cannot be used on its own
>
> If it is one module with two top level augments (foo and foo-state) then
> this problem still exists.  Hence, please can you clarify why converging
> them on a single root node means that monitoring cannot be used on it own?
> Wouldn't a device need to use deviations in both cases to strip out the
> config nodes that they are not supporting?
>
>
Before the "rule" I can choose to place monitoring in its own module
without any reliance on other modules.  If the monitoring does not share
indexing,
what value is there in putting it in the config tree?  I see none except a
poor
attempt at model classification.



>
>
> 2) access control
> placing the monitoring data within configuration means the
> monitoring-only clients
> need write permission turned on for the nodes they can access for
> read-only
> This relies on granular and complex NACM rules which require regular
> maintenance.
>
> Again, I don't quite follow this, in the specific example that I have
> regarding putting a RIB under a config true NP container, I would have
> thought that NACM read access would have been sufficient for a
> monitoring-only client.  Is that not the case?
>


If the monitoring is rooting under config=true nodes, then those config=true
nodes need to be created somehow.  A client with write access is probably
required.



>
>
> 3) YANG conformance
> placing the monitoring data inside the configuration means the
> configuration
> will be required for conformance; it is not likely to be just 1 NP
> container.
>
> Similar to my response to the first question, I thought that conformance
> was done on a per module base, not a per sub-tree basis.  So even if you
> have top level 'foo' and 'foo-state' as part of the same module don't you
> run into the same conformance problem?
>
>
>
Much easier to solve the conformance since /foo-state does not need any
objects from /foo
to exist first.  Creating the /foo container means that all config=true
requirements for
that container must be implemented (or complex deviations used)


>
> 4) pointless;
>given that new RPC operations are needed to access applied config, the
> only data not
>affected (and moved under the config container anyway) is stuff that
> does not share
>the same indexing, or counters which are not part of the opstate
> problem.
>
> Sorry, I don't really follow this one.  The original opstate draft put
> forward by OpenConfig was asking for both applied-configuration and derived
> state (e.g. statistics and other state) to be co-located under the same
> structures.  The original discussions focused on applied configuration, but
> when this was being discussed more recently the desire for a solution to
> the co-located derived state was also discussed - which is why both
> draft-schoenw-netmod-revised-datastores-01 and
> draft-wilton-netmod-refined-datastores-01 propose solutions to this
> problem.
>


> There are also benefits to merging this data:
>
> 1) Having co-located config and state data means that clients can easily
> request config and state for a related object in a single request
> 1b) Having co-located config and state makes it easier for clients to code
> - they don't need to unify data across two (potentially different
> structures/indexes).
> 1c) Having a single structure, means less copying of the same organization
> structure into both config and state sub trees (which could be a source of
> bugs)
>
> 2) Having a single root makes schema mount work more nicely, it avoids a
> duplicate hierarchy.
>
> 3) Finally, I also agree with Kent, in that merging these makes the models
> easier to read and removes a historical wart.
>
>

I don't agree with any of these "benefits".
The protocol can be made to solve these problems. (1) is already solved.
(1b) is pure speculation about implementation cost.
(1c) also makes subjective implementation assumptions
The new problems that are raised just make YANG worse and full of CLRs
that confuse people trying to learn YANG.




> Thanks,
> Rob
>
>
>
Andy


>
>
>
> Andy
>
>
> Hint: the first 

Re: [netmod] OpsState and Schema-Mount

[Juergen Schoenwaelder]

On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
> 
> In particular, I think that the guideline would be along the lines:
> If a given module "foo" only contains state and no configuration, then
> having a single top-level "foo" config false node is fine, but if a given
> module contains both config and state then the recommendation is to put that
> under a config=true "foo" top-level node.  Refining that slightly, If the
> state data is relevant even if "foo" hasn't been enabled then make the top
> level "foo" an NP container.  If "foo" has to be enabled on the system for
> the state data to be relevant then make "foo" a P container (or give it a
> separate foo/enable leaf).  In summary, I would suggest that the foo state
> data should be pushed as far down the combined config/state tree as
> possible.  It should be sited below (or adjacent to) whichever config node
> is required to make that state data relevant.
> 
> If config and state are in the same tree then it is easy to return all the
> data in one RPC, or have separate RPC operations that just return
> configuration (e.g. ), or just return "state + containing
> hieararchy" (e.g. a newly defined , or equivalent).
> 
> Having separate foo vs foo-state trees at the top level is always going to
> make it harder to return and manage a combined view of the config and state
> data.

I think it is crucial to separate (a) what protocols do today and (b)
what protocols might do at some time in the future.

The current protocol reality, that is (a), paired with the reality of
network interfaces has lead to the (/interfaces, /interfaces-state)
design pattern and until we have (b) in place I do not think we have
really an alternative for the (/interfaces, /interfaces-state)
design pattern.

If you have config and state are in the same tree, you simply can't
represent certain things that exist in reality. A single tree may look
'simpler' but in several cases also simply 'unusable'. We did not
particularly like the (/interfaces, /interfaces-state) design but it
was the only solution that seemed to work for all cases given the
protocol reality we were in.

/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] OpsState and Schema-Mount

[Robert Wilton]

On 09/08/2016 00:30, Andy Bierman wrote:



On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <kwat...@juniper.net 
<mailto:kwat...@juniper.net>> wrote:


For 1,2,3, realize that placing config false nodes under config
true nodes has been with us from the beginning.  All the issues
you mentioned (if they’re issues at all) can’t be new.   Having a
duplicate -state tree is the wart here, it’s introducing an
inconsistency in how models have been written for a long time.  I
prefer to remove the wart than celebrate it.


No, it actually is not the way we have been doing things all along.
Historically (even with NETCONF, not just SNMP) we standardize
read-only monitoring information.  Sometimes configuration is added later.


For me, it seems to have been the opposite.  I.e. all the early pressure 
was to get configuration covered by YANG models, with the operational 
state following afterwards.  We are either being asked for config 
models, or config+state models.  I guess that is because there is an 
existing solution (SNMP) for monitoring devices, but there is no 
workable solution to configure devices without using YANG.


Further, it seems to me that NETCONF is quite config focused, and that 
handling state was more added as an afterthought (e.g. according to the 
NETCONF RFC, config false leaves don't even exist as part of any 
datastore!).  If reporting state was the main driver for NETCONF/YANG 
then I would have thought that the semantics for handling operational 
state would have been formalized earlier on.





Issues 1 - 3 are practical issues that need to be addressed if 
top-level config=false

nodes are not allowed anymore.
I don't think that the proposal is to make them 'not allowed', but 'not 
recommended' instead.


In particular, I think that the guideline would be along the lines:
If a given module "foo" only contains state and no configuration, then 
having a single top-level "foo" config false node is fine, but if a 
given module contains both config and state then the recommendation is 
to put that under a config=true "foo" top-level node.  Refining that 
slightly, If the state data is relevant even if "foo" hasn't been 
enabled then make the top level "foo" an NP container.  If "foo" has to 
be enabled on the system for the state data to be relevant then make 
"foo" a P container (or give it a separate foo/enable leaf).  In 
summary, I would suggest that the foo state data should be pushed as far 
down the combined config/state tree as possible.  It should be sited 
below (or adjacent to) whichever config node is required to make that 
state data relevant.


If config and state are in the same tree then it is easy to return all 
the data in one RPC, or have separate RPC operations that just return 
configuration (e.g. ), or just return "state + containing 
hieararchy" (e.g. a newly defined , or equivalent).


Having separate foo vs foo-state trees at the top level is always going 
to make it harder to return and manage a combined view of the config and 
state data.


Thanks,
Rob





Andy

For 4, right, this discussion on s5.23 of 6087bis regards how to
handle state for system-generated objects (e.g., interfaces).  It
is not directly related to the how to report applied configuration
problem.  It is however indirectly related, in that a holistic
solution can address both.

Kent

*From: *Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>>
*Date: *Monday, August 8, 2016 at 5:51 PM
*To: *Kent Watsen <kwat...@juniper.net <mailto:kwat...@juniper.net>>
*Cc: *"Acee Lindem (acee)" <a...@cisco.com
<mailto:a...@cisco.com>>, "Robert Wilton -X (rwilton - ENSOFT
LIMITED at Cisco)" <rwil...@cisco.com <mailto:rwil...@cisco.com>>,
Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>, Balazs
Lengyel <balazs.leng...@ericsson.com
<mailto:balazs.leng...@ericsson.com>>, "netmod@ietf.org
<mailto:netmod@ietf.org>" <netmod@ietf.org <mailto:netmod@ietf.org>>
*Subject: *Re: [netmod] OpsState and Schema-Mount

On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <kwat...@juniper.net
<mailto:kwat...@juniper.net>> wrote:

Acee writes:
>Then I see no YANG language barriers in collapsing config
and state trees
>- the model root just needs to be “config true”.

Great, I think we’re all agreed. Can we now discuss the text I
proposed for 6087bis?  - here’s the link to my proposal:
https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s

<https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s>.

IMO this effort to avoid 2 containers is not well thought out.

Some conc

Re: [netmod] OpsState and Schema-Mount

[Robert Wilton]

Hi Andy,

I don't properly understand the points that you are making, please see 
clarifying comments/questions inline ...


On 08/08/2016 22:51, Andy Bierman wrote:



On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen > wrote:


Acee writes:
>Then I see no YANG language barriers in collapsing config and
state trees
>- the model root just needs to be “config true”.

Great, I think we’re all agreed.  Can we now discuss the text I
proposed for 6087bis?  - here’s the link to my proposal:
https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s
.


IMO this effort to avoid 2 containers is not well thought out.
Some concerns:

1) modularity
placing the monitoring objects within the configuration means the 
monitoring

cannot be used on its own
If it is one module with two top level augments (foo and foo-state) then 
this problem still exists.  Hence, please can you clarify why converging 
them on a single root node means that monitoring cannot be used on it 
own?  Wouldn't a device need to use deviations in both cases to strip 
out the config nodes that they are not supporting?





2) access control
placing the monitoring data within configuration means the 
monitoring-only clients
need write permission turned on for the nodes they can access for 
read-only
This relies on granular and complex NACM rules which require 
regular maintenance.
Again, I don't quite follow this, in the specific example that I have 
regarding putting a RIB under a config true NP container, I would have 
thought that NACM read access would have been sufficient for a 
monitoring-only client.  Is that not the case?





3) YANG conformance
placing the monitoring data inside the configuration means the 
configuration
will be required for conformance; it is not likely to be just 1 NP 
container.
Similar to my response to the first question, I thought that conformance 
was done on a per module base, not a per sub-tree basis.  So even if you 
have top level 'foo' and 'foo-state' as part of the same module don't 
you run into the same conformance problem?





4) pointless;
   given that new RPC operations are needed to access applied config, 
the only data not
   affected (and moved under the config container anyway) is stuff 
that does not share
   the same indexing, or counters which are not part of the opstate 
problem.
Sorry, I don't really follow this one.  The original opstate draft put 
forward by OpenConfig was asking for both applied-configuration and 
derived state (e.g. statistics and other state) to be co-located under 
the same structures.  The original discussions focused on applied 
configuration, but when this was being discussed more recently the 
desire for a solution to the co-located derived state was also discussed 
- which is why both draft-schoenw-netmod-revised-datastores-01 and 
draft-wilton-netmod-refined-datastores-01 propose solutions to this problem.


There are also benefits to merging this data:

1) Having co-located config and state data means that clients can easily 
request config and state for a related object in a single request
1b) Having co-located config and state makes it easier for clients to 
code - they don't need to unify data across two (potentially different 
structures/indexes).
1c) Having a single structure, means less copying of the same 
organization structure into both config and state sub trees (which could 
be a source of bugs)


2) Having a single root makes schema mount work more nicely, it avoids a 
duplicate hierarchy.


3) Finally, I also agree with Kent, in that merging these makes the 
models easier to read and removes a historical wart.


Thanks,
Rob






Andy


Hint: the first few edits are just nits...skip over the first few
paragraphs until you start seeing large blocks of changed lines...

Kent // as a contributor



___
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] OpsState and Schema-Mount

[Ladislav Lhotka]

Kent Watsen <kwat...@juniper.net> writes:

> For 1,2,3, realize that placing config false nodes under config true
> nodes has been with us from the beginning.  All the issues you
> mentioned (if they’re issues at all) can’t be new.   Having a
> duplicate -state tree is the wart here, it’s introducing an
> inconsistency in how models have been written for a long time.  I
> prefer to remove the wart than celebrate it.

Before making changes to the existing models, I'd love to see a
(proposal of a) complete solution. Just moving the config false stuff
from foo-state to foo doesn't help at all.

Lada

>
> For 4, right, this discussion on s5.23 of 6087bis regards how to handle state 
> for system-generated objects (e.g., interfaces).  It is not directly related 
> to the how to report applied configuration problem.  It is however indirectly 
> related, in that a holistic solution can address both.
>
> Kent
>
>
> From: Andy Bierman <a...@yumaworks.com>
> Date: Monday, August 8, 2016 at 5:51 PM
> To: Kent Watsen <kwat...@juniper.net>
> Cc: "Acee Lindem (acee)" <a...@cisco.com>, "Robert Wilton -X (rwilton - 
> ENSOFT LIMITED at Cisco)" <rwil...@cisco.com>, Ladislav Lhotka 
> <lho...@nic.cz>, Balazs Lengyel <balazs.leng...@ericsson.com>, 
> "netmod@ietf.org" <netmod@ietf.org>
> Subject: Re: [netmod] OpsState and Schema-Mount
>
>
>
> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen 
> <kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:
> Acee writes:
>>Then I see no YANG language barriers in collapsing config and state trees
>>- the model root just needs to be “config true”.
>
> Great, I think we’re all agreed.  Can we now discuss the text I proposed for 
> 6087bis?  - here’s the link to my proposal:  
> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>
> IMO this effort to avoid 2 containers is not well thought out.
> Some concerns:
>
> 1) modularity
> placing the monitoring objects within the configuration means the 
> monitoring
> cannot be used on its own
>
> 2) access control
> placing the monitoring data within configuration means the 
> monitoring-only clients
> need write permission turned on for the nodes they can access for 
> read-only
> This relies on granular and complex NACM rules which require regular 
> maintenance.
>
> 3) YANG conformance
> placing the monitoring data inside the configuration means the 
> configuration
> will be required for conformance; it is not likely to be just 1 NP 
> container.
>
> 4) pointless;
>given that new RPC operations are needed to access applied config, the 
> only data not
>affected (and moved under the config container anyway) is stuff that does 
> not share
>the same indexing, or counters which are not part of the opstate problem.
>
>
>
> Andy
>
>
> Hint: the first few edits are just nits...skip over the first few paragraphs 
> until you start seeing large blocks of changed lines...
>
> Kent // as a contributor
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] OpsState and Schema-Mount

[Andy Bierman]

On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <kwat...@juniper.net> wrote:

> For 1,2,3, realize that placing config false nodes under config true nodes
> has been with us from the beginning.  All the issues you mentioned (if
> they’re issues at all) can’t be new.   Having a duplicate -state tree is
> the wart here, it’s introducing an inconsistency in how models have been
> written for a long time.  I prefer to remove the wart than celebrate it.
>
>
>

No, it actually is not the way we have been doing things all along.
Historically (even with NETCONF, not just SNMP) we standardize
read-only monitoring information.  Sometimes configuration is added later.

Issues 1 - 3 are practical issues that need to be addressed if top-level
config=false
nodes are not allowed anymore.


Andy



> For 4, right, this discussion on s5.23 of 6087bis regards how to handle
> state for system-generated objects (e.g., interfaces).  It is not directly
> related to the how to report applied configuration problem.  It is however
> indirectly related, in that a holistic solution can address both.
>
>
>
> Kent
>
>
>
>
>
> *From: *Andy Bierman <a...@yumaworks.com>
> *Date: *Monday, August 8, 2016 at 5:51 PM
> *To: *Kent Watsen <kwat...@juniper.net>
> *Cc: *"Acee Lindem (acee)" <a...@cisco.com>, "Robert Wilton -X (rwilton -
> ENSOFT LIMITED at Cisco)" <rwil...@cisco.com>, Ladislav Lhotka <
> lho...@nic.cz>, Balazs Lengyel <balazs.leng...@ericsson.com>, "
> netmod@ietf.org" <netmod@ietf.org>
> *Subject: *Re: [netmod] OpsState and Schema-Mount
>
>
>
>
>
>
>
> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <kwat...@juniper.net> wrote:
>
> Acee writes:
> >Then I see no YANG language barriers in collapsing config and state
> trees
> >- the model root just needs to be “config true”.
>
> Great, I think we’re all agreed.  Can we now discuss the text I proposed
> for 6087bis?  - here’s the link to my proposal:
> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>
>
>
> IMO this effort to avoid 2 containers is not well thought out.
>
> Some concerns:
>
>
>
> 1) modularity
>
> placing the monitoring objects within the configuration means the
> monitoring
>
> cannot be used on its own
>
>
>
> 2) access control
>
> placing the monitoring data within configuration means the
> monitoring-only clients
>
> need write permission turned on for the nodes they can access for
> read-only
>
> This relies on granular and complex NACM rules which require regular
> maintenance.
>
>
>
> 3) YANG conformance
>
> placing the monitoring data inside the configuration means the
> configuration
>
> will be required for conformance; it is not likely to be just 1 NP
> container.
>
>
>
> 4) pointless;
>
>given that new RPC operations are needed to access applied config, the
> only data not
>
>affected (and moved under the config container anyway) is stuff that
> does not share
>
>the same indexing, or counters which are not part of the opstate
> problem.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
> Hint: the first few edits are just nits...skip over the first few
> paragraphs until you start seeing large blocks of changed lines...
>
> Kent // as a contributor
>
>
>
> ___
> 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] OpsState and Schema-Mount

[Kent Watsen]

For 1,2,3, realize that placing config false nodes under config true nodes has 
been with us from the beginning.  All the issues you mentioned (if they’re 
issues at all) can’t be new.   Having a duplicate -state tree is the wart here, 
it’s introducing an inconsistency in how models have been written for a long 
time.  I prefer to remove the wart than celebrate it.

For 4, right, this discussion on s5.23 of 6087bis regards how to handle state 
for system-generated objects (e.g., interfaces).  It is not directly related to 
the how to report applied configuration problem.  It is however indirectly 
related, in that a holistic solution can address both.

Kent


From: Andy Bierman <a...@yumaworks.com>
Date: Monday, August 8, 2016 at 5:51 PM
To: Kent Watsen <kwat...@juniper.net>
Cc: "Acee Lindem (acee)" <a...@cisco.com>, "Robert Wilton -X (rwilton - ENSOFT 
LIMITED at Cisco)" <rwil...@cisco.com>, Ladislav Lhotka <lho...@nic.cz>, Balazs 
Lengyel <balazs.leng...@ericsson.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] OpsState and Schema-Mount



On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:
Acee writes:
>Then I see no YANG language barriers in collapsing config and state trees
>- the model root just needs to be “config true”.

Great, I think we’re all agreed.  Can we now discuss the text I proposed for 
6087bis?  - here’s the link to my proposal:  
https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.

IMO this effort to avoid 2 containers is not well thought out.
Some concerns:

1) modularity
placing the monitoring objects within the configuration means the monitoring
cannot be used on its own

2) access control
placing the monitoring data within configuration means the monitoring-only 
clients
need write permission turned on for the nodes they can access for read-only
This relies on granular and complex NACM rules which require regular 
maintenance.

3) YANG conformance
placing the monitoring data inside the configuration means the configuration
will be required for conformance; it is not likely to be just 1 NP 
container.

4) pointless;
   given that new RPC operations are needed to access applied config, the only 
data not
   affected (and moved under the config container anyway) is stuff that does 
not share
   the same indexing, or counters which are not part of the opstate problem.



Andy


Hint: the first few edits are just nits...skip over the first few paragraphs 
until you start seeing large blocks of changed lines...

Kent // as a contributor



___
netmod mailing list
netmod@ietf.org<mailto: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] OpsState and Schema-Mount

[Andy Bierman]

On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:

> Acee writes:
> >Then I see no YANG language barriers in collapsing config and state
> trees
> >- the model root just needs to be “config true”.
>
> Great, I think we’re all agreed.  Can we now discuss the text I proposed
> for 6087bis?  - here’s the link to my proposal:
> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>
>
IMO this effort to avoid 2 containers is not well thought out.
Some concerns:

1) modularity
placing the monitoring objects within the configuration means the
monitoring
cannot be used on its own

2) access control
placing the monitoring data within configuration means the
monitoring-only clients
need write permission turned on for the nodes they can access for
read-only
This relies on granular and complex NACM rules which require regular
maintenance.

3) YANG conformance
placing the monitoring data inside the configuration means the
configuration
will be required for conformance; it is not likely to be just 1 NP
container.

4) pointless;
   given that new RPC operations are needed to access applied config, the
only data not
   affected (and moved under the config container anyway) is stuff that
does not share
   the same indexing, or counters which are not part of the opstate problem.



Andy


Hint: the first few edits are just nits...skip over the first few
> paragraphs until you start seeing large blocks of changed lines...
>
> Kent // as a contributor
>
>
>
> ___
> 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] OpsState and Schema-Mount

[Kent Watsen]

Acee writes:
>Then I see no YANG language barriers in collapsing config and state trees
>- the model root just needs to be “config true”.

Great, I think we’re all agreed.  Can we now discuss the text I proposed for 
6087bis?  - here’s the link to my proposal:  
https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.

Hint: the first few edits are just nits...skip over the first few paragraphs 
until you start seeing large blocks of changed lines...

Kent // as a contributor



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

Re: [netmod] OpsState and Schema-Mount

[Acee Lindem (acee)]

On 8/4/16, 6:52 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
 wrote:

>
>
>On 03/08/2016 19:37, Acee Lindem (acee) wrote:
>>
>> On 8/3/16, 5:02 AM, "netmod on behalf of Robert Wilton -X (rwilton -
>> ENSOFT LIMITED at Cisco)" > rwil...@cisco.com> wrote:
>>
>>>
>>> On 03/08/2016 07:49, Ladislav Lhotka wrote:
> On 02 Aug 2016, at 18:35, Balazs Lengyel
>
> wrote:
>
> Hello,
> If we allow foo and foo-state for opstate, mounting models atop such
>a
> multi rooted yang module will be fun.
> mount modB-config-part onto modA-config-part
> mount modB-state-part onto modA-state-part
> One mount becomes two and you have to maintain parallel mounts
> otherwise you are mounting half modules.
 This is already happenning with augments. It means some work but
 nothing terribly complex.

> Actually the problem is not caused by opstate, but rather by
> multi-rooted models. but avoiding foo-state would make life easier
>once
> more.
 We already agreed that some items (such as RIBs) are "true" state
which
 don't have direct counterparts in configuration. If we don't have
 foo-state, where are these supposed to be placed?
>>> One choice is that they could just be placed under foo, where foo is a
>>> config false leaf.
>> While there is a NETCONF/RESTCONF incompatibility with config-false data
>> nodes under config-true data nodes, there is no problem with the
>>reverse -
>> correct?
>You are allowed config false nodes under config true, but not config
>true nodes under config false.
>
>I had assumed in the example above that there wasn't already a config
>true "foo" to put them under, so to reconsider my answer:
>
>In draft-ietf-netmod-routing-cfg "routing" is a top level container that
>is nominally config true.  But it is also a non presence container, so
>it would be allowed to put the config false RIB nodes directly under the
>"routing" container.  Given that "routing" is an NP container, its
>existence (e.g. to report the RIB) doesn't imply that routing has been
>configured.
>
>In fact (given the recent discussion on the NETCONF alias), it is
>questionable what a "config" true NP container actually means.  I
>suspect that really it just ends up being a filter as to what type of
>child nodes are allowed.  I.e. if the NP container is config=true, then
>child nodes can be config true or config false. Conversely, if the NP
>container is config false then any child nodes must also be config false.


Then I see no YANG language barriers in collapsing config and state trees
- the model root just needs to be “config true”.

Thanks,
Acee 



>
>Thanks,
>Rob
>
>
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>>> Rob
>>>
>>>
 Lada

> regards Balazs
>
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email:
>balazs.leng...@ericsson.com
>
 --
 Ladislav Lhotka, CZ.NIC Labs
 PGP Key ID: E74E8C0C




 .

>>> ___
>>> 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] OpsState and Schema-Mount

[Robert Wilton]

On 03/08/2016 19:37, Acee Lindem (acee) wrote:


On 8/3/16, 5:02 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:



On 03/08/2016 07:49, Ladislav Lhotka wrote:

On 02 Aug 2016, at 18:35, Balazs Lengyel 
wrote:

Hello,
If we allow foo and foo-state for opstate, mounting models atop such a
multi rooted yang module will be fun.
mount modB-config-part onto modA-config-part
mount modB-state-part onto modA-state-part
One mount becomes two and you have to maintain parallel mounts
otherwise you are mounting half modules.

This is already happenning with augments. It means some work but
nothing terribly complex.


Actually the problem is not caused by opstate, but rather by
multi-rooted models. but avoiding foo-state would make life easier once
more.

We already agreed that some items (such as RIBs) are "true" state which
don't have direct counterparts in configuration. If we don't have
foo-state, where are these supposed to be placed?

One choice is that they could just be placed under foo, where foo is a
config false leaf.

While there is a NETCONF/RESTCONF incompatibility with config-false data
nodes under config-true data nodes, there is no problem with the reverse -
correct?
You are allowed config false nodes under config true, but not config 
true nodes under config false.


I had assumed in the example above that there wasn't already a config 
true "foo" to put them under, so to reconsider my answer:


In draft-ietf-netmod-routing-cfg "routing" is a top level container that 
is nominally config true.  But it is also a non presence container, so 
it would be allowed to put the config false RIB nodes directly under the 
"routing" container.  Given that "routing" is an NP container, its 
existence (e.g. to report the RIB) doesn't imply that routing has been 
configured.


In fact (given the recent discussion on the NETCONF alias), it is 
questionable what a "config" true NP container actually means.  I 
suspect that really it just ends up being a filter as to what type of 
child nodes are allowed.  I.e. if the NP container is config=true, then 
child nodes can be config true or config false. Conversely, if the NP 
container is config false then any child nodes must also be config false.


Thanks,
Rob




Thanks,
Acee





Rob



Lada


regards Balazs

--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com


--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




.


___
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] OpsState and Schema-Mount

[Acee Lindem (acee)]

On 8/3/16, 5:02 AM, "netmod on behalf of Robert Wilton -X (rwilton -
ENSOFT LIMITED at Cisco)"  wrote:

>
>
>On 03/08/2016 07:49, Ladislav Lhotka wrote:
>>> On 02 Aug 2016, at 18:35, Balazs Lengyel 
>>>wrote:
>>>
>>> Hello,
>>> If we allow foo and foo-state for opstate, mounting models atop such a
>>>multi rooted yang module will be fun.
>>> mount modB-config-part onto modA-config-part
>>> mount modB-state-part onto modA-state-part
>>> One mount becomes two and you have to maintain parallel mounts
>>>otherwise you are mounting half modules.
>> This is already happenning with augments. It means some work but
>>nothing terribly complex.
>>
>>> Actually the problem is not caused by opstate, but rather by
>>>multi-rooted models. but avoiding foo-state would make life easier once
>>>more.
>> We already agreed that some items (such as RIBs) are "true" state which
>>don't have direct counterparts in configuration. If we don't have
>>foo-state, where are these supposed to be placed?
>One choice is that they could just be placed under foo, where foo is a
>config false leaf.

While there is a NETCONF/RESTCONF incompatibility with config-false data
nodes under config-true data nodes, there is no problem with the reverse -
correct? 

Thanks,
Acee




>
>Rob
>
>
>>
>> Lada
>>
>>> regards Balazs
>>>
>>> -- 
>>> Balazs Lengyel   Ericsson Hungary Ltd.
>>> Senior Specialist
>>> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
>>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> .
>>
>
>___
>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] OpsState and Schema-Mount

[Robert Wilton]

On 03/08/2016 07:49, Ladislav Lhotka wrote:

On 02 Aug 2016, at 18:35, Balazs Lengyel  wrote:

Hello,
If we allow foo and foo-state for opstate, mounting models atop such a multi 
rooted yang module will be fun.
mount modB-config-part onto modA-config-part
mount modB-state-part onto modA-state-part
One mount becomes two and you have to maintain parallel mounts otherwise you 
are mounting half modules.

This is already happenning with augments. It means some work but nothing 
terribly complex.


Actually the problem is not caused by opstate, but rather by multi-rooted 
models. but avoiding foo-state would make life easier once more.

We already agreed that some items (such as RIBs) are "true" state which don't 
have direct counterparts in configuration. If we don't have foo-state, where are these 
supposed to be placed?
One choice is that they could just be placed under foo, where foo is a 
config false leaf.


Rob




Lada


regards Balazs

--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com


--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




.



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

Re: [netmod] OpsState and Schema-Mount

[Robert Wilton]

Hi Balazs,

Yes, it would be exactly as you describe: you end up having two parallel 
trees, with two parallel sets of mount points.


It feels like this would be an extra wart, but not the end of the world.

I also agree that avoiding the foo/foo-state split would help mitigate this.

Thanks,
Rob


On 02/08/2016 17:35, Balazs Lengyel wrote:

Hello,
If we allow foo and foo-state for opstate, mounting models atop such a 
multi rooted yang module will be fun.

mount modB-config-part onto modA-config-part
mount modB-state-part onto modA-state-part
One mount becomes two and you have to maintain parallel mounts 
otherwise you are mounting half modules.


Actually the problem is not caused by opstate, but rather by 
multi-rooted models. but avoiding foo-state would make life easier 
once more.


regards Balazs



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

Re: [netmod] OpsState and Schema-Mount

[Ladislav Lhotka]

> On 02 Aug 2016, at 18:35, Balazs Lengyel  wrote:
> 
> Hello,
> If we allow foo and foo-state for opstate, mounting models atop such a multi 
> rooted yang module will be fun.
> mount modB-config-part onto modA-config-part
> mount modB-state-part onto modA-state-part
> One mount becomes two and you have to maintain parallel mounts otherwise you 
> are mounting half modules.

This is already happenning with augments. It means some work but nothing 
terribly complex.

> 
> Actually the problem is not caused by opstate, but rather by multi-rooted 
> models. but avoiding foo-state would make life easier once more.

We already agreed that some items (such as RIBs) are "true" state which don't 
have direct counterparts in configuration. If we don't have foo-state, where 
are these supposed to be placed?

Lada 

> 
> regards Balazs
> 
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

[netmod] OpsState and Schema-Mount

[Balazs Lengyel]

Hello,
If we allow foo and foo-state for opstate, mounting models atop such a 
multi rooted yang module will be fun.

mount modB-config-part onto modA-config-part
mount modB-state-part onto modA-state-part
One mount becomes two and you have to maintain parallel mounts otherwise 
you are mounting half modules.


Actually the problem is not caused by opstate, but rather by 
multi-rooted models. but avoiding foo-state would make life easier once 
more.


regards Balazs

--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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