Re: [RFA] TLV fields for radiotap

On Tue, 2018-12-18 at 14:45 +0100, Johannes Berg wrote:

> > I had a thought about this tonight: maybe the solution is to define
> > a new radiotap field, "hint," that contains a hint about the offset
> > to a field.  The field begins with a 16-bit (?) field number, f, to
> > be interpreted in the current namespace.  Following that is a 16-bit
> > (?) absolute offset from the end of the hint field to field f.  If you
> > introduce your vendor namespace when the last-assigned presence bit is
> > bit p, and later you reuse the vendor namespace with newly-assigned
> > presence bit p+k, then you can supply a hint for the vendor namespace
> > field so that old readers can still benefit from presence bits 0..p and
> > your vendor fields.

I thought about this again ... and I decided I still don't think it's a
good idea.

> Hmm. Actually, yes, I think that would work. However, it's hard to guess
> which fields the parser can do, so unless you have a really smart parser
> you'd end up with
> 
> fields 0..n, hint, n+1, hint, n+2, hint, n+3, vendor_data

I think this one's the killer to me, in a sense.

If you think about it - yes, right now, you could say

   Implementations currently understand fields 0..HE-MU, and I want to
   have some new field (e.g. S1G) and will add a hint.

With this thinking, you get:

 0..HE-MU, vendor-data-hint, S1G, vendor-data

But like I described above, the next time you do this you probably don't
want to change it to be

 0..HE-MU, S1G, vendor-data-hint, EHT, vendor-data

but rather

 0..HE-MU, vendor-data-hint, S1G, vendor-data-hint, EHT, vendor-data

and that gets complex really fast, and also *bigger* than any sort of
TLV formatting would ever get.

I'll resend the adoption proposal now, I think it's the better solution.

johannes