> On 08 Jan 2016, at 14:17, Martin Bjorklund <m...@tail-f.com> wrote: > > Ladislav Lhotka <lho...@nic.cz> wrote: >> >>> On 08 Jan 2016, at 13:53, Martin Bjorklund <m...@tail-f.com> wrote: >>> >>> Ladislav Lhotka <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. >>> >>> Well, the applied config is part of the operational state, and there >> >> According to 6020bis, state data are tagged with "config false" in >> YANG modules. I don't think it is going to be the case of applied >> configuration. > > Right; but this term "state data" is more like the new term "derived > state" (which I think is a bit unfortunate - derived from what?)
For me, operational state exists independently of management interfaces, applied configuration doesn't - it is an artefact. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
