Benoit, I think Rob and others have already addressed the first issue raised in the comments from your group. For the second point, your mail says that the OpenConfig opstate draft says:
* "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.* While the draft does say this, you've unfortunately misunderstood the point being made in that section (I'll have to accept some responsibility for writing it this way). The preface to Section 7 says, "A number of issues have been raised with the proposed solution ..." and point #3 is just stating the issue that was raised with regard to our proposal -- if you read the rest of the explanation in #3, it describes an example of how the solution can address these situations, using a specific example of configuring 'all' interfaces , some of which may not be present. Similarly, if an implementation supports pre-configuration of interfaces, for example, the intended configuration reflects that preconfiguration, while the corresponding state would show that it is applied but also that oper-status = 'NOT PRESENT' So I would say that your point about the solution limiting expressivity that is otherwise allowed by the language is based on a misreading of the section. Other points in Section 7 also first relate the issue raised, followed by our response regarding how it can be addressed. thanks. -- Anees On Thu, Sep 10, 2015 at 1:40 AM, Benoit Claise <bcla...@cisco.com> wrote: > 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. > > 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 > > 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 > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
