On 1/8/16, 7:47 AM, "netmod on behalf of Ladislav Lhotka"
<netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
>Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes:
>
>> On Thu, Jan 07, 2016 at 05:24:45PM +0000, Robert Wilton wrote:
>>> Hi Juergen,
>>>
>>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote:
>>> >On Wed, Jan 06, 2016 at 06:18:46PM +0000, Kent Watsen wrote:
>>> >>It’s true that the draft is largely centered around the
>>> >>intended/applied config notion, but not exclusively. Specifically,
>>>4-B
>>> >>has "Ability to map intended config nodes to associated derived
>>>state
>>> >>nodes". I think that this might be the only exclusion though and,
>>>if it
>>> >>weren’t for it I would’ve used your title suggestion from the LC
>>> >>review. Should one requirement have such influence over the title
>>>is
>>> >>the question. I was trying to be fair to it, but maybe it's going
>>>too
>>> >>far.
>>> >>
>>> >>Regarding visibility and control, I was attempting to use common
>>>words
>>> >>(not normative terms) here. My intent for them is something along
>>>the
>>> >>lines of:
>>> >>
>>> >> visibility: read/understand
>>> >> control: write/orchestrate
>>> >>
>>> >We do not write operational state. I have no clue how 'orchestrate'
>>> >helps me either. What is wrong with using defined terminology in
>>> >a title?
>>> I don't think that using defined terminology is a problem. But I also
>>> think that the title that you have suggested seems to suggest a
>>>narrower
>>> scope that what the requirements articulate.
>>>
>>> In particular, the draft places requirements relating the
>>>configuration
>>> to the derived state (I.e. Req 4B).
>>>
>>> It also places further requirements on how management protocols are
>>> expected to handle synchronous and asynchronous config edit requests.
>>> (E.g. Req 2 A, B, C and associated definitions).
>>
>> Note that synchronous and asynchronous are defined in terms of
>> intended / applied configuration.
>>
>>> I don't have a particular problem with the current title, but if you
>>> don't like visibility/control, then perhaps "Terminology and
>>> Requirements for Enhanced Handling of Operational State"?
>>
>> Better but I still think this proposal is too broad given the content
>> of the document. I still believe my proposal is right to the point.
>
>+1
>
>The draft talks about introducing applied configuration and its
>relationship to state data and intended configuration (which, I believe,
>is the good old "running"). I don't see any enhanced handling of
>operational state.
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
C. Be able to retrieve both the applied configuration and
derived state aspects of operational state together
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
Thanks,
Acee
>
>Lada
>
>>
>> /js
>>
>> --
>> Juergen Schoenwaelder Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
