Subject: [netmod] actions and keyless lists

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 4 Apr 2016 14:48:19 -0300

Hi,

in the thread [1], we agreed that it is necessary to prevent actions (and notifications) being defined on a state data node that is (or its ancestor is) a list for which no keys are defined because then the instance to which the action is tied may not be uniquely defined. The rfc6020bis-11 doesn't address this situation though. Is it still possible to add a corresponding text to sections 7.15 and 7.16?

Lada

[1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Apr 2016 11:57:44 -0700

Hi,

I do not see any reason to prohibit this use of action-stmt
or notification-stmt.  If the list has no keys then there is
no need to distinguish instances because the data model defines
no such semantics.

What breaks if this is allowed?

Andy

On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka <[email-masked]> wrote:

> Hi,
>
> in the thread [1], we agreed that it is necessary to prevent actions (and
> notifications) being defined on a state data node that is (or its ancestor
> is) a list for which no keys are defined because then the instance to which
> the action is tied may not be uniquely defined. The rfc6020bis-11 doesn't
> address this situation though. Is it still possible to add a corresponding
> text to sections 7.15 and 7.16?
>
> Lada
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 4 Apr 2016 16:01:09 -0300

> On 04 Apr 2016, at 15:57, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

If such a keyless list has multiple entries, how can an action request specify which of the list entries it is tied to?

> What breaks if this is allowed?

The behaviour is undefined.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Apr 2016 12:15:54 -0700

On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka <[email-masked]> wrote:

> If such a keyless list has multiple entries, how can an action request
> specify which of the list entries it is tied to?
>

it must be be relevant to distinguish instances or else the designer
would have defined a key.

> The behaviour is undefined.

IMO lists without keys are a really bad idea.
But the semantics are fully defined according to YANG.
If the list has no keys then there is no instance information
relevant to the data model.  The action or notification is passed
all the keys (happens to be zero in this case).

Andy

> > in the thread [1], we agreed that it is necessary to prevent actions
> (and notifications) being defined on a state data node that is (or its
> ancestor is) a list for which no keys are defined because then the instance
> to which the action is tied may not be uniquely defined. The rfc6020bis-11
> doesn't address this situation though. Is it still possible to add a
> corresponding text to sections 7.15 and 7.16?
> >
> > Lada
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 4 Apr 2016 17:08:37 -0300

> On 04 Apr 2016, at 16:15, Andy Bierman <[email-masked]> wrote:
> 
> 

To my understanding, each action request has to specify the unique instance that's the "receiver" of the action. If this cannot be done, it is IMO a problem in the spec.

An alternative implementation of actions would be to use instance identifiers instead of an explicit data hierarchy, and in this case it would be possible to use indices for identifying entries. But the hierarchy provides no such option.

It's not a big issue, but there is already a couple of rules regarding where actions can and cannot be defined, so this would be another one intended to avoid potential ambiguity.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Apr 2016 14:36:16 -0700

On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka <[email-masked]> wrote:

> To my understanding, each action request has to specify the unique
> instance that's the "receiver" of the action. If this cannot be done, it is
> IMO a problem in the spec.
>
> An alternative implementation of actions would be to use instance
> identifiers instead of an explicit data hierarchy, and in this case it
> would be possible to use indices for identifying entries. But the hierarchy
> provides no such option.
>
> It's not a big issue, but there is already a couple of rules regarding
> where actions can and cannot be defined, so this would be another one
> intended to avoid potential ambiguity.
>
>
I agree actions were not considered when keyless lists were allowed in YANG.
There was an assumption that this data is always read-only that is no
longer true in YANG 1.1.

I certainly prefer adding a restriction than redoing the way actions work.
Using /foo[5] does not work because entry "5" might move or get deleted,
so the numbering is not stable.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Apr 2016 16:09:38 +0200 (CEST)

> so the numbering is not stable.

How about:

  An action MUST NOT have any ancestor node that is a list node without
  a "key" statement.

(and ditto for notifs)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Apr 2016 07:38:54 -0700

>   An action MUST NOT have any ancestor node that is a list node without

OK

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Apr 2016 13:52:04 -0300

> On 05 Apr 2016, at 11:09, Martin Bjorklund <[email-masked]> wrote:
> 

Or rather:

An action MUST NOT be defined for a node that is a list without a "key" statement, or has a list node without a "key" statement as its ancestor.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Apr 2016 13:54:27 -0300

I just noticed a typo in fourth paragraph of sec. 7.15:

s/an the top-level/at the top-level/

Lada

> On 05 Apr 2016, at 13:52, Ladislav Lhotka <[email-masked]> wrote:
> 
>>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Apr 2016 09:55:38 -0700

On Tue, Apr 5, 2016 at 9:52 AM, Ladislav Lhotka <[email-masked]> wrote:

> An action MUST NOT be defined for a node that is a list without a "key"
> statement, or has a list node without a "key" statement as its ancestor.
>
>
correct -- it is ancestor-or-self

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Apr 2016 21:32:33 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> An action MUST NOT be defined for a node that is a list without a
> "key" statement, or has a list node without a "key" statement as its
> ancestor.

I don't see the difference.  Even in:

   list foo {
     action bar { ... }
   }

"foo" is an ancestor to "bar".

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Apr 2016 21:32:47 +0200 (CEST)

> s/an the top-level/at the top-level/

Thanks, fixed.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Apr 2016 17:33:13 -0300

> On 05 Apr 2016, at 16:32, Martin Bjorklund <[email-masked]> wrote:
> 

Provided "action" is a schema node which it doesn't seem to be:

action: An operation defined for a node in the data tree.

Lada

---

From: Per Hedeland <[email-masked]>
Date: Wed, 6 Apr 2016 00:04:21 +0200

> action: An operation defined for a node in the data tree.

IMO it is absolutely clear that it is a schema node - later in the
Terminology section:

   o  schema node: A node in the schema tree.  One of action, container,
      leaf, leaf-list, list, choice, case, rpc, input, output,
      notification, anydata, and anyxml.

And "7.15 The action Statement":

   The "action" statement defines an action node in the schema tree.

I can see how the "action" entry in the Terminology section - which
apparently talks about the action "concept" rather than the statement or
the node - can be confusing, though. And looking for symmetry with "rpc"
it gets perhaps even more confusing - there is no literal "rpc" entry,
but:

   o  RPC: A Remote Procedure Call.

Yeah, but...:-) Anyway, given

4.2.9.  Operation Definitions

   YANG allows the definition of operations.  The operations' name,
   input parameters, and output parameters are modeled using YANG data
   definition statements.  Operations on the top-level in a module are
   defined with the "rpc" statement.  Operations can also be tied to a
   data node.  Such operations are defined with the "action" statement.

[snip example]

   The "rpc" statement is covered in Section 7.14, and the "action"
   statement in Section 7.15.

- it seems to me that the full picture is clear enough.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Apr 2016 22:00:06 -0300

> On 05 Apr 2016, at 19:04, Per Hedeland <[email-masked]> wrote:
> 

OK, you are right, I missed this one, sorry.

Lada