Re: [netmod] Yang 1.1 change: Allow type "empty" in a key.

> On 15 Feb 2017, at 15:56, Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco) <mciglan@cisco.com> wrote:
> 
> 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.

So what's your problem with them?

Lada

> ________________________________________
> Od: Jernej Tuljak <jernej.tuljak@mg-soft.si>
> 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); netmod@ietf.org
> Predmet: RE: [netmod] Yang 1.1 change:  Allow type "empty" in a key.
> 
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: Wednesday, February 15, 2017 11:40 AM
>> To: Jernej Tuljak <jernej.tuljak@mg-soft.si>
>> Cc: Alex Campbell <Alex.Campbell@Aviatnet.com>; Martin Ciglan -X (mciglan
>> - PANTHEON TECHNOLOGIES at Cisco) <mciglan@cisco.com>; Igor Foltin -X
>> (ifoltin - PANTHEON TECHNOLOGIES at Cisco) <ifoltin@cisco.com>;
>> netmod@ietf.org
>> Subject: Re: [netmod] Yang 1.1 change: Allow type "empty" in a key.
>> 
>> 
>>> On 15 Feb 2017, at 11:16, Jernej Tuljak <jernej.tuljak@mg-soft.si> 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:netmod-bounces@ietf.org] On Behalf Of Alex
>> Campbell
>>> Sent: Tuesday, February 14, 2017 9:59 PM
>>> To: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)
>> <mciglan@cisco.com>
>>> Cc: Igor Foltin -X (ifoltin - PANTHEON TECHNOLOGIES at Cisco)
>> <ifoltin@cisco.com>; netmod@ietf.org
>>> 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 <netmod-bounces@ietf.org> on behalf of Martin Ciglan -X
>> (mciglan - PANTHEON TECHNOLOGIES at Cisco) <mciglan@cisco.com>
>>> Sent: Wednesday, 15 February 2017 2:48 a.m.
>>> To: netmod@ietf.org
>>> 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
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> 
>> 
>> 
> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67