[Cerowrt-devel] Editorial questions for response to the FCC

[dpreed at reed.com]

This is good. Regarding my concern about asking for mandated FCC-centered control - we need less of that. It establishes a bad precedent for the means of "protecting the airwaves".  (or reinforces a precedent that must be changed soon - of establishing de-facto, anti-innovation monopolies that derive from regulatory mandates). And it creates a problematic "us vs. them" debate where there is none.
 
A vast majority of folks want interoperability of all kinds of communications, and that includes sharability of the wireless medium.  That means finding approaches for coexistence and innovation, without mandates for the technological solution based on a particular implementation of hardware or systems architecture. An evolutionary approach.
 
So we don't have to specify alternative rules in detail.  And by going into detail too much, we only lose support.
 
What have to demonstrate is that there is *at least one* better approach, while also pointing out what will be lost with the proposed approach in the NPRM.  Most of the letter focuses on these, quite correctly, but it might be useful to clarify those two lines of argument by an editorial pass.  The approach suggested in the letter should be presented as open to further improvement that achieves the shared goals.
 
This is why emphasizing "mandates" and punishments is probably counterproductive. The goals that stand behind the proposed mandates should be emphasized, the mandates left to be developed in detail based on those goals.
 
The battle here is part of a longer term, necessary reframing of regulatory practice.  Current regulation is based on means rather than ends, and doesn't consider what is technologically possible. And it is centered on control of what capabilities are delivered in fixed function devices, rather than in how those devices are used or how they integrate into systems. As an absurd example, we certainly would like to prevent people from being electrocuted.  But does that mean we must specify how an electric vehicle is built down to the voltages of batteries used and what kind of switching transistors must be used in the power supply?  Or that the only battery charging that is allowed must be done at stations owned by the vendor of the vehicle?
 
That longer term reframing must take into account the characteristics of the trillions of wireless nodes that will be deployed in the next 25 years.  There's been no study of that by the FCC (though some of us have tried, as I did at the TAC when I was on it) at all.
 
That can't be accomplished in this NPRM.  The battle is to prevent this regulation from being deployed, because it is a huge step backwards.  Fortunately, we *don't* need to rewrite the regulation, so quickly.
 
We need to argue that they need to go back to the drawing board with a new perspective.  The approach proposed should focus that effort, but it need not be adopted now.  It might turn out even worse...  So the goal is to stop the NPRM.
 


On Friday, October 2, 2015 10:22am, "Rich Brown" <richb.hanover at gmail.com> said:



> Folks,
> 
> I have screwed up my nerve to take an editorial pass over the document. It has a
> lot of good information and many useful citations, but it needs focus to be
> effective.
> 
> As I read through (yesterday's) draft of the document and the comments, I came up
> with observations to confirm and questions that I want to understand before
> charging ahead.
> 
> Observations:
> 
> 1) Unfortunately, we are coming to this very late: if I understand the timeline,
> the FCC proposed these rules a year ago, the comment period for the NPRM closed 2
> months ago, and we only got an extra month's extension of the deadline because
> their computer was going to be down on the original filing date. (Note - that
> doesn't challenge any of our points' validity, only that we need to be very
> specific in what we say/ask for.)
> 
> 2) The FCC will view all this through the lens of "Licensed use has priority for
> spectrum over unlicensed." That's just the rules. Any effort to say they should
> change their fundamental process will cause our comments to be disregarded.
> 
> 3) The *operator* (e.g., homeowner) is responsible for the proper operation of a
> radio. If the FCC discovers your home router is operating outside its allowed
> parameters *you* must (immediately?) remediate it or take it off the air.
> 
> 4) We must clearly and vigorously address the FCC admonishment to "prevent
> installing DD-WRT"
> 
> 5) [Opinion] I share dpreed's concern that the current draft overplays our hand,
> requesting more control/change than the FCC would be willing to allow. See
> Question 7 below for a possible alternative.
> 
> Questions:
> 
> 1) What is our request? What actions would we like the FCC to take?
> 
> 2) How much of a deviation from their current rules (the ones we're commenting on)
> are we asking them to embrace?
> 
> 3) How much dust could/should we kick up? For example, is it useful to point out
> that these FCC rules do not address other practices that are possible today:
> - Use of high gain antennas (which would certainly introduce a stronger signal
> than the design parameters);
> - Use of other (non-commercially produced) SDR transmitters;
> - Malicious attack that takes control of insecure vendor software to alter the RF
> parameters
> - Router manufacturers in most cases are already *contractually obliged* to
> release full source code for their routers (GPL). In the past, many have been
> resistant to doing so, especially for the RF drivers. Do any concerns of the FCC
> change if there were to be a full source code release?
> 
> 4) Footnotes 15, 16, and 17 cite published reports of router vendors using
> activation codes or new firmware lockdowns where previously not present. Do any
> readers have personal/verified knowledge of these activities?
> 
> 5) Vendors certify release X of their firmware in tests with the FCC. It includes
> the entire binary, including radio control parameters, OS version, web GUI, etc.
> Do we know anything about whether vendor's X+1 release goes through the same FCC
> certification process? Or do they just fix a couple bugs and re-release knowing
> that they haven't touched the RF driver...
> 
> 6) Vendors are generally do not release source code for the wireless drivers. How
> likely is it that this reluctance is due to a concern that the vendor could get in
> trouble with the FCC if people modified that code?
> 
> 7) Would it be feasible to ask the FCC to require that vendors *publish* the
> critical parameters/source code for operating in spec, so that responsible
> software developers can carefully observe those parameters? (We already have code
> that handles the RF specs for various countries. Could we envision doing the same
> for each router/model/version radio parameters?)
> 
> I'm going to collect your comments for ~24 hours, then start editing. My goal is
> to have a draft by Monday morning, 5 Oct to refine for the 9 Oct deadline.
> Thanks!
> 
> Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20151002/2a16c911/attachment-0002.html>