Re: New Version Notification for draft-troan-6man-universal-ra-option-03.txt

[Ted Lemon <[e-mail]>]

On Oct 8, 2020, at 2:09 PM, Michael Richardson <[e-mail]> wrote:
> Assuming you only write one TLV parser, and one JSON parser, and you use them
> both once, then your comparison is valid.

You missed my main point, which is that you have to write a validator for each data object. So yes, maybe in the ideal case you have a really great CBOR parser that even lives up to some of the promises that Brian quoted from the abstract. And maybe you have good validators for some data objects, and not as good validators for other data objects. Who knows?

> How many TLV formats does the IETF have?  Seven? Ten?

> How many are written with the same care as the CBOR (apples to apples here), parser?
> The goal here is not to enable embedded systems to parse RA option in
> python[%], but to enable new RA options to be passed through to
> *applications* (not kernels) that need them.

“the CBOR parser?”

I don’t disagree that it would be nice to have a common TLV format document that specified all the data types, how arrays are represented, how dictionaries are represented, etc. What I am saying is simply that specifying CBOR not only doesn’t automatically make things safe, but in fact actually makes it a lot easier to write code that is unsafe, for exactly the reason Brian mentioned—it’s really easy to throw a binary blob at a CBOR parser and get a data structure back, and it’s really easy to not fully validate that data structure. You can always do that later.

What you really want is something like what PHB did a while back: define the data encapsulation as a grammar from which a parser can simply be compiled.