Hi guys,

The distinction between dynamic & learned origin may be a bit confusing (and 
could be a grey zone in some cases).  We likely need further clarification 
around this in the draft (maybe a dedicated section in the doc, further 
examples, and ideas of how to decide whether something is dynamic vs learned).  
Perhaps another useful differentiation is that ‘dynamic’ comes from a dynamic 
datastore while ‘learned’ does not have a datastore associated with it ?  Or 
does dynamic data sometimes not come from a datastore ?

Rob makes the following statement below:  “The I2RS requirements wants to be 
able to write to config false nodes...”

Why would YANG modules used in dynamic datastores necessarily use “config 
false” leafs ?  If a controller is setting leaf values in a dynamic datastore 
then I’d expect those leafs to be “config true”.  That YANG module may or may 
not also be programmable via a conventional datastore (i.e. may or may not 
exist in running/candidate).

I’m not sure we should really assert that “Every schema node that is "config 
true" is configuration and hence may be programmed via the conventional 
datastores”.  Why not allow the existence of YANG modules that are bound to 
specific datastores or interfaces ?   A module could have “config true” nodes, 
be supported in a dynamic datastore and in the operational datastore, but not 
be supported in running/candidate.

Different implementations may support different combinations for programming 
table ‘foo’:

  *   system A: via dynamic datastores only (but not via conventional 
  *   system B: via dynamic datastore *and* via conventional datastores

If a system supports programming of a table via a dynamic datastore *and* via 
conventional datastores, then those leafs would be “config true”.  So why not 
make the model have “config true” leafs in the first place (even if some 
implementations won’t support configuring those via conventional datastores) ?


From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Wednesday, July 12, 2017 18:57
To: Benoit Claise <bcla...@cisco.com>; NETMOD Working Group <netmod@ietf.org>
Cc: draft-ietf-netmod-revised-datasto...@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-revised-datastores-03 feedback

Hi Benoit,

Thanks for the review.  Some of these points will probably require further 

Please see inline ...

On 11/07/2017 14:55, Benoit Claise wrote:
Dear all,

Good job on this document.

Some comments below.



   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 

      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 

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


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".


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 

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



                      | <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.

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


   In the original NETCONF model the operational

   state only had "config false" nodes.


   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?
I'm not sure on this one.

Regards, Benoit


netmod mailing list



netmod mailing list

Reply via email to