On 17/07/2020 09.11, Ladislav Lhotka wrote:
On 17. 07. 20 8:57, Michal Vaško wrote:
Hi Carsten,
you had an interesting idea to have tools that could warn about these problems
(although that is hardly a proper solution) but it is not really possible
because the problem may occur whenever there is union with a 'string' and
'int8' - 'int32', 'uint8' - 'uint32', or 'boolean', in any order. Meaning in
lots of, if not most, unions. And I have considered only XML and JSON, I have
not looked into CBOR, which may make it even worse.
What you can do is to define a metadata annotation specifying the union
member for a particular instance, and implement it in your tools. This
would be a solution independent of instance representation.
IMO this does not solve the problem that XML can not encode all values
of the value space in certain awkward unions (JSON and CBOR can't do
that either only the constraints are alternative supersets).
If the XML representation rules in the YANG definition were provided as
an inherent constraint to the value space of the union type there was
not going to be ambiguity and there would have been a bug in any
encoding that does not enforce this exact constraint. This is not
spelled out in RFC7950 but is a good rule of thumb to avoid unions that
have value space that can not be represented in XML.
The alternative is to rework the XML representation to not have such
limitation in a next version of YANG (e.g. adding XML attributes with
the active member type index and name).
That said I think there is one underestimated feature of the union type
being entirely mapped to a string also for integer types as it is in the
current XML encoding definition. Without requirement for resolving which
member type the data actually is representing but just validating there
is at least one match allows implementations to encode the data without
resolving a possibly complex logical relationship. For example a union
of interface index and leafref to interface name (for whatever reason
someone would design such a union). You really do not need to know if
there is an interface named "2" in the candidate configuration when you
send <edit-config> in XML. With JSON you have to resolve this.
/Vladimir
Lada
Regards,
Michal
In my view, if it is a bug, it is in the design of the union type in YANG -
there is no general way to signal the actual union member type for an instance.
Right. The ambiguity is normally not a problem for a type choice (which is
just a union of the possible values of all types given), unless what specific
alternative was chosen is intended to carry semantics.
I believe it is a good thing that some encodings allow for at least partial
signalling.
Note that similar issues may arise even more often in CBOR, see e.g. comments
for section 5.12 in
https://mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4/
In the original YANG (XML-only), everything was represented as a text string,
so the ambiguity was the highest we see now. YANG-JSON and YANG-CBOR provide
progressively more disambiguating information, so the interpretation (which
chosen alternative) may be different from the one after converting to YANG-XML.
It gets slightly worse if the non-text type has a conversion to text that is
not fully nailed down; I don’t know if that is a problem with the current set
of YANG types, but any new type could of course worsen the situation.
The onus is now on the author of the YANG module to make sure that the varying
levels of ambiguity do not cause a problem. I would be interested to know
whether there is any tool support for this.
Grüße, Carsten
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
