Hi, comments inline.
Benoit Claise <bcla...@cisco.com> writes: > Dear all, > > The YANG coordination team > <http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html> has > spent some time reading and gathering input on the requirements and > proposed solutions in draft-openconfig-netmod-opstate. This note is to > collect some observations that will hopefully contribute to progress in > the working group. > > We believe it is useful to consider that YANG was initially designed to > be a data modeling language for the NETCONF protocol. IETF is also > working on RESTCONF which is an HTTP-based protocol to access data > defined in YANG, using the datastores defined in NETCONF. > > YANG is fulfilling its intended role with NETCONF and RESTCONF and has > gained some significant traction in this capacity. There are some > changes worked on in YANG 1.1, but they are mostly incremental. > > There is interest in using other protocols outside of NETCONF and > RESTCONF to manipulate data described by YANG. The proposals in the > draft is based on the assertion that YANG models should be usable for > protocols beyond RESTCONF and NETCONF. So these are new requirements on > YANG from, or in preparation for, new protocol bindings. > > We have focused on two main aspects of the draft. > > FIRSTLY: The proposed split between intended and applied configuration > as described in sections 4.1 (requirements) and 5.1 (implications) > > There are two observations here: > 1. The implication is that all configurable data nodes ("intended > configuration") shall be repeated in an operational version ("applied > configuration") in all models for all applications going forward. This > would apply independent of if the system is synchronous or asynchronous > in nature. Synchronous systems would simply hard-wire the applied > configuration to be the same as intended configuration at all times. > 2. An informal round of conversations with some vendors as well as some > tooling vendors show that there are currently no widely known platforms > that allow for observing the intended and applied state separately. A > common architecture includes a central configuration data store that is > being updated by the manageability framework and updates read by the > subsystems affected by the change (e.g. the BGP service or the interface > manager). In this case, there is no other source of configuration except > for the content of the data store. It may be because vendors tend to limit user access to the device configuration to a few official interfaces. In contrast, consider for example a typical Linux system. No matter what "official" configuration system is used (init scripts, NetworkManager, UCI in OpenWRT, even NETCONF), there is always a way to change the run-time configuration without the official configuration system being notified. For instance, one can go to the /proc filesystem and change many kernel parameters on the fly, such as IP addresses assigned to interfaces. Since I am mainly interested in such open systems, I do see a use case for making the distinction between intended and applied configuration. And by the way, it might help solve the NETCONF/I2RS dilemma: NETCONF/RESTCONF would only be allowed to modify intended configuration whereas I2RS would operate exclusively on applied configuration. Finally, most existing NETMOD models in fact already have intended and applied configuration even if they aren't called so: the applied one is represented by nodes in *-state trees that are duplicates of configuration entries. > > Please note that this was not an exhaustive collection of data, but > should give some directional information. > > The *implication* we would like to make here is that by making this > feature mandatory part of the YANG language itself (as opposed to an > optional capability) we risk introducing a fake perception that the > current NETCONF server supports a capability it can't support. Indeed, > polling the applied configuration would always return the intended > configuration. > > A *question* would be if it would be useful to consider a direction > where we make an attempt to separate out requirements that are tied to > specific protocols and solve them in the protocol semantics rather than > in the language to the extent we can. Without knowing more about the > intended protocol in the case of this draft, it is hard to make more > progress. > > A *suggestion* is to ask the draft authors to document the protocol > bindings in order to qualify the requirements going forward. > > SECONDLY: The proposed schema locations for configuration and > corresponding operational state in sections 4.5 (requirements) and 5.4 > (implications) > > The observation to be made here is well captured in the draft itself as > bullet 3 under section 7: > > "The proposal does not allow items that are not configured, > configured but not present, or system configured." > > Please note that this is a general note that would apply to the language > itself. Meaning that YANG will no longer be able to describe situations > like the above for any type of application in any context. > > Examples beyond what's already mentioned in the bullet of this could > include: > - Removable physical assets (line cards, mezzanine cards) in systems > that allow pre-provisioning of configuration > - Physical assets that arrive in the system with readable default > state I agree, existing NETMOD modules already support pre-provisioning and system-controlled components. Lada > > Independent of the direction we will be taking going forward, the > implication we make is that it is a pretty significant impact on the > expressivity of the language itself and how useful it is in terms of > modeling application data sets that may not align with the requirements. > > The question we would ask is if it would be possible to rebalance the > implication and make it a little more modular and optional in the > language. We are aware of suggestions to use the extensibility of the > language itself (e.g. in draft-kwatsen-netmod-opstate) to express > relations across data sets. Understanding that this suggested approach > does not normalize the paths according to the wish of the authors, but > it can perhaps be a balanced approach that impacts the expressivity less. > > Regards, the YANG coordination team > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
