Re: [netmod] upcoming adoptions

[Robert Wilton <[e-mail]>]

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.

Thanks,
Rob


>
>
> /martin
> .
>