Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?

[Andy Bierman <[e-mail]>]

On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> It seems we are jumping between topics. I will skip over comments
> concerning the YANG library and whether it is OK or not OK that YANG
> library allows different schemas in different datastores.
>
\
\

Actually, this is the only issue that matters.

I decided that no special text is needed because the YANG library is
violating a MUST requirement
in RFC 7950 and needs to be changed.

There can only be one implementation of a module per server, not per
datastore.
Therefore a module MAY appear in multiple module-sets, but it MUST NOT
be different.  The exact same revision, features, and deviations MUST be
present
in each instance.

Andy



> On Tue, Oct 24, 2017 at 11:21:54AM -0700, Andy Bierman wrote:
> > On Tue, Oct 24, 2017 at 10:21 AM, Juergen Schoenwaelder <
> > [e-mail]> wrote:
> >
> > > On Tue, Oct 24, 2017 at 10:13:35AM -0700, Andy Bierman wrote:
> > > >
> > > > IMO the more complex NMDA is to implement, the less likely it will
> > > > be implemented.  If you want the tools to figure out the correct
> > > > datastore(s) from description-stmts instead of something
> > > > deterministic and machine-usable, NMDA is less likely to be
> > > > implemented.
> > >
> > > There is nothing machine readable today that tells you which argument
> > > of get-config identifies the datastore that is being accessed by
> > > get-config. Our reasoning is that for most actions that default is
> > > going to do the right thing. If there is a need to have further
> > > language support to handle the cases where operations may relate to
> > > datastores different than operational, then this should be taken up by
> > > a future version of YANG.
> > >
> > >
> > There is only 1 schema tree now in pre-NMDA so it is easy to parse
> > instance data against the one and only set of modules.
> >
> >
> >
> > > > Given that the same objects can be defined differently in each
> > > > datastore in NMDA, it is especially useful to know which set of YANG
> > > > modules applies, before parsing instance data against those modules.
> > >
> > > I am not sure I parse this correctly.
> > >
> >
> > The new YANG library requires the implementation to know the datastore
> > to pick the correct set of modules for the datastore used in the
> operation.
> > Module sets are allowed to overlap, so the same module can be different
> > in <running> vs. <operational>.
> >
> > Developers unaware of the new NMDA complexities should read the drafts
> > again.
> >
> >
> >
> > >
> > > > (2) Define <action2>:
> > > > >
> > > > > I'm not convinced that this is really required/helpful, given that
> most
> > > > > actions are likely to only apply to operational.  If it turns out
> that
> > > this
> > > > > is particularly useful then I would propose that this is deferred
> > > until a
> > > > > future revision of NETCONF, particularly because we are trying to
> keep
> > > the
> > > > > NETCONF NMDA and RESTCONF NMDA drafts as small as possible.
> > > > >
> > > > > Is this OK?
> > > > >
> > > >
> > > > The NMDA theme has been to declare things that are possible in
> pre-NMDA
> > > > but not supported in post-NMDA to be not useful, so this can be left
> to
> > > > vendors I guess.
> > >
> > > Not sure I understand this either.
> > >
> > > If you have a concrete change proposal, perhaps the discussion becomes
> > > more concrete and productive.
> > >
> >
> >
> > I already said to declare that <action> is invoked in <operational>.
> Period.
> > No description-stmt exceptions.
> >
> > If another datastore is needed, use rpc-stmt instead of action-stmt.
>
> So you are fine if for RPCs description statements can define which
> datastores are affected by an RPC? I probably did not get that you
> make a distinction between actions and RPCs here.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>