Lou You say below " > It's just a ro version/view of the config data. I'm not sure why this > is problematic. Perhaps I'm just missing something. "
I see it as a fundamental change (to NETCONF). Tracking other lists (e.g.I2RS) I repeatedly get the sense that they have not grasped what configuration data is (editable, potential persistent but a minute fraction of what a box needs to operate), and by contrast what is state. I see some, if not many, of Juergen's posts to that list as reflecting that such as "I have no clue what the above sentence is trying to say. Please try to use YANG terminology. " Every time I read 'ephemeral state' I think the same; state is ephemeral, the phrase does not convey any meaning (except that the user does not understand what configuration is). And this comes mostly from RFC6241 not from RFC6020. So, I see a strong preference for Option B which is all very logical, as Acee points out. But Option B I see as being a fundamental change to RFC6241, so if the netmod WG takes that decision, then it is stamping on the netconf WG. Perhaps the WG should be merged, now that 6020bis is on its way, but for the moment, I believe that changes to NETCONF need the consensus of the NETCONF WG. Tom Petch ----- Original Message ----- From: "Lou Berger" <lber...@labn.net> To: "t.petch" <ie...@btconnect.com>; "netmod WG" <netmod@ietf.org> Cc: <netmod-cha...@ietf.org> Sent: Friday, June 17, 2016 7:22 PM Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput > Tom, > > Thanks for the perspective. I'm a little unsure if you're expecting > a response or just making a statement, so if you're looking for > something specific and don't see it below -- please let me know. > > On 6/17/2016 11:15 AM, t.petch wrote: > > Lou > > > > By now, 17th June, I see solid support for one option but only see > > comments from a somewhat small number of participants > This is true, and I've heard privately that some more may/should be > forthcoming. > > > 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. > > So two points on this: > - Today is different in that there are a great number of players > using/looking to YANG at the moment --- so I think we have more lurkers > out there than you'd expect. > > - The fact that 172 documents (and that's just in the IETF) would be > impacted by option (A) is exactly why we think it's the wrong way to go. > Think about if we came up with a solution that requires each modeler to > build their definitions a fixed way how this would be > socialized/enforced. Now think about doing that in other SDOs. > > > 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. > It's just a ro version/view of the config data. I'm not sure why this > is problematic. Perhaps I'm just missing something. > > > 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. > The first question is deciding on an approach (A vs B), the second > question is on the details of the selected option. If we move forward > with B, I think which WG does the data store work is a fine topic to > consider. But we (netmod) first need to close on A vs B -- which will > be easy if there are no new comments in short order. > > Lou > > Tom Petch > > > > ----- Original Message ----- > > From: "Lou Berger" <lber...@labn.net> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
