[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 protected] on behalf of [email protected]>
wrote:
>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/>
>
>_______________________________________________
>netmod mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
