[netmod] AD review: draft-ietf-netmod-revised-datastores-08

[Benoit Claise <[e-mail]>]

Dear all,

In order not to be the bottleneck in the process and assuming that the 
document will be in "publication requested" pretty soon, here is my AD 
review of draft-ietf-netmod-revised-datastores-08

-


        5.3.2. Missing Resources

    Configuration in <intended> can refer to resources that are not
    available or otherwise not physically present.  In these situations,
    these parts of <intended> are not applied.  The data appears in
    <intended> but does not appear in <operational>.


I understand what you want to say.
Let me take an example. I have a router with a Line Card configured and 
working well. if I remove the LC, the configuration should still be in 
the <running> and <intended> but not in <operational>.
However, based on figure below, the notion of "inactive" nodes might be 
misleading. Indeed, people might read that the LC is inactive, so the LC 
configuration should not be in <intended>

      +-------------+                 +-----------+
      | <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)   |
                       +------------+

I understand that "inactive nodes" has a different meaning.

Proposal:
OLD: removal of "inactive" nodes
NEW: removal of the nodes marked as "inactive"

- In the C.1 example,

    <system
        xmlns="urn:example:system"
        xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

      <hostname or:origin="or:dynamic">bar</hostname>

      <interface or:origin="or:intended">
        <name>eth0</name>
        <auto-negotiation>
          <enabled or:origin="or:default">true</enabled>
          <speed>1000</speed>
        </auto-negotiation>
        <speed>100</speed>
        <address>
          <ip>2001:db8::10</ip>
          <prefix-length>64</prefix-length>
        </address>
        <address or:origin="or:dynamic">
          <ip>2001:db8::1:100</ip>
          <prefix-length>64</prefix-length>
        </address>
      </interface>

I guess it "or:dynamic" should be replaced by "or:learned"

Justification:

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

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


_Editorial:_

- number the figures

- section 8.2
    This document registers two YANG modules in the YANG Module Names
    registry [RFC6020 <https://tools.ietf.org/html/rfc6020>].  Following the format in [RFC6020 <https://tools.ietf.org/html/rfc6020>], the the
    following registrations are requested:

duplicated "the the"
  
Regards, Benoit (OPS AD)