Re: [netmod] upcoming adoptions

[Robert Wilton <[e-mail]>]

On 07/09/2017 11:15, Martin Bjorklund wrote:
> 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).
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.

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 would suggest adding something to 6087bis, 
but my previous suggested additions to 6087bis didn't appear to be well 
received ;-)

Thanks,
Rob

>
>
> /martin
> .
>