Subject: [netconf] Open question 2/4 "Timestamps" in draft-lindblad-netconf-transaction-id-01.txt

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

Hello NETCONF team,

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

In RESTCONF (RFC 8040), clients and servers may send and receive Etag values, or they may opt to use a similar mechanism based on timestamps. Should a similar timestamp mechanism also be introduced for NETCONF transaction IDs?

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: I have collected arguments for and against this feature. Here are the most salient ones, in my opinion.
+ Adding timestamps makes feature parity between RESTCONF and NETCONF.
+ Using timestamps is potentially saving a lot of overhead, since timestamps are inherently ordered, and can be used as short hand for large set of Etag values.
+ Clock synchronization between clients and servers in a large network may not always be very reliable.
+ NETCONF edit-configs may often have a larger scope than RESTCONF update operations. It is not uncommon with transaction commit times of a few minutes (or occasionally more than a few). This may dilute the meaning of the timestamp, and thereby reduce its utility for If-Before etc. In order to make it useful, some additional language (beyond what's found in RFC 8040) may be necessary. Perfect feature parity may not be achievable here.
+ In RESTCONF update operations, only a single timestamp is being exchanged. When translated to a NETCONF context, I expect many Etag values and timestamps would be present in the payload. The added overhead for providing both kinds of meta information is significant. To include both attributes (Etags and timestamp) for a lot of nodes in the data tree sounds unnecessarily costly.

Best Regards,
/jan

On 22 Oct 2021, at 13:28, [email-masked]<mailto:[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