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. 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
