Thanks for information, but still, from implementation point of view, we've got empty keys in Map structures, searching for values... that was my point. ________________________________________ Od: Jernej Tuljak <[email protected]> Odoslané: 15. februára 2017 13:27 Komu: 'Ladislav Lhotka' Kópia: 'Alex Campbell'; Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco); Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco); [email protected] Predmet: RE: [netmod] Yang 1.1 change: Allow type "empty" in a key.
> -----Original Message----- > From: Ladislav Lhotka [mailto:[email protected]] > Sent: Wednesday, February 15, 2017 11:40 AM > To: Jernej Tuljak <[email protected]> > Cc: Alex Campbell <[email protected]>; Martin Ciglan -X (mciglan > - PANTHEON TECHNOLOGIES at Cisco) <[email protected]>; Igor Foltin -X > (ifoltin - PANTHEON TECHNOLOGIES at Cisco) <[email protected]>; > [email protected] > Subject: Re: [netmod] Yang 1.1 change: Allow type "empty" in a key. > > > > On 15 Feb 2017, at 11:16, Jernej Tuljak <[email protected]> wrote: > > > > Plus, "empty keys" were aready allowed in YANG 1. > > Well, keys with "empty" type were not allowed. What you are saying is that > the same (dubious) effect can be achieved in other ways that were > permitted in YANG 1. Indeed. I meant »empty keys«. Quoting is hard. :) Jernej > Note also that while if in XML encoding an empty leaf > and a leaf containing string of length 0 look the same, in JSON encoding they > are different: > > "first": [null] > > versus > > "first": "" > > > > > module empty-key { > > namespace "org:example:empty-key"; > > prefix "ek"; > > > > container stuff { > > list item { > > key "first second"; > > leaf first { > > type string { > > length 0; > > } > > } > > leaf second { > > type string { > > pattern '.{0}'; > > } > > } > > } > > } > > } > > > > Therefore this change removed a redundant (perhaps even broken) rule. > > Agreed. > > Lada > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg16763.html > > Jernej > > > > From: netmod [mailto:[email protected]] On Behalf Of Alex > Campbell > > Sent: Tuesday, February 14, 2017 9:59 PM > > To: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco) > <[email protected]> > > Cc: Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco) > <[email protected]>; [email protected] > > Subject: Re: [netmod] Yang 1.1 change: Allow type "empty" in a key. > > > > Hi, > > > > It means exactly what the summary says. In YANG 1.0 (RFC 6020) we have: > > A leaf that is part of the key can be of any built-in or derived > > type, except it MUST NOT be the built-in type "empty". > > and in YANG 1.1 (RFC 7950) we have: > > A leaf that is part of the key can be of any built-in or > > derived type. > > > > In YANG 1.1, leaves of type "empty" are not disallowed from being keys. > > > > Note that since leaves of type "empty" only convey information through > their presence or absence, and since > > key leaves must always be present, key leaves of type "empty" convey no > useful information. > > > > Alex > > > > > > From: netmod <[email protected]> on behalf of Martin Ciglan -X > (mciglan - PANTHEON TECHNOLOGIES at Cisco) <[email protected]> > > Sent: Wednesday, 15 February 2017 2:48 a.m. > > To: [email protected] > > Cc: Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco) > > Subject: [netmod] Yang 1.1 change: Allow type "empty" in a key. > > > > Hi all > > > > Yang 1.1 change: Allow type "empty" in a key. > > > > What is the meaning of this change? We're interested from > implementation point of view. > > > > Thanks > > > > Martin > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
