> 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.
Lada
>
>
> /martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
