Re: [netmod] upcoming adoptions

[Robert Wilton <[e-mail]>]

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.

>
>
>
>     > 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.

Thanks,
Rob


>
> (Automation tools like deterministic rules, not naming conventions.
> Here is an example why... there are always exceptions that do not follow
> the conventions. Always people who are unaware of the conventions.)
>
>
>
>     K.
>
>
>
>
> Andy
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod