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

2015-10-02 Thread dpreed

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"  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

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

2015-10-02 Thread Rich Brown
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
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel


Re: [Cerowrt-devel] patreon plea for funding make-wifi-fast

2015-10-02 Thread Bill Merriam
On Wed, 2015-09-23 at 11:05 -0700, Dave Taht wrote:
> Since I have been basically working full time on make-wifi-fast since
> april and the grant that I had counted on to fill in some gaps is
> still unaccountably held up, keeping things going is starting to
> become difficult - and ramping up, impossible. So I put up a patreon
> plea for some help on funding here:
> 
> https://www.patreon.com/dtaht
> 
> TIA.
> 

The latest hack:

https://www.patreon.com/posts/important-notice-3457485
http://www.zdnet.com/article/patreon-hacked-anonymous-patrons-exposed/

Bill

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel