Hi Andy,
Please can you let me know whether you think that any of the three
proposed solutions wouldn't meet this backwards compatibility requirement?
draft-kwatsen-netmod-opstate-00 has some features that might be
generally useful to NETCONF, like adding <get-state> support as defined
in section 5.1, that I would expect could just be added to a future
version of NETCONF. Would a requirement that the solution is backwards
compatible with existing implementations require that support for
<get-state> must always be optional? Or could a new version of the
NETCONF protocol require that support for <get-state> is required?
Thanks,
Rob
On 17/12/2015 16:06, Andy Bierman wrote:
Hi,
I agree with Juergen that this should be clear.
It was discussed several times. All existing protocol
functionality for NETCONF and RESTCONF MUST continue to work
for clients which do not choose to examine the differences between
intended config and applied config.
Andy
On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen <[email protected]
<mailto:[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
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
