Re: [netmod] upcoming adoptions

[Martin Bjorklund <[e-mail]>]

Robert Wilton <[e-mail]> wrote:
> 
> 
> On 07/09/2017 11:05, Martin Bjorklund wrote:
> > Robert Wilton <[e-mail]> wrote:
> >>
> >> On 07/09/2017 03:36, Andy Bierman wrote:
> >>>
> >>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <[e-mail]
> >>> <mailto:[e-mail]>> 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