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

[Andy Bierman <[e-mail]>]

On Wed, Oct 25, 2017 at 10:14 AM, Martin Bjorklund <[e-mail]> wrote:

> Hi,
>
> Robert Wilton <[e-mail]> wrote:
> > Hi Andy,
> >
> >
> > On 25/10/2017 16:54, Andy Bierman wrote:
> > >
> > >
> > > On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder
> > > <[e-mail]
> > > <mailto:[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.
> > Are you referring to this text, or something else:
> >
> > 5.6.5.  Implementing a Module
> >
> >    A server implements a module if it implements the module's data
> >    nodes, RPCs, actions, notifications, and deviations.
> >
> >    A server MUST NOT implement more than one revision of a module.
> >
> > If, so, then we still agree with this constraint, and this hasn't
> > changed for NMDA.  I think that YANG library should make this clear in
> > the list of modules.
> >
> > But I don't think that text specifically prevents different deviations
> > or features for different datastores ...
> >
> > >
> > > 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.
> >
> > The NMDA draft already states that the schema for all conventional
> > configuration datastores must be the same (meaning that all deviations
> > and features must be the same as well):
> >
> > 5.1. Conventional Configuration Datastores
> >
> >    The conventional configuration datastores are a set of configuration
> >    datastores that share exactly the same schema, allowing data to be
> >    copied between them.
> >
> >
> > So, I think that the main question is about how the schema for
> > <operational> can differ from the configuration datatstores.
> >
> > We want to allow different features to be supported in running vs
> > operational, so that feature statements can be useful to turn off
> > features that may be supported by a device, but might not be
> > externally configurable (e.g router-id).  But we could partially
> > constrain their use.  So I propose that we add the following extra
> > sentence to the NMDA draft on section 5.3  The Operational State
> > Datastore (<operational>).
> >
> > My proposed NEW text is:
> >
> > If a YANG feature is supported for a module in any configuration
> > datastore then it SHOULD also be supported in <operational>.  This is
>
> I think this should be a MUST; if something is supported in the
> conventional datastores, then the same schema must be used for the
> applied config.
>
> > to allow the applied configuration and any other operational state
> > associated with that feature to be available.  The inverse constraint
> > does not hold, a server MAY support a feature in <operational> without
> > also supporting it in any configuration datatstore.
>
> I agree.
>

I disagree


>
> > I'm not sure that it makes sense to constrain deviations to be the
> > same for all datastores, since these are the mechanism for reporting
> > why a server doesn't conform to the standard ...
>
> I agree.
>
>
I disagree


Features and deviations are are part of the one implementation.
Features are not mentioned in the cited text because they are inherently
optional and do not have to be implemented.

There is no text in RFC 7950 that supports the notion that an
if-feature-stmt
or a deviation-stmt can apply to a specific datastore.  It applies to the
object.

Good luck getting client developers to support conflicting schema trees
for the same module. Good luck comparing <running> to <operational>.




>
> /martin
>


Andy