Dear all,
Good job on this document.
Some comments below.
-
OLD:
o learned configuration: Configuration that has been learned via
protocol interactions with other systems that is not conventional
or dynamic configuration.
NEW (is this what wou want to say?):
o learned configuration: Configuration that has been learned via dynamic
configuration
or protocol interactions with other systems that is not conventional
Thinking some more about this definition. Let's come back to it.
-
o dynamic datastore: A datastore holding data obtained dynamically
during the operation of a device through interaction with other
systems, rather than through one of the conventional configuration
datastores.
Should the dynamic datastore should say:
o dynamic datastore: A datastore holding configuration data obtained
dynamically ...
Background:
Reading this definition:
o system state: The additional data on a system that is not
configuration, such as read-only status information and collected
statistics. System state is transient and modified by
interactions with internal components or other systems. System
state is modeled in YANG using "config false" nodes.
I guessed that the system states don't include the content from the dynamic
datastore.
It's not obvious with the current definitions.
- This figure and section 4.7 text.
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
| // configuration transformations,
| // e.g., removal of "inactive"
| // nodes, expansion of templates
v
+------------+
| <intended> | // subject to validation
| (ct, ro) |
+------------+
| // changes applied, subject to
| // local factors, e.g., missing
| // resources, delays
|
| +-------- learned configuration
dynamic | +-------- system configuration
datastores -----+ | +-------- default configuration
| | |
v v v
+---------------+
| <operational> | <-- system state
| (ct + cf, ro) |
+---------------+
Section 4.7
<operational> contains system state and all configuration actually
used by the system. This includes all applied configuration from
<intended>, system-provided configuration, and default values defined
by any supported data models. In addition, <operational> also
contains applied data from dynamic datastores.
What about "learned configuration"
- Section 3.
The important question is whether the section 2 "datastore" and
"configuration datastore" definitions are aligned with previous
definitions or not.
I guess not. If this is the case, it should be clearly mentioned.
- Section 4.5
No need to repeat what's in the terminology section.
- Section 4.7
OLD:
In the original NETCONF model the operational
state only had "config false" nodes.
OLD:
In the original NETCONF model (RFC6241 or section 3.1) the operational
state only had "config false" nodes.
- Security Considerations.
You might want to stress that, even if this document contains YANG
modules, those modules have no read or read/write leaves: only
identities and a metadata. Hence "YANG module security guidelines" don't
apply.
Now, there surely exist some security considerations anyway.
- Is appendix A normative?
Should it move to the document core?
Regards, Benoit
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
