Sounds great to me On Sep 25, 2015, Dave Taht wrote: >The core of the FCC letter is currently this. comments? > >snip snip > >In place of last year’s and the new proposed regulations, we propose a >system of rules that would foster innovation, improve security, make >Wi-Fi better, and overall improve usage of the Wi-Fi spectrum for >everybody. > >1) Mandate that: for a SDR, wireless, or Wi-Fi radio of any sort - in >order to achieve FCC compliance - full and maintained source code for >at least the device driver and radio firmware be made publicly >available in a source code repository on the internet, available for >review and improvement by all. > >2) Mandate that: the vendor supply a continuous update stream, one >that must respond to regulatory transgressions and CVEs within 45 days >of disclosure, for the warranted lifetime of the product + 5 years >after last customer ship. > >3) Mandate that: secure update of firmware be working at shipment, and >that update streams be under ultimate control of the owner of the >equipment. Problems with compliance can then be fixed going forward. > >4) Failure to comply with these regulations will result in FCC >decertification of the existing product and in severe cases, bar new >products from that vendor from being considered for certification. > >5) In addition, we ask that the FCC review and rescind the rules for >anything that conflicts with open source best practices, and/or which >causes the vendors to believe they should hide the mechanisms they use >by shipping undocumented “binary blobs” of compiled code. This had >been an ongoing problem to all in the internet community trying to do >change control and error correction on safety-critical systems. > > >On Fri, Sep 25, 2015 at 9:16 PM, David P. Reed wrote: >> Those of us who innovate at the waveform and MAC layer would argue >> differently. The cellular operators are actually the responsible >control >> operators and hold licenses for that. They may want to lock down >phones' >> cellular transmitters. But U-NII and ism bands are not licensed to >these >> operators. There is no license requirement for those bands to use >particular >> waveforms or MAC layers. >> >> So this is massive overreach. The control operator of the "licensed >by rule" >> Part 15 radios in your phone or home are licensed to the device user >and not >> to the mfr at all. For example, the user is responsible that the >device not >> interfere with licensed services, and that the device stop >transmitting if >> such harmful interference is called to their attention, *even* if the >device >> passed certification. >> >> Lock down has not been demonstrated to be necessary. This is all due >to >> fearful what - if speculation by people who have no data to justify >the >> need, plus attempt to stop innovation by licensees who want to >exclude >> competitors from being created, like LTE operators proposing LTE-U >which >> will be locked down and is the stalking horse for taking back open >part 15 >> operation into a licensed regime based on property rights to >spectrum. >> >> >> On Sep 24, 2015, Dave Taht wrote: >>> >>> a commenter that I will keep anonymous wrote: >>> >>> >>> Regarding the FCC firmware lockdown issue, I’m sure you’re aware >that >>> baseband firmware in cellphones has been subject to similar >>> restrictions for some time. In fact, the FCC effectively mandates >that >>> baseband functionality is implemented on a whole separate subsystem >>> with its own CPU to make it easier to isolate and protect. Also, the >>> cellphone system is designed so that a misbehaving node can be >easily >>> identified and blocked from the network, making it useless and >>> removing most of the incentive to find ways around regulatory >>> restrictions. Wi-Fi devices have none of these protections. >>> >>> I believe this new attention to Wi-Fi devices is a consequence of >many >>> factors: >>> >>> The precedent from cellphone baseband firmware control; regulators >are >>> easily inspired by success stories in related areas >>> The substantial increase in flexibility offered by SDR >implementations >>> Technical ignorance, for example of the difference between OS, >>> protocol, and UI firmware and baseband firmware >>> The expansion of allowed capabilities in Wi-Fi hardware (from 5.8 >GHz >>> ISM to the U-NII bands, increases in transmit power allowances, >etc.) >>> The improved spectrum utilization of newer Wi-Fi modulation schemes >>> Inconsistencies among international regulations for spectrum >allocation >>> Spectrum sharing between Wi-Fi and life safety applications >>> The relative lack of attention to (and sometimes, the deliberate >>> flouting of) regulatory constraints in open-source firmware >>> The increased availability of open-source firmware for higher-power >>> and narrow-beam Wi-Fi devices (not just the WRT-54G :-) >>> >>> >>> And probably more I can’t think of off the top of my head, but which >>> regulators are obsessing over every day. >>> >>> Although I agree with the spirit of your FCC email draft letter, it >>> does not address most of these factors, so it’s likely to be seen as >>> missing the point by regulators. If you want to reach these people, >>> you have to talk about the things they’re thinking about. >>> >>> What you ought to be pushing for instead is that Wi-Fi devices be >>> partitioned the same way cellphones are, defining a baseband section >>> that can be locked down so that the device can’t operate in ways >that >>> are prohibited by the relevant local regulations, so that the OS, >>> protocol, and UI code on the device can be relatively more open for >>> the kinds of optimizations and improvements we all want to see. >>> >>> It’s possible that the partition could be in software alone, or in >>> some combination of hardware and software, that doesn’t require a >>> cellphone-style independent baseband processor, which would add a >lot >>> of cost to Wi-Fi devices. For example, the device vendor could put >>> baseband-related firmware into a trusted and _truly minimal_ binary >>> module that the OS has to go through to select the desired >frequency, >>> power, and modulation scheme, even for open-source solutions. That >>> doesn’t mean the source code for the binary module can’t be >published, >>> or even that there can’t be a mandate to publish it. >>> >>> I’m sure that doesn’t sound like a great solution to you, but making >>> it easy for end users to configure commercial devices to transmit at >>> maximum power on unauthorized frequencies using very dense >modulation >>> schemes doesn’t sound like a great solution to regulators, and the >>> difference between you and the regulators is that they are more >>> determined and, frankly, better armed. It will do you no good to >>> constrain the range of the solutions you’ll accept so that it >doesn’t >>> overlap with the solutions they will accept. >>> >>> . png >>> >>> >>> On Sep 21, 2015, at 5:10 AM, Dave Taht >wrote: >>> >>> >>> Dave, >>> >>> >>> Huh. I have been interested in mesh networking for a couple of years >>> now, and curious about Battlemesh, but I had no idea I knew someone >>> who was active in it. >>> >>> >>> Are there any other reports online from this year or last year? The >>> website doesn't seem to serve any purpose beyond announcing the >event. >>> >>> >>> >>> As you can tell I am way, way behind on my email. I've mostly been >>> chasihg funding for my main project, make-wifi-fast for over a year >>> now - I added in the mill and the "cake switch chip" to that overall >>> list as I tried to climb the financial ladders. My funding at google >>> dried up suddenly (due to the re-org), and I was forced to chase >other >>> avenues. I think i got a grant from comcast coming in, but it is for >>> 1/10th the total I needed for make-wifi-fast... and it is hung up in >>> legal, and in the fact the work has to mostly happen in europe. >>> >>> So I've moved to europe, trying to find bases in bristol, england, >>> berlin, and sweden. That's taken a while (I dropped out of the mill >>> process in may or so due to the sudden google silences, and the lack >>> of compiler - and I view mill's biggest problem is funding, so it >>> seems like just combining my own quest with yours the right thing) >>> >>> I was very involved in the early days of wireless networking but >>> dropped out by 2002 or so, much to my now, later regret. The only >devs >>> left that understand it at more than one level all go to battlemesh, >>> so I've been there twice. I still find it quite discouraging how few >>> grok the minstrel algorithm, or what is wrong with packet >aggregation. >>> A billion+ users that all think wifi "just works", and "always >>> sucked"... :( I gave a talk on the latter as well at at this >>> battlemesh. >>> >>> anyway the videos and results from this battlemesh are all now >online. >>> I am pushing on all fronts, but being a manager was a bit wearying >so >>> I took time out to do some recording at a place called >theconvent.net >>> for the past 2 weeks. Haven't played the piano so much in 5 years! >>> >>> Youtube videos: >>> >>> https://www.youtube.com/channel/UCxfh-2aOR5hZUjxJLQ2CIHw >>> >>> blog post: >>> >https://wlan-si.net/en/blog/2015/09/08/battlemesh-v8-and-its-many-stories/ >>> >>> The test results were dismal, as expected. Finally knocking a few >>> heads to use abusive network tests like what toke and I developed >were >>> hopefully an eye-opener, and a lot more people grok what >>> make-wifi-fast is really about, and how to do it. >>> >>> http://docs.battlemesh.org/ >>> >>> one very positive outcome of the fcc talk was a level of net outrage >>> and organisation over some new fcc rules I have not seen before. My >>> letter to the fcc, in progress, with vint cerf and other >>> co-signers is up for review at: >>> >>> >>> >https://docs.google.com/document/d/1VTOHEpRXSvhWvQ0leM-sROJ_XC7Fk1WjFXq57ysFtAA/edit?usp=sharing >>> >>> A similar letter has to go to the eu, as they just passed similar >rules. >>> >>> as much as I would like to be working on the mill, it seems >politics, >>> finance, and organisation are in more need of my attentions right >now. >>> but I will keep plugging y'all at every opportunity. >>> >>> But, but... as I said, I just took a few weeks off and am picking up >>> the pieces and trying to figure out what to focus on, at the moment. >>> >>> If you wish a faster response to my email, please use >dave.taht@gmail.com >>> >>> >>> >> >> -- Sent with K-@ Mail - the evolution of emailing. -- Sent with K-@ Mail - the evolution of emailing.