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. (and ditto for notifs) /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
