[As a contributor] As I count it, there are four in favor and two not in favor of the title proposed by Robert, so I’m going to post -03 with that one.
Kent On 1/8/16, 9:26 AM, "netmod on behalf of Ladislav Lhotka" <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote: > >> 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
