>>>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

Reply via email to