On Sun, Jun 19, 2016 at 2:52 AM, t.petch <ie...@btconnect.com> wrote:
> 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. > I disagree. I have implemented NETCONF and RESTCONF and I do not see any problems with adding additional (optional) datastores. As often the case in the IETF, when a WG does not have consensus on a particular topic, the standard is silent on that topic. That is what happened with config=false in RFC 6241 and 6020. I don't see a problem with a datastore model that evolves over time. > > Tom Petch > Andy > > ----- 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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
