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.
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
