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: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 discussion. Please see inline ... On 11/07/2017 14:55, Benoit Claise wrote: 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 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. 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 ... 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". 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. 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 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" 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. 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: 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. OK. - 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. - Is appendix A normative? Should it move to the document core? I'm not sure on this one. Regards, Benoit Thanks, Rob _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
