Hi Rob,
thank you for pointing at RFC 8342, I missed it earlier.
The whole question stems from the requirements put on the parties
involved. While I agree that the server should not be mandated to serve
a totally consistent state, leafrefs are type-based constraints, and
these are, by RFC 8342 sec. 5.3, considered syntactic.
That brings ambiguity for the leafref targets. In case of dynamically
changing operational state, the target may cease existing before the
dump procedure reaches them, or even it may get recycled. That is indeed
syntactially korrekt unless require-instance true, but semantically
possibly misleading.
My approach would be to should-not leafrefs targetting operational data,
as that is putting too much requirements onto the servers, which points
back to my second mail to the netmod ML, proposing deduplication
metadata for cases where the server would otherwise send the same thing
ridiculous amount of times:
https://mailarchive.ietf.org/arch/msg/netmod/9QHj6zeP4rybMfr68M_C2iWhhq8/
Another approach would be to clarify the leafref semantics in
operational data, so that the server requirements would become obvious,
which would be something around the lines of some intermittent locking,
and the client would know what to expect.
That whole thing becomes worse with XPath-based tree filtering with
nested queries on large operational data, specifically with leafrefs.
This is what I'm thinking about:
/one/tree/branch[id = /another/tree/branch/where[../value >
/yet/another/branch/threshold]/../id]/name
That is doable with config trees where all values are local, but
querying operational data in other daemons or even hardware may become
a consistency nightmare for the implementation.
Maybe the right approach is just to support a subset of XPath, not
allowing these brutalities, but there is no hint on that in RFC 6241
sec. 8.9 at all. And not supporting XPath at all doesn't look well
either.
I'll be grateful for more pointers, or if there is no pointer but some
common position on this, I'm OK with drafting a document on that so that
the information is well-preserved for future.
Have a nice day!
Maria
--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
On Fri, Apr 24, 2026 at 04:08:52PM +0000, Rob Wilton (rwilton) wrote:
> Hi Maria,
>
> I suspect that the most useful information here is probably RFC 8342, section
> 5.3, https://www.rfc-editor.org/rfc/rfc8342.html#section-5.3
>
> But from a practical point of view, the answer has to be no, operational data
> is often doesn't exhibit transactional consistency semantics because it is
> can frequently be distributed across multiple cards (e.g., linecards),
> multiple processes/daemons (depending on architecture), or large databases
> without snapshot functionality.
>
> In these systems, without additional complexity, you only ever get a best
> effort snapshot, probably one that converges on eventual-consistency, but for
> any given request, it may contain inconsistencies within the request and
> between requests.
>
> Kind regards,
> Rob
>
>
> From: Reshad Rahman <[email protected]>
> Date: Thursday, 23 April 2026 at 19:37
> To: [email protected] <[email protected]>; Maria Matejka
> <[email protected]>; NETCONF WG <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: [netmod] Re: Operational data lifetime
>
> +NETCONF
>
> On Thursday, April 23, 2026 at 01:33:31 PM EDT, Maria Matejka
> <[email protected]> wrote:
>
>
>
> Howdy!
>
> I’m getting confused by the session semantics. What is the lifetime of
> operational data? More specifically, should NETCONF sessions behave as if the
> operational state has done a snapshot at a specific time, or is it intended
> to change between queries?
>
> The actual problem arises with using leafrefs in operational data referring
> to another leaf inside the operational data tree. That is indeed possible to
> be queried by the XPath filtering, as specified in RFC 6241 § 8.9, yet that’s
> an optional thing.
>
> Do I suppose correctly that the returned data is not required to be
> consistent between queries?
>
> Actually, should we even expect that the returned data is time-consistent
> inside itself? That is a valid question for various counters (e.g. packet
> count on an interface) where the data storage may not be accessible at the
> exact same time, and also for interface states if there is a lot of
> interfaces to query, but also for large route dumps.
>
> There is an implication for any answer to this question. Either the clients
> have to expect inconsistent results, or the servers have to freeze the states.
>
> Thank you for helping me out of this swamp.
> Have a nice day!
> Maria
>
> –
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
> _______________________________________________
> netmod mailing list -- [email protected]<mailto:[email protected]>
> To unsubscribe send an email to
> [email protected]<mailto:[email protected]>
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
