Network Management Datastore Architecture (NMDA)
draft-ietf-netmod-revised-datastores-10

The examples in Appendix C use IP addresses from RFC1918 ranges rather than addresses from those blocks reserved for documentation. At the same time, current IAB guidance <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/> calls for IPv6 examples in current standards-track documents. Consequently, I would suggest replacing "10.1.2.3" with "2001:DB8::BEEF:FACE" (or your favorite address from 2001:DB8::/32) everywhere.

(1) Please add a sentence to the Introduction explaining how this document updates rfc7950.  I know that a couple of sections explicitly indicate what part of rfc7950 they update, but having a short summary at the beginning would be nice.

(2) Section 3 says: “It is expected that the revised definitions provided in this section will replace the definitions in [RFC6241] and [RFC7950] when these documents are revised.”  Why not formally Update those documents here?  [See my note above about the Update to rfc7950.]

(3) s/Section 4.4 of this document/Section 4.4 of rfc6244

      protocol interactions with other systems and that is neither
      conventional nor dynamic configuration.
Could you provide an example of this?


   datastore that holds the complete current configuration on the
   device.  It MAY include configuration that requires further
   transformation before it can be applied, e.g., inactive
   
If I am reading the text, this doesn't seem to be true because "system
configuration" is not included.

Hello,

Thanks for your work on this draft.  I'm a little confused with some text in the draft and appreciate Benoit working with the authors to clarify text around these points.  This was previously a discuss, but the explanations provided were helpful and the tweaks discussed are appreciated.

Original questions from discuss:

1. The introductions says, 
"This architectural framework identifies a set of conceptual datastores but
   it does not mandate that all network management protocols expose all
   these conceptual datastores.  This architecture is agnostic with
   regard to the encoding used by network management protocols."

As such, the data stores could be exposed for some implementations, using whatever network management protocol (likely NetCONF or RESTCONF).  If this is the case, why doesn't at least some of the security considerations template apply for at least secure transport?

2. Section 5.3.4 - Is there any integrity protection on the origin information?  If not, can it be added or is there a good reason why it’s not possible?  I realize these are conceptual models that may or may not be exposed, but if exposed and used, wouldn’t some integrity protection on this be helpful?

Thanks in advance!