[netconf] Re: RFC 8040/8527: ETags on /ds/operational?

[Kent Watsen <[e-mail]>]

Hi Tomáš,

> On Oct 7, 2026, at 4:26 AM, Tomáš Pecka <tomas.pecka=[e-mail]> wrote:
> 
> Hello Kent,
> 
> thanks for the reply and the intended interpretation.
> 
> I understand the mechanisms are used in place of locking. I was confused that RFC 8527 does not say anything about not supporting them on read-only datastores (as it does, for instance, in Section 3.2 about write operations on <intended>), while RFC 8040 says the server MUST support them for the datastore resource. I probably read the document too literally, hence the confusion.

For RFC 8040, there is only the "data" resource that represents "unified view of the underlying datastore implementation on the server".  There is no "operational" datastore and hence its statement about maintaining ETags for "configuration".


> Re {+restconf}/data (not) being available: I think that removing it would contradict Section 1 (Introduction) of RFC 8527. It explicitly says that RFC 8527 is backwards compatible with RFC 8040.

In theory, RFC 8527 is backwards compatible to RFC 8040.  In practice, not so much.  As NMDA is now "best practice", my advice is for *new* server implementations to skip trying to be non-NMDA.  My own RESTCONF server implementation does this.

Case in point.  Let's say a server supports both NMDA and non-NMDA:

what would YANG Library say?   If it declares support for both NMDA-native and non-NMDA "state" modules, what would an NMDA-client receive from <operational>?

Obviously a non-NMDA client access <operational>, <system>, <startup>, <factory-default>, <system>, or <intended>.  If there's a mix of NMDA-aware and -unaware clients, the unaware clients are effectively blind to the workings of the system.

Kent