Robert Wilton <[email protected]> wrote: > > > On 07/09/2017 11:05, Martin Bjorklund wrote: > > Robert Wilton <[email protected]> wrote: > >> > >> On 07/09/2017 03:36, Andy Bierman wrote: > >>> > >>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> > >>> > >>> >> /netconf-state and /restconf-state don't seem to follow the > >>> >> general > >>> >> pattern we're correcting with the various NMDA updates. > >>> Particularly, > >>> >> these -state trees are NOT for the purpose to providing the > >>> >> opstate > >>> >> value for configured nodes. These modules have the misfortune of > >>> >> having "-state" in their name, but they're otherwise fine. > >>> > > >>> > > >>> > This contradicts some details we have been told about NMDA > >>> > > >>> > 1) the transition guidelines say otherwise > >>> > > >>> > New modules and modules that are not concerned with the > >>> > operational state of configuration information SHOULD > >>> > immediately be structured to be NMDA-compatible > >>> > >>> Yes, I'm suggesting we give ourselves some leeway, by taking > >>> advantage of the SHOULD keyword above and defer updating these > >>> two modules to when it makes more sense to do so. > >>> > >>> > >>> > >>> OK -- good. > >>> I think another sentence needs to be added. > >>> > >>> > >>> NMDA compatibility conversion MAY be deferred if the module > >>> does not contain any configuration datastore objects. > >> I agree. > > +1 > > > > > >>> > 2) RD defines operational state to include config=false nodes > >>> > such as counters, so these modules are properly named. > >>> > >>> module-name == top-level node name. Either way, my point is that > >>> the -state tree in these modules is not trying to provide the > >>> opstate value for configured nodes (i.e. applied configuration). > >>> > >>> > >>> So a data node naming convention is needed? > >>> And a module naming convention? > >>> > >>> We need a rule that says the suffix "-state" is reserved for NMDA > >>> compatibility > >>> so module names and data nodes SHOULD NOT be named with an identifier > >>> that > >>> ends in this suffix. > >> Also agree. > > -1 > > > > There are cases where a -state suffix is natural, e.g. in > > ietf-hardware we have admin-state, oper-state, usage-state etc. > > > > I prefer to have a recommendation that generated modules and top-level > > nodes are called ...-state, but that should not be a reason for making > > -state illegal in general. > Sorry, it was specifically modules and top level data nodes that I > think this restriction should apply to.
Even in this case I'd prefer to make a one-way recommendation. Is there a technical reason for not allowing a normal module or top-level node be called ...-state? IMO, *if* it is important to mark these modules as being generated, we should use a formal way to convey this information, not rely on a naming convention. (i.e., use a YANG extension in the module). /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
