Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

[Robert Wilton <[e-mail]>]

On 10/01/2016 11:21, Juergen Schoenwaelder wrote:
> On Fri, Jan 08, 2016 at 01:46:44PM +0000, Acee Lindem (acee) wrote:
>> The draft is quite succinct and I’m not sure how you and Juergen do not
>> agree that there are requirements beyond intended/applied state. Perhaps
>> you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
>> For your convenience, I’ve excerpted them below:
>>
>>
>>     3.  Separation of the applied configuration and derived state aspects
>>         of operational state; ability to retrieve them independently and
>>         together
>>
>>         A.  Be able to retrieve only the applied configuration aspects of
>>             operational state
>>
>>         B.  Be able to retrieve only the derived state aspects of
>>             operational state
> This is nothing new. See for example section 4.3.3.2 of RFC 6244.
>
>>         C.  Be able to retrieve both the applied configuration and
>>             derived state aspects of operational state together
> Did you notice that 3.C talks about 'applied configuration'?
>   
>>     4.  Ability to relate configuration with its corresponding
>>         operational state
>>
>>         A.  Ability to map intended config nodes to corresponding applied
>>             config nodes
>>
>>         B.  Ability to map intended config nodes to associated derived
>>             state nodes
>>
>>         C.  The mappings needs to be programmatically consumable
> I do not agree that 4.B and 4.C require to broaden the title.
>
> In fact, I wonder why 4.B is useful. If we agree that the applied
> config (an extended subset of the intended config) is the configration
> that determines what the device is doing, then we likely should have a
> mapping of the applied config to associated derived state.
Yes, in essence the relationship is intended config => applied config => 
derived state.  So I would say that derived state has a transitive 
association with the intended config.

Personally, I think that the relationship should be expressed in the 
reverse direction.  I.e. a particular node of derived state should be 
allowed to refer back to the config (intended/applied) that is derived 
from.  This is presumably an implementation detail rather than a 
requirement.

However, I'm not sure that we actually need to change the text, I think 
that the requirement text is probably sufficiently clear to compare 
solutions.

Thanks,
Rob


>
> /js
>