Subject: [netmod] review of draft-ietf-netmod-opstate-reqs-01

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Dec 2015 19:16:28 +0100

Hi,

reviewing as technical contributor....

a) Title:

     NETMOD Operational State Requirements

   I do not think having a WG name in the title is useful in the
   long-term. WGs come and go, technology stays. But likely more
   important, is the document really about 'operational state
   requirements'?  My understanding is that the document is primarily
   about the separation of intended config and applied config and not
   operational state requirements in general. Let me make a
   constructive proposal you can throw darts at...

     Separation of Intended Configuration from Applied Configuration:
     Terminology and Requirements

b) Abstract:

     This document defines requirements for servers enabling better
     visibility and control over the server's operational state.

   Do the requirements apply to _all_ servers? You later define server
   = device = system = network element but I think it is desirable if
   the abstract stands on its own. And, as stated above already, I
   think the document is not really about "enabling better visibility
   and control over the server's operational state" - it is primarily
   about the separation of Intended Configuration from Applied
   Configuration. Let me again try to make a constructive proposal:

     This document discusses the difference between intended
     configuration and applied configuration of a device and how
     intended and applied configuration relate to the operational
     state of a device. The document defines the necessary terminology
     and identifies requirements enabling visibility into the
     difference of intended configuration and applied configuration.

c) The document does not have an Introduction. I am personally OK with
   that but most RFCs do have an Introduction section. Well, the
   Gen-ART reviewers will tell us I guess.

d) I note that there is no reference to RFC 6244. For me, it seems
   Intended Configuration maps to the box 'config database' in the
   figure on page 15 of RFC 6244 and Applied Configuration is part of
   the box marked 'system software component' in RFC 6244. If this is
   correct, perhaps it is useful to spell this out. If this is
   incorrect, it is likely useful to spell this out as well. While RFC
   6244 might have its limitations, it is the only architectural
   document we have in the NETCONF and YANG space and we should
   perhaps not ignore it.

e) Title of Appendix A

   This should probably be 'in Other Documents" instead of in Other
   Drafts" since RFC 6241 is not really a "Draft".

f) Editorial: It would be nice to write terms such as
   continue-on-error always in the same way - makes searching in the
   document easier (I think I have seen Continue On Error, continue on
   error, and continue-on-error).  Same for stop-on-error and
   rollback-on-error. Or be explicit that continue-on-error means
   RFC6241 continue-on-error and Continue On Error means this
   document's continue on error.

g) Appendix A:

     The following terms were originally defined in [RFC6241], but since
     modified by the NETMOD WG:

     o  continue-on-error
     o  stop-on-error
     o  rollback-on-error

  Instead of noting the fact that terms are different, it might be
  more useful to _explain_ what the difference is between the terms
  defined in RFC 6241 the terms defined in this document. Are the
  terms defined here just a generalization to make the definition less
  protocol specific or is there also a semantic change beyond that?
  Perhaps also make it clear that the definitions provided here do not
  change the semantics of the terms defined in RFC 6241 (otherwise
  this document would have to formally update RFC 6241).

h) Appendix C: This should probably be marked with an RFC Editor
   instruction that this appendix should be removed from the final
   version.

i) Security Considerations

   I am wondering whether there are really none. For example, if
   applied and intended configuration differ for a longer period of
   time and it is not possible to observe the difference, then a
   configuration client might believe certain security policies are
   enforced while they actually are not. In other words, an attacker
   might be interested in trying to extend the period where intended
   configuration differs from applied configuration by finding ways to
   prevent the server to apply the intended configuration.

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Dec 2015 21:27:12 +0000

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

Thanks again,
Kent

On 12/17/15, 1:16 PM, "netmod on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Dec 2015 08:59:47 +0100

On Thu, Dec 17, 2015 at 09:27:12PM +0000, Kent Watsen wrote:
> 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:
> 

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 18 Dec 2015 20:56:10 +0000

[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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 18 Dec 2015 15:13:18 -0800

My preference would also be to leave #5 out. 

> On Dec 18, 2015, at 12:56 PM, Kent Watsen <[email-masked]> wrote:
> 
> [As a contributor]
> 
> Hi Juergen,
> 

Mahesh Jethanandani
[email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Mon, 21 Dec 2015 11:13:52 +0000

Hi Kent,

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Dec 2015 14:04:47 +0100

> So far it sounds like Juergen and I are with #2, how about others?

I prefer #2.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C