> On Dec 21, 2015:8:55 AM, at 8:55 AM, Ladislav Lhotka <[email protected]> wrote:
>
> Juergen Schoenwaelder <[email protected]> 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 <[email protected]>
>>>> 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.
—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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
