Hi Benoit,
Thanks for the review. Some of these points will probably require
further discussion.
Please see inline ...
On 11/07/2017 14:55, Benoit Claise wrote:
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
The aim here is to indicate that "learned configuration" explicitly
excluded configuration data that comes via the conventional or dynamic
datastores.
So, configuration from I2RS would be dynamic configuration and not
learned configuration.
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 ...
We think that dynamic datastores may also contain data for nodes that
are not configuration. Every schema node that is "config true" is
configuration and hence may be programmed via the conventional
datastores. The I2RS requirements wants to be able to write to config
false nodes, my assumption is that this is because they don't want all
of their I2RS specific models (e.g. for modifying RIB/FIB entries) to
also have to be configurable via conventional datastores.
So, this is the reason that it refers to "data" rather than "configuration".
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.
If the dynamic datastore contains data for config false schema nodes
then this would modify the system state in the operational state datastore.
- 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"
This is an omission and should be added.
- 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.
OK.
The definition of "datastore" aligns with NETCONF (RFC 6241) updated by
YANG 1.1 (RFC 7050).
The definition of "configuration datastore" is slightly different, but I
believe that it is meant to be semantically equivalent.
- Section 4.5
No need to repeat what's in the terminology section.
Do you mean not to mention the conventional datastores at all here?
Currently the text does expand somewhat on the definition 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.
OK.
- 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.
Yes.
- Is appendix A normative?
Should it move to the document core?
I'm not sure on this one.
Regards, Benoit
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
