> On 08 Jan 2016, at 14:46, Acee Lindem (acee) <a...@cisco.com> wrote: > > > > 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: >
Well, opstate-reqs defines applied configuration and *proclaims* it to be a part of operational state, whereas it is a new artefact that has to do with how the server processes configuration. With two exceptions commented on below, the requirements really are directly related to the introduction of applied configuration. In other words: for those who don't want to use applied configuration, there is very little benefit in terms of enhanced handling of operational state. > > 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 Yes, the inability to retrieve state data separately is a known shortcoming of NETCONF, and Andy proposed a solution long ago. RESTCONF has this function out of the box. > > 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 This might be useful but I think it will only have a limited value because it can't capture all possible semantics of such associations. For example, we can indicate in the data model that static routes are associated with RIBs, but it won't be possible to specify how (formally). Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
