Subject: [netmod] when are 'when' and leafref checked?

From: Andy Bierman <[email-masked]>
Date: Sat, 27 Aug 2011 11:08:44 -0700

Hi,

1) when-stmt:

The 'when-stmt' is not considered a validation constraint wrt/
constraint rules of procedure in sec. 8.3. It is supposed to have
instant results (8.3.2, last bullet).  All false when-stmt nodes
are supposed to all get deleted as part of the edit-config that
changes a value (causing the new false result to occur).

This introduces ordering requirements into edit-config,
and goes against the scratchpad design of the candidate.

Martin says it is a feature that when-stmt works like choice-stmt
and automatically deletes nodes right away.

But it also applies to nodes you are creating in the candidate, not
just the ones already there.  Any node with a when-stmt becomes
an order-dependency statement.  The nodes in the when-stmt expression have to
all be set up first, then the node with the when-stmt.  And if
those nodes have when-stmts, it gets really complicated.

IMO the value of the candidate is greatly diminished if the client
cannot build up a valid config with any sequence of partial edits.

2) leafref-stmt)

The text in 9.9 is not really clear about when a leafref type
needs to be valid:

    The leafref type is used to reference a particular leaf instance in
    the data tree.

This is code for the current tree.  Otherwise the text would mention
a valid configuration.  But 8.3.3 clearly says a leafref is checked
during a 'validate':

    o  Any referential integrity constraints defined via the "path"
       statement MUST be satisfied.

So is a leafref path-stmt included here?
leafref-stmt is the only one that uses path-stmt, so it must.
Is the text in sec. 9.9 incomplete or wrong?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Aug 2011 08:40:04 +0200

> and automatically deletes nodes right away.

The big difference between when-stmt and choice-stmt is that the latter by design never depends on node *values*.

The auto-deletion behaviour also goes against the principle of least embarrassment in that a trivial typo in a node value may potentially lead to deletion of large parts of candidate.

> cannot build up a valid config with any sequence of partial edits.

I agree. Only grammatical and data type constraints should be enforced for candidate and the rest should be checked during commit. In fact, I've been thinking about introducing a new "sandbox" datastore with this semantics in our Netopeer implementation.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Aug 2011 08:47:20 +0200 (CEST)

> Is the text in sec. 9.9 incomplete or wrong?

9.9 also says:

   All leafref nodes MUST reference
   existing leaf instances or leafs with default values in use (see
   Section 7.6.1) for the data to be valid.  This constraint is enforced
   according to the rules in Section 8.

So I think it is clear from 9.9 when this constraint is enforced.

I fear I might have misunderstood your concern.

/martin