Re: [netmod] Query about draft-ietf-netconf-rfc7895bis-06

[Robert Wilton <[e-mail]>]

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
>