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

From: Benoit Claise <[email-masked]>
Date: Tue, 11 Jul 2017 15:55:58 +0200

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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 12 Jul 2017 17:56:49 +0100

Hi Benoit,

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

Please see inline ...

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

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

> 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.
This is an omission and should be added.

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

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

>     state only had "config false" nodes.
OK.

> identities and a metadata. Hence "YANG module security guidelines" 
> don't apply.
Yes.

> Should it move to the document core?
I'm not sure on this one.

> Regards, Benoit
Thanks,
Rob

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 17 Jul 2017 09:29:23 +0000

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 datastores)
  *   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) ?

Rgds,
Jason

From: netmod [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Wednesday, July 12, 2017 18:57
To: Benoit Claise <[email-masked]>; NETMOD Working Group <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] draft-ietf-netmod-revised-datastores-03 feedback

Hi Benoit,

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

Please see inline ...

Some comments below.

-

OLD:

      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.

-

      datastores.

   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.

Background:

Reading this definition:

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.

            |           |       |           |

            |         +-----------+         |

                      | (ct, rw)  |

                      +-----------+

                            |

                            v

                      +------------+

                      | (ct, ro)   |

                      +------------+

                            |        // resources, delays

                            |

                       |    |   |

                       v    v   v

                    +---------------+

                    | (ct + cf, ro) |

                    +---------------+

  Section 4.7

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

OLD:

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

Regards, Benoit
Thanks,
Rob

netmod mailing list

[email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Jul 2017 18:26:03 +0200

> 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 s…

The text in the I-D says

   o  dynamic: represents data provided by a dynamic datastore.
   
   o  learned: represents configuration that has been learned via
      protocol interactions with other systems, including protocols such
      as link-layer negotiations, routing protocols, DHCP, etc.

and

     identity dynamic {
       base origin;
       description
         "Denotes data from a dynamic datastore.";
     }

     identity learned {
       base origin;
       description
         "Denotes configuration learned from protocol interactions with
          other devices, instead of via the intended configuration
          datastore or any dynamic datastore.

          Examples of protocols that provide learned configuration
          include link-layer negotiations, routing protocols, and
          DHCP.";
     }

Is this text unclear?

/js

PS: We consider to change 'configuration' to 'data' in the definition
    of 'learned', i.e., 'represents data that has been learned...' and
    'Denotes data learned from..."

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