Subject: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 11 Jul 2016 16:36:20 +0000

While there are details to be worked out between the two data stores
models (as indicated below), we now have implicit modeling of applied
configuration. Existing models (both standard and draft) do not take this
into consideration and, consequently, much of the state that is modeled
explicitly represents the application configuration. For the RFC models,
it probably doesn’t make much sense to redo them (unless they are being
reworked for other reasons). This still leaves the existing WG draft
models for which we have basically 3 options:

  1. Do nothing - allow them proceed as they are with multiple ways of
representing the applied configuration. This would provide visibility to
the data independent of whether or not the device supported the revised
data-stores supporting implicit retrieval of the applied configuration.
  2. Prune out the redundant data nodes except those required as list
keys, etc, since they can be obtained from the applied state data store.
  3. #2 plus collapse the config (read-write) and  system-state
(read-only) into common containers. No more branching of
<model-name>-config and <model-name>-state at the top level of the model.

At I high-level, I feel these are the options. I’m not married to any one
of these and the worse thing we could do is hold up progression of the
existing YANG model drafts for another couple years while we debate the
best course. Having said that, #3 is compelling since it will yield the
most concise models and colocates the schema data nodes for any managed
object. 

Thanks,
Acee 

On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
<[email-masked] on behalf of [email-masked]> wrote:

>All,
>
>It's time to make a consensus call on this topic, so that we can all move
>on to defining a solution and aligning modules under development. Based
>on the feedback received and the overall discussions on the topic, we see
>that there is consensus to follow a datastore based approach to
>supporting operational state, i.e., direction 'B'.
>
>We will be asking the authors of [4] and [5] to review their proposals
>(individual drafts) in Berlin, as well as to highlight differences and
>suggest ways that their work could be consolidated. Of course, others may
>also choose to submit their own proposals. Given the importance of this
>work, we will be looking to have active discussion on the topic both in
>Berlin and on the list, with an objective of having a draft ready for
>considerations as a WG document by the November IETF.
>
>We have reviewed this decision with our AD and the NetConf chairs and
>have agreed to begin this work in NetMod. We certainly expect to
>coordinate the work with the NetConf WG and re-home work as/if needed.
>
>Finally, we'd also like to thank all those who have contributed to this
>discussion to date, from problem identification to proposed solutions,
>and we look forward to your continued efforts to publish a standard
>solution. 
>
>Lou (and Kent)
>
>
>On 6/7/2016 10:19 AM, Lou Berger wrote:
>> All,
>>
>> We want to provide an update based on the off line discussions
>> related to OpState Solutions that we have been having and solicit
>> input from the WG.
>>
>> All authors of current solution drafts [1,2,3] together with those
>> who helped conduct the solutions analysis* were invited to the these
>> discussions -- with the objective of coming up with a single
>> consolidated proposal to bring to the WG. (I/Lou acted as facilitator
>> as Kent and Juergen were and are involved with the technical details.)
>>
>> The discussions have yielded some results but, unfortunately,
>> not a single consolidated proposal as hoped, but rather two
>> alternate directions -- and clearly we need to choose one:
>>
>>     1) Adopt the conventions for representing state/config
>>        based on Section 6 of [1].
>>
>>        From a model definition perspective, these conventions
>>        impact every model and every model writer.
>>
>>     2) Model OpState using a revised logical datastore definition
>>        as introduced in [4] and also covered in [5]. There is
>>        also a variant of this that we believe doesn't significantly
>>        impact this choice.
>>
>>        With this approach, model definitions need no explicit
>>        changes to support applied configuration.
>>
>> >From a technology/WG standpoint, we believe an approach
>> that doesn't impact every model written (i.e., #2) is superior.
>> The counterpoint to this is that the conventions based
>> approach (i.e., #1) is available today and being followed in
>> OpenConfig defined models.
>>
>> We would like to hear opinions on this from the WG before
>> declaring one of the following as the WG direction:
>>
>>     A) models that wish to support applied configuration MUST
>>        follow conventions based on [1] -- and the WG needs to
>>        formalize these conventions.
>> or
>>     B) no explicit support is required for models to support
>>        applied configuration -- and that the WG needs to
>>        formalize an opstate solution based on the approach
>>        discussed in [4] and [5].
>>
>> We intend to close on this choice before Berlin.
>>
>> Thank you,
>> Lou (and co-chairs)
>>
>> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
>> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
>> [4] 
>>https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
>> [5] 
>>https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
>> * - Chris H. and Acee L.
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Lou Berger <[email-masked]>
Date: Tue, 12 Jul 2016 11:23:58 -0400

Acee,

    I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here.  Can you elaborate what you're thinking here?

Thanks,

Lou

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Jul 2016 15:52:00 +0000

Hi Lou, 
I’m not advocating this #2. If you are going to rely on the revised data
stores to obtain the information, you should go all the way to #3. For
example, based on the control-plane-protocols in routing-cfg, we have
separate top level containers for config state.

 +--rw routing
      +--rw router-id?
      +--rw control-plane-protocols
      |  +--rw control-plane-protocol* [type name]

And:
+— ro routing-state
      +--ro router-id?
      +--ro interfaces
      |  +--ro interface*
      +--ro control-plane-protocols
      |  +--ro control-plane-protocol* [type name]
      |     +--ro type
      |     +--ro name

The control plane protocols augment these two lists separately. With #2,
we leave the bifurcated structure and simply remove the data nodes that
are not needed from the protocol state.

Thanks,
Acee

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 09:17:52 -0700

On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <[email-masked]> wrote:

> .....
> >.....

I would really like to understand what problem (3) is supposed to solve.

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary
configuration mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be
co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.  Why is that progress?

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Jul 2016 16:30:19 +0000

Hi Andy,

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 12, 2016 at 12:17 PM
To: Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, netmod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
Acee,

Thanks,

Lou
.....

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration mechanisms.
(e.g., the way the SNMP world has worked for 30 years)

If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.

If they are meant to be supported independently, why wouldn’t they be separate models?

Thanks,
Acee

Why is that progress?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 09:38:20 -0700

On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Andy,
>
> From: Andy Bierman <[email-masked]>
> To: Lou Berger <[email-masked]>
> Cc: Acee Lindem <[email-masked]>, netmod WG <[email-masked]>

YANG features can be used and they can still be supported independently.

Andy

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Jul 2016 16:56:53 +0000

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 12, 2016 at 12:38 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>, netmod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Tue, Jul 12, 2016 at 9:30 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Thanks,

Lou
.....

True - but I have not run across a model featured at the config/state branch.

Acee

Thanks,
Acee

Andy

Why is that progress?

Andy

---

From: Robert Wilton <[email-masked]>
Date: Tue, 12 Jul 2016 17:59:17 +0100

Hi Andy,

> I would really like to understand what problem (3) is supposed to solve.
My personal view is that I think that it makes the models simpler, with 
less duplication.

E.g. I also see that it makes it easier for a client to fetch all of the 
information associated with a particular feature in a single sub tree 
rather that needing to merge data from two separate config & state sub 
trees.

> (e.g., the way the SNMP world has worked for 30 years)
I thought that it was config that was originally driving YANG because 
there is already a solution for state data (SNMP).  Hence, I would have 
thought that the most common case would be that YANG is used just for 
config, or config & state.  So, I think that it makes sense to optimize 
models for these scenarios.

> unless the standard configuration is also supported.
Both datastore draft solutions allow for system created config entries.  
So in both drafts the operational state datastore can instantiate 
whatever config nodes are necessary to parent config false state nodes.

I also don't think that separate monitoring subtrees are going to be 
banned, they should be used where appropriate.  It is just that it will 
be no longer be required to have separate state subtrees purely because 
of potential differences in the lifetime of config vs state objects 
(e.g. interfaces vs interfaces-state).

I would be very happy if "interfaces" and "interfaces-state" could be 
merged into "interfaces" as a new/updated interfaces YANG model that 
draft models could be updated to use.  I understand that would be a 
impactful change to make (but seemingly mostly on IETF models that 
haven't yet been standardized).  But I hope that we are going to have to 
live with the YANG model structure for a long time, and if we still have 
an opportunity to "fix" a fairly big wart then I think that it would be 
good to do so.

Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 10:01:42 -0700

On Tue, Jul 12, 2016 at 9:56 AM, Acee Lindem (acee) <[email-masked]> wrote:

> To: Acee Lindem <[email-masked]>
> Cc: Lou Berger <[email-masked]>, netmod WG <[email-masked]>
Can you answer the question "What problem is created by having separate
configuration
and monitoring subtrees?"

Seems like an RPC-based opstate solution does not depend on this change,
so why is it being proposed?

Acee
Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 10:05:12 -0700

> rather that needing to merge data from two separate config & state sub
This is your opinion.
I think separate makes it easier to read, especially if the monitoring data
is relevant regardless of how associated configuration was done.

> models for these scenarios.

This is marketing.
Do you have any technical arguments?

> So in both drafts the operational state datastore can instantiate whatever
> config nodes are necessary to parent config false state nodes.
>
> banned, they should be used where appropriate.  It is just that it will be
> no longer be required to have separate state subtrees purely because of
> potential differences in the lifetime of config vs state objects (e.g.
> interfaces vs interfaces-state).
>
> merged into "interfaces" as a new/updated interfaces YANG model that draft
> models could be updated to use.  I understand that would be a impactful
> change to make (but seemingly mostly on IETF models that haven't yet been
> standardized).  But I hope that we are going to have to live with the YANG
> model structure for a long time, and if we still have an opportunity to
> "fix" a fairly big wart then I think that it would be good to do so.
>
>
I can't say if the pre-provisioning model in ietf-interfaces should be
generalized.
I have not seen any good general solutions for combining config and state.

Andy

> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 12 Jul 2016 18:22:29 +0100

On 12/07/2016 18:05, Andy Bierman wrote:
>
>
> On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Andy,
>
>
>     My personal view is that I think that it makes the models simpler,
>     with less duplication.
>
>     E.g. I also see that it makes it easier for a client to fetch all
>     of the information associated with a particular feature in a
>     single sub tree rather that needing to merge data from two
>     separate config & state sub trees.
>
>
> This is your opinion.
This is easily achievable by filtering (e.g. only return config false 
leaves + config true structural nodes).

>     I thought that it was config that was originally driving YANG
>     because there is already a solution for state data (SNMP).  Hence,
>     I would have thought that the most common case would be that YANG
>     is used just for config, or config & state.  So, I think that it
>     makes sense to optimize models for these scenarios.
>
>
>
> This is marketing.
Yes, I gave them below: I don't see that merging config and state 
prevents entities from only monitoring state if they wish.

Thanks,
Rob

>     Both datastore draft solutions allow for system created config
>     entries.  So in both drafts the operational state datastore can
>     instantiate whatever config nodes are necessary to parent config
>     false state nodes.
>
>     I also don't think that separate monitoring subtrees are going to
>     be banned, they should be used where appropriate.  It is just that
>     it will be no longer be required to have separate state subtrees
>     purely because of potential differences in the lifetime of config
>     vs state objects (e.g. interfaces vs interfaces-state).
>
>     I would be very happy if "interfaces" and "interfaces-state" could
>     be merged into "interfaces" as a new/updated interfaces YANG model
>     that draft models could be updated to use.  I understand that
>     would be a impactful change to make (but seemingly mostly on IETF
>     models that haven't yet been standardized).  But I hope that we
>     are going to have to live with the YANG model structure for a long
>     time, and if we still have an opportunity to "fix" a fairly big
>     wart then I think that it would be good to do so.
>
>

>>     [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 10:27:19 -0700

On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton <[email-masked]> wrote:

>> On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger < <[email-masked]>
>> [email-masked]> wrote:
>>
>>> Acee,
>>>

Filtering is not widely implemented or implemented correctly.

IMO it is up to the data model designers how they want to organize their
data.
I have not heard any valid reasons why a generalized solution is even
needed,
let alone why separate config and state needs to be avoided.

Andy

> Yes, I gave them below: I don't see that merging config and state prevents
> entities from only monitoring state if they wish.
>
> Thanks,
> Rob
>
>
>
>
>>
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Jul 2016 17:43:55 +0000

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 12, 2016 at 1:27 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]<mailto:[email-masked]>>
Cc: netmod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

On Tue, Jul 12, 2016 at 10:22 AM, Robert Wilton <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton <[email-masked]<mailto:[email-masked]>> wrote:

Hi Andy,

On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
Acee,

Thanks,

Lou
.....

I would really like to understand what problem (3) is supposed to solve.
My personal view is that I think that it makes the models simpler, with less duplication.

E.g. I also see that it makes it easier for a client to fetch all of the information associated with a particular feature in a single sub tree rather that needing to merge data from two separate config & state sub trees.

This is your opinion.
I think separate makes it easier to read, especially if the monitoring data
is relevant regardless of how associated configuration was done.
This is easily achievable by filtering (e.g. only return config false leaves + config true structural nodes).

IMO it is up to the data model designers how they want to organize their data.
I have not heard any valid reasons why a generalized solution is even needed,
let alone why separate config and state needs to be avoided.

There is definitely value in having model conventions. One argument for collapsing the config and state is that once you have the implicit retrieval of the applied state, there is much less operational state that isn’t redundant.

There is also requirement #4 in https://www.ietf.org/id/draft-ietf-netmod-opstate-reqs-04.txt. However, I know you’ve never been a fan of this document.

Thanks,
Acee

Andy

Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary configuration mechanisms.
(e.g., the way the SNMP world has worked for 30 years)
I thought that it was config that was originally driving YANG because there is already a solution for state data (SNMP).  Hence, I would have thought that the most common case would be that YANG is used just for config, or config & state.  So, I think that it makes sense to optimize models for these scenarios.

This is marketing.
Do you have any technical arguments?
Yes, I gave them below: I don't see that merging config and state prevents entities from only monitoring state if they wish.

Thanks,
Rob

If you forbid separate monitoring subtrees and force the data to be co-located
with configuration, that means the standard monitoring will not be supported
unless the standard configuration is also supported.
Both datastore draft solutions allow for system created config entries.  So in both drafts the operational state datastore can instantiate whatever config nodes are necessary to parent config false state nodes.

I also don't think that separate monitoring subtrees are going to be banned, they should be used where appropriate.  It is just that it will be no longer be required to have separate state subtrees purely because of potential differences in the lifetime of config vs state objects (e.g. interfaces vs interfaces-state).

I would be very happy if "interfaces" and "interfaces-state" could be merged into "interfaces" as a new/updated interfaces YANG model that draft models could be updated to use.  I understand that would be a impactful change to make (but seemingly mostly on IETF models that haven't yet been standardized).  But I hope that we are going to have to live with the YANG model structure for a long time, and if we still have an opportunity to "fix" a fairly big wart then I think that it would be good to do so.

I can't say if the pre-provisioning model in ietf-interfaces should be generalized.
I have not seen any good general solutions for combining config and state.

Rob

Andy

  Why is that progress?

Andy

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 11:36:03 -0700

On Tue, Jul 12, 2016 at 10:43 AM, Acee Lindem (acee) <[email-masked]> wrote:

>
>
> From: netmod <[email-masked]> on behalf of Andy Bierman <
> [email-masked]>
> To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <
> [email-masked]>
> Cc: netmod WG <[email-masked]>
> There is definitely value in having model conventions. One argument for
> collapsing the config and state is that once you have the implicit
> retrieval of the applied state, there is much less operational state that
> isn’t redundant.
>
>
Yes there is value in modeling conventions in general.
I am trying to understand the value of this specific convention.

If I have an RPC that asks for applied state, then it doesn't really matter
how the config and state is organized.  There is only overlap in the objects
if the data model is designed that way.

Whether or not an edit is applied yet is a property of the implementation,
not the data model.

There is also requirement #4 in
> https://www.ietf.org/id/draft-ietf-netmod-opstate-reqs-04.txt. However, I
> know you’ve never been a fan of this document.
>
> Thanks,
> Acee
>
>
>
>
>
Andy

---

From: Lou Berger <[email-masked]>
Date: Tue, 12 Jul 2016 14:53:26 -0400

Andy,

    This may be a bit OBE by the conversation on the list, but see below...

> I would really like to understand what problem (3) is supposed to solve.

    The config/state split discussed in the context of opstate, and the
openconfig draft in particular, reflects two different types of separations:

1) configuration vs operational information (e.g., intf parameter vs
counters)

2) intended vs applied configuration

My earlier comment about assuming that we're getting rid of -config and
-state (as part f the decision to move to revised datastores) was really
focused on the second.

> Most of the foo-state variables are for monitoring.

I really wasn't commenting on conventions WRT configuration data and
operational parameters relationship/organization -- although I think
having a general convention for these is "a good idea".

> unless the standard configuration is also supported.  Why is that

Again, I was focusing on the intended vs applied aspects here.  I can
see reasons to keep a top level spit for config vs operational state,
but alos don't have a strong personal bias on this.

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jul 2016 21:07:11 +0200

> Whether or not an edit is applied yet is a property of the implementation,

The current /foo and /foo-state approach requires some amount of
duplication. If the trees contain some nested lists of lists, you have
to at least replicate all the key leafs in the schema definition. For
a small model, this is not a bit deal; for more complex models, this
becomes complex and there are possible sources of errors. If it is
possible to simply data models, this may be a long-term win.

The reason why we have the /foo and /foo-state convention is, I
believe, the design of the NETCONF <get/> operation, which assumes
state and config can be represented together in a single tree. And we
have carried this further into YANG (e.g., the way contexts are
constructed for xpath expressions). In hindsight, I am not sure the
consequences of the <get/> design were that well thought through - but
I am not complaining, at that time we did not have YANG nor did we
have experience with bigger data models written in YANG. Is it worth
fixing it? This is a tough question and I understand that people have
different opinions and also different views on where we are on the
lifecycle of this technology. The challenge, as always, is to evolve a
technology along with its usage and upcoming new requirements. If the
evolution is too fast, you risk fragmentation since people will then
run many different versions. If evolution is too slow or stops
entirely, you pave the way for complete replacements of the
technology.

I think it is worth to step back for a moment and to think about where
we like to be in 5 or 10 years from now when we discuss architectural
questions.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 12:15:31 -0700

> possible to simply data models, this may be a long-term win.

It only requires duplication if you insist on modeling opstate objects.
IMO an RPC + notification approach is far superior.
In this approach I only need to identify the intended config object
and retrieve (or be notified) of the applied-state transition.

> we like to be in 5 or 10 years from now when we discuss architectural

We have read-only foo-state because we have only been standardizing
monitoring data for the last 30 years.  I completely agree that if the
state depends
on the config in order for an instance to exist, then co-locate the config
and
state and share the node naming.

But modeling admin-state and oper-state with the same object is not a
requirement.
Being able to determine if the intended config is applied yet is a
requirement.
This can be done with protocol operations so it is 100% data model neutral.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jul 2016 16:44:59 -0700

> entirely, you pave the way for complete replacements of the

I think the foo-state convention comes from the fact that 99% of the NM
standards
have been read-only until now.  It is often desirable to index the
monitoring
tables differently than the configuration, even for opstate values.
The data structures for counters may mirror the hardware, which
may not be how the service configuration is indexed.

The premise all those years (still valid today) is that standard monitoring
makes it easier for application developers to write monitoring applications.
Configuration was left to the proprietary CLI.

It would be a mistake to lose standard monitoring unless and until
the standard configuration was finished and implemented.
This would be an unintended side effect of moving all monitoring under
the configuration subtree for a feature.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Wed, 13 Jul 2016 10:38:50 +0100

> we like to be in 5 or 10 years from now when we discuss architectural
RW:

This makes sense, if we can do it in parallel to making progress on the 
opstate discussions.  In particular, I think that IETF needs to very 
quickly resolve any open issues that are preventing WGs from publishing 
standard YANG models (e.g. the config/state split). Delaying this risks 
making the IETF YANG models some what obsolete (at least in some parts 
of the market) before they are published.

Not necessarily directly related, but my understanding is that the way 
that some of the OpenConfig operators are intending to configure and 
manage networks is quite different from how networks have been 
historically managed.  I think that writing up this architecture as an 
Information draft would likely benefit individuals who are trying to 
understand the proposed changes to NETCONF/YANG and what those changes 
are trying to achieve.

Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 13 Jul 2016 10:43:47 +0100

Please see RW: inline

On 12/07/2016 20:15, Andy Bierman wrote:
>
>
> On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
RW:

Are you thinking of a single global notification of convergence?

Although such a scheme may be sufficient if the configuration is 
changing infrequently, it is not sufficient for a system in which 
configuration is changing frequently (e.g. say to provision very short 
lived tunnels across a data center network).

If the client is interested when a particular config change has 
converged then a global converged flag:
  (i) may be delayed a long time (if at all) after the config change has 
completed (because other subsequent config operations are in progress)
  (ii) may be hard to relate back to the original config change

Hence, I think that there are only 2 technical solutions to this problem:
(a) reporting/notifying the state of the applied configuration nodes (as 
per the requirements stated in draft-ietf-netmod-opstate-reqs, and 
covered by the all the various solution drafts)
(b) report the success/failure of the particular config operation.

My opinion, is that as network configuration becomes more dynamic, and 
programmatically controlled then (a) is the easier solution and more 
robust to failure over (b).  But both approaches can be supported by 
devices.

RW:

This is only part of the solution, since metadata can only be used when 
nodes exist in the YANG data tree.  So, this method alone cannot 
indicate configuration that is applied by the device and is in the 
process of being deleted.

That is primarily why draft-wilton-netconf-opstate-metadata-00 offers 
metadata both on the "persistent" datastore and "operational state 
datastore".

> on the config in order for an instance to exist, then co-locate the 
> config and
RW:

I agree, but when the oper-state exactly of a node reflects the applied 
admin-state then I see no benefit in having a separate duplicate "config 
false" node.

Rob

---

From: Alex Campbell <[email-masked]>
Date: Wed, 13 Jul 2016 09:49:48 +0000

Isn't that exactly what the proposed applied configuration datastore is for?
If a device doesn't allow management stations to create or remove list entries, but still creates or removes list entries itself, then it can publish them through the applied configuration datastore, while leaving the intended configuration datastore empty.  Operational data can be contained inside those list entries which exist in the applied configuration store, instead of needing a separate tree to contain it.

- Alex

________________________________
From: netmod <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Sent: Wednesday, 13 July 2016 4:17 a.m.
To: Lou Berger
Cc: netmod WG
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Thanks,

Lou
.....

Andy

---

From: Robert Wilton <[email-masked]>
Date: Wed, 13 Jul 2016 11:04:53 +0100

Hi Alex,

What you describe is close, but not quite what either of the two 
datastore solutions are proposing.

In this case, the two solutions in both proposed drafts would contain:
   - intended config doesn't contain the list entries
   - applied config doesn't contain the list entries
   - operational state datastore contains the system created (config 
true) list entries + descendant config false nodes.

The reason why these system created entries are not in the applied 
configuration is because of the requirement from 
draft-ietf-netmod-opstate-reqs state that "intended config" = "applied 
config" if the system has converged and all configuration has been 
successfully applied.

But, yes, the reason for allowing system created config true entries in 
the operational state datastore is to solve this problem.

Rob

On 13/07/2016 10:49, Alex Campbell wrote:
> If a device doesn't allow management stations to create or remove list 
> entries, but still creates or removes list entries itself, then it can 
> publish them through the applied configuration datastore, while 
> leaving the intended configuration datastore empty.  Operational data 
> can be contained inside those list entries which exist in the applied 
> configuration store, instead of needing a separate tree to contain it.
>
> - Alex
>
>
>
>
> ------------------------------------------------------------------------
> *From:* netmod <[email-masked]> on behalf of Andy Bierman 
> <[email-masked]>
> *Sent:* Wednesday, 13 July 2016 4:17 a.m.
> *To:* Lou Berger
> *Cc:* netmod WG
> *Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF 
> YANG Model Structure
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jul 2016 09:27:11 -0700

On Wed, Jul 13, 2016 at 3:04 AM, Robert Wilton <[email-masked]> wrote:

> Hi Alex,
>
>
> What you describe is close, but not quite what either of the two datastore
> solutions are proposing.
>
>   - operational state datastore contains the system created (config true)
> list entries + descendant config false nodes.
>

I do not agree with Alex that config=true can mean "no client can ever set
this value".
It can only if NACM is configured to disable client write access.
I understand how one might want to use server-created values in validation
rules
but YANG does not support that right now (for config=false).

The line between server-created config and operational state is confusing
at best.

Rob

Andy

> publish them through the applied configuration datastore, while leaving the
> intended configuration datastore empty.  Operational data can be contained
> inside those list entries which exist in the applied configuration store,
> instead of needing a separate tree to contain it.
>
> - Alex
>
>
>
>
> ------------------------------
> *From:* netmod <[email-masked]> <[email-masked]> on
> behalf of Andy Bierman <[email-masked]> <[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 13 Jul 2016 18:12:38 +0100

On 13/07/2016 17:27, Andy Bierman wrote:
>
>
> On Wed, Jul 13, 2016 at 3:04 AM, Robert Wilton <[email-masked] 
>       - operational state datastore contains the system created
>     (config true) list entries + descendant config false nodes.
>
>     draft-ietf-netmod-opstate-reqs state that "intended config" =
>     "applied config" if the system has converged and all configuration
>     has been successfully applied.
>
>     But, yes, the reason for allowing system created config true
>     entries in the operational state datastore is to solve this problem.
>
>
>
>
> I do not agree with Alex that config=true can mean "no client can ever 
> set this value".
RW:
I agree with you, but I didn't read Alex's email as stating that.

Instead, I read it as: even if a device doesn't allow the nodes to be 
configured then they could still be populated by the device in the 
applied configuration datastore.

> I understand how one might want to use server-created values in 
> validation rules
> The line between server-created config and operational state is 
> confusing at best.
RW:

Yes, OK.  That is perhaps because they are not completely related.

The original OpenConfig opstate draft also asked for a solution to what 
they perceived as an unnecessary split between "feature" vs "feature-state".

When discussing the datastore solutions it became clear that having a 
formal definition of an "operational state datastore" also allowed for a 
solution to the problem above.  Specifically by allowing the operational 
state datastore to contain any necessary config true leaves (even if 
they have not been configured) that are required to hold any descendant 
config false leaves.

To cite an example:

If the schema content of if:interfaces-state was merged into the schema 
for if:interfaces then the "operational state datastore" of a device 
would be allowed to contain entries in the if:interfaces list for 
interfaces that exist in the system but have not been configured.

As a side note, the metadata draft that I've put forward then suggests 
to use metadata annotations of these system created entries in the 
"operational state datastore" to allow clients to distinguish between 
config true entries that exist because they are applied configuration, 
vs config true entries that exist because they are system created.

Rob

>>     If a device doesn't allow management stations to create or remove
>>     list entries, but still creates or removes list entries itself,
>>     then it can publish them through the applied configuration
>>     datastore, while leaving the intended configuration datastore
>>     empty. Operational data can be contained inside those list
>>     entries which exist in the applied configuration store, instead
>>     of needing a separate tree to contain it.
>>
>>     - Alex
>>
>>
>>
>>
>>     *From:* netmod <[email-masked]>
>>     <mailto:[email-masked]> on behalf of Andy Bierman
>>     <[email-masked]> <mailto:[email-masked]>
>>     *Subject:* Re: [netmod] OpsState Direction Impact on Recommended
>>     IETF YANG Model Structure
>>
>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jul 2016 12:10:41 -0700

On Wed, Jul 13, 2016 at 2:43 AM, Robert Wilton <[email-masked]> wrote:

> <[email-masked]>[email-masked]
> > wrote:
>

No

I think the client would request a notification for its edit.
There would be a long-form and short-form notification.

The interaction model is simple:
   A) at the time of the request the client opt-in for being notified
   B) the server will send the short form (all-ok) ASAP or even return the
short-form all-ok
        in the response and skip the notifications if possible
    C) if the timeout occurs, then the server sends the long-form
notification, which lists
         all the intended config operations not yet applied.  (This is
easier to do for YANG Patch
        where the edits are identified, than with <edit-config> that has an
unordered blob of XML).

Parameters would be added to the edit request:

    - want-notif:  (boolean: default false)
    - notif-timeout: how long the server should wait before sending the
long-form notification
    - trace-id:  string provided by the client similar to persist-id that
will identify this edit
       in the notifications

This approach does not deal with multi-client conflicts.
If client A does "create /foo" then the server ACKs that edit even if
client B
has started a subsequent "delete /foo" edit before the first edit was ACKed.

A separate RPC to retrieve the long-form notification for all pending edits
would
also be needed to allow for a notification to be lost or a client to query
the entire
list of unapplied edits.

Andy

> Although such a scheme may be sufficient if the configuration is changing
> infrequently, it is not sufficient for a system in which configuration is
> changing frequently (e.g. say to provision very short lived tunnels across
> a data center network).
>
> If the client is interested when a particular config change has converged
> then a global converged flag:
> per the requirements stated in draft-ietf-netmod-opstate-reqs, and covered
> by the all the various solution drafts)
> programmatically controlled then (a) is the easier solution and more robust
> to failure over (b).  But both approaches can be supported by devices.
>
>
> nodes exist in the YANG data tree.  So, this method alone cannot indicate
> configuration that is applied by the device and is in the process of being
> deleted.
>
>> Fax:   +49 421 200 3103         < <http://www.jacobs-university.de/>
>> http://www.jacobs-university.de/>
>>
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 13 Jul 2016 22:17:25 +0000

>   A) at the time of the request the client opt-in for being notified

opstate-reqs refers to this as an asynchronous configuration operation.  Requirement 2-B says:

           Servers that support asynchronous configuration operations
           MUST provide a mechanism to notify the client when a request
           has completed processing.  The notification MUST indicate
           whether the intended config is now fully applied or if there
           were any errors from applying the configuration change.

I don’t see a need for long/short forms or timeouts here.  Are you suggesting a need to change how the requirements are worded?

Kent

>   B) the server will send the short form (all-ok) ASAP or even return the short-form all-ok
>    C) if the timeout occurs, then the server sends the long-form notification, which lists
>         all the intended config operations not yet applied.  (This is easier to do for YANG Patch
>        where the edits are identified, than with <edit-config> that has an unordered blob of XML).
>
>
>    - notif-timeout: how long the server should wait before sending the long-form notification
>    - trace-id:  string provided by the client similar to persist-id that will identify this edit
>       in the notifications
>
>
> If client A does "create /foo" then the server ACKs that edit even if client B
> A separate RPC to retrieve the long-form notification for all pending edits would
> also be needed to allow for a notification to be lost or a client to query the entire
> list of unapplied edits.
>
> Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jul 2016 15:22:40 -0700

On Wed, Jul 13, 2016 at 3:17 PM, Kent Watsen <[email-masked]> wrote:

> I don’t see a need for long/short forms or timeouts here.  Are you
> suggesting a need to change how the requirements are worded?
>
>
>

I am just suggesting how I would design this feature.
I certainly don't want to read any more requirements drafts, so implement
whatever you want.

The short-form is really just the long-form with an empty list of unapplied
edits.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Jul 2016 20:00:44 +0000

[This thread took on a life of its own, so I’m replying to this email from two days ago]

I had assumed the plan/recommendation would be:
  - for works-in-progress, to evaluate if their models can be improved.
  - for existing RFCs, do nothing (though we may want to consider RFC7223).

By “if their models can be improved” in the above, I’m implying that having a top-level -state branch may still be the best solution for some models.  It’s up to each model designer to decide the best approach for their models.

Makes sense?

Kent  // as a contributor

On 7/12/16, 11:23 AM, "netmod on behalf of Lou Berger" <[email-masked] on behalf of [email-masked]> wrote:

Acee,

Thanks,

Lou

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Jul 2016 14:16:38 +0000

On 7/14/16, 4:00 PM, "Kent Watsen" <[email-masked]> wrote:

>By “if their models can be improved” in the above, I’m implying that
>having a top-level -state branch may still be the best solution for some
>models.  It’s up to each model designer to decide the best approach for
>their models.
>
>Makes sense?

I think the statement “if their models can be improved” leaves too much
subjectivity in the guideline. Either we are going to avail the revised
data store model to avoid duplication of YANG schema nodes or we are going
to leverage the new data stores solely to meet the intended/applied config
requirement. If it is the latter and a good portion of the network devices
will not support, then I would agree.

>
>Kent  // as a contributor
>
>
>On 7/12/16, 11:23 AM, "netmod on behalf of Lou Berger"

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Jul 2016 15:23:20 +0100

> will not support, then I would agree.
Devices can still leverage the new operational state datastore (and 
hence allow foo and foo-state to be merged) without having to supporting 
an intended/applied configuration split (i.e. they just treat applied = 
intended).

I'm keen to get the models simpler were possible because I think that 
will help with their longevity and ease of use.

Thanks,
Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 15 Jul 2016 16:48:58 +0000

On 7/15/16, 10:23 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at

>an intended/applied configuration split (i.e. they just treat applied =

Right - but then the applied configuration wouldn’t be available for the
cases where it does differ from intended configuration.

>will help with their longevity and ease of use.

For the record, I agree. However, reaching consensus will be difficult.

Thanks,
Acee

---

From: thomas nadeau <[email-masked]>
Date: Fri, 15 Jul 2016 20:08:23 +0100

> On Jul 15, 2016, at 5:48 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

Indeed. There are enough people wanting to do this both ways that it will be difficult at best.

tom

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jul 2016 18:39:29 +0200

Hi,

So after the various meetings and discussions this week, I think that 
the most important thing for IETF to do is to publish reviewed YANG 
models quickly, with the understanding that it is better to publish 
imperfect models than to end up not publishing any models at all.  This 
is with the understanding that these models could be fixed by subsequent 
RFCs if required.

So, I effectively support Acee's solution (2).  But to state this more 
precisely, I would suggest that the specific guidance should be:
1) IETF Models MUST NOT have a split for applied configuration leaves.  
All IETF models that have not been turned into RFCs must be modified to 
remove any applied configuration nodes.  Any models that have this 
convention in RFCs should be revised to follow a consistent 
intended/applied convention for IETF models.  [The justification here is 
that IETF standard models have to be able to assume that the applied 
configuration will be available via a separate applied configuration (or 
operational state) datastore or equivalent mechanism.]
2) All IETF Models MUST put "derived state and statistics" into a 
separate namespace from the configuration (i.e. top level "feature" and 
"feature-state").  The two trees must be as structurally similar as 
possible, sharing the same paths, node names (except the top level 
node), using the same lists keys where appropriate, etc.*
3) Both of these rules should be written into rfc6087bis.  We should 
then get this guidelines document finished as quickly as possible at the 
highest priority, and use that as the definitive guideline for the 
modules that the working groups are working on.

* Note, I chose this option not because I think that it is elegant 
(because I don't) but because it seems to me that it is the only 
pragmatically option that we have available.  The alternatives appear to 
be: (i) we wait another year before publishing any models (if ever), or 
(ii) we publish models that no-one can use today without violating the 
existing RFCs, or (iii) we end up with a hybrid mess without any 
consistency.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jul 2016 19:17:11 +0200

[Re-titled thread for a separate applied config observation, and to 
avoid derailing the intend of the original thread]

If the conclusion below reaches consensus, and all models have both 
"feature" and "feature-state" trees (as required), then I wonder whether 
it wouldn't also make sense to represent applied configuration on the 
path "feature-applied" as a direct duplication of the schema for the 
config nodes that live under "feature".  I.e. I specifically *don't* 
mean writing this into the schema by hand, but just have systems 
(clients and servers) that support applied configuration instantiate a 
copy of all of the config schema nodes on to the "feature-applied" path.

This would arguably be more in keeping with separate "feature" and 
"feature-state" trees, and also wouldn't require clients to manage 
separate trees for each datastore.  It also means that the 
intended/applied/and derived state all have independent, but 
mechanically relate-able, paths.

Rob

On 21/07/2016 18:39, Robert Wilton wrote:
> imperfect models than to end up not publishing any models at all.  
> This is with the understanding that these models could be fixed by 
> subsequent RFCs if required.
>
> 1) IETF Models MUST NOT have a split for applied configuration 
> leaves.  All IETF models that have not been turned into RFCs must be 
> modified to remove any applied configuration nodes.  Any models that 
> have this convention in RFCs should be revised to follow a consistent 
> intended/applied convention for IETF models.  [The justification here 
> is that IETF standard models have to be able to assume that the 
> applied configuration will be available via a separate applied 
> configuration (or operational state) datastore or equivalent mechanism.]
> separate namespace from the configuration (i.e. top level "feature" 
> and "feature-state").  The two trees must be as structurally similar 
> as possible, sharing the same paths, node names (except the top level 
> then get this guidelines document finished as quickly as possible at 
> the highest priority, and use that as the definitive guideline for the 
> pragmatically option that we have available.  The alternatives appear 
> to be: (i) we wait another year before publishing any models (if 
> ever), or (ii) we publish models that no-one can use today without 
> violating the existing RFCs, or (iii) we end up with a hybrid mess 
> without any consistency.
>
> Thanks,
> Rob
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2016 19:40:33 +0200

On Thu, Jul 21, 2016 at 06:39:29PM +0200, Robert Wilton wrote:
> Hi,
> 
> So after the various meetings and discussions this week, I think that the
> most important thing for IETF to do is to publish reviewed YANG models
> quickly, with the understanding that it is better to publish imperfect
> models than to end up not publishing any models at all.  This is with the
> understanding that these models could be fixed by subsequent RFCs if
> required.
> 
> 1) IETF Models MUST NOT have a split for applied configuration leaves.  All
> IETF models that have not been turned into RFCs must be modified to remove
> any applied configuration nodes.  Any models that have this convention in
> RFCs should be revised to follow a consistent intended/applied convention
> for IETF models.  [The justification here is that IETF standard models have
> to be able to assume that the applied configuration will be available via a
> separate applied configuration (or operational state) datastore or
> equivalent mechanism.]

Are there any published models that have "applied configuration
nodes"?  What is actually an "applied configuration node"? Perhaps an
example helps: Are you trying to suggest that

  /if:interfaces-state/if:interface/ipv4/address/ip

is now made illegal and we have right now no way to represent
operationally used IP addresses? That sounds somewhat broken to me.

> 2) All IETF Models MUST put "derived state and statistics" into a separate
> namespace from the configuration (i.e. top level "feature" and
> possible, sharing the same paths, node names (except the top level node),
> using the same lists keys where appropriate, etc.*

Not sure what exactly drived state is. And even then, why MUST derived
state and statistics be in a separate tree? And can we please avoid
'feature' and 'feature-state' since YANG uses the term 'feature' in a
very different sense.

> 3) Both of these rules should be written into rfc6087bis.  We should then
> get this guidelines document finished as quickly as possible at the highest
> priority, and use that as the definitive guideline for the modules that the
> working groups are working on.
> 
> * Note, I chose this option not because I think that it is elegant (because
> I don't) but because it seems to me that it is the only pragmatically option
> that we have available.  The alternatives appear to be: (i) we wait another
> year before publishing any models (if ever), or (ii) we publish models that
> no-one can use today without violating the existing RFCs, or (iii) we end up
> with a hybrid mess without any consistency.

I do not see how the proposed rules achieve the goals you stated. Again,
examples may help:

  /if:interfaces-state/if:interface/ipv4/address/ip

This can be implemented today. It may not be necessary anymore some
time in the future if we have a revised datastore model plus matching
solutions. The upgrade path from this is, however, extremly simple:
We change the status of the definition of this object to deprecated.

Bottom line: I think we should continue to follow the model used by
the ietf-interfaces model and the ietf-ip model until we have a better
solution in place (and subsequently we can deprecate objects that
became redundant).

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 22 Jul 2016 09:59:20 +0200

On 21/07/2016 19:40, Juergen Schoenwaelder wrote:
> nodes"?
I'm not 100% sure.  I thought that there was a BGP model that was about 
to be published as an RFC standard that contains intended vs applied 
configuration split.  Possibly draft-ietf-idr-bgp-model-02.

>   What is actually an "applied configuration node"?
A config false node written in the schema with the sole purpose of 
indicating whether of not the configuration has been applied on the device.

For example, looking at the "bgp-common-neighbor-group-timers-config" 
grouping in draft-ietf-idr-bgp-model-02, then the uses statement 
instantiates it twice for the BGP peer group timers, once under a 
"config" (config true) container to hold the configuration, and also 
under "state" (config false) to solely represent whether the 
configuration has been applied.

>   Perhaps an
No, I'm not suggesting that.  I don't see that node as specifically only 
indicating whether the IP address configuration is applied, but instead 
represents the actual IP address in use by the system.

> Not sure what exactly drived state is.
 From draft-ietf-netmod-opstate-reqs-04:

    Derived State:  This data represents information which is generated
        as part of the server's own interactions.  For example, derived
        state may consist of the results of protocol interactions (the
        negotiated duplex state of an Ethernet link), statistics (such as
        message queue depth), or counters (such as packet input or output
        bytes).

But in essence, I mean all config false nodes that are not "applied 
configuration nodes" (as per my example above).

>   And even then, why MUST derived
> state and statistics be in a separate tree?
My aim is to make the structure of the models consistent and 
predictable, with the specific aim of making it easier for tooling. If 
some IETF models are going to split configuration and state into 
separate trees (e.g. RFC 7723), then I'm suggesting that all IETF 
modules must have same structure.

>   And can we please avoid
Yes, OK.

> This can be implemented today.

>   It may not be necessary anymore some
Potentially true.  But in the future, if we try to combine "foo-state" 
into "foo" for all IETF models then that would mean updating every 
published IETF YANG model.  Is that realistic?  I don't think that just 
changing some modules makes sense, neither does having two ways to do 
this.  I would rather have a single consistent approach that applied to 
all IETF (and hopefully other SDO) models.

> solution in place (and subsequently we can deprecate objects that
This is pretty much what I'm trying to say as well, but in a stronger 
way.  I.e. mandating that all IETF YANG models MUST follow this 
structure, and split config and state into two top level trees.

Rob

---

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Jul 2016 20:03:41 +0000

>> Juergen writes:
> Rob writes:

I agree that a revised datastore model plus matching solutions can
eliminate the need for the interfaces-state convention.  But this would
only apply to client/servers that have been updated to grok the new
approach - right?  If these nodes are subsequently deprecated, or new
modules are created assuming the new approach from the get go, are
we leaving the legacy client/servers behind with no way to get, for
instance, the operational status for system-created interfaces?

It seems that we need to make a hard cutover sooner or later...

Kent  // as a contributor

---

From: Robert Wilton <[email-masked]>
Date: Tue, 26 Jul 2016 16:52:57 +0100

On 25/07/2016 21:03, Kent Watsen wrote:
> approach - right?
RW: Yes.

>   If these nodes are subsequently deprecated, or new
>
RW: Yes.

When chatting to Chris Hopps, we had come to conclusion that this may 
not pragmatically matter, but it would still be a violation of the RFCs ...

So my thinking is that if we can't merge "foo-state" into "foo" then 
instead we should have consistent rules that explicitly state that for 
all IETF models "foo" and "foo-state" are separate trees with a 
consistent naming convention and structure.  That should hopefully allow 
tooling to programmatically relate the two separate trees together.  It 
may give a path to allow "foo-state" to be merged into "foo" in future, 
but once IETF has standardized 600+ models with separate sub-trees, I 
cannot see that they would get merged back together again.

What other alternatives are available?  As a WG we need to tell the 
other WGs how the IETF YANG models should be structured.

In short, unfortunately I think that we have probably already missed the 
opportunity to merge "foo" and "foo-state" subtrees together ...

Rob

---

From: Rob Shakir <[email-masked]>
Date: Tue, 26 Jul 2016 10:43:40 -0600

> On 26 Jul, 2016, at 9:52 AM, Robert Wilton <[email-masked]> wrote:
> 
> What other alternatives are available?  As a WG we need to tell the other WGs how the IETF YANG models should be structured.

An interested observer could note that the convention that was described in the initial OpenConfig proposal had objections to it based on the fact that it required models to be written in a certain way. Although this way is prescriptive, and could be observed to cause some pain to the model writer (albeit limited), it has a number of advantages in terms of being very deterministic as to how the model should be structured, allowing leaves to be easily related to each other, and can be programmatically verified.

It seems to me like the working group is trying to have its cake and eat it — that is to say, get these advantages without being prescriptive to the model writer. It is not clear to me that this is actually achievable.

r, An Interested Observer.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Jul 2016 20:36:33 +0000

<Rob Wilton writes>

So my thinking is that if we can't merge "foo-state" into "foo" then instead we should have consistent rules that explicitly state that for all IETF models "foo" and "foo-state" are separate trees with a consistent naming convention and structure.  That should hopefully allow tooling to programmatically relate the two separate trees together.  It may give a path to allow "foo-state" to be merged into "foo" in future, but once IETF has standardized 600+ models with separate sub-trees, I cannot see that they would get merged back together again.

In short, unfortunately I think that we have probably already missed the opportunity to merge "foo" and "foo-state" subtrees together ...

</Rob Wilton>

Firstly, I’m trying to get a sense of how big a problem this foo/foo-state thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].   I know about RFC 7223, which was done out of consideration for system-generated interfaces, but how many other such models are there envisioned to be?  Is this issue currently blocking models from progressing, or are we getting ourselves wrapped around a hypothetical?  If RFC 7223 is an outlier, then we can address it as a special case (perhaps via the related-state/related-config YANG annotations).  What do you think?

Next, regarding paths forward (assuming 7223 is not an outlier), I’m thinking the opposite.  I’m quite sure that we would never merge the 600+ models with separate subtrees back together again.  So I’m thinking we immediately merge foo and foo-state in all active YANG models (so that the YANG “conceptual” models are stable and good) *and* then we use your idea to programmatically generate the “foo-state” tree, presumably only when needed.  This foo-state tree could be generated offline by tools and provided as a second YANG module in drafts.  In this way, servers (opstate aware or not) can advertise if clients can access the foo-state tree (an opstate-aware server may still advertise it for business reasons, and it can ‘deprecate’ the tree when no longer needed).   We could do the same without tools today by just using a feature statement on, for instance, the interfaces-state container, but I like pushing for tooling upfront so that we’re guaranteed mergeability later.  Thoughts?

Kent // as a contributor

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 Jul 2016 21:37:45 +0000

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 26, 2016 at 10:36 PM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]<mailto:[email-masked]>>, netmod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

<Rob Wilton writes>

</Rob Wilton>

There are a number of issues here. The first is that you are now depending on the separate applied state data store being implemented on every network device if you are going to eliminate the duplication of actual values in the OpState. The second is that OpsState is MUCH more than just counters. For example, for routing protocols will many times include a local RIB. The third is that it is a big change for these draft models and, if you have been following the discussion on the list, you should know that this option is not universally accepted (reference the E-mail thread I started with options before IETF 96).

Acee

Kent // as a contributor

---

From: Kent Watsen <[email-masked]>
Date: Tue, 26 Jul 2016 22:19:36 +0000

<Acee>
</Acee>

But I specifically called out that I was only talking about counters (e.g., 7223) and not applied config.   For applied config, I think that we’ll wait for the opstate solution, per decision ‘B’.

Regardless, let’s not lose focus on my first question about how prevalent an issue this is.  If 7223 is a singularity, then we should stop worrying about this as a general problem.  I’d like to understand how big this box is before jumping into it.

We’ve had config false leafs mixed in config true trees forever.  Only when there are system-generated values or values whose lifetimes extend past the lifetime of the config true object is there an issue.   This isn’t a new thing, nor an applied config thing, but it can be nicely solved by the opstate solution.  The only question is what we do in the interim.

Kent  // as a contributor

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 Jul 2016 22:24:44 +0000

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 27, 2016 at 12:19 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]<mailto:[email-masked]>>, netmod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

<Acee>

Why would we consider handling counters differently from other operational state that is not part of applied config???

Acee

Kent  // as a contributor

---

From: Robert Wilton <[email-masked]>
Date: Wed, 27 Jul 2016 18:05:00 +0100

On 26/07/2016 21:36, Kent Watsen wrote:
> consistent naming convention and structure.  That should hopefully 
> allow tooling to programmatically relate the two separate trees 
> together.  It may give a path to allow "foo-state" to be merged into 
> "foo" in future, but once IETF has standardized 600+ models with 
> separate sub-trees, I cannot see that they would get merged back 
> together again.
>
> In short, unfortunately I think that we have probably already missed 
> the opportunity to merge "foo" and "foo-state" subtrees together ...
>
> </Rob Wilton>
>
> Firstly, I’m trying to get a sense of how big a problem this 
> foo/foo-state thing is.  [Note: by foo-state, I’m only referring to 
> counters, not opstate].
>
RW:
By counters, I think that we also mean any config false nodes that don't 
directly represent "applied configuration", right?  E.g. is an interface 
operationally up or down.

>    I know about RFC 7223, which was done out of consideration for 
> system-generated interfaces, but how many other such models are there 
> envisioned to be?
>
RW:
- Any models that augment RFC 7223 and have config false nodes will be 
impacted.
- I thought that quite a lot of other IETF models that are in the 
process of being standardized have a top level split between "foo" and 
"foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has 
this split.  I suspect that all the routing models will be structured 
similarly.
- Although it is perhaps worth pointing out that I think that the 
OpenConfig modules effectively have exactly this same issue (e.g. they 
have a combined interfaces tree keyed by config true leaves), and they 
pragmatically just ignore the issue of system created interface entries.

>  Is this issue currently blocking models from progressing, or are we 
> getting ourselves wrapped around a hypothetical?
>
RW:
I think that it is blocking models from progressing.

The current guidance for "intended vs applied" is clear.  I.e. there 
must not be "config false" leaves in the IETF YANG data models to 
represent "applied config".

But there is no clear guidance for the rest of operational state that 
isn't applied config.  The other WGs need clear guidance (effectively 
now) to ensure that they can start publishing models as RFCs.

>   If RFC 7223 is an outlier, then we can address it as a special case 
> (perhaps via the related-state/related-config YANG annotations).  What 
> do you think?
>
RW:
Personally, I would like one common convention that applies to all IETF 
YANG models.

Idealistically I would like foo and foo-state to be merged because I 
think that will make the models easier to use and maintain in the long 
term, but I don't know if we are just too late to go in that direction.  
It seems to me that the NETMOD WG really should try to come to a 
decision quite quickly on this, but I don't know how to encourage that.  
A virtual interim on just this topic perhaps?

> Next, regarding paths forward (assuming 7223 is not an outlier), I’m 
> thinking the opposite.  I’m quite sure that we would never merge the 
> 600+ models with separate subtrees back together again.  So I’m 
> thinking we immediately merge foo and foo-state in all active YANG 
> models (so that the YANG “conceptual” models are stable and good) 
> *and* then we use your idea to programmatically generate the 
> “foo-state” tree, presumably only when needed.  This foo-state tree 
> could be generated offline by tools and provided as a second YANG 
> module in drafts.  In this way, servers (opstate aware or not) can 
> advertise if clients can access the foo-state tree (an opstate-aware 
> server may still advertise it for business reasons, and it can 
> ‘deprecate’ the tree when no longer needed).   We could do the same 
> without tools today by just using a feature statement on, for 
> instance, the interfaces-state container, but I like pushing for 
> tooling upfront so that we’re guaranteed mergeability later.  Thoughts?
>
RW:
So the generated "foo-state" tree would contain a copy of all config 
false nodes in the YANG schema and a "config false copy" of any config 
true nodes in the YANG schema that are required to provide parental 
structure for the descendant config false nodes.
- The Xpath expressions would also need to be adjusted, and possibly 
some of those might break (or need to be fixed by hand).
- Groupings might be a problem, but potentially they could be expanded.

Technically this solution might work, but is it possible to get everyone 
to agree that this is the right direction to go in before we spend time 
on this?

Thanks,
Rob

---

From: "Xufeng Liu" <[email-masked]>
Date: Wed, 27 Jul 2016 14:22:30 -0400

The assumption of “I suspect that all the routing models will be structured similarly” is not correct. Very few models in routing area structure this way.

Regards,

- Xufeng

From: netmod [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Wednesday, July 27, 2016 1:05 PM
To: Kent Watsen <[email-masked]>; netmod WG <[email-masked]>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

<Rob Wilton writes>

</Rob Wilton>

Firstly, I’m trying to get a sense of how big a problem this foo/foo-state thing is.  [Note: by foo-state, I’m only referring to counters, not opstate].

RW:
By counters, I think that we also mean any config false nodes that don't directly represent "applied configuration", right?  E.g. is an interface operationally up or down.

   I know about RFC 7223, which was done out of consideration for system-generated interfaces, but how many other such models are there envisioned to be?

RW:
- Any models that augment RFC 7223 and have config false nodes will be impacted.
- I thought that quite a lot of other IETF models that are in the process of being standardized have a top level split between "foo" and "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect that all the routing models will be structured similarly.
- Although it is perhaps worth pointing out that I think that the OpenConfig modules effectively have exactly this same issue (e.g. they have a combined interfaces tree keyed by config true leaves), and they pragmatically just ignore the issue of system created interface entries.

 Is this issue currently blocking models from progressing, or are we getting ourselves wrapped around a hypothetical?

RW:

The current guidance for "intended vs applied" is clear.  I.e. there must not be "config false" leaves in the IETF YANG data models to represent "applied config".

But there is no clear guidance for the rest of operational state that isn't applied config.  The other WGs need clear guidance (effectively now) to ensure that they can start publishing models as RFCs.

  If RFC 7223 is an outlier, then we can address it as a special case (perhaps via the related-state/related-config YANG annotations).  What do you think?

RW:
Personally, I would like one common convention that applies to all IETF YANG models.

Idealistically I would like foo and foo-state to be merged because I think that will make the models easier to use and maintain in the long term, but I don't know if we are just too late to go in that direction.  It seems to me that the NETMOD WG really should try to come to a decision quite quickly on this, but I don't know how to encourage that.  A virtual interim on just this topic perhaps?

RW:
So the generated "foo-state" tree would contain a copy of all config false nodes in the YANG schema and a "config false copy" of any config true nodes in the YANG schema that are required to provide parental structure for the descendant config false nodes.
- The Xpath expressions would also need to be adjusted, and possibly some of those might break (or need to be fixed by hand).
- Groupings might be a problem, but potentially they could be expanded.

Technically this solution might work, but is it possible to get everyone to agree that this is the right direction to go in before we spend time on this?

Thanks,
Rob

Kent // as a contributor

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 27 Jul 2016 12:07:35 -0700

Robert mentions IS-IS, and if I look at OSPF, I see a clear separation of rw and ro nodes. 

> On Jul 27, 2016, at 11:22 AM, Xufeng Liu <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 27 Jul 2016 19:44:59 +0000

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 27, 2016 at 9:07 PM
To: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Cc: netmod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Right - and this separation is based on the routing and routing-state split in the ietf-routing-cfg model. In general, ietf-routing-cfg specifies that all control plane protocol YANG models should adapt this structure. Anyone who thinks collapsing all the models one config/state tree is simply a matter of moving a few counters should taking a better look at the existing drafts. I outlined the options in the E-mail thread prior to IETF 96.  Now, with the context of IETF 96 behind us, I believe more NETMOD participants will understand the options. To review the options specified in the previous E-mail thread.

Prior to IETF 96, I don’t believe we had selected a direction. However, I believe we agreed on option #1 in order to allow the publication of these models within the next year. We’d still be able to avail the benefits of applied vs intended configuration on network devices supporting these data stores.

Thanks,
Acee

On Jul 27, 2016, at 11:22 AM, Xufeng Liu <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

- Xufeng

From: netmod [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Wednesday, July 27, 2016 1:05 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>; netmod WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

<Rob Wilton writes>

</Rob Wilton>

Thanks,
Rob

Kent // as a contributor

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 27 Jul 2016 20:48:02 +0100

Hi Xufeng,

OK, so perhaps there is even less consistency in the IETF models than I 
thought!

But actually what I am most interested in (from you and others reading 
the Netmod WG alias), is whether you have an opinion on which direction 
we should go.  Even hearing that you don't have an opinion at all is 
useful input :-)

Thanks,
Rob

On 27/07/2016 19:22, Xufeng Liu wrote:
>
> The assumption of “I suspect that all the routing models will be 
> structured similarly” is not correct. Very few models in routing area 
> structure this way.
>
> Regards,
>
> - Xufeng
>
> *From:*netmod [mailto:[email-masked]] *On Behalf Of *Robert 
> Wilton
> *Sent:* Wednesday, July 27, 2016 1:05 PM
> *To:* Kent Watsen <[email-masked]>; netmod WG <[email-masked]>
>     So my thinking is that if we can't merge "foo-state" into "foo"
>     then instead we should have consistent rules that explicitly state
>     that for all IETF models "foo" and "foo-state" are separate trees
>     with a consistent naming convention and structure.  That should
>     hopefully allow tooling to programmatically relate the two
>     separate trees together.  It may give a path to allow "foo-state"
>     to be merged into "foo" in future, but once IETF has standardized
>     600+ models with separate sub-trees, I cannot see that they would
>     get merged back together again.
>
>     What other alternatives are available?  As a WG we need to tell
>     the other WGs how the IETF YANG models should be structured.
>
>     In short, unfortunately I think that we have probably already
>     missed the opportunity to merge "foo" and "foo-state" subtrees
>     together ...
>
>
>     </Rob Wilton>
>
> By counters, I think that we also mean any config false nodes that 
> don't directly represent "applied configuration", right?  E.g. is an 
> interface operationally up or down.
>
>
>     system-generated interfaces, but how many other such models are
>     there envisioned to be?
>
> RW:
> "foo-state".  E.g the ISIS model (draft-ietf-isis-yang-isis-cfg-08) 
> has this split.  I suspect that all the routing models will be 
> structured similarly.
>      Is this issue currently blocking models from progressing, or are
>     we getting ourselves wrapped around a hypothetical?
>
> RW:
>       If RFC 7223 is an outlier, then we can address it as a special
>     case (perhaps via the related-state/related-config YANG
>     annotations).  What do you think?
>
> RW:
> term, but I don't know if we are just too late to go in that 
> direction.  It seems to me that the NETMOD WG really should try to 
> come to a decision quite quickly on this, but I don't know how to 
> encourage that.  A virtual interim on just this topic perhaps?
>
>
>     Next, regarding paths forward (assuming 7223 is not an outlier),
>     I’m thinking the opposite.  I’m quite sure that we would never
>     merge the 600+ models with separate subtrees back together again. 
>     So I’m thinking we immediately merge foo and foo-state in all
>     active YANG models (so that the YANG “conceptual” models are
>     stable and good) *and* then we use your idea to programmatically
>     generate the “foo-state” tree, presumably only when needed.  This
>     foo-state tree could be generated offline by tools and provided as
>     a second YANG module in drafts.  In this way, servers (opstate
>     aware or not) can advertise if clients can access the foo-state
>     tree (an opstate-aware server may still advertise it for business
>     reasons, and it can ‘deprecate’ the tree when no longer needed).  
>     We could do the same without tools today by just using a feature
>     statement on, for instance, the interfaces-state container, but I
>     like pushing for tooling upfront so that we’re guaranteed
>     mergeability later.  Thoughts?
>
> RW:
> Technically this solution might work, but is it possible to get 
> everyone to agree that this is the right direction to go in before we 
> spend time on this?
>
> Thanks,
> Rob
>
>
>
>     Kent // as a contributor
>
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 27 Jul 2016 20:09:25 +0000

>> foo/foo-state thing is.  [Note: by foo-state, I’m only referring
>> to counters, not opstate].

RW:

KW:  Yes, the term “counters” is a misnomer.  We are indeed talking about regular old config false nodes, whether they be used for counters, gauges, or whatever.   It is what the opstate-reqs draft refers to as derived state.

>> I know about RFC 7223, which was done out of consideration
>> for system-generated interfaces, but how many other such models
>> are there envisioned to be?

RW:

KW: I also notice that draft-ietf-netmod-routing-cfg does this and, to your point, you know the ietf-routing module is intended to be augmented by many other modules.  This issue is not easily isolated.

RW:
The current guidance for "intended vs applied" is clear.  I.e. there must not be "config false" leaves in the IETF YANG data models to represent "applied config".  But there is no clear guidance for the rest of operational state that isn't applied config.  The other WGs need clear guidance (effectively now) to ensure that they can start publishing models as RFCs.

KW: indeed.

RW:

KW: I was going to suggest the same - will discuss with Lou.

>> server may still advertise it for business reasons, and it can ‘deprecate’
>> the tree when no longer needed).   We could do the same without tools
>> today by just using a feature statement on, for instance, the interfaces-
>> state container, but I like pushing for tooling upfront so that we’re
>> guaranteed mergeability later.  Thoughts?

RW:

KW: all good points.

KW: it was just an idea.   I’m trying to strike a balance between having the YANG models we want, and what is possible today (while waiting for the opstate solution to roll out).

To flesh this idea out just a bit more, let’s say we have module “ietf-foo” as follows:

module ietf-foo {
  namespace “foo-namespace”;
  container foo {
    list bar {
      key a;
      leaf a {
        type string;
      }
      leaf b {
         type int8;
         config false;
      }
   }
  }
}

whereby it’s possible that the system may generate some bars as well.  To address this, the module is run through a TBD-tool to generate second module foo-state as follows:

module ietf-foo-state {
  namespace “foo-state-namespace”;
  container foo-state {
    list bar {
      config false;    <-- everything below is config false
      key a;
      leaf a {    <-- this config true node kept only because it’s the key
        type string;
      }
      leaf b {
         type int8;
         config false;
      }
   }
  }
}

Now, here are the choices:

1) an opstate-unaware server might only support “ietf-foo”, as it is deemed unnecessary to provide the operational state for system-generated bars.

2) an opstate-unaware server might support both “ietf-foo” and “ietf-foo-state” as follows:

       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <foo xmlns="foo-namespace"/>
         </filter>
       </get-config>

returns the derived state for just configured bars, while:

       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <foo-state xmlns="foo-state-namespace"/>
         </filter>
       </get-config>

returns the derived state for both configured and system-generated bars.

3) an opstate-aware server only support “ietf-foo”, as it is expected that the derived state for system-generated bars can be obtained another way (e.g., via the “operational” datastore).

4) an opstate-aware server supports both “ietf-foo” and “ietf-foo-state”, most likely for backwards compatibility reasons.   The examples provided under (2) above continue to work and, later in time, the vendor can deprecate support for ietf-foo-state.

Kent  // as a contributor

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Jul 2016 13:29:33 -0700

Hi,

*Re: - Any models that augment RFC 7223 and have config false nodes will be
impacted.*

There are many such vendor modules already.
They augment the /interfaces container with config
and the /interfaces-state container with non-config.
Nobody is complaining this is broken, AFAIK.
If you tell them to throw it out and start over, the request
is likely to be ignored.

Andy

On Wed, Jul 27, 2016 at 1:09 PM, Kent Watsen <[email-masked]> wrote:

> KW:  Yes, the term “counters” is a misnomer.  We are indeed talking about
> regular old config false nodes, whether they be used for counters, gauges,
> or whatever.   It is what the opstate-reqs draft refers to as derived state.
>
>
>
>
>
>
>
> - I thought that quite a lot of other IETF models that are in the process
> of being standardized have a top level split between "foo" and
> KW: I also notice that draft-ietf-netmod-routing-cfg does this and, to
> your point, you know the ietf-routing module is intended to be augmented by
> many other modules.  This issue is not easily isolated.
>
>
>
> RW:
> The current guidance for "intended vs applied" is clear.  I.e. there must
> not be "config false" leaves in the IETF YANG data models to represent
> "applied config".  But there is no clear guidance for the rest of
> operational state that isn't applied config.  The other WGs need clear
> guidance (effectively now) to ensure that they can start publishing models
> as RFCs.
>
> KW: indeed.
>
>
>
>
>
> RW:
> Idealistically I would like foo and foo-state to be merged because I think
> that will make the models easier to use and maintain in the long term, but
> I don't know if we are just too late to go in that direction.  It seems to
> me that the NETMOD WG really should try to come to a decision quite quickly
> on this, but I don't know how to encourage that.  A virtual interim on just
> this topic perhaps?
>
> ‘deprecate’
> So the generated "foo-state" tree would contain a copy of all config false
> nodes in the YANG schema and a "config false copy" of any config true nodes
> in the YANG schema that are required to provide parental structure for the
> descendant config false nodes.
> - The Xpath expressions would also need to be adjusted, and possibly some
> of those might break (or need to be fixed by hand).
> to agree that this is the right direction to go in before we spend time on
> this?
>
> KW: it was just an idea.   I’m trying to strike a balance between having
> the YANG models we want, and what is possible today (while waiting for the
> opstate solution to roll out).
>
>
>
>
>
>
>
> whereby it’s possible that the system may generate some bars as well.  To
> address this, the module is run through a TBD-tool to generate second
> module foo-state as follows:
>
>
>
> module ietf-foo-state {
>
> 1) an opstate-unaware server might only support “ietf-foo”, as it is
> deemed unnecessary to provide the operational state for system-generated
> bars.
>
>
>
> 3) an opstate-aware server only support “ietf-foo”, as it is expected that
> the derived state for system-generated bars can be obtained another way
> (e.g., via the “operational” datastore).
>
>
>
> 4) an opstate-aware server supports both “ietf-foo” and “ietf-foo-state”,
> most likely for backwards compatibility reasons.   The examples provided
> under (2) above continue to work and, later in time, the vendor can
> deprecate support for ietf-foo-state.
>
>
>
>
>
> Kent  // as a contributor
>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Jul 2016 15:52:57 +0200

> this split.  I suspect that all the routing models will be structured 

Correct. One reason is that the core routing model envisions
system-controlled RIBs.

> pragmatically just ignore the issue of system created interface

The NETMOD WG considered this issue quite important in the past.

My impression from the OpState discussion is that we are on the quest of
the philosopher's stone, trying to find a shortcut where none is
possible in general. The long session in Berlin concentrated on the
life-cycle of a single parameter that's somehow configured, then
manipulated, and eventually ends up as operational state. IMO this
is too simplistic, the relationship between configuration and state can
be much more complex. RIB is one example - it combines contributions
from configuration (static routes) and derived state (routing
protocols).

After all, most real devices have some configuration mode and "show"
commands. They are separate even though there is certainly some
relationship between their data.

Lada

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 28 Jul 2016 13:57:48 +0000

Hi Lada, 

On 7/28/16, 9:52 AM, "netmod on behalf of Ladislav Lhotka"
<[email-masked] on behalf of [email-masked]> wrote:

>>don't 

If one were to support the Applied-Config data store, it be comprised of
only the current state of the configured static routes.  The complete RIB
would still need to be accessible in separate data nodes.

Thanks,
Acee 

>>everyone

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Jul 2016 16:20:48 +0200

> On 28 Jul 2016, at 15:57, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Lada, 
> 

Yes, but I didn't talk about intended-applied. I understand that another goal of OpState is to unify config and (true) state and get rid of the foo and foo-state dichotomy in the data model. I am sceptical about it.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Jul 2016 15:42:56 +0100

> Yes, but I didn't talk about intended-applied. I understand that another goal of OpState is to unify config and (true) state and get rid of the foo and foo-state dichotomy in the data model. I am s…
The goal is/was to unify where the only reason that they were split was 
because the lifetime of the configured containing datanode may differ 
from the operational containing datanode.  E.g. interfaces vs 
interfaces-state was split to allow for system created interfaces that 
were not configured, but other than this reason the split seems quite 
artificial and not particularly helpful.

OpenConfig is modelling interfaces and interfaces-state as a single 
list.  It would be kind of helpful if IETF models and OpenConfig models 
could be consistent in this regard, and I prefer the combined list 
approach used by OpenConfig interfaces (on the assumption that we can 
solve the technical problems associated with this approach - which I 
think that we can).

I've no particular issue with a RIB existing under routing-state. But 
personally, if it was the ISIS specific routing table, I would prefer it 
to be under a single top level ISIS container on the assumption that you 
cannot really have an ISIS routing table if ISIS isn't actually running 
on the device.

Cheers,
Rob

> .

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 28 Jul 2016 14:48:45 +0000

On 7/28/16, 10:42 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)" <[email-masked]> wrote:

>>>>>>there
>>>>>has
>> Yes, but I didn't talk about intended-applied. I understand that
>>another goal of OpState is to unify config and (true) state and get rid
>>of the foo and foo-state dichotomy in the data model. I am sceptical
>>about it.

Don’t confuse a global RIB instance with an IS-IS local RIB instance.
These are separate tables (although the former may contain active entries
from the latter) and both would be interesting from an operational
perspective. 

Thanks,
Acee

>>>>>>case
>>>>>direction.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Jul 2016 15:57:26 +0100

> from the latter) and both would be interesting from an operational
Sorry, I wasn't trying to -  I should have written "a global RIB" 
instead of "a RIB" ;-)

I am suggesting that a global RIB could reasonably go under a path like 
"routing-state/rib" (because it is not tidied to a particular protocol), 
but that the IS-IS specific RIB instance could go under 
"routing/isis/rib" (because it can surely only exist if IS-IS is running*).

*Note that I explicitly mean "running" here, as opposed to "configured", 
since both "opstate drafts" allow the operational state datastore to 
contain config true datanodes for things that are running but not 
explicitly configured.

Cheers,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Jul 2016 16:58:32 +0200

> On 28 Jul 2016, at 16:48, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

Right. I believe the term RIB was originally coined for a data structure that was internal to BGP, so this sometimes causes confusion.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Jul 2016 16:00:47 +0100

On 27/07/2016 20:44, Acee Lindem (acee) wrote:
>
>
> From: netmod <[email-masked] 
> <mailto:[email-masked]>> on behalf of Mahesh Jethanandani 
> <[email-masked] <mailto:[email-masked]>>
> Cc: netmod WG <[email-masked] <mailto:[email-masked]>>
> Right - and this separation is based on the routing and routing-state 
> split in the ietf-routing-cfg model. In general, ietf-routing-cfg 
> specifies that all control plane protocol YANG models should adapt 
> this structure. Anyone who thinks collapsing all the models one 
> config/state tree is simply a matter of moving a few counters should 
> taking a better look at the existing drafts. I outlined the options in 
> the E-mail thread prior to IETF 96.  Now, with the context of IETF 96 
> behind us, I believe more NETMOD participants will understand the 
> options. To review the options specified in the previous E-mail thread.
>
> Prior to IETF 96, I don’t believe we had selected a direction. 
> However, I believe we agreed on option #1 in order to allow the 
> publication of these models within the next year. We’d still be able 
> to avail the benefits of applied vs intended configuration on network 
> devices supporting these data stores.
My take is that I think that the leaning at IETF was towards 2.

I.e. I think that we ruled out 1.  I.e. the models must not have 
separate nodes to represent applied configuration because that will be 
solved by the datastore solution.

But it feels a bit inconsistent that the models don't need to have 
explicit leaves for foo vs foo-applied (because it will be solved by 
datastores), but the models do still need explicit leaves for foo vs 
foo-state (even though this could/should also be solved by an 
operational state datastore - noting that both draft-schoenw and 
draft-wilton propose a solution to this problem).

My preference, if we can get quick consensus would be to do 3, or if 
consensus is not possible for 3, then we should fallback to doing 2, as 
the next best option.  But whatever the decision, I favour agreeing a 
direction quickly so that the other WGs know what to put in the RFCs.

Thanks,
Rob

>
> Thanks,
> Acee
>
>
>
>
>
>>     On Jul 27, 2016, at 11:22 AM, Xufeng Liu
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     structured similarly” is not correct. Very few models in routing
>>     area structure this way.
>>     Regards,
>>     - Xufeng
>>     *From:*netmod [mailto:[email-masked]]*On Behalf
>>     Of*Robert Wilton
>>     *Sent:*Wednesday, July 27, 2016 1:05 PM
>>     *To:*Kent Watsen <[email-masked]
>>     <mailto:[email-masked]>>; netmod WG <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Subject:*Re: [netmod] OpsState Direction Impact on Recommended
>>>     then instead we should have consistent rules that explicitly
>>>     state that for all IETF models "foo" and "foo-state" are
>>>     separate trees with a consistent naming convention and
>>>     structure.  That should hopefully allow tooling to
>>>     programmatically relate the two separate trees together.  It may
>>>     give a path to allow "foo-state" to be merged into "foo" in
>>>     future, but once IETF has standardized 600+ models with separate
>>>     sub-trees, I cannot see that they would get merged back together
>>>     again.
>>>
>>     By counters, I think that we also mean any config false nodes
>>     that don't directly represent "applied configuration", right?
>>     E.g. is an interface operationally up or down.
>>
>>
>>     process of being standardized have a top level split between
>>     "foo" and "foo-state".  E.g the ISIS model
>>     (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect
>>     that all the routing models will be structured similarly.
>>     OpenConfig modules effectively have exactly this same issue (e.g.
>>     they have a combined interfaces tree keyed by config true
>>     leaves), and they pragmatically just ignore the issue of system
>>     created interface entries.
>>
>>
>>>      Is this issue currently blocking models from progressing, or
>>>     are we getting ourselves wrapped around a hypothetical?
>>     RW:
>>     The current guidance for "intended vs applied" is clear.  I.e.
>>     there must not be "config false" leaves in the IETF YANG data
>>     models to represent "applied config".
>>
>>     But there is no clear guidance for the rest of operational state
>>     that isn't applied config.  The other WGs need clear guidance
>>     (effectively now) to ensure that they can start publishing models
>>     as RFCs.
>>
>>
>>
>>     Idealistically I would like foo and foo-state to be merged
>>     because I think that will make the models easier to use and
>>     maintain in the long term, but I don't know if we are just too
>>     late to go in that direction.  It seems to me that the NETMOD WG
>>     really should try to come to a decision quite quickly on this,
>>     but I don't know how to encourage that.  A virtual interim on
>>     just this topic perhaps?
>>
>>
>>>     merge the 600+ models with separate subtrees back together
>>>     again.  So I’m thinking we immediately merge foo and foo-state
>>>     in all active YANG models (so that the YANG “conceptual” models
>>>     are stable and good) *and* then we use your idea to
>>>     programmatically generate the “foo-state” tree, presumably only
>>>     when needed.  This foo-state tree could be generated offline by
>>>     tools and provided as a second YANG module in drafts.  In this
>>>     way, servers (opstate aware or not) can advertise if clients can
>>>     access the foo-state tree (an opstate-aware server may still
>>>     advertise it for business reasons, and it can ‘deprecate’ the
>>>     tree when no longer needed).   We could do the same without
>>>     tools today by just using a feature statement on, for instance,
>>>     the interfaces-state container, but I like pushing for tooling
>>>     upfront so that we’re guaranteed mergeability later.  Thoughts?
>>     RW:
>>     So the generated "foo-state" tree would contain a copy of all
>>     config false nodes in the YANG schema and a "config false copy"
>>     of any config true nodes in the YANG schema that are required to
>>     provide parental structure for the descendant config false nodes.
>>     - The Xpath expressions would also need to be adjusted, and
>>     possibly some of those might break (or need to be fixed by hand).
>>     everyone to agree that this is the right direction to go in
>>     before we spend time on this?
>>
>>     Thanks,
>>     Rob
>>
>>
>>
>>>     Kent // as a contributor
>>>
>>>
>     [email-masked] <mailto:[email-masked]>
>
>
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 28 Jul 2016 15:38:39 +0000

On 7/28/16, 10:20 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>Yes, but I didn't talk about intended-applied. I understand that another
>goal of OpState is to unify config and (true) state and get rid of the
>foo and foo-state dichotomy in the data model. I am sceptical about it.

Suffice it to day that in a combined tree there will be state that has not
corresponding config. For example, the populated global RIB instances
would fall into this category.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 28 Jul 2016 15:40:20 +0000

Agreed. I’m not saying it isn’t possible to have a combined config/state
tree. My previous point is that it represents a major shift and would be
hard to reach consensus in the desired time frame.

Thanks,
Acee 

On 7/28/16, 10:57 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
Cisco)" <[email-masked]> wrote:

>>>>>>>>then
>>>>>>>>the
>>>>>>>>missed
>>>>>>> they
>>>>>> My impression from the OpState discussion is that we are on the
>>>>>>quest
>>>>>> of
>>>>>>>>we
>>>>>>>that
>>>>>>>>I’m
>>>>>>>config
>>>>>>>possibly

---

From: Robert Wilton <[email-masked]>
Date: Thu, 28 Jul 2016 16:43:48 +0100

Hi Andy,

I think that it would be fair to say that the authors of 
draft-openconfig-netmod-opstate-01 think that it broken (e.g. sections 
6.1, 8.1.2), particularly given that they have decided that it is better 
to have their own OpenConfig version of interfaces rather than augment 
RFC 7223.  I might be mistaken, but my understanding is that the reason 
that they have done this is to avoid the interfaces vs interfaces-state 
split.

My impression from conversations in Berlin is that other individuals at 
IETF also don't particularly like the foo vs foo-state split, 
particularly for interfaces.

Regarding not breaking existing users, yes, I agree with you.  But this 
could still allow a new version of RFC 7223 to be published that marks 
the existing interfaces-state tree nodes as deprecated and adds new 
config false leaves to be under /interfaces.

Thanks,
Rob

On 27/07/2016 21:29, Andy Bierman wrote:
> Hi,
>
> *Re: - Any models that augment RFC 7223 and have config false nodes 
> will be impacted.*
>
> On Wed, Jul 27, 2016 at 1:09 PM, Kent Watsen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     don't directly represent "applied configuration", right? E.g. is
>     an interface operationally up or down.
>
>     KW:  Yes, the term “counters” is a misnomer.  We are indeed
>     talking about regular old config false nodes, whether they be used
>     for counters, gauges, or whatever.   It is what the opstate-reqs
>     draft refers to as derived state.
>
>     process of being standardized have a top level split between "foo"
>     and "foo-state".  E.g the ISIS model
>     (draft-ietf-isis-yang-isis-cfg-08) has this split.  I suspect that
>     all the routing models will be structured similarly.
>
>     KW: I also notice that draft-ietf-netmod-routing-cfg does this
>     and, to your point, you know the ietf-routing module is intended
>     to be augmented by many other modules.  This issue is not easily
>     isolated.
>
>     RW:
>     models to represent "applied config".  But there is no clear
>     guidance for the rest of operational state that isn't applied
>     config.  The other WGs need clear guidance (effectively now) to
>     ensure that they can start publishing models as RFCs.
>
>     KW: indeed.
>
>     RW:
>     Idealistically I would like foo and foo-state to be merged because
>     I think that will make the models easier to use and maintain in
>     the long term, but I don't know if we are just too late to go in
>     that direction.  It seems to me that the NETMOD WG really should
>     try to come to a decision quite quickly on this, but I don't know
>     how to encourage that.  A virtual interim on just this topic perhaps?
>
>     config false nodes in the YANG schema and a "config false copy" of
>     any config true nodes in the YANG schema that are required to
>     everyone to agree that this is the right direction to go in before
>     we spend time on this?
>
>     KW: it was just an idea. I’m trying to strike a balance between
>     having the YANG models we want, and what is possible today (while
>     waiting for the opstate solution to roll out).
>
>     whereby it’s possible that the system may generate some bars as
>     well.  To address this, the module is run through a TBD-tool to
>     generate second module foo-state as follows:
>
>     module ietf-foo-state {
>
>     1) an opstate-unaware server might only support “ietf-foo”, as it
>     is deemed unnecessary to provide the operational state for
>     system-generated bars.
>
>     3) an opstate-aware server only support “ietf-foo”, as it is
>     expected that the derived state for system-generated bars can be
>     obtained another way (e.g., via the “operational” datastore).
>
>     4) an opstate-aware server supports both “ietf-foo” and
>     “ietf-foo-state”, most likely for backwards compatibility
>     reasons.   The examples provided under (2) above continue to work
>     and, later in time, the vendor can deprecate support for
>     ietf-foo-state.
>
>     Kent  // as a contributor
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Jul 2016 16:15:45 +0200

> solve the technical problems associated with this approach - which I 

If we agree that there may be state data that have no direct
counterpart in configuration, and these will be in foo-state, then the
likely outcome is that in order to collect all state data, one will have
to query both foo and foo-state, which doesn't seem ideal.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 Jul 2016 07:39:04 -0700

Hi,

I am somewhat confused about this discussion.
Apparently it is a hyge problem to put foo-counters under
foo-state?  Configuration must be used (and setup by the operator?)
in order for foo-counters to exist?

So what problem does this solve?

The opstate solution proposal requires a config path-expr to be altered
to generate the corresponding path-expr under the 'state' container.
It does not seem to be a problem that a new path-expr needs to be
constructed.
Is that what you are trying to solve? Even though counters never have
a corresponding configuration node with the same name?

So what happens to modules like ietf-restconf-monitoring?
It is no longer allowed to write monitoring modules?
They all have to contained within some configuration nodes?
Again, what problem is this trying to solve?

Andy

On Fri, Jul 29, 2016 at 7:15 AM, Ladislav Lhotka <[email-masked]> wrote:

> another goal of OpState is to unify config and (true) state and get rid of
> the foo and foo-state dichotomy in the data model. I am sceptical about it.

---

From: Robert Wilton <[email-masked]>
Date: Fri, 29 Jul 2016 16:35:05 +0100

Hi Andy,

The main problem that I'm currently trying to solve, and get agreement 
on, is "where does the operator's automated code look to find the state 
nodes associated with a particular config node".

E.g. for feature /foo, do they look for the config false nodes under 
/foo, or do the look somewhere in /foo-state.  The current answer 
appears to be, that the config false nodes could appear in either place 
in the IETF modules without any requirement for a consistent approach.  
Is that right?

Separately, the OpenConfig folks have said that it would be better if 
they could get (or register for notification of) all of the data 
associated with "foo" with a single request rather than having to make 
multiple requests in different trees.  Personally, I prefer their model 
where they have merged interface-state into interfaces.  Mainly because 
I think that it should make the YANG modules easier to read with less 
duplication of structure, and I think that it is a better long term 
direction to go in.  However, I appreciate Acee's comments that we may 
just be too late to change this now, and we must just accept the status 
quo (whatever that is).

I would like to know what should the common approach for IETF standard 
models be?  E.g. is it one of the following:

1) All config false leaves for foo must go under /foo-state.
2) All config false leaves for foo must go under /foo
3) All config false leaves go under /foo where possible, or /foo-state 
otherwise (e.g. for restconf-monitoring).
4) Config false leaves go wherever the model writer decides is appropriate.

I've put further comments inline below ...

On 29/07/2016 15:39, Andy Bierman wrote:
> foo-state?
RW:
This isn't just about counters, it is all config false nodes that are 
not present solely to represent "applied configuration".

>   Configuration must be used (and setup by the operator?)
RW:
No, this is not being proposed.

draft-schoenw and draft-wilton propose that the config true nodes are 
allowed to exist in an "operational state datastore" to parent child 
config false nodes, even though they haven't been configured. I also 
proposed that metadata annotations could be used to indicate that the 
containing config=true nodes in the operational state datastore exist 
only in the system (and not in the configuration).

Further I would propose that NETCONF/RESTCONF servers could support an 
"operational state datastore" without any requirement to distinguish 
applied configuration separately from intended configuration.

> So what problem does this solve?
RW:
I see that it potentially allows modules to avoid an arbitrary foo vs 
foo-state split.

> to generate the corresponding path-expr under the 'state' container.
RW:
Are you referring to the OpenConfig model solution here or 
draft-schoenw, or draft-wilton?

> So what happens to modules like ietf-restconf-monitoring?
RW:
Either it stays exactly as it is now, or alternatively it could just be 
named "restconf" rather than "restconf-state", even if it just contains 
config false nodes.

> It is no longer allowed to write monitoring modules?
RW:
It is still allowed to write monitoring modules, no change here.

> They all have to contained within some configuration nodes?
RW:
No, not necessarily:
  - it they are just state then either call them "foo" or "foo-state" as 
per above.
  - if they are mix of config and state then they would go under "foo", 
which would be a config true node (but not necessarily configured, as 
per my comments on the operational state datastore above).

> Again, what problem is this trying to solve?
RW:
Hopefully this one has already been answered above.

Thanks,
Rob

>
>
> Andy
>
>
> On Fri, Jul 29, 2016 at 7:15 AM, Ladislav Lhotka <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Robert Wilton <[email-masked] <mailto:[email-masked]>> writes:
>
>     >>> On 28 Jul 2016, at 15:57, Acee Lindem (acee) <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>
>     >>> Hi Lada,
>     >>>
>     >>> <[email-masked] <mailto:[email-masked]> on
>     behalf of [email-masked] <mailto:[email-masked]>> wrote:
>     >>>
>     >>>> Robert Wilton <[email-masked] <mailto:[email-masked]>>
>     writes:
>     >>>>
>     (draft-ietf-isis-yang-isis-cfg-08) has
>     >> Yes, but I didn't talk about intended-applied. I understand
>     that another goal of OpState is to unify config and (true) state
>     and get rid of the foo and foo-state dichotomy in the data model.
>     I am sceptical about it.
>     because I

---

From: Lou Berger <[email-masked]>
Date: Fri, 29 Jul 2016 12:12:12 -0400

Picking this message as it is the most recent on this thread - I'd like
to "up level "the discussion.

My read (as chair) on this topic is that in our Berlin meeting, see
discussions related to slide on Section 5.23 of rfc6087bis, we were left
with opinion in the room supporting the current text -- basically saying
that there are different options and that a model writer should make an
informed choice (between a cf-only -state branch and commingling cf and
ct nodes -- basically Rob's #4 below.) 

>From the process standpoint, this was an easy result as it left
unmodified text in a WG document that we hope to LC soon.

>From this thread, and the number of comments being made, it seems that
some would like to change 5.23 and provide more specific/stronger
guidance. 

I'd like to request that those who wish to provide different guidance
than what is currently written (in 
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-07#section-5.23
) please propose text on the list for consideration and discussion.  My
rationale for this request is that having specific proposed language
will help focus the discussion and determining consensus.

Thank you,
Lou (as co-chair)

On 7/29/2016 11:35 AM, Robert Wilton wrote:
> on, is "where does the operator's automated code look to find the
> state nodes associated with a particular config node".
>
> appears to be, that the config false nodes could appear in either
> place in the IETF modules without any requirement for a consistent
> approach.  Is that right?
>
> multiple requests in different trees.  Personally, I prefer their
> model where they have merged interface-state into interfaces.  Mainly
> because I think that it should make the YANG modules easier to read
> with less duplication of structure, and I think that it is a better
> long term direction to go in.  However, I appreciate Acee's comments
> that we may just be too late to change this now, and we must just
> accept the status quo (whatever that is).
>
> Either it stays exactly as it is now, or alternatively it could just
> be named "restconf" rather than "restconf-state", even if it just
> contains config false nodes.
>
>  - it they are just state then either call them "foo" or "foo-state"
> as per above.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 29 Jul 2016 09:13:08 -0700

Hi,

You said "automated code".
Write some YANG extensions for your tools to manually assign
the mapping.  This has already been suggested several times.
This approach can also address N:M mappings.  Supporting 1:1
mappings and ignoring everything else doesn't really help.

Andy

On Fri, Jul 29, 2016 at 8:35 AM, Robert Wilton <[email-masked]> wrote:

> Hi Andy,
>
> The main problem that I'm currently trying to solve, and get agreement on,
> is "where does the operator's automated code look to find the state nodes
> associated with a particular config node".
>
> E.g. for feature /foo, do they look for the config false nodes under /foo,
> or do the look somewhere in /foo-state.  The current answer appears to be,
> that the config false nodes could appear in either place in the IETF
> modules without any requirement for a consistent approach.  Is that right?
>
> Separately, the OpenConfig folks have said that it would be better if they
> could get (or register for notification of) all of the data associated with
> "foo" with a single request rather than having to make multiple requests in
> different trees.  Personally, I prefer their model where they have merged
> interface-state into interfaces.  Mainly because I think that it should
> make the YANG modules easier to read with less duplication of structure,
> and I think that it is a better long term direction to go in.  However, I
> appreciate Acee's comments that we may just be too late to change this now,
> and we must just accept the status quo (whatever that is).
>
> This isn't just about counters, it is all config false nodes that are not
> present solely to represent "applied configuration".
>
> allowed to exist in an "operational state datastore" to parent child config
> false nodes, even though they haven't been configured.  I also proposed
> that metadata annotations could be used to indicate that the containing
> config=true nodes in the operational state datastore exist only in the
> system (and not in the configuration).
>
> Are you referring to the OpenConfig model solution here or draft-schoenw,
> or draft-wilton?
>
> which would be a config true node (but not necessarily configured, as per
> my comments on the operational state datastore above).
>
>> quest of

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jul 2016 18:32:20 +0200

> 1) All config false leaves for foo must go under /foo-state.

I think if you have /foo-state, then this is a logical consequence. Do
we have any data models that have a /foo-state tree and config false
nodes under the /foo tree?

> 2) All config false leaves for foo must go under /foo

This apparently does not make sense in certain circumstances until we
have a revised datastore solution defined and implemented that may
allow this to work in all situations.

> otherwise (e.g. for restconf-monitoring).

I think it should be fairly easy for a tool to figure out whether a
/foo tree is a pure config true tree or whether there are any config
false leafs as well and /foo is a mixed tree. Things are fairly easy
as long as people split at the root if they split.

> 4) Config false leaves go wherever the model writer decides is appropriate.

I think we will have to live for a while with both the (i) /foo (pure
config true tree) and /foo-state (pure config false tree) split at the
root approach and the (ii) /foo (mixed config true and false tree)
approach. We need to document the trade-offs between the two so that
module writers can make an informed decision. Whether a module uses
(i) or (ii) should be possible to determine by inspecting the
properties of the schema tree, in particular if module writers follow
the guideline to use consistent names and structure in the /foo and
/foo-state approach wherever possible.

I think we also wanted to strongly discourage models where (iii) the
trees split at the leaves or very close to the leaves.

/js