Hi Rob,
> 1) Regarding the encoding of the bits datatype:
> [draft-ietf-core-yang-cbor-12, section 6.7]
>
> The CBOR YANG encoding of the bits datatype is defined as a byte string
> encoding of a bitfield. However, my concern here is that YANG bit positions
> are allowed to be up 2^32-1.
>
> E.g. the following, pathologically bad, bits definition would seem to have a
> very inefficient encoding in CBOR:
>
> typedef alarm-state {
> type bits {
> bit unknown {
> position 4000000000;
My knee jerk reaction would be “don’t do that then” [1].
[1]: http://catb.org/jargon/html/D/Don-t-do-that-then-.html
> }
> bit under-repair;
> bit critical;
> bit major;
> bit minor;
> bit warning;
> bit indeterminate;
> }
> }
>
>
> How much should we be concerned about this pathological case? Would it be
> reasonable for implementations to reject bitfields larger than a small set
> size (e.g. perhaps 256 bits)?
>
> Or, if it is supported by the language then is it reasonable that
> implementation SHOULD support it? In which case I think that we might need a
> second encoding of bits that supports this pathological case. Perhaps an
> array of 'set' bit positions, or alternatively the union string encoding of
> bits could be used.
This could reduce the attack vector by malicious YANG specification, but I
think an arbitrary limit (such as the 256 mentioned above) should work, too.
(Except that arbitrary limits always come back to bite you, but that’s what we
have software maintenance contracts for.)
> 2) Regarding the encoding of unions:
>
> I was questioning whether the special encoding of bits type within a union
> was required in CBOR [draft-ietf-core-yang-cbor-12, section 6.7]. Am I right
> to presume that this is to ensure that the CBOR encoding of unions is always
> at least as specific as XML? If so, this seems like a reasonable design
> choice.
The semantics of Union types in YANG is closely married to the XML
representation of YANG; if two branches of a union have a (non-empty)
intersection in their XML encoding, this ambiguity is pretty much considered a
feature.
So YANG-CBOR falls back to something that looks more like XML encoding (i.e.,
is less efficient) in unions.
The one nice thing is that a YANG spec writer can avoid the pathology by not
using unions in this way; unfortunately, the fallback cannot rely on
recognizing that the intersection is non-empty.
It occurs to me that this fallback could also be used for the above anomalies;
we would need to agree on a threshold when that becomes active.
> But that leads on to these general YANG questions:
>
> Should the value encoding of a YANG union type behave the same way regardless
> of whether the encoding is XML/JSON/CBOR?
Of course it “should”, while retaining reasonableness for each of the
encodings, but that ship seems to have sailed (at least for 1.0/1.1).
> Or is it reasonable for there to be differences in the case of conflicting
> values? Perhaps this is already answered by RFC 7951 that can behave
> differently from the XML encoding of unions.
>
> Longer term, should YANG be looking for a discriminated-union type? Or
> perhaps it would be sufficient for tooling to flag up potentially ambiguous
> union definitions, particularly those that may be encoding dependent.
These are all good questions.
I don’t have an answer, except that the marriage of YANG to XML semantics
probably should get a divorce at some point.
Grüße, Carsten
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
