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

[Martin Bjorklund <[e-mail]>]

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



/martin