Lou Berger writes: >This starts a two week working group last call on >draft-ietf-netmod-revised-datastores-04.
I have reviewed this document and have several minor recommendations. In addition, there were comments at the mic at the last IETF during the NETCONF WG meeting regarding the draft-dsdt-nmda-netconf-00.txt draft that refer to the architecture rather than the NETCONF mapping of that architecture, specifically on validation, and restraints on templating mechanisms. The video is: https://www.youtube.com/watch?v=wTlyEqTSuqo&feature=youtu.be&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=4726 I'm submitting these comments as a "diff" against the text source of the draft. Hopefully this is clear and precise. Thanks, Phil diff --git a/draft-ietf-netmod-revised-datastores.org b/draft-ietf-netmod-revised-datastores.org index b859760..be3b3b8 100644 --- a/draft-ietf-netmod-revised-datastores.org +++ b/draft-ietf-netmod-revised-datastores.org @@ -210,8 +210,8 @@ Some observations: - Operational state has not been defined as a datastore although there were proposals in the past to introduce an operational state datastore. -- The NETCONF <get/> operation returns the content of the running - configuration datastore together with the operational state. It is +- The NETCONF <get> operation returns the content of <running> + together with the operational state. It is therefore necessary that "config false" data is in a different branch than the "config true" data if the operational state can have a different lifetime compared to configuration or if @@ -318,6 +318,26 @@ If a device does not have a distinct <startup> and non-volatile is available, the device will typically use that non-volatile storage to allow <running> to persist across reboots. +*** Validation + +The process of "validation" examines a datastore to ensure the +resulting configuration data will satisfy all data models constraints +given in ^YANG^ section 8.1. All constraints in all supported +data models must be satisfied for the data to be considered "valid". + +Validation will examine the data after any locally-defined templating +mechanism is performed and any inactive configuration is removed. + +While the operation of any specific templating mechanism is outside +the scope of this document, such mechanisms are constrained by the +rules of any data models, and cannot break the constraints given in +^YANG^. + +The implication of the existence of templating mechanisms is that +<running> is now explicitly allowed to be invalid, since the +templating mechanism may be supplying additional data that satisfies +constraints that may be satisfied by <running> itself. + ** The Intended Configuration Datastore (<intended>) The intended configuration datastore (<intended>) is a read-only @@ -422,6 +442,7 @@ error. <operational> does not persist across reboots. *** Remnant Configuration @remnant@ + Changes to configuration may take time to percolate through to <operational>. During this period, <operational> may contain nodes for both the previous and current configuration, as closely as @@ -709,12 +730,14 @@ This example defines a dynamic configuration datastore called "ephemeral", which is loosely modeled after the work done in the I2RS working group. - 1. Name : ephemeral - 2. YANG modules : all (default) - 3. YANG data nodes : all "config true" data nodes - 4. How applied : automatic - 5. Protocols : NC/RC (default) - 6. YANG Module : (see below) +| Name | Value | +|-----------------+------------------------------| +| Name | ephemeral | +| YANG modules | all (default) | +| YANG data nodes | all "config true" data nodes | +| How applied | automatic | +| Protocols | NC/RC (default) | +| YANG Module | (see below) | !! include-figure example-ds-ephemeral.yang _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
