Re: [netmod] CBOR YANG encoding of union & bits [draft-ietf-core-yang-cbor-12]

[Andy Bierman <[e-mail]>]

On Wed, May 6, 2020 at 8:52 AM Carsten Bormann <[e-mail]> wrote:

> 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
>
>
I remember this issue was discussed by the WG.
The only real reason to assign explicit bit positions is to match some
protocol specification,
which would never waste space in a bitset.

Rob has a valid concern -- what if a large bit position is encountered?


> >       }
> >       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.)
>
>

This is the approach we started with for the union type but ended up
changing it later.
It is better to fully support YANG semantics with a less efficient
encoding, rather than
tag some YANG modules as "unsupportable".

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

Would it be possible to have 2 encoding formats for bits?
   1) binary encoding using bit positions (only bit positions 0 -- 255
allowed)
   2) YANG XML encoding using bit names (any bit positions over position
255)

The client and server already have to deal with the YANG XML encoding for
union types
so this would not be that different.



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

This is already the case but the RFCs have not caught up yet.
If YANG is ever updated the XML-specific text will probably get moved to a
separate document.


> Grüße, Carsten
>
>

Andy


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