Hi, I suggested the naming guideline because the NMDA design team decided to add semantics to certain naming patterns, so authors have to be warned.
But this is a really bad idea (and slippery slope). First we tell everybody "these are just identifiers, pick any string you want", then we want to change it 8 years later to "except these strings which mean special things". The proper deterministic way to identify that the module or subtree is special is to tag it with a YANG extension. Adding semantics to the user-selected identifier space 8 years after dozens of exceptions already exist is not a great plan. If anybody ever actually implements this NMDA stuff, I think they will find it useful to identify modules written for specific datastore usage, or if the module is an NMDA transition module, an I2RS-specific module, etc. The extension you suggested in another email would work. Andy On Thu, Sep 7, 2017 at 4:10 AM, Martin Bjorklund <[email protected]> wrote: > Robert Wilton <[email protected]> wrote: > > > > > > On 07/09/2017 11:15, Martin Bjorklund wrote: > > > 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). > > My logic is slightly different: > > > > I think that new top level containers shouldn't be called ...-state > > because either > > (i) they already contain config nodes, in which case they are > > misnamed, or > > (ii) they might be revised to contain config nodes in the future, in > > which case they would end up being misnamed. > > > > I basically, think that the suffix "-state" doesn't generally provide > > any useful extra information. > > Sure. But there are many suffixes that don't generally provide useful > extra information. I just think we should be careful with these kinds > of rules. Bad names are hopefully catched during the review process. > > > Lower down the tree, I guess that using "state" or "*-state" is OK if > > it can be known that the leaf/container will *always* only be state > > and never potentially be configurable in future. But I still think > > that it is necessary to be very careful here. > > > > For example, If I designed a new routing protocol, then in v1 there > > might be no explicit neighbor configuration, and hence I put all of > > the neighbor information into a container call > > neighbor-state. However, if a v2 version of that protocol (or vendor > > extensions) wants to add some per neighbor configuration then it would > > hit the problem that the original container is poorly named to be > > updated to now also hold configuration. So, generally avoiding > > "-state" in the name of containers seems to be good common sense to > > me. > > I agree. And avoid "*-config". > > > > /martin > > > > I would suggest adding something to 6087bis, but my previous > > suggested additions to 6087bis didn't appear to be well received ;-) > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
