>>>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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
