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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 24 Jul 2017 20:22:06 +0000

Hi Jason,

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 17, 2017 at 6:22 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] nmda-guidelines-01: value space for config vs state

Hi all,

A note in Rob Wilton’s presentation today in rtgwg mentioned something about consistency in the value space for config vs state leafs.  The NMDA approach results in the same leaf for both config & state in many cases (at least for the cases where the separate config & state leafs were only there to represent intended vs applied config).

But aren’t there some cases where the value space for state will be different than the value space for config ?  I’m thinking of the basic admin/oper state for interfaces for example where config may allow enable/disable but state may have additional values like ‘testing’.  If the config & state value spaces aren’t 100% the same, are module designers recommended to create a separate state leaf ?

In this particular example, the leaf you are describing would be read-only system state as opposed to applied state. If there were such a leaf that could take on a wider range of values of applied state values than the intended state, I’d expect the value space would need to be the superset.

Thanks,
Acee

Rgds,
Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 24 Jul 2017 20:32:25 +0000

Hi Acee,

OK – maybe this example isn’t the best.  But in the general case my concern about using a super-set would be that it implies all those values are valid input values for an edit-config in the candidate/running.  I can’t immediately see a clean way to indicate that some of the values aren’t valid for writing.

Another possible approach we could use is that if the value space is different, then it means we should have separate leafs.   The model designer could have 1 typedef for the common values (i.e. for applied/intended config), and then use a union with additional values for the state/operational leaf that supports the extra values.

Jason

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Monday, July 24, 2017 16:22
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: [netmod] nmda-guidelines-01: value space for config vs state

Hi Jason,

Hi all,

Thanks,
Acee

Rgds,
Jason

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 24 Jul 2017 20:35:33 +0000

Hi Jason,

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 24, 2017 at 4:32 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netmod] nmda-guidelines-01: value space for config vs state

Hi Acee,

Right – if there additional values that the leaf can take, then it is probably pure operational state as opposed to applied config.

Thanks,
Acee

Jason

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Monday, July 24, 2017 16:22
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] nmda-guidelines-01: value space for config vs state

Hi Jason,

Hi all,

Thanks,
Acee

Rgds,
Jason

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Jul 2017 00:53:00 +0000

Related, revised-datastores-03#section-4.7 says:

   As a result of remnant configuration, the semantic constraints
   defined in the data model cannot be relied upon for <operational>,
   since the system may have remnant configuration whose constraints
   were valid with the previous configuration and that are not valid
   with the current configuration.  Since constraints on "config false"
   nodes may refer to "config true" nodes, remnant configuration may
   force the violation of those constraints.  The constraints that may
   not hold include "when", "must", "min-elements", and "max-elements".
   Note that syntactic constraints cannot be violated, including
   hierarchical organization, identifiers, and type-based constraints.

The last sentence implies that the value-space must be the same between
nodes in <operational> and the conventional datastores.

Kent // contributor

On 7/24/17, 4:35 PM, "netmod on behalf of Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Jason,

Hi Acee,

Thanks,
Acee

Jason

Hi Jason,

Hi all,

Thanks,
Acee

Rgds,
Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 25 Jul 2017 15:19:09 +0000

OK – so the same leaf (in the schema) has the same value space in the conventional datastores and in the operational datastore.  That probably makes sense since a single schema describes the model for that leaf whether it is accessed in conventional DSes or the operational DS.

But I think that also means that *if* you need slightly different value spaces for an item, then you’ll need to split it into multiple leafs in the schema.

Jason

From: Kent Watsen [mailto:[email-masked]]
Sent: Monday, July 24, 2017 20:53
To: Acee Lindem (acee) <[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: [netmod] nmda-guidelines-01: value space for config vs state

Kent // contributor

Hi Jason,

Hi Acee,

Thanks,
Acee

Jason

Hi Jason,

Hi all,

Thanks,
Acee

Rgds,
Jason

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Jul 2017 12:46:26 +0200

"Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> writes:

> But I think that also means that *if* you need slightly different
> value spaces for an item, then you’ll need to split it into multiple
> leafs in the schema.

This is easier said than done: will there be "foo" and "foo-state" as
sibling leaves, both present in <operational>, as sec. 4.7 indicates?

Apart from value space mismatch, there are other potential issues like
the one that I mentioned in Prague: "if-feature" applies to
configuration but not to state data. An example is in ietf-routing: in
config, "router-id" leaf is only present if "router-id" feature is
advertised (other servers derive router-id by other means), but in state
data "router-id" does not depend on the feature.

The assumption made in NMDA that config and state data schemas can be
unified is IMO simply broken. YANG, being basically a document-oriented
schema language, is not designed to support such tricks.

Lada

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

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Robert Wilton <[email-masked]>
Date: Fri, 28 Jul 2017 11:34:27 +0100

Hi Lada,

> data "router-id" does not depend on the feature.
It is perhaps worth noting that the proposed NMDA YANG library allows 
for different features to be expressed in different datastores.  Not 
that I am actually suggesting that this would be a good solution here.

> schema language, is not designed to support such tricks.
I agree that you cannot align config and state schema values in all 
cases.  However, I think that in the vast majority of cases there is 
close alignment between the configured value, and what the system is 
using.  Optimizing for this common case should make management systems 
simpler for the mainline cases.  There will always be some exceptions, 
but that is OK too.

For the router-id, I think that my preferred solution would be to:
Define the "configurable-router-id" feature, have a single router-id 
leaf, then put in the description that it is only configurable if the 
"configurable-router-id" feature is enabled.

Possibly, in future, we could extend the YANG language to allow 
if-feature to be conditionally applied to only config true or config 
false elements.

An alternative solution, that works today, is to just have 2 separate, 
but co-located, leaves:
1) cfg-router-id, config true, conditional on if-feature.
2) router-id, config false, operational.
- In the future, we could define a YANG extension to bind the config and 
state leaves together in the model (e.g. a related-config statement).  
But I think that we should see how often this issue turns up in practice 
before we jump to doing this.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Jul 2017 13:24:11 +0200

Hi Rob,

> On 28 Jul 2017, at 12:34, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> 
> It is perhaps worth noting that the proposed NMDA YANG library allows for different features to be expressed in different datastores.  Not that I am actually suggesting that this would be a good solution here.
> 
>> 
> I agree that you cannot align config and state schema values in all cases.  However, I think that in the vast majority of cases there is close alignment between the configured value, and what the system is using.  Optimizing for this common case should make management systems simpler for the mainline cases.  There will always be some exceptions, but that is OK too.

I agree that there is a close alignment but then I guess NETMOD should have started with a different approach, perhaps object-oriented rather than document-oriented, where configuration could play the role of "methods" intended for changing the object's state. (If Randy Presuhn was reading this, he would probably refer to certain ancient technologies at this point.:-)

> Define the "configurable-router-id" feature, have a single router-id leaf, then put in the description that it is only configurable if the "configurable-router-id" feature is enabled.
> 
> Possibly, in future, we could extend the YANG language to allow if-feature to be conditionally applied to only config true or config false elements.

It is quite remarkable that formalisms closely related to YANG (W3C XML Schema, RELAX NG/Schematron/DSDL, XPath) were all initially relatively simple and elegant (albeit limited) and became popular, but subsequent consortia-driven "improvements" made them so complex that nobody understands the new versions any more, and only the old versions remain in use. I am concerned that YANG is now bound to the same path.

Lada

> 
> An alternative solution, that works today, is to just have 2 separate, but co-located, leaves:
> - In the future, we could define a YANG extension to bind the config and state leaves together in the model (e.g. a related-config statement).  But I think that we should see how often this issue turns up in practice before we jump to doing this.
> 
> Thanks,
> Rob
> 
>> Lada
>> 
>>> Jason
>>>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jul 2017 15:11:45 +0000

Hi Lada,

<KENT> I just added https://github.com/netmod-wg/yang-next/issues/25.  Note,
this would definitely be in a YANG 2.0 (if done at all), as oppose to in a
YANG 1.2.

<KENT> This is an important point.  Perhaps you're saying that it's better for
us to obsolete/cannibalize ourselves than passively waiting for it to happen.
FWIW, in terms of complexity, I think that schema-mount in particular has 
pushed the YANG-complexity envelope more so than any other recent activity.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Jul 2017 11:05:26 -0700

> On Jul 28, 2017, at 3:34 AM, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> 
>> "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked] <mailto:[email-masked]>> writes:
>> 

Is this true for if-feature statement only?

What happens if I have a ‘must' statement that is written for validating configuration? Will it be enforced on operational datastore?

>>> On 7/24/17, 4:35 PM, "netmod on behalf of Acee Lindem (acee)" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>> on behalf of [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> Hi Jason,
>>> 
>>> From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>>> To: Acee Lindem <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>>> From: Acee Lindem (acee) [mailto:[email-masked] <mailto:[email-masked]>]
>>> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>>> From: netmod <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> on behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>>> To: "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
[email-masked]

---

From: Phil Shafer <[email-masked]>
Date: Fri, 28 Jul 2017 14:13:28 -0400

Mahesh Jethanandani writes:
>What happens if I have a 'must' statement that is written for
>validating configuration? Will it be enforced on operational datastore?

The last paragraph of 4.7 of the NMDA draft talks about constraints
in operational:

So constraints like value space (since the are type-based) cannot
be violated.

IMHO there are few cases where the value spaces differ and those
must be modeled with dual leafs.  This is unfortunate, but is better
than forcing dual leafs on all situations.  As mentioned in the
future we can make a YANG extension statement to tie the two leafs
together.

Thanks,
 Phil

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Jul 2017 11:24:13 -0700

> On Jul 28, 2017, at 11:13 AM, Phil Shafer <[email-masked]> wrote:
> 
>   not hold include "when", "must", "min-elements", and "max-elements”.

Should this be a ‘may not’ or a ‘MUST NOT’? How does one decide whether constraints will apply or not?

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 20:29:05 +0200

> Should this be a ‘may not’ or a ‘MUST NOT’? How does one decide whether constraints will apply or not?

Mahesh,

you report the actual operational state - if the actual operational
state violates constraints, you still report it. What else would you
do?

/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: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Jul 2017 11:34:38 -0700

> On Jul 28, 2017, at 11:29 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Then what you are suggesting is a MUST NOT. That constraints like “when”, “must”, “min-elements”, and “max-elements” MUST NOT be enforced in case of operational state.

> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>>

Mahesh Jethanandani
[email-masked]

---

From: Phil Shafer <[email-masked]>
Date: Fri, 28 Jul 2017 15:08:24 -0400

Mahesh Jethanandani writes:
>   Then what you are suggesting is a MUST NOT. That constraints like
>when, must, min-elements, and max-elements MUST
>NOT be enforced in case of operational state.

I think it's more of a "may" issue.  In the main, these constraints
will remain true, but if the current operational state of the box
violates them, then the box should report the current values even
if/when they violate the containts.  The server will certainly not
enforce these constraint, so the suggestion is to the client, and
telling the client they MUST NOT do something seems odd.

The real point is that the data returned may violate the constraints
and hopefully the current text expresses that.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 28 Jul 2017 23:11:58 +0200

> Then what you are suggesting is a MUST NOT. That constraints like “when”, “must”, “min-elements”, and “max-elements” MUST NOT be enforced in case of operational state.

For <operational>, the constraints are likely more a client-side
utility (if at all); a client can check whether constraints are
violated and if so this can be seen as an _indication_ that the server
may be in a 'bad state'. Note that this can be a transient 'bad state'
and also note that we do not have atomic snapshots of state and hence
what the client sees may also be violating constraints due to changes
of <operational> while retrieving state. Hence, a violation of
constraints noticed on the client side remains just an _indication_ of
a possible 'bad state'.

I think writing "MUST NOT enforced" is not helpful since what would
that enforcement be? Not reporting state that does not exist?  This
will make everybody troubleshooting networks cry. It is essential to
see the truth and not a beautified view of the uglyness if you
troubleshoot a network. Or do you have a different idea what
'enforced' would mean? If we do not define 'enforced', then saying
'MUST NOT enforced' is somewhat pointless. (This is very different
from configuration datastores where we can reject edits if they
violate contraints; we can't reject operational state.)

/js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Jul 2017 18:35:21 -0700

> On Jul 28, 2017, at 2:11 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Juergen,

I am putting on an server implementors hat and wondering how to parse the statement - The constraints that may not hold include "when", "must", "min-elements", and "max-elements”.

As you suggest, the server cannot ignore operational state or not report it. In essence the server is not “enforcing" the must statement even if it exists. It ignores it and all the other constraints when it reports the operational state. The client may, as you suggest “enforce" the constraints if it chooses to. Although, there also what does it mean for the client to not report something from the <operational> that the server has reported? It is after all a state, as you rightly point out.

Constraints therefore have no meaning in <operational> datastore and SHOULD be ignored. How about saying something to that effect? Saying “may not” is at best ambiguous and at worst confusing. 

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 29 Jul 2017 10:04:15 +0200

On Fri, Jul 28, 2017 at 06:35:21PM -0700, Mahesh Jethanandani wrote:
> 
> The client may, as you suggest “enforce" the constraints if it chooses to. Although, there also what does it mean for the client to not report something from the <operational> that the server has reported? It is after all a state, as you rightly point out.
> 

A client can 'check' constraints, I think 'enforce' is the wrong
term. I assume that the client has a perspective on the task it wants
to achieve and hence it should be able to decide whether constraints
matter to the task the client wants to achieve or not.

> Constraints therefore have no meaning in <operational> datastore and
> SHOULD be ignored. How about saying something to that effect? Saying
> “may not” is at best ambiguous and at worst confusing.

I do not know whether RFC 2119 keywords are needed here (after >10
years of trying to get this right I generally declare failure to get
this right) but if RFC 2119 keywords apply than SHOULD and MAY are the
same. Since you negate the statement, it is at the end the same as
what we have. ;-)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 29 Jul 2017 10:07:47 +0200

> same. Since you negate the statement, it is at the end the same as

Oops, I have to correct myself. MAY is a synonym to OPTIONAL and
SHOULD is a synonym for RECOMMENDED. Obviously, I find the current
text sufficient. Well, regarding the question whether RFC 2119
language is needed here, I can't tell.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 31 Jul 2017 17:55:44 +0200

> this would definitely be in a YANG 2.0 (if done at all), as oppose to in a

I suspect it would have very little in common with YANG as we know it,
but I am not suggesting to start such work - my point is that the
config/state schema unification tries to fit a round peg in a square hole.

> us to obsolete/cannibalize ourselves than passively waiting for it to

Not really, what I am saying is that it may be wiser to accept
limitations of YANG architecture instead of stretching it too far. I
agree that foo and -foo state duplicity is suboptimal but I think it is
not THAT bad. In terms of NMDA, I can imagine that schema for
configuration datastores and <operational> be specified separately.

> pushed the YANG-complexity envelope more so than any other recent

I fully agree and I have said it myself several times. My concern applies to
schema mount as well.

Lada