Lou By now, 17th June, I see solid support for one option but only see comments from a somewhat small number of participants
The majority of the authors of the 172 YANG files I have in an archive are probably unaware of this discussion and yet some at least will be affected. What concerns me is that history might be repeating itself. In a sense, this discussion is about the original proposals for NETCONF and YANG not meeting current requirements which may be because there has mostly been a limited number of participants in netmod discussions. I was struck by Dale's recent, brilliant review of 6020bis because it came from a fresh angle and brought up nagging concerns that I had had but had not been able to articulate. With a wider audience, similar comments might have been made much earlier to the advantage of YANG (perhaps even about RFC6020). In the same vein, there is NETCONF. Juergen's I-D, which I see finding favour, could be said to cut the ground from under NETCONF (well, I would). RFC6241 says " Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics. " The proposed 'intended' in the I-D is (ct, ro). It is ct, configuration true, so it is configuration data. It is ro, read only, so it is clearly not configuration data. Without changing RFC6241, I cannot reconcile this. So I see RFC6241 being changed; can anyone reading the RFC understand it any more? And yet the I-D makes no mention of this change to NETCONF nor have I seen any discussion on the netconf list. Stimulated by posts to the I2RS list, perhaps also a trigger for Juergen's I-D, I wrote up my own summary of the current state of datastores but I called it draft-tp-netconf-datastore because I see NETCONF currently telling us almost all that we know about datastores; YANG 1.0 adds very little. For me, NETCONF should be the starting point. Tom Petch ----- Original Message ----- From: "Lou Berger" <lber...@labn.net> To: "netmod WG" <netmod@ietf.org> Cc: <netmod-cha...@ietf.org> Sent: Tuesday, June 07, 2016 3:19 PM > All, > > We want to provide an update based on the off line discussions > related to OpState Solutions that we have been having and solicit > input from the WG. > > All authors of current solution drafts [1,2,3] together with those > who helped conduct the solutions analysis* were invited to the these > discussions -- with the objective of coming up with a single > consolidated proposal to bring to the WG. (I/Lou acted as facilitator > as Kent and Juergen were and are involved with the technical details.) > > The discussions have yielded some results but, unfortunately, > not a single consolidated proposal as hoped, but rather two > alternate directions -- and clearly we need to choose one: > > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. > > From a model definition perspective, these conventions > impact every model and every model writer. > > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. > > With this approach, model definitions need no explicit > changes to support applied configuration. > > >From a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. > The counterpoint to this is that the conventions based > approach (i.e., #1) is available today and being followed in > OpenConfig defined models. > > We would like to hear opinions on this from the WG before > declaring one of the following as the WG direction: > > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > We intend to close on this choice before Berlin. > > Thank you, > Lou (and co-chairs) > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > * - Chris H. and Acee L. > > > _______________________________________________ > 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
