Hi Andy,
Please can you state the specific text that is being proposed to be
added as a new requirement?
Thanks,
Rob
On 17/12/2015 17:33, Andy Bierman wrote:
Hi,
I am not commenting on the solution proposals.
The document being discussed is the requirements document.
I agree with Juergen that backward compatibility needs to be an
explicit requirement. Are you objecting to such a requirement?
Andy
On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
