RFC: moving Radiotap forward

RFC: moving Radiotap forward

[David Young]

I have written some proposals and desires for moving Radiotap forward.

1 This list will "keep" the Radiotap standard.  That is, this is the venue
  at which to propose new fields for discussion and eventual adoption.
  We will adopt new fields into the standard when there is "rough
  consensus and running code."  Let's strive for general agreement of the
  list membership, at least one driver and at least one packet capture
  tool that groks a new field.

  The list membership needs to be representative of folks who have
  a stake in Radiotap, especially developers of device drivers
  for Linux, OpenSolaris, *BSD, et cetera, and developers of packet
  capture/filter/dissection/display software such as WireShark, libpcap,
  Kismet, and TCPDump.  "Are we all here?"

2 The Radiotap documentation needs to appear on "neutral ground" on the
  web---i.e., not in a NetBSD manual page.  Web resources need to be
  "beefed up" to include a careful specification, lists of assigned
  numbers, examples, reference implementations, and tests.  I have
  reserved a couple of Radiotap domain names to hold that information.
  Radiotap needs a volunteer web admin.

3 We need to set minimum requirements for a field, such as specifying
  its width, alignment, name, and interpretation.

4 We need to prioritize arresting Radiotap fragmentation.  I do not know
  if we can reconcile the conflicting uses for bits 14 and upward, but
  I hope Radiotap stakeholders can be reconciled with our introduction
  of a consensus process.

5 It seems to me that we need to decide

    Will we adopt fields for WiMax?  Do we have enough people both with a
    stake and with expertise in WiMax to do that?

    Do we / how will we support vendor-specific fields?

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933 ext 24

Re: RFC: moving Radiotap forward

[Charles Clancy]

> 1 This list will "keep" the Radiotap standard.  That is, this is the venue
>   at which to propose new fields for discussion and eventual adoption.
>   We will adopt new fields into the standard when there is "rough
>   consensus and running code."
 > ...
 > 3 We need to set minimum requirements for a field, such as specifying
 >   its width, alignment, name, and interpretation.

Sounds very IETF-ish.  Any thoughts on publishing Radiotap as an 
Internet Draft and eventually RFC?  You could set up an IANA registry 
for the extensible fields.  IETF is typically L3+, but Radiotap could be 
pitched abstractly enough that it wouldn't necessarily violate that.

I have significant experience with the IETF, and could help out with the 
process if the group is interested.

> 5 It seems to me that we need to decide
> 
>     Will we adopt fields for WiMax?  Do we have enough people both with a
>     stake and with expertise in WiMax to do that?

Well, I'm one...

>     Do we / how will we support vendor-specific fields?

In similar situations in the past, I've defined field identifiers in 
general to be 6 bytes, with the first four bytes being the vendor's 
object identifier (OID) and the last two being the actual field. 
OID==0x00000000 represents the non-vendor-specific list of 2^16 possible 
fields.

-- 
t. charles clancy, ph.d.  <>  tcc-e45ueOrobK4@public.gmane.org  <>  www.cs.umd.edu/~clancy