> On 21 Dec 2015, at 15:20, Nadeau Thomas <tnad...@lucidvision.com> wrote: > >> >> On Dec 21, 2015:8:55 AM, at 8:55 AM, Ladislav Lhotka <lho...@nic.cz> wrote: >> >> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: >> >>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote: >>>> >>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen <kwat...@juniper.net> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>> I’m struggling a bit to understand what is motivating you to ask this >>>>>>>> question. That is, as a tool vendor, I wouldn’t think that any >>>>>>>> decision made here would affect you immediately. My expectations are >>>>>>>> that any impact to YANG/NETCONF/RESTCONF would be backwards >>>>>>>> compatible, such that implementations would only opt-in when needed - >>>>>>>> a pay as you grow strategy. But herein perhaps lies an unstated >>>>>>>> requirement, that the impact to YANG/NETCONF/RESTCONF needs to be >>>>>>>> backwards compatible with respect to existing deployments. Did we >>>>>>>> miss it or is it too obvious? >>>>>>>> >>>>>>> >>>>>>> It may be obvious for many of us but for the sake of completeness I >>>>>>> prefer to have this backwards compatibility assumption explicitely >>>>>>> stated. >>>>>> >>>>>> +1 >>>>> >>>>> >>>>> [as a chair] >>>>> >>>>> As last call comment, there seems to be support for adding a requirement >>>>> to the opstate-reqs draft to state that solutions supporting said >>>>> requirements MUST be backwards compatible with respect to existing >>>>> deployments. Do we have WG consensus to add this as a requirement to >>>>> this draft? Are there any objections? Please voice your opinion before >>>>> the last call cutoff date (Dec 30). >>>>> >>>>> >>>>> [as a contributor] >>>>> >>>>> >>>>> I’m unsure if it makes sense to call it out in this draft, in that it >>>>> seems universally applicable, but I don’t see any harm in it either and >>>>> thus do not object. >>>>> >>>>> >>>>> Kent >>>> >>>> [As Co-chair] >>>> >>>> Given the tall hill we climbed to get to this point on the >>>> requirements, I >>>> want to be clear that there needs to be very significant support to change >>>> the requirements >>>> in any significant way. We went round and round the drain on settling on >>>> these requirements, and >>>> people had a whole host of reasonable opportunities to add this during >>>> those times. I want to point out that while this statement may seem >>>> subtle, slipping this in at the last minute could have a profound impact >>>> on solutions built from these requirements, so I want to be sure everyone >>>> involved has through through this kind of change. >>>> >>>> —Tom >>> >>> Tom, >>> >>> I think Andy is talking about applicability - to which kind of servers >>> do these requirements apply. For example, if it takes more time on a >>> certain class of devices to retrieve the difference between applied >>> and intended config than it takes to turn intended config into applied >>> config, then these requirements may not be applicable (since by the >>> time you have finished retrieving the difference it has vanished). >> >> I think it is not only matter of synchronisation delays between intended >> and applied configuration. I have serious troubles understanding how >> these concepts map to the class of devices I am mainly interested in. >> >> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF >> server that supports intended and applied config. Assume the server >> implements modules of the acl-model family so that firewall rules can be >> configured through NETCONF/RESTCONF. Great. >> >> Now an admin runs "iptables" to manipulate netfilter rules in the >> kernel. How does it affect the applied and intended configurations? >> >> A. The change isn't reflected in applied configuration. Then applied >> configuration is no more "…, the configuration state which is >> currently being used by server components (e.g., control plane >> daemons, operating system kernels, line cards)." >> >> B. The change is reflected in applied but not in intended >> configuration. This violates requirement 1 sub D, and also it may be >> impossible to map the kernel changes back to the configuration. >> >> For sure, these problems exist also with the good old "running", but I >> think the migration to intended-applied would just make things worse. >> >> Lada > > My note above was not concerned with technical details, but rather > procedural. As I noted, we spend numerous hours getting that document > and the agreements around that to the point where it is at by meeting with > a lot of people. Those changes are then the result (and consensus) of those > many meetings and peoples’ inputs. It is one thing to be making > minor/editorial > changes, but an entirely other to be making substantive technical changes > at the last minute without everyones' buy-in.
I did ask these questions previously but only got hand-waving or procedural answers (like yours). Therefore, I want to make sure that this intended-applied thing isn't the only way that will be supported from now on. That's all. Thanks, Lada > > —Tom > > > >> >> >>> >>> Andy, did I get this right? >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
