Re: [netmod] draft-ietf-netmod-revised-datastores-03 feedback

[Robert Wilton <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod