Hi Kent,
On 18/12/2015 20:56, Kent Watsen wrote:
[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?
Yes, I support #2.
draft-rtgyangdt-rtgwg-device-model-01 is aiming to cover requirement #5,
and is explicitly referencing the previous version of the Netmod
requirements draft.
I would have thought that moving just this into a separate requirements
document would make such a document too short. So would it be
appropriate to temporarily move the section 5 requirements to the next
version of draft-rtgyangdt-rtgwg-device-model? They could always be
removed again at a future date if they are outlived their usefulness.
Thanks,
Rob
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
