Kent Watsen <[email protected]> writes: > [As a contributor] > > Hi Juergen, > > I agree with you that req #5 sticks out as the odd ball in the bunch. I > suggested once to remove it a long time back, but I guess it fell on deaf > ears then. Anyway, given where we are with this document, I’m unsure what to > do, but here are our options: > > 1. Leave requirement #5 in the document, but spend time improving it to WG > satisfaction. > > 2. Take requirement #5 out, declaring it an unwanted distraction from the > primary opstate focus. We’d have to be sure to get sign-off from the OC > folks too... > > So far it sounds like Juergen and I are with #2, how about others?
I prefer #2. Lada > > Thanks, > Kent > > > > > > On 12/18/15, 2:59 AM, "Juergen Schoenwaelder" > <[email protected]> wrote: > >>On Thu, Dec 17, 2015 at 09:27:12PM +0000, Kent Watsen wrote: >>> [As a contributor] >>> >>> Thank you for the review Juergen. >>> >>> Great suggestions. If no one objects, I’ll incorporate them into the next >>> revision of the document after last call. >>> >>> My one comment is that I don’t believe the document is limited to the >>> introduction of applied configuration. For instance, the relating of config >>> to derived state and also the model structure requirement are not related >>> to applied config. In all fairness, Requirement #5 (model structure) isn’t >>> even about operational state. >> >>Reading #5 again I must admit that I do not really understand what >>this requirement tries to accomplish: >> >> 5. Ability for distinct modules to leverage a common model-structure >> >> A. Focus on the IETF-defined modules, and ideally provides >> guidance to other SDOs >> >> B. Multiple domain-specific model-structure trees are okay >> >> C. Model-structures may be defined in multiple modules with >> distinct namespaces >> >>At this level of abstraction, #5 really does not mean anything or N >>people will have at least N different interpretations of it. I >>actually think this should be taken out and moved into a different >>document and then it requires to be developed into something much more >>concrete. >> >>/js >> >>> So your title and abstract suggestions might define too narrow a scope. So >>> how about: >>> >>> Title: Terminology and Requirements for Operational State and Model >>> Structure >>> >>> Abstract: >>> This document defines requirements for enhancing the support >>> of operational state through the introduction of a conceptual >>> "applied configuration". The document also defines requirements >>> enabling distinct modules to leverage a common model structure. >>> >>> …and add an Introduction section that expands on this theme further? >> >>I think this is getting into the wrong direction and as explained >>above #5 is by far underspecified to be of any value. I suggest to >>take it out so that we can publish the rest in a timely manner. The >>alternative is to hold off this document in an attempt to replace #5 >>with something that is concrete and actionable. >> >>/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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
