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

[Ladislav Lhotka <[e-mail]>]

> On 22 Feb 2017, at 07:59, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> On Wed, Feb 22, 2017 at 03:02:08AM +0000, Sterne, Jason (Nokia - CA) wrote:
>> 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.
>> 
> 
> 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.

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

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

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.   

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

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

> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

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