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

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Aug 2016 01:10:05 +0000

<as a contributor>

Following Lou’s recommendation, my proposed changes for rfc6087bis Section 5.23 follow:

5.23.  Operational Data

   In YANG, any data that has a "config" statement value of "false"
   could be considered operational data.  The relationship between
   configuration (i.e., "config" statement has a value of "true") and
   operational data can be complex.

-   One challenge for client developers is determining if the configured
-   value is being used, which requires the developer to know which
-   operational data parameters are associated with the particular
+  One challenge for client applications is determining if a configured
+  value is being used, which requires the application to know which
+  operational data parameters are associated with a particular
   configuration object (or group of objects).

   In the simplest use-cases, there is no interaction between
   configuration and operational data.  For example, the arbitrary
   administrative name or sequence number assigned to an access control
   rule.  The configured value is always the value that is being used by
   the system.

   However, some configuration parameters interact with routing and
-   other signalling protocols, such that the operational value in use by
+  other signaling protocols, such that the operational value in use by
   the system may not be the same as the configured value.  Other
   parameters specify the desired state, but environmental and other
   factors can cause the actual state to be different.

-   For example a "temperature" configuration setting only represents the
+   For example, a "temperature" configuration setting only represents the
   desired temperature.  An operational data parameter is needed that
   reports the actual temperature in order to determine if the cooling
   system is operating correctly.  YANG has no mechanism other than the
   "description" statement to associate the desired temperature and the
   actual temperature.

  [Editor’s Note: we should define a ‘related-config’ statement ASAP!]

   Careful consideration needs to be given to the location of
   operational data.  It can either be located within the configuration
   subtree for which it applies, or it can be located outside the
   particular configuration subtree.  Placing operational data within
-   the configuration subtree is appropriate if the operational values
-   can only exist if the configuration exists.
+   the configuration subtree is ideal, as the association between the
+   configuration and operational state is clear.  However, doing so must
+   be done with the knowledge that NETCONF and RESTCONF can 
+   currently only return the operational state for configured values,
+   not system generated values such as system created interfaces or
+   routing table entries.   This is because the config false nodes are 
+   descendants of config true nodes and hence cannot be returned
+   for nodes that haven’t been configured.   At least, this is the case
+   for how NETCONF and RESTCONF currently support returning
+   mixed config true and config false content.

-   The "interfaces" and "interfaces-state" subtrees defined in [RFC7223]
-   are an example of a complex relationship between configuration and
-   operational data.  The operational values can include interface
-   entries that have been discovered or initialized by the system.  An
-   interface may be in use that has not been configured at all.
-   Therefore, the operational data for an interface cannot be located
-   within the configuration for that same interface.
+   In order to support returning operational state for system generated
+   values, some YANG module designers have created a parallel top-level
+   config false hierarchy that mirrors the structure of the config true 
+   hierarchy.  For instance, this is seen in the ‘interfaces-state’ node in 
+   [RFC7223].  By doing this, it enables the operational state for system
+   generated values to be returned, since then all the ancestor nodes are
+   config false as well.  However, this approach is not ideal as it leads to 
+   needing to maintain duplicate structures and also requires the use of
+   description statements to describe the association between the two
+   structures.

+   To address this situation, the NETMOD and NETCONF working groups
+   are at this time in the process of defining a holistic operational state
+   solution that entails both a revised conceptual datastore model and
+   the necessary protocol extensions to enable, in part, both NETCONF
+   and RESTCONF to be able to return operational state for system
+   generated values using the same config true hierarchy used to return
+   the operational state for configured values.

+   This being the case, it is RECOMMENDED that YANG module designers
+   always mix config true and config false nodes into a single hierarchy.
+   This is so the YANG modules will be in proper form for when the
+   holistic operational state solution is available.   To address any 
+   immediate needs to also report the operational state for system
+   generated values, it is RECOMMENDED to define a second module
+   that imports the first module and defines a parallel top-level
+   config false hierarchy that mirrors the structure of the config true 
+   hierarchy in the first module.   This recommendation is made to
+   enable NETCONF/RESTCONF servers supporting the finalized
+   opstate solution to choose when to stop supporting the second 
+   module, as it would then only be needed to support legacy 
+   opstate-unaware clients.

FOUR SCENARIOS:

1) an opstate-unaware server might only support “ietf-foo”, as it is deemed unnecessary to provide the operational state for system-generated bars.  A client can get the operational state for just the configured bars using NETCONF’s <get> or RESTCONF’s content ‘all’ query parameter.
 
2) an opstate-unaware server might support both “ietf-foo” and “ietf-foo-state”, as it is deemed important to provide the operational state for system-generated bars.   Same as above, a client can get the operational state for just the configured bars, when targeting the “ietf-foo” module.  Better though, a client can get the operational state for both configured and system-generated bars together when targeting the “ietf-foo-state” module.  A client that is savvy enough to do this would of course not want the redundant operational state data from the ietf-foo module and therefore would likely only use NETCONF’s <get-config> and/or RESTCONF’s content ‘config’ query parameter when targeting the “ietf-foo” module.

3) an opstate-aware server might only support “ietf-foo”, as it can provide the operational state for both configured and system-generated bars using protocol mechanisms defined by the holistic opstate solution (e.g., via an “operational” datastore), and it doesn’t care about enabling legacy opstate-unaware clients to be able to obtain the operational state for the system generated bars.

4) an opstate-aware server might support both “ietf-foo” and “ietf-foo-state”, so that it can provide the operational state for both configured and system-generated bars to both opstate-aware and opstate-unaware clients.  This is hopefully a temporary condition as eventually the clients will be upgraded to be opstate-aware and then the vendor can deprecate support for the ietf-foo-state module.

WHY IMPORT?   The text above includes the statement “it is RECOMMENDED to define a second module that imports the first module”.  Technically, there isn’t a need for the import as of yet, but I’m very much thinking that we should *quickly* define a YANG statement called “related-config” that allows the client to programmatically related which config true nodes in the first module might are associated to the config false nodes in the second module.  Obviously, this would only make the association for configured values, and the client could assume that any key-misses are the result of the that operational state being for a system-generated value.  The association has to be in that direction because config false nodes can point to config true nodes, but not visa versa.

<EXAMPLE>

Assume 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, we create a second module “ietf-foo-state” (ideally using tool) that discards are the config true leafs and sets the entire tree to config false.  The resulting module follows:
 
module ietf-foo-state {
  namespace “foo-state-namespace”;
  import ietf-foo { prefix “f”; }
  container foo-state {
    config false;    <-- everything below is config false
    list bar {
      key a;
      related-config {      <-- config false point to config true (only present for *configured* bars)
          path “/f:foo/f:bar/f:a”
      }
      leaf a {    <-- this “config true” leaf is kept only because it’s the key (but now it’s config false)
        type string;
      }
      leaf b {
         type int8;
         config false;
      }
   }
  }
}
</EXAMPLE>

<SNIP - I didn’t try to rewrite any of the below stuff from Section 5.23. Some of it would be obsolete from the text above, but other parts may still be useful...>

   Sometimes the configured value represents some sort of procedure to
   be followed, in which the system will select an actual value, based
   on protocol negotiation.

      leaf duplex-admin-mode {
        type enumeration {
          enum auto;
          enum half;
          enum full;
        }
      }

      leaf duplex-oper-mode {
        config false;
        type enumeration {
          enum half;
          enum full;
        }
      }

   For example a "duplex" mode configuration may be "auto" to auto-
   negotiate the actual value to be used.  The operational parameter
   will never contain the value "auto".  It will always contain the
   result of the auto-negotiation, such as "half" or "full".  This is
   just one way in which the configuration data model is not exactly the
   same as the operational data model.  Another is if the detailed
   properties of the data are different for configured vs. learned
   entries.

   If all the data model properties are aligned between configuration
   and operational data, then it can be useful to define the
   configuration parameters within a grouping, and then replicate that
   grouping within the operational data portion of the data model.

       grouping parms {
          // do not use config-stmt in any of the nodes
          // placed in this grouping
       }

       container foo {
         uses parms;  // these are all config=true by default
         state {
           config false;  // only exists if foo config exists
           uses parms;
         }
       }

   Note that this mechanism can also be used if the configuration and
   operational data are in separate sub-trees:

       container bar { // bar config can exist without bar-state
         config true;
         uses parms;
       }

       container bar-state {  // bar-state can exist without bar
         config false;
         uses parms;
       }

   The need to replicate objects or define different operational data
   objects depends on the data model.  It is not possible to define one
   approach that will be optimal for all data models.  Designers SHOULD
   describe the relationship in detail between configuration objects and
   any associated operational data objects.  The "description"
   statements for both the configuration and the operational data SHOULD
   be used for this purpose.

</SNIP>

Thanks,
Kent

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 2 Aug 2016 18:29:46 +0200

Hello,

Later I will try to provide a text proposal as well, but some
points:

I prefer a tight definition so even if we allow both 1) and
2)  we should state that other combinations e.g. trees spliting
close to the leaves or a mix of 1) and 2) in the same module are
not allowed (VERYYYY STRONGLY discouraged).

In one of the earlier mails there was a a statement: if we
have foo and foo-state trees, the containers/list/key-leafs
SHOULD be the same in the two. The structures of the two trees
SHOULD not just be si,i;ar, they should be the same.

This way you could look at the root objects of the module and
immediately know what is the situation.

regards Balazs

On 2016-07-29 18:32, Juergen
Schoenwaelder wrote:

On Fri, Jul 29, 2016 at 04:35:05PM +0100, Robert Wilton wrote:

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.

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.

3) All config false leaves go under /foo where possible, or /foo-state
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

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 2 Aug 2016 18:35:54 +0200

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

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

regards Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 2 Aug 2016 18:39:57 +0200

I don't know if we can make them a rule, but IMHO single-rooted
modules are definitely easier to use. E.g. just as a single
example: we only need one set of access control rules. Similar
double handling is needed often.  I don't like foo-state trees.

Balazs

On 2016-07-28 17:00, Robert Wilton
wrote:

On 27/07/2016 20:44, Acee Lindem
(acee) wrote:

From: netmod <[email-masked]>
on behalf of Mahesh Jethanandani <[email-masked]>

Date: Wednesday, July
27, 2016 at 9:07 PM

To: Xufeng Liu <[email-masked]>

Cc: netmod WG <[email-masked]>

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

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

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.

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.

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

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

On 26/07/2016
21:36, Kent Watsen wrote:

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

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>

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

Kent
// as a contributor

_______________________________________________

netmod mailing list

[email-masked]

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

Mahesh Jethanandani

[email-masked]

_______________________________________________
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: Rob Shakir <[email-masked]>
Date: Tue, 2 Aug 2016 10:52:16 -0600

Balazs,

> On 2 Aug, 2016, at 10:29 AM, Balazs Lengyel <[email-masked]> wrote:
> I prefer a tight definition so even if we allow both 1) and 2)  we should state that other combinations e.g. trees spliting close to the leaves or a mix of 1) and 2) in the same module are not allowed (VERYYYY STRONGLY discouraged). 

What is the motivation for this very strongly discouraged statement? The problem I take with this is that you are not only getting zero consistency that will let a user determine how a model might look  (painful for those actually *using the models* rather than writing them - who are hugely under-represented in this discussion), but you’re also throwing out a bunch of models (both inside and outside of the IETF) at the same time.

Apologies to pick specifically on this email, but I have still yet to see any justification why anything other than a solution that is already being implemented is preferable to this WG other than it seeming like the WG doesn’t like the aesthetics of the modules in this case.

I am soon going to shut up on this topic, but it’s quite frankly lamentable that such a division is being created with no reasonable justification.

Note that the statement that Benoit/Lou/Kent made in Berlin related to applied config - the structure that is being objected to can be trivially implemented without those leaves if one wanted to.

r.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 3 Aug 2016 08:49:02 +0200

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

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

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

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

Lada 

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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Aug 2016 09:46:41 +0100

Hi Balazs,

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

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

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

Thanks,
Rob

On 02/08/2016 17:35, Balazs Lengyel wrote:
> multi-rooted models. but avoiding foo-state would make life easier 
> once more.
>
> regards Balazs
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Aug 2016 10:02:14 +0100

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

Rob

> .

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Aug 2016 18:37:53 +0000

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

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

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

Thanks,
Acee

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Aug 2016 11:52:53 +0100

> nodes under config-true data nodes, there is no problem with the reverse -
You are allowed config false nodes under config true, but not config 
true nodes under config false.

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

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

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

Thanks,
Rob

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 4 Aug 2016 13:56:12 +0000

On 8/4/16, 6:52 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
<[email-masked]> wrote:

>>>>> On 02 Aug 2016, at 18:35, Balazs Lengyel
>>>>><[email-masked]>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>once

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

Thanks,
Acee

---

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Aug 2016 20:16:12 +0000

>    - the model root just needs to be “config true”.

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

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

Kent // as a contributor

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Aug 2016 14:51:27 -0700

On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <[email-masked]> wrote:

> Great, I think we’re all agreed.  Can we now discuss the text I proposed
> for 6087bis?  - here’s the link to my proposal:
> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>
>
IMO this effort to avoid 2 containers is not well thought out.
Some concerns:

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

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

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

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

Andy

Hint: the first few edits are just nits...skip over the first few
> paragraphs until you start seeing large blocks of changed lines...
>
> Kent // as a contributor
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 8 Aug 2016 23:24:39 +0000

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

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

Kent

From: Andy Bierman <[email-masked]>
Date: Monday, August 8, 2016 at 5:51 PM
To: Kent Watsen <[email-masked]>
Cc: "Acee Lindem (acee)" <[email-masked]>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>, Ladislav Lhotka <[email-masked]>, Balazs Lengyel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] OpsState and Schema-Mount

On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

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

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

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

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

Andy

Kent // as a contributor

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 8 Aug 2016 16:30:52 -0700

On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <[email-masked]> wrote:

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

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

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

Andy

> For 4, right, this discussion on s5.23 of 6087bis regards how to handle
> state for system-generated objects (e.g., interfaces).  It is not directly
> related to the how to report applied configuration problem.  It is however
> indirectly related, in that a holistic solution can address both.
>
>
>
> Kent
>
>
>
>
>
> *From: *Andy Bierman <[email-masked]>
> *Date: *Monday, August 8, 2016 at 5:51 PM
> *To: *Kent Watsen <[email-masked]>
> *Cc: *"Acee Lindem (acee)" <[email-masked]>, "Robert Wilton -X (rwilton -
> ENSOFT LIMITED at Cisco)" <[email-masked]>, Ladislav Lhotka <
> [email-masked]>, Balazs Lengyel <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [netmod] OpsState and Schema-Mount
>
>
>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Aug 2016 13:34:17 +0200

Kent Watsen <[email-masked]> writes:

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

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

Lada

---

From: Robert Wilton <[email-masked]>
Date: Tue, 9 Aug 2016 13:24:18 +0100

Hi Andy,

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

On 08/08/2016 22:51, Andy Bierman wrote:
>     Great, I think we’re all agreed.  Can we now discuss the text I
>     proposed for 6087bis?  - here’s the link to my proposal:
>     https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s
>     <https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s>.
>
>
If it is one module with two top level augments (foo and foo-state) then 
this problem still exists.  Hence, please can you clarify why converging 
them on a single root node means that monitoring cannot be used on it 
own?  Wouldn't a device need to use deviations in both cases to strip 
out the config nodes that they are not supporting?

>     This relies on granular and complex NACM rules which require 
Again, I don't quite follow this, in the specific example that I have 
regarding putting a RIB under a config true NP container, I would have 
thought that NACM read access would have been sufficient for a 
monitoring-only client.  Is that not the case?

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

>    the same indexing, or counters which are not part of the opstate 
Sorry, I don't really follow this one.  The original opstate draft put 
forward by OpenConfig was asking for both applied-configuration and 
derived state (e.g. statistics and other state) to be co-located under 
the same structures.  The original discussions focused on applied 
configuration, but when this was being discussed more recently the 
desire for a solution to the co-located derived state was also discussed 
- which is why both draft-schoenw-netmod-revised-datastores-01 and 
draft-wilton-netmod-refined-datastores-01 propose solutions to this problem.

There are also benefits to merging this data:

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

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

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

Thanks,
Rob

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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 9 Aug 2016 14:12:01 +0100

On 09/08/2016 00:30, Andy Bierman wrote:
>
>
> On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     For 1,2,3, realize that placing config false nodes under config
>     true nodes has been with us from the beginning.  All the issues
>     you mentioned (if they’re issues at all) can’t be new.   Having a

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

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

>
> Issues 1 - 3 are practical issues that need to be addressed if 
> top-level config=false
I don't think that the proposal is to make them 'not allowed', but 'not 
recommended' instead.

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

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

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

Thanks,
Rob

>
>
> Andy
>
>     For 4, right, this discussion on s5.23 of 6087bis regards how to
>     handle state for system-generated objects (e.g., interfaces).  It
>     is not directly related to the how to report applied configuration
>     problem.  It is however indirectly related, in that a holistic
>     solution can address both.
>
>     Kent
>
>     *From: *Andy Bierman <[email-masked] <mailto:[email-masked]>>
>     *To: *Kent Watsen <[email-masked] <mailto:[email-masked]>>
>     *Cc: *"Acee Lindem (acee)" <[email-masked]
>     <mailto:[email-masked]>>, "Robert Wilton -X (rwilton - ENSOFT
>     LIMITED at Cisco)" <[email-masked] <mailto:[email-masked]>>,
>     Ladislav Lhotka <[email-masked] <mailto:[email-masked]>>, Balazs
>     Lengyel <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>         Hint: the first few edits are just nits...skip over the first
>         few paragraphs until you start seeing large blocks of changed
>         lines...
>
>         Kent // as a contributor
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Aug 2016 15:38:56 +0200

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

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

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

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

/js

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 9 Aug 2016 16:16:46 +0200

> On 09 Aug 2016, at 15:38, Juergen Schoenwaelder <[email-masked]> wrote:
> 

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

> protocol reality we were in.

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

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

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 9 Aug 2016 07:23:29 -0700

On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton <[email-masked]> wrote:

> them on a single root node means that monitoring cannot be used on it own?
> Wouldn't a device need to use deviations in both cases to strip out the
> config nodes that they are not supporting?
>
>
Before the "rule" I can choose to place monitoring in its own module
without any reliance on other modules.  If the monitoring does not share
indexing,
what value is there in putting it in the config tree?  I see none except a
poor
attempt at model classification.

> monitoring-only client.  Is that not the case?

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

> have top level 'foo' and 'foo-state' as part of the same module don't you
> run into the same conformance problem?
>
>
>
Much easier to solve the conformance since /foo-state does not need any
objects from /foo
to exist first.  Creating the /foo container means that all config=true
requirements for
that container must be implemented (or complex deviations used)

> forward by OpenConfig was asking for both applied-configuration and derived
> state (e.g. statistics and other state) to be co-located under the same
> structures.  The original discussions focused on applied configuration, but
> when this was being discussed more recently the desire for a solution to
> the co-located derived state was also discussed - which is why both
> draft-schoenw-netmod-revised-datastores-01 and

> 1b) Having co-located config and state makes it easier for clients to code
> - they don't need to unify data across two (potentially different
> structures/indexes).
> 1c) Having a single structure, means less copying of the same organization
> structure into both config and state sub trees (which could be a source of
> bugs)
>
> 3) Finally, I also agree with Kent, in that merging these makes the models
> easier to read and removes a historical wart.
>
>

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

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Aug 2016 19:44:24 +0000

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

[KENT] from opstate-reqs:

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

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

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

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

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 9 Aug 2016 14:01:09 -0700

On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> the
> to
+1

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

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

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

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

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

/js

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Aug 2016 21:31:51 +0000

Juergen, Andy,

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

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

Kent // as a contributor

From: Andy Bierman <[email-masked]>
Date: Tuesday, August 9, 2016 at 5:01 PM
To: Juergen Schoenwaelder <[email-masked]>, Robert Wilton <[email-masked]>, Andy Bierman <[email-masked]>, Kent Watsen <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] OpsState and Schema-Mount

On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

+1

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

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

   container foo {

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Aug 2016 23:56:58 +0200

Comments inline... I generally like the approach of explaining the
situation so that module writers can take an informed decision. I am
struggling a bit with the strong recommendation given and I am not
sure whether using two separate modules for /foo and /foo-state makes
things really simpler.

/js

> +   the operational state for configured values.

I do not know what a 'holistic operational state solution is'.
Interestingly, the revised datastore design team is _not_ tasked to
address the operational state datastore (even though this might still
fall out of their work).

> +   always mix config true and config false nodes into a single hierarchy.

I have a problem with this. In several situations, this is the wrong
thing to do until there is a solution where doing so makes sense. 

> +   opstate-unaware clients.

Factoring things into separate modules may be a workable idea but it
is just a different variant from simply deprecating /foo-state nodes
onces there is a solution in place that can work with a single tree.
I have no clear view what the trade-offs between the two options
really are.

> 2) an opstate-unaware server might support both “ietf-foo” and “ietf-foo-state”, as it is deemed important to provide the operational state for system-generated bars.   Same as above, a client can…

Not sure what 'targeting the “ietf-foo-state” module means in protocol
terms. If you select all in ietf-foo-state, you will likely get all in
ietf-foo-state and not more. I am not sure I understand the argument,
it all boils down how you use filters.

> 4) an opstate-aware server might support both “ietf-foo” and “ietf-foo-state”, so that it can provide the operational state for both configured and system-generated bars to both opstate-aware and o…

I think the same works with /foo and /foo-state in one module with
/foo-state eventually being deprecated. The real costs, likely, is
that some modules provide definitions other modules build on and it
does not matter how you organize the trees into modules - once you
have many dependent modules, making changes is going to be hard.
 
> WHY IMPORT?   The text above includes the statement “it is RECOMMENDED to define a second module that imports the first module”.  Technically, there isn’t a need for the import as of yet, but I’m v…
 
An IMPORT makes sense if there is something to import. It does not
make sense to IMPORT a module just because in the future such an
import may be useful.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 9 Aug 2016 16:04:51 -0700

Hi,

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

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

Andy

On Tue, Aug 9, 2016 at 2:31 PM, Kent Watsen <[email-masked]> wrote:

> Juergen, Andy,
>
>
>
> I think that my proposed text for 6087bis clearly articulates what
> protocols can do today and tomorrow, while making a *very subtle*
> recommendation for today’s model designers to future-proof their models.
>
>
>
> Please focus on the proposal, consistent with the Lou’s chair-request (
> https://mailarchive.ietf.org/arch/msg/netmod/NK864oXvIfeAYoCUTK40wn2Kw-8).
>
>
>
> Kent // as a contributor
>
>
>
>
>
> *Date: *Tuesday, August 9, 2016 at 5:01 PM
> *To: *Juergen Schoenwaelder <[email-masked]>,
> Robert Wilton <[email-masked]>, Andy Bierman <[email-masked]>,
> Kent Watsen <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Aug 2016 13:39:31 +0200

Andy Bierman <[email-masked]> writes:

> without any reliance on other modules.  If the monitoring does not
> share indexing, what value is there in putting it in the config tree?
> I see none except a poor attempt at model classification.

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

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

Lada

---

From: Alex Campbell <[email-masked]>
Date: Wed, 10 Aug 2016 21:54:57 +0000

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

________________________________________
From: netmod <[email-masked]> on behalf of Ladislav Lhotka <[email-masked]>
Sent: Wednesday, 10 August 2016 11:39 p.m.
To: Andy Bierman; Robert Wilton
Cc: netmod WG
Subject: Re: [netmod] OpsState and Schema-Mount

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Aug 2016 09:01:57 +0200

> On 10 Aug 2016, at 23:54, Alex Campbell <[email-masked]> wrote:
> 

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

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

Lada