> 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. Lada > are requirements for retrieval of the operational state. So it is > related. I think the current title is fine. > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
