On Wed, May 6, 2020 at 10:22 AM Michael Richardson <[email protected]> wrote:
> > Carsten Bormann <[email protected]> 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 <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > _______________________ Andy > ________________________ > core mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/core >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
