On Thu, Dec 17, 2015 at 9:29 AM, Juergen Schoenwaelder < [email protected]> wrote:
> 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). > > Andy, did I get this right? > pretty much. I can see how the time delay is subjective and depends on the use-case and the operator preferences. In 1 deployment a delay of 5 seconds is not a concern, and in another it is a concern. The solution does not have to polling. The server can send 1 indication when intended == applied for the entire datastore, or it can answer a million individual "are you done yet?" queries from the client. Both could be considered solutions to the same problem. > /js > Andy > > -- > 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/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
