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