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
