Subject: [netconf] Open question 3/4 "Allowing client side allocation of Etag values" in draft-lindblad-netconf-transaction-id-01.txt

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Thu, 11 Nov 2021 20:46:20 +0000

Hello NETCONF team,

This thread (3/4) is about Allowing client side allocation of Etag values: at the NETCONF WG session earlier this week, the chairs asked me to start a separate thread for each of the outstanding question relating to draft-lindblad-netconf-transaction-id-01. 

Should it be possible for a client to specify which Etag value the server should use for a particular transaction?

Proposed solution #1) No, this is not needed. IETF or another SDO is of course free to define such a mechanism at a later time, and an implementor could define a proprietary mechanism.

Proposed solution #2) Yes, but it should be an optional capability for a server to implement. If available on a server, it would also be optional for a client to use it.

Proposed solution #3) Yes, and it should me mandatory for servers that implement the Etag mechanism to also support the timestamp mechanism. It would be optional for a client to use it.

The -01 draft specifies solution #1. Please indicate your preferences among the options. Comments or suggestions for other options are also welcome.

Comments: Without this feature, the server will have to generate valid Etag values. If a server supported this feature, and a client chose to leverage the possibility to specify an Etag value, the server would simply use the Etag value specified by the client instead of generating a different value. This is trivial to implement. This mechanism allows the client to know before hand what the Etag values will be, and does not need to keep a transaction hanging until completed by all participating servers. This would significantly simplify and speed up high cadence orchestration scenarios.

Best Regards,
/jan

> On 22 Oct 2021, at 13:28, [email-masked] wrote:
> 
> 
> A new version of I-D, draft-lindblad-netconf-transaction-id-01.txt
> has been successfully submitted by Jan Lindblad and posted to the
> IETF repository.
> 
> Name:		draft-lindblad-netconf-transaction-id
> Revision:	01
> Title:		Transaction ID Mechanism for NETCONF
> Document date:	2021-10-22
> Group:		Individual Submission
> Pages:		22
> URL:            https://www.ietf.org/archive/id/draft-lindblad-netconf-transaction-id-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-lindblad-netconf-transaction-id/
> Html:           https://www.ietf.org/archive/id/draft-lindblad-netconf-transaction-id-01.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-id
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-lindblad-netconf-transaction-id-01
> 
> Abstract:
>   NETCONF clients and servers often need to have a synchronized view of
>   the server's configuration data stores.  The volume of configuration
>   data in a server may be very large, while data store changes
>   typically are small when observed at typical client resynchronization
>   intervals.
> 
>   Rereading the entire data store and analyzing the response for
>   changes is an inefficient mechanism for synchronization.  This
>   document specifies an extension to NETCONF that allows clients and
>   servers to keep synchronized with a much smaller data exchange and
>   without any need for servers to store information about the clients.
> 
> 
> 
> 
> The IETF Secretariat
>