On 09/05/2018 17:47, Juergen Schoenwaelder wrote:
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).
This sounds like a reasonable starting point.
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.
I don't know either.
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.
I think that having the flexibility of a binary encoding is likely to
become more important over time, particularly for dynamic configuration,
or streaming telemetry. From the previous discussions, it looks almost
trivial to add binary encoding support into RESTCONF, but a lot of work
to add it to NETCONF.
One thing that I prefer in RESTCONF is being able to provide a config
update as a single tree update that includes both merge and delete
operations as annotations within the tree. This seems like an efficient
way to generate and send a delta of a configuration from a client to the
server.
But possibly a useful discussion to have may be what the members of the
NETCONF WG perceives is the future for the IETF network management
protocols.
Thanks,
Rob
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
