Subject: Re: [netmod] netmod-revised-datastores: templates, interactions with RFC6243 'report-all'

From: Kent Watsen <[email-masked]>
Date: Thu, 16 Feb 2017 22:30:00 +0000

Hi Jason,

> draft-nmdsdt-netmod-revised-datastores-00 mentions that “Templates
> are expanded when copied into <intended>”.
>
> That means the non-expanded template (i.e. the single copy of template data itself)
> is in the running.

Yes.

> Is that original non-expanded template data (which is presumably part of the schema)
> also present in the <intended> DS (along with the expanded copies of the data) ?

Yes, the YANG would have to define schema for both the template and expanded forms.
No, having both data values in 'intended' that would be redundant and confusing.

> What would an RFC6243 <get-config> response from the <running> DS with ‘report-all’
> be expected to return for a leaf that is deleted in the ‘main’ part of the config but has
> been overridden by a value for that leaf in a template ?

RFC6243 'report-all' doesn't have any template awareness, it only relates to default
values.   Assuming the deleted leaf has a default value, then that default value would
be reported and, when using 'report-all-tagged', it would be tagged as such.

> Example -> some leaf-a with a default value of 50, that is not present in the config, but
> is present in a template that sets leaf-a to 55.   A ‘report-all’ response could show a
> value for leaf-a in the template and in the main part of the config.  What value would
> be returned for leaf-a in the main part of the config ?  50 (since ‘running’ doesn’t have
> expanded templates) or 55 (i.e. the result of the value of leaf-a due to the template
> expansion) ?

50.

> The spirit of report-all seems to be to reflect what values the router is using, even when
> they aren’t explicitly configured.  So 55 is the actual value being used in the system.  But
> returning 55 would mean we are returning the ‘expanded’ view (which the running isn’t
> supposed to have).

What is needed is a <get-config> flag like 'report-inheritance' that does some combination
of template-expansion and returning metadata for where values came from.  However, this
is only going to be defined when someone writes a "template" draft.

Kent (as a contributor)

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Feb 2017 13:27:03 +0100

> Yes, the YANG would have to define schema for both the template and

Are you saying that running and intended (may) have different schemas?
The draft indicates that only intended is subject to validation. Either
way, it significantly changes the rules of the game because validation
in RFC 7950 is bound to running.

I cannot help myself: we need to remove all dependecies on protocols,
specific datastores and data representation (encoding) from the YANG spec in
order to make it generally applicable.

Lada

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

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

---

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Feb 2017 14:53:48 +0000

Hi Lada,

>in RFC 7950 is bound to running.

I've been assuming that there is only one configuration schema, but that the template schema wouldn't apply in the intended datastore.  This might be an academic distinction if <edit/copy-config>, or RESTCONF's unified datastore, only act on the running datastore.  Yes, we'd want to support read-only operations on 'intended', but I'm not entirely sure about read-write operations, including the <lock> or even the <validate> operations.

Regarding moving validation from running to intended, I think that Section 6.3 might be just poorly worded.  At least, I took it to mean that semantic validation conceptually takes place after the system has removed inactive data and flattened templates.  Not only does it seem intuitive, but it also helps simplify must/when/etc. expressions, as they only need to target the expanded/flattened template paths.

> specific datastores and data representation (encoding) from the YANG
> spec in order to make it generally applicable.

I made a similar comment recently here: https://www.ietf.org/mail-archive/web/netconf/current/msg12356.html.  Read the remainder of the thread to see the response there.

That said, I definitely think that a 7950bis should remove all of the XML and NETCONF encoding text in RFC7950.  A number of these kinds of changes are being tracked here: https://github.com/netmod-wg/yang-next/issues.

Kent  // as an author

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Feb 2017 16:49:23 +0100

> On 20 Feb 2017, at 15:53, Kent Watsen <[email-masked]> wrote:
> 
> 
> Hi Lada,
> 
> 
> I've been assuming that there is only one configuration schema, but that the template schema wouldn't apply in the intended datastore.  This might be an academic distinction if <edit/copy-config>, or RESTCONF's unified datastore, only act on the running datastore.  Yes,

I think my problem is rather the opposite: could running containing templates be invalid? Of course, it depends on how templates work, which isn't clear from the document (yet).

>  we'd want to support read-only operations on 'intended', but I'm not entirely sure about read-write operations, including the <lock> or even the <validate> operations.
> 

OK, but RFC 7950 list a number of properties that must be true in "all data trees". I suspect that running (or candidate) with unexpanded templates might break some of these properties.

> I made a similar comment recently here: https://www.ietf.org/mail-archive/web/netconf/current/msg12356.html.  Read the remainder of the thread to see the response there.

Yes, this has been discussed several times, in fact I proposed it even before work on YANG 1.1 had started (at IETF 87). Juergen wants to have an architecture document first, but I think we could instead limit the scope of YANG, make it into kind of schema language for hierarchical data, and use as a building block that does validation.

Lada

---

From: "Mehmet Ersue" <[email-masked]>
Date: Mon, 20 Feb 2017 19:54:49 +0100

> > I made a similar comment recently here:
https://www.ietf.org/mail-archive/web/netconf/current/msg12356.html.  Read
the remainder of the thread to see the response there.
>
> Yes, this has been discussed several times, in fact I proposed it even
before work on YANG 1.1 had started (at IETF 87). Juergen wants to have an
architecture document first, but I think we could instead limit the 
> scope of YANG, make it into kind of schema language for hierarchical data,
and use as a building block that does validation.

I fully agree and strongly support making YANG generally applicable and
independent of protocols and datastores.
We also agreed to put out encoding rules for particular protocols out of
YANG specification.

Mehmet

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Ladislav
> Lhotka
> Sent: Monday, February 20, 2017 4:49 PM
> To: Kent Watsen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] netmod-revised-datastores: templates, interactions
> with RFC6243 'report-all'
> 
> 
> >> The draft indicates that only intended is subject to validation.
> >> Either way, it significantly changes the rules of the game because
> >> validation in RFC 7950 is bound to running.
> >
> > I've been assuming that there is only one configuration schema, but
> > that the template schema wouldn't apply in the intended datastore.
> > This might be an academic distinction if <edit/copy-config>, or
> > RESTCONF's unified datastore, only act on the running datastore.  Yes,
> 
> I think my problem is rather the opposite: could running containing
templates
> be invalid? Of course, it depends on how templates work, which isn't clear
> from the document (yet).
> 
> >  we'd want to support read-only operations on 'intended', but I'm not
> entirely sure about read-write operations, including the <lock> or even
the
> <validate> operations.
> >
> > Regarding moving validation from running to intended, I think that
Section
> 6.3 might be just poorly worded.  At least, I took it to mean that
semantic
> validation conceptually takes place after the system has removed inactive
> data and flattened templates.  Not only does it seem intuitive, but it
also
> helps simplify must/when/etc. expressions, as they only need to target the
> expanded/flattened template paths.
> 
> OK, but RFC 7950 list a number of properties that must be true in "all
data
> trees". I suspect that running (or candidate) with unexpanded templates
> might break some of these properties.
> 
> >
> >
> > I made a similar comment recently here: https://www.ietf.org/mail-
> archive/web/netconf/current/msg12356.html.  Read the remainder of the
> thread to see the response there.
> 
> Yes, this has been discussed several times, in fact I proposed it even
before
> work on YANG 1.1 had started (at IETF 87). Juergen wants to have an
> architecture document first, but I think we could instead limit the scope
of
> YANG, make it into kind of schema language for hierarchical data, and use
as
> a building block that does validation.
> 
> Lada
> 
> >
> > That said, I definitely think that a 7950bis should remove all of the
XML and
> NETCONF encoding text in RFC7950.  A number of these kinds of changes are
> being tracked here: https://github.com/netmod-wg/yang-next/issues.
> >
> >
> > Kent  // as an author
> >
> >
> 
> --

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Wed, 22 Feb 2017 03:02:08 +0000

I think that an implementation that supports templates can indeed have the situation where the running is not valid.  The template (when expanded) may provide data that completes the data in a way that makes it valid.

I can see how it is intuitive to consider that validation happens after template expansion.  But it does break the letter of the RFC.

Jason

> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Monday, February 20, 2017 10:49
> Cc: Sterne, Jason (Nokia - CA) <[email-masked]>; [email-masked]
> Subject: Re: [netmod] netmod-revised-datastores: templates, interactions with
> RFC6243 'report-all'
> 
> 
> I think my problem is rather the opposite: could running containing templates
> be invalid? Of course, it depends on how templates work, which isn't clear from
> the document (yet).
> 
> >  we'd want to support read-only operations on 'intended', but I'm not entirely
> sure about read-write operations, including the <lock> or even the <validate>
> operations.
> >
> > Regarding moving validation from running to intended, I think that Section
> 6.3 might be just poorly worded.  At least, I took it to mean that semantic
> validation conceptually takes place after the system has removed inactive data
> and flattened templates.  Not only does it seem intuitive, but it also helps
> simplify must/when/etc. expressions, as they only need to target the
> OK, but RFC 7950 list a number of properties that must be true in "all data
> trees". I suspect that running (or candidate) with unexpanded templates might
> break some of these properties.
> 
> >
> >
> Yes, this has been discussed several times, in fact I proposed it even before
> architecture document first, but I think we could instead limit the scope of
> YANG, make it into kind of schema language for hierarchical data, and use as a
> building block that does validation.
> 
> Lada
> 
> >
> > That said, I definitely think that a 7950bis should remove all of the XML and

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Wed, 22 Feb 2017 03:02:05 +0000

Thanks Kent.

About the presence of template data in the ‘intended’ -> I can see your point about it being redundant but Juergen’s initial gut feel was to have it present.  I guess this is something that we’ll need to decide and describe somewhere as it may not be obvious. I’m not sure if that is for the datastores draft or for some potential future ‘templates’ draft).

You mentioned “Assuming the deleted leaf has a default value”.  Do you make a distinction between a default value that is present in the schema (i.e. a ‘default’ statement in the YANG) vs an internal default value that the system may use but isn’t exposed in the YANG ?   Another way of saying this -> is ‘report-all’ required to only return values that are in the ‘default’ statements of the YANG schema ?

One example -> an incomplete YANG schema that is missing the default value statement for some leaf abc.  But the system knows the default and can return it in a ‘report-all’ query.

Another example -> what about a leaf that has a dynamic default value ?  For example -> an interface mtu that can be explicitly configured by the user, but if that leaf is deleted then the system selects different values X or Y depending on whether the interface is using dot1q encap vs null ethernet.  That dynamic type of default can’t really be expressed in YANG.  But the system could report the value X or Y in a ‘report-all’ query.

Would we really need ‘report-inheritance’ if we add the ability to read the ‘intended’ datastore ?

Jason

From: Kent Watsen [mailto:[email-masked]]
Sent: Thursday, February 16, 2017 17:30
To: Sterne, Jason (Nokia - CA) <[email-masked]>; [email-masked]
Subject: Re: [netmod] netmod-revised-datastores: templates, interactions with RFC6243 'report-all'

Hi Jason,

Yes.

50.

Kent (as a contributor)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Feb 2017 07:59:42 +0100

> I can see how it is intuitive to consider that validation happens after template expansion.  But it does break the letter of the RFC.

Templates are interesting since (a) template data should be valid and
(b) the expanded config should be valid. My understanding is that both
are desirable.

The RFCs do not talk about templates and hence people seem to have
different interpretations and I do not think it valid to say that
interpretations break the letter of the RFC. (And I think it would
help if you point to the RFC statements that you think clarify
template behaviour.)

The WG needs to decide what the expectations are for templates and
whether validity of templated config means just (a), just (b) or both
(a) and (b). I actually think it should be (a) and (b) but there might
be implementations that only do (a) or only do (b).

/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: Wed, 22 Feb 2017 08:41:55 +0100

> On 22 Feb 2017, at 07:59, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Agreed, but either may then need a different data model. For example, where "yang-identifier" leaf is permitted in expanded data, a template may use globs or regular expressions (that's one way of templating I know from CLIs).  

> help if you point to the RFC statements that you think clarify

So far the idea has been that a data model (i.e. YANG Library and modules listed therein) encompasses basically all data that a server deals with. So, for example, RFC 7950 says that all data trees must satisfy certain conditions. This will no more be the case with templates, at least not with the same data model.   

> be implementations that only do (a) or only do (b).

We now have:

1. YANG as a language for specifying schema, datatypes and constraints.

2. YANG library as a means for composing YANG modules into data models.

What's IMO needed is

3. a formalism for binding data models to specific checkpoints in a network management workflow (such as intended or ephemeral datastore). Different use cases may have different datastores and workflows, and that's why I believe this has to be "parametrised".

RFC 6020/7950 does #3 in a relatively rigid way that really works only for the NETCONF protocol (which was of course the original aim).

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Feb 2017 09:31:15 +0100

> 1. YANG as a language for specifying schema, datatypes and constraints.

YANG also defines when and how constraints are expected to be checked. Are
you saying we should remove this, i.e., have a language where I can write
down must constraints but leave it open when and how they are checked?

> 2. YANG library as a means for composing YANG modules into data models.

YANG library reports the set of YANG modules implemented. I do not think
it does composition of YANG modules into data models.

> RFC 6020/7950 does #3 in a relatively rigid way that really works only for the NETCONF protocol (which was of course the original aim).

I do not agree with the statement that the model used by YANG only
works for the NETCONF protocol. The question is whether

(a) we can agree on a common datastore model with clearly defined
    semantics such that it simplifies implementations of clients and
    servers since datastore semantics are predictable (this is what
    the datastore design team has been working on)

(b) or we raise the bar for clients by requiring that clients obtain
    sufficient information about the specific workflow supported by a
    server so that they can reliably map a configuration change
    request to the appropriate datastore the server likes to have
    modified.

My fear is that (b) significantly raises the bar and thus many clients
in reality will simply assume certain datastore semantics and then
fail to interoperate with other servers. We may get back to vendor
specific silos.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Feb 2017 11:22:22 +0100

> On 22 Feb 2017, at 09:31, Juergen Schoenwaelder <[email-masked]> wrote:
> 

The semantics of constraints are mostly defined in terms of a data tree, child nodes etc. that are pretty universal. Accessible trees for evaluating XPath have specific definitions, such as state data + running, but the XPath semantics don't really depend on this - the tree just has to be defined somehow. 

> down must constraints but leave it open when and how they are checked?

Yes. Even now, you can write a must constraint referring to a node that may not eventually exist in the data model (because the corresponding module isn't implemented). YANG modules are just building blocks, it is the data model that has to make sense as a whole.

> it does composition of YANG modules into data models.

So what's your definition of a data model? For me it's exactly what YANG Library says, including supported features etc. Schema mount could be an additional part of this. The point is that implementations and tools that want to do validation have to be able to compose the schema of the entire data tree, and the result is what I call the data model. 

> works for the NETCONF protocol. The question is whether

Well, yes, you can use it for any protocol as long as it has certain datastores and operations, or if you selectively ignore/reinterpret parts of RFC 7950. Sample from sec. 8.3.3:

If the datastore is "running" or "startup", these constraints MUST be enforced at the end of the <edit-config> or <copy-config> operation.  If the datastore is "candidate", the constraint enforcement is delayed until a <commit> or <validate> operation takes place.

>    the datastore design team has been working on)

I doubt that any particular datastore model can work for everybody. What's in the revised-datastore draft is already way too complex for some use cases but, on the other hand, other use cases may need something different or more complicated. 

> fail to interoperate with other servers. We may get back to vendor

I don't mean that implementations will necessarily have to dynamically parse and set up such a workflow - a protocol definition could simply specify a particular workflow, or a few related ones. In fact, already NETCONF covers a number of workflows that are used in the wild, including

- persistent and writable running

- persistent startup + writable ephemeral running

- persistent startup + persistent writable candidate + ephemeral read-only running

I also suspect that most troubles I2RS folks have had with YANG were due to the need to retrofit their workflow to that of NETCONF.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Feb 2017 11:34:45 +0100

> Yes. Even now, you can write a must constraint referring to a node that may not eventually exist in the data model (because the corresponding module isn't implemented). YANG modules are just buildi…

YANG says very clearly what it means for a configuration datastore to
be valid and we have a common understanding that the <running>
datastore is always kept valid.
 
> So what's your definition of a data model? For me it's exactly what YANG Library says, including supported features etc. Schema mount could be an additional part of this. The point is that implemen…

OK. Certainly one way to look at things.

> I doubt that any particular datastore model can work for everybody. What's in the revised-datastore draft is already way too complex for some use cases but, on the other hand, other use cases may n…

Not every datastore needs to be in every implementation or accessible over
every protocol. If this is not stated clearly enough, we may need to improve
the writing.

> I also suspect that most troubles I2RS folks have had with YANG were due to the need to retrofit their workflow to that of NETCONF.

So you want per protocol datastore models? How do you then deal with
implementations that have to support multiple protocols, i.e.,
multiple data store models? How do you ensure that all combinations
you get can be implemented meaningful together?

But then, you wrote 'different use cases' and not 'differnet
protocols' so it did sound like you want even different use cases with
the same protocol to use different datastore semantics and workflows.
It seems there is a flexibility - complexity tradeoff here.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Feb 2017 13:45:20 +0100

> On 22 Feb 2017, at 11:34, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Yes, but what we are now discussing are several different configuration datastores - running, intended, maybe other - and validity may mean something different in each, even validity in terms of schema or datatypes.

> every protocol. If this is not stated clearly enough, we may need to improve

How can a client learn which datastores are actually implemented? Trial and error, or via capabilities?

> you get can be implemented meaningful together?

Clever clients supporting multiple datastore models could probably be written but I don't think it is a general requirement. Similarly, a NETCONF client can be designed to work only with writable running, or with a very particular data model - does it mean it is non-compliant?

Unlike very generic protocols such as TCP or HTTP, network management tools can mostly be selected specifically for the network at hand - and be more or less flexible. I can accept that tools designed for remote management of IoT devices cannot be used for backbone router configuration.

> It seems there is a flexibility - complexity tradeoff here.

OK, it depends on how the terms are defined, so yes, maybe I should have written "application" rather than "protocol". And yes, I do think it makes sense to develop applications that, for example, use the syntax and semantics of RESTCONF messages but not the exact structure of resources prescribed in RFC 8040. If RESTCONF is to support the revised datastore model, will it require a new protocol?

Lada