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).
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"?
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
