Subject: Re: [netmod] Using an empty type in a list key

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Tue, 6 Sep 2016 02:50:19 +0000

I did manage to find some older posts about empty types in keys. It seems that perhaps YANG 1.1 allows them but they are not actually useful.  I believe perhaps my example below does *not* work as I show and instead every apartment would be required to be a "bis" apartment.  Keys must be present which means the "bis" leaf would always have to be present.

Any confirmation of this would be appreciated.

Regards,
Jason

From: netmod [mailto:[email-masked]] On Behalf Of Sterne, Jason (Nokia - CA)
Sent: Tuesday, August 30, 2016 18:17
To: [email-masked]
Subject: [netmod] Using an empty type in a list key

Hi all,

I saw the addition of empty types in list keys in YANG 1.1 but had troubles finding more details in the NETMOD list.  Is it discussed in the YANG 1.1 issues page (and if so, where is that now ?  I tried an old link and it didn't work) ?

If I take this example where I have a set of a apartments 1,2,3 but there may also be occasional 'bis' apartments (e.g. 7bis).

list apartment {
    key "number bis";
    leaf number {
        type int16;
    }
    leaf bis {
        type empty;
    }
    leaf description {
         type string;
    }
}

Can I create list entries like this ?

<apartment>
    <number>5</number>
    <description>apartment 5</description>
<apartment>
<apartment>
    <number>8</number>
    <bis/>
    <description>apartment 8bis</description>
<apartment>
<apartment>
    <number>8</number>
    <description>apartment 8</description>
<apartment>

Doesn't the empty type have two states and the absence/presence of the leaf/tag indicates those states ?

I realize that a Boolean type could be used for bis but the use case (a question of preference/style) is that 'bis' is unusual and so it becomes noisy to have to set <bis>false</bis> all the time when creating apartment entries.  It may be useful to only have to specify <bis/> in the rare cases that it is needed.

Regards,
Jason

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Sep 2016 07:45:24 +0200

On Tue, Sep 06, 2016 at 02:50:19AM +0000, Sterne, Jason (Nokia - CA) wrote:

> I did manage to find some older posts about empty types in keys. It
> seems that perhaps YANG 1.1 allows them but they are not actually
> useful.

Yes. Note that there are other constructs that are legal but not
useful (a list key leaf with a type that only allows a single value
is very close to list key leaf of type empty).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Phil Shafer <[email-masked]>
Date: Tue, 6 Sep 2016 14:11:19 -0400

>is very close to list key leaf of type empty).

No, a missing key is worse, since the spec requires that all keys
must appear (7.8.6: 'If all keys are not specified for a list entry,
a "missing-element" error is returned.' Also 8.3.1).  A key that
only allows a single value may be useless, but it makes data that
can be consistently manipulated.  Is there a change in 7950 for
handling these?

In a similar node, while looking in 7950 for a such a rule, I saw the
following in 9.13.4:

     /* instance-identifier for a list entry where the second
        key ("enabled") is of type "empty" */
     /ex:system/ex:service[ex:name='foo'][ex:enabled='']

But XPath says (4.2):

    A node-set is converted to a string by returning the string-value
    of the node in the node-set that is first in document order.
    If the node-set is empty, an empty string is returned.

So if no <ex:enabled> elements are present, then the expression
ex:enabled selects an empty node set, and the string comparison
forces a conversion to type string, which generates an empty string.
Unless I'm off, the line should be fixed to avoid the string
conversion:

         /ex:system/ex:service[ex:name='foo'][ex:enabled]

and a negation should be:

         /ex:system/ex:service[ex:name='foo'][not(ex:enabled)]

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Sep 2016 16:42:49 -0700

>          /ex:system/ex:service[ex:name='foo'][not(ex:enabled)]
There is only one value provided by type empty.  The 2nd instance
identifier is invalid.
There is no instance possible that does not include the 'enabled' leaf.

I added a section on this issue in the latest 6087bis draft:

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-08#section-5.11.5

I think we had it right in YANG 1.0.
Using a key of type empty is utterly pointless unless the point
is to make the instance identifier longer.

>  Phil

Andy

>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 07 Sep 2016 22:02:27 -0400

> is to make the instance identifier longer.

IMO using a key of type empty (or any type with only one value) is
*pointless* but should be *valid*.  Things should be valid unless
processing them according to the ordinary rules can't work.  Indeed,
specifically banning them increases the complexity of the
specification.

The reason for this is that the code (in this case, the module
definition) may be generated by an automatic process, and those
processes are easier to construct if the rules contain fewer
irregularities.  E.g., multiplying a number by zero is pointless, in
that the result is always zero, and one might ask, Why not just write 0
instead of the multiplication?  But everyone agrees that the statement

    a = 0 * b;

is *valid*, and can easily imagine situations where a process might
generate it as an output.

> There is no instance possible that does not include the 'enabled' leaf.

The 2nd instance identifier is (should be) *valid* even if it always
returns the empty set.  (Assuming it is used in contexts where a set can
be returned.)

Dale

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Sep 2016 19:20:21 -0700

> specifically banning them increases the complexity of the
It is both pointless and valid.

> generate it as an output.
Not sure that this has to do with YANG list keys.

> returns the empty set.  (Assuming it is used in contexts where a set can

I disagree -- an instance identifier has a strict syntax.
The 2nd expression is valid XPath (again, pointless and valid)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 09 Sep 2016 15:44:49 +0200

> specifically banning them increases the complexity of the

+1

There is no need to ban keys with type "empty", XPath and everything
works fine if other YANG rules are followed.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Sep 2016 07:07:05 -0700

> works fine if other YANG rules are followed.

Why should YANG Doctors approve a YANG module that uses type empty as a key?
The guidelines say SHOULD NOT use empty as a key.  Come up with a use-case.
(You can't). If you can, I will remove the guideline from the draft.

The YANG Guidelines draft restricts YANG usage for IETF standards track
modules.
Use lots of empty keys in your data model if you want.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 9 Sep 2016 16:26:58 +0200

> On 09 Sep 2016, at 16:07, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

This is all fine, my point (and I think Dale's as well) is that it should be permitted in YANG the language, so it is a good thing that this 6020 CLR is no more present in 7950:

   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".

Earlier in this thread you said that we had it right in YANG 1.0, and I don't agree with that.

Lada

> 
> The YANG Guidelines draft restricts YANG usage for IETF standards track modules.