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. > Lada > > Andy > > > > > > > > Lada > > > > > > Andy > > > > > > > > > > > > > Andy > > > > > > > > > On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka <lho...@nic.cz> > wrote: > > > Hi, > > > > > > in the thread [1], we agreed that it is necessary to prevent actions > (and notifications) being defined on a state data node that is (or its > ancestor is) a list for which no keys are defined because then the instance > to which the action is tied may not be uniquely defined. The rfc6020bis-11 > doesn't address this situation though. Is it still possible to add a > corresponding text to sections 7.15 and 7.16? > > > > > > Lada > > > > > > [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html > > > > > > -- > > > 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 > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
