On 07/09/2017 11:05, Martin Bjorklund wrote:
Robert Wilton <rwil...@cisco.com> wrote:

On 07/09/2017 03:36, Andy Bierman wrote:

On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <kwat...@juniper.net
<mailto:kwat...@juniper.net>> 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.

Thanks,
Rob




/martin
.


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to