Subject: [netmod] Union Clarification (was: RE: Y53: YANG 1.1 Key Flexibility)

From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" <[email-masked]>
Date: Fri, 9 May 2014 14:00:53 +0000

[Changing the subject to separate the clarifications on unions from the original problem we're trying to solve...]

[...snip...]

To check we're on the same page, my understanding is that in that union, if a specifier matches the domain-name pattern, it would always resolve to the inet:host type (based on RFC 6020 9.2: "When a string representing a union data type is validated, the string is validated against each member type, in the order they are specified in the "type" statement, until a match is found.") -- though I could be misunderstanding what "validated" means here.
In any case, this question arises because there can be overlap in the value space of the different elements; so as well as the value itself, we need the information on which of the options is being represented to interpret the data correctly.
A union type is like a logical-OR expression.
The YANG validation tool goes through each 'type' in order and checks
if the supplied value is valid for that type.  If so, then the leaf is valid.
If the parser gets to end of the list and none of the types have validated
for the supplied value, then the leaf is rejected with an invalid-value error-tag.

OK, thanks for the clarification.

So you want to place the most selective patterns first, and the catch-all 'string' last.

So I still feel I'm missing something here. If it's just a logical-OR expression, why would it matter whether the most selective patterns are placed first? (And by extension, why is there any mention of ordering at all?]

[If anything, it sounds like if the most selective pattern is a subset of another pattern, it's not serving any purpose beyond possibly documentation; and specifying them the other way round would presumably make the validation more efficient.]

It is an implementation detail how the union type is represented within the server.

   leaf maintenance-domain {
       type maintenance-domain-identifier;
   }

Right, so if I understand correctly, you are saying that the set of types listed in the union is for no other purpose than to determine whether a leaf is valid; and the implementation can choose to interpret the value however it wishes.

If so, it would be useful to make this explicit; in particular when Yang is mapped to a binary data representation, this subtlety makes a difference to the behavior. (e.g. It looks like it is interpreted as inferring a specific type in the Yang JSON draft<https://tools.ietf.org/html/draft-lhotka-yang-json-01#section-3.3.10>.)

Thanks,
Peyman
Based on that, it looks like the data needs to be represented as a choice or as independent leaves rather than a union, right?
No

Thanks,

Peyman

Andy

These strings can be overlapping, so this cannot be represented as a union.
======

Do you have thoughts on how this should be modelled (and if extensions are needed)?

In particular, it seems there is a solution using Y09-01, though to do this we effectively have to reinvent the choice/union using a "must" statement (and I'm not sure whether this is even compatible with the "CLI" comment in Y09-01):
======
list maintenance-domains {
  key "host id name";
  leaf host { type inet:host;  mandatory false; }
  leaf id   { type hex-string; mandatory false; }
  leaf name { type string;     mandatory false; }

  // Rule to ensure exactly one of the above is specified
  must "count(host) + count(id) + count(name) = 1";
}
======

Is that the best approach, or is there a better answer? (For example, introducing a union type with a discriminator would perhaps work as it would allow the above to be modelled as a union and therefore used as a key.)

Thanks,
Peyman

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 May 2014 07:25:17 -0700

On Fri, May 9, 2014 at 7:00 AM, Peyman Owladi -X (powladi - Ensoft Ltd at
Cisco) <[email-masked]> wrote:

>  In any case, this question arises because there can be overlap in the
> value space of the different elements; so as well as the value itself, we
> need the information on which of the options is being represented to
> interpret the data correctly.
>
> So I still feel I'm missing something here. If it's just a logical-OR
> expression, why would it matter whether the most selective patterns are
> placed first? (And by extension, why is there any mention of ordering at
> all?]
>
>
>

The server implementation can take advantage of the classification.
Having a standard processing order helps for that purpose, but you are
right that it doesn't matter for validation.

The base type string matches everything so no type-stmt following it would
ever get tested.  If the implementation is using the union to convert to the
proper internal binary representation, putting 'string' first would be a
bad idea.

Andy

 [If anything, it sounds like if the most selective pattern is a subset of
> another pattern, it's not serving any purpose beyond possibly
> documentation; and specifying them the other way round would presumably make
> the validation more efficient.]
>
>
>
> Right, so if I understand correctly, you are saying that the set of types
> listed in the union is for no other purpose than to determine whether a
> leaf is valid; and the implementation can choose to interpret the value
> however it wishes.
>
>
>
> If so, it would be useful to make this explicit; in particular when Yang
> is mapped to a binary data representation, this subtlety makes a difference
> to the behavior. (e.g. It looks like it is interpreted as inferring a
> specific type in the Yang JSON draft<https://tools.ietf.org/html/draft-lhotka-yang-json-01#section-3.3.10>
> .)
>
>
>
> Thanks,
>
> Peyman
>
>    Based on that, it looks like the data needs to be represented as a
> choice or as independent leaves rather than a union, right?
>
>  No
>
>
>
>
>
>    Thanks,
>
> Peyman
>
>
>
> Andy
>
>
>
>
>
>
>
> In particular, it seems there is a solution using Y09-01, though to do
> this we effectively have to reinvent the choice/union using a "must"
> statement (and I'm not sure whether this is even compatible with the "CLI"
> comment in Y09-01):
> ======
> Is that the best approach, or is there a better answer? (For example,
> introducing a union type with a discriminator would perhaps work as it
> would allow the above to be modelled as a union and therefore used as a
> key.)
>
> Thanks,
> Peyman
>
>
>
>
>