> On 05 Apr 2016, at 19:04, Per Hedeland <p...@tail-f.com> wrote:
>
> On 2016-04-05 22:33, Ladislav Lhotka wrote:
>>
>>> On 05 Apr 2016, at 16:32, Martin Bjorklund <m...@tail-f.com> wrote:
>>>
>>> Ladislav Lhotka <lho...@nic.cz> wrote:
>>>>
>>>>> On 05 Apr 2016, at 11:09, Martin Bjorklund <m...@tail-f.com> wrote:
>>>>>
>>>>> Andy Bierman <a...@yumaworks.com> wrote:
>>>>>> On Mon, Apr 4, 2016 at 1:08 PM, Ladislav Lhotka <lho...@nic.cz> wrote:
>>>>>>
>>>>>>>
>>>>>>>> On 04 Apr 2016, at 16:15, Andy Bierman <a...@yumaworks.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Apr 4, 2016 at 12:01 PM, Ladislav Lhotka <lho...@nic.cz> wrote:
>>>>>>>>
>>>>>>>>> On 04 Apr 2016, at 15:57, Andy Bierman <a...@yumaworks.com> wrote:
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> What breaks if this is allowed?
>>>>>>>>
>>>>>>>> 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).
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> How about:
>>>>>
>>>>> An action MUST NOT have any ancestor node that is a list node without
>>>>> a "key" statement.
>>>>
>>>>
>>>> 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.
>>>
>>> I don't see the difference. Even in:
>>>
>>> list foo {
>>> action bar { ... }
>>> }
>>>
>>> "foo" is an ancestor to "bar".
>>
>> Provided "action" is a schema node which it doesn't seem to be:
>>
>> 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.
OK, you are right, I missed this one, sorry.
Lada
>
> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
