Subject: [netconf] Open question 1/4 "Etag values" in draft-lindblad-netconf-transaction-id-01.txt

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

Hello NETCONF team,

This thread (1/4) is about 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. 

When clients and servers send and receive Etag values, what should be the value space and semantics associated with them?

Proposed solution #1) Use exactly the same value space as specified in RFC 8040 (RESTCONF) which in turn points to RFC 7232 (HTTP Conditional Requests) sec 2.3. This means the Etag is an arbitrary length string of 8-bit characters of the server's own choice, except it must not contain ASCII control characters, space, backslash or double quotes.

Proposed solution #2) Server uses a monotonously increasing integer for Etag values. Special cases like behavior at server reboot have not yet been discussed.

Proposed solution #3) Server uses an arbitrary length string of UTF-8 characters of its own choice.

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

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
> 
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 11 Nov 2021 14:28:26 -0800

[As a contributor]

My preference would also be solution #1. That way the application logic remains the same, and does not depend on whether the request/response is being send/received over NETCONF or RESTCONF.

Cheers.

> On Nov 11, 2021, at 12:40 PM, Jan Lindblad (jlindbla) <jlindbla=[email-masked]> wrote:
> 
> Hello NETCONF team,
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]