Hi, Robert Wilton <[email protected]> wrote: > Hi Andy, > > > On 25/10/2017 16:54, Andy Bierman wrote: > > > > > > On Wed, Oct 25, 2017 at 4:08 AM, Juergen Schoenwaelder > > <[email protected] > > <mailto:[email protected]>> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
