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

On Wed, May 6, 2020 at 10:22 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Carsten Bormann <cabo@tzi.org> wrote:
>     >> 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.)
>
> I think that the YANG knows what the maximum value is.
> So I think that anyone generating code from specific YANG definitions could
> size their array based upon that value.
> If it's a generic decoder for YANG encoded content, then it might need
> a hint from the application, or it could have a compile-time arbitrary
> limit.
>
>
There are 2 competing goals: fidelity and efficiency

For network management and telemetry, fidelity is critical.
Missing data and altered data are dealbreakers.

I think 1 point Rob is making is that the bitset encoding can end up being
much less efficient
than an XSD-style list of tokens.  Encoding bit position 4 million requires
an octet string 500,000 bytes long.
Obviously not a workable solution, even for an unconstrained device/network.
Also not OK to drop bit values that seem too big for the implementation.
That is not reliable enough.

Why is the bit position allowed to be a uint32 in YANG? Who knows, but it
has to be supported.

--
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> _______________________

Andy

> ________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>