On Wed, May 09, 2018 at 05:15:12PM +0100, Robert Wilton wrote: > +1 for a generic solution. > > At the moment RFC 8040 states that ETAGS only apply to configuration, so > they don't necessarily help with operational data. > > Perhaps we should be introducing something like ETAG support for operational > as well. Although, we would need to careful consider the implementation > performance impact. Given that operational data may come from multiple > daemons, it may be very hard to efficiently generate reliable ETAGs that > span across large chunks of operational data.
Yes, there is fast changing data and slow changing data, there is expensive data (in terms of instrumentation) and there is inexpensive data. I think the solution is to let the server decide an which data to provide etags (or something equivalent). HTTP also has all the Cache-Control magic - I have no clue whether RESTCONF implementations and in particular RESTCONF clients do honor HTTP caching mechanisms and maintain local caches at the HTTP interaction level. It seems HTTP has a lot to offer here (no surprise) and it is not clear what needs backporting to NETCONF or whether we are better off making RESTCONF do all the things NETCONF does - or we do both and the implementations will ultimately decide. In the long run, maintaining two protocols providing similar functionality does not seem to be effective. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
