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

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Feb 22, 2017 at 08:41:55AM +0100, Ladislav Lhotka wrote:
> 
> > 
> > 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.

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.

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

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

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