[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? Thanks, Kent On 12/18/15, 2:59 AM, "Juergen Schoenwaelder" <j.schoenwael...@jacobs-university.de> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
