From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7FBCB21FC4B for ; Fri, 2 Oct 2015 13:21:26 -0700 (PDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8AA31380410; Fri, 2 Oct 2015 16:21:25 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 62856380403; Fri, 2 Oct 2015 16:21:25 -0400 (EDT) Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 23E08380410; Fri, 2 Oct 2015 16:21:25 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.4.2); Fri, 02 Oct 2015 20:21:25 GMT Received: from reed.com (localhost.localdomain [127.0.0.1]) by app39.wa-webapps.iad3a (Postfix) with ESMTP id 104773812AE; Fri, 2 Oct 2015 16:21:25 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 2 Oct 2015 16:21:25 -0400 (EDT) Date: Fri, 2 Oct 2015 16:21:25 -0400 (EDT) From: dpreed@reed.com To: "Rich Brown" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20151002162125000000_15184" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <49d53a3e-b7a0-4069-a87b-d9778bb8a229@reed.com> <16684.1443643019@turing-police.cc.vt.edu> <21167.1443646296@turing-police.cc.vt.edu> X-Auth-ID: dpreed@reed.com Message-ID: <1443817285.064125532@apps.rackspace.com> X-Mailer: webmail/11.5.7-RC Cc: esr@icei.org, fcc@lists.prplfoundation.org, david.collier.brown@worldgaming.com, make-wifi-fast@lists.bufferbloat.net, mellon@fugue.com, "cerowrt-devel@lists.bufferbloat.net" , Christopher Waid Subject: Re: [Cerowrt-devel] Editorial questions for response to the FCC X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 20:21:50 -0000 ------=_20151002162125000000_15184 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThis is good. Regarding my concern about asking for mandated FCC-centere= d control - we need less of that. It establishes a bad precedent for the me= ans of "protecting the airwaves". (or reinforces a precedent that must be = changed soon - of establishing de-facto, anti-innovation monopolies that de= rive from regulatory mandates). And it creates a problematic "us vs. them" = debate where there is none.=0A =0AA vast majority of folks want interoperab= ility of all kinds of communications, and that includes sharability of the = wireless medium. That means finding approaches for coexistence and innovat= ion, without mandates for the technological solution based on a particular = implementation of hardware or systems architecture. An evolutionary approac= h.=0A =0ASo we don't have to specify alternative rules in detail. And by g= oing into detail too much, we only lose support.=0A =0AWhat have to demonst= rate is that there is *at least one* better approach, while also pointing o= ut what will be lost with the proposed approach in the NPRM. Most of the l= etter focuses on these, quite correctly, but it might be useful to clarify = those two lines of argument by an editorial pass. The approach suggested i= n the letter should be presented as open to further improvement that achiev= es the shared goals.=0A =0AThis is why emphasizing "mandates" and punishmen= ts 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.=0A =0AThe battle here is part of a longer term, neces= sary reframing of regulatory practice. Current regulation is based on mean= s rather than ends, and doesn't consider what is technologically possible. = And it is centered on control of what capabilities are delivered in fixed f= unction devices, rather than in how those devices are used or how they inte= grate into systems. As an absurd example, we certainly would like to preven= t people from being electrocuted. But does that mean we must specify how a= n 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 t= he only battery charging that is allowed must be done at stations owned by = the vendor of the vehicle?=0A =0AThat 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.= =0A =0AThat can't be accomplished in this NPRM. The battle is to prevent t= his regulation from being deployed, because it is a huge step backwards. F= ortunately, we *don't* need to rewrite the regulation, so quickly.=0A =0AWe= need to argue that they need to go back to the drawing board with a new pe= rspective. 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 t= he NPRM.=0A =0A=0A=0AOn Friday, October 2, 2015 10:22am, "Rich Brown" said:=0A=0A=0A=0A> Folks,=0A> =0A> I have screwed up m= y nerve to take an editorial pass over the document. It has a=0A> lot of go= od information and many useful citations, but it needs focus to be=0A> effe= ctive.=0A> =0A> As I read through (yesterday's) draft of the document and t= he comments, I came up=0A> with observations to confirm and questions that = I want to understand before=0A> charging ahead.=0A> =0A> Observations:=0A> = =0A> 1) Unfortunately, we are coming to this very late: if I understand the= timeline,=0A> the FCC proposed these rules a year ago, the comment period = for the NPRM closed 2=0A> months ago, and we only got an extra month's exte= nsion of the deadline because=0A> their computer was going to be down on th= e original filing date. (Note - that=0A> doesn't challenge any of our point= s' validity, only that we need to be very=0A> specific in what we say/ask f= or.)=0A> =0A> 2) The FCC will view all this through the lens of "Licensed u= se has priority for=0A> spectrum over unlicensed." That's just the rules. A= ny effort to say they should=0A> change their fundamental process will caus= e our comments to be disregarded.=0A> =0A> 3) The *operator* (e.g., homeown= er) is responsible for the proper operation of a=0A> radio. If the FCC disc= overs your home router is operating outside its allowed=0A> parameters *you= * must (immediately?) remediate it or take it off the air.=0A> =0A> 4) We m= ust clearly and vigorously address the FCC admonishment to "prevent=0A> ins= talling DD-WRT"=0A> =0A> 5) [Opinion] I share dpreed's concern that the cur= rent draft overplays our hand,=0A> requesting more control/change than the = FCC would be willing to allow. See=0A> Question 7 below for a possible alte= rnative.=0A> =0A> Questions:=0A> =0A> 1) What is our request? What actions = would we like the FCC to take?=0A> =0A> 2) How much of a deviation from the= ir current rules (the ones we're commenting on)=0A> are we asking them to e= mbrace?=0A> =0A> 3) How much dust could/should we kick up? For example, is = it useful to point out=0A> that these FCC rules do not address other practi= ces that are possible today:=0A> - Use of high gain antennas (which would c= ertainly introduce a stronger signal=0A> than the design parameters);=0A> -= Use of other (non-commercially produced) SDR transmitters;=0A> - Malicious= attack that takes control of insecure vendor software to alter the RF=0A> = parameters=0A> - Router manufacturers in most cases are already *contractua= lly obliged* to=0A> release full source code for their routers (GPL). In th= e past, many have been=0A> resistant to doing so, especially for the RF dri= vers. Do any concerns of the FCC=0A> change if there were to be a full sour= ce code release?=0A> =0A> 4) Footnotes 15, 16, and 17 cite published report= s of router vendors using=0A> activation codes or new firmware lockdowns wh= ere previously not present. Do any=0A> readers have personal/verified knowl= edge of these activities?=0A> =0A> 5) Vendors certify release X of their fi= rmware in tests with the FCC. It includes=0A> the entire binary, including = radio control parameters, OS version, web GUI, etc.=0A> Do we know anything= about whether vendor's X+1 release goes through the same FCC=0A> certifica= tion process? Or do they just fix a couple bugs and re-release knowing=0A> = that they haven't touched the RF driver...=0A> =0A> 6) Vendors are generall= y do not release source code for the wireless drivers. How=0A> likely is it= that this reluctance is due to a concern that the vendor could get in=0A> = trouble with the FCC if people modified that code?=0A> =0A> 7) Would it be = feasible to ask the FCC to require that vendors *publish* the=0A> critical = parameters/source code for operating in spec, so that responsible=0A> softw= are developers can carefully observe those parameters? (We already have cod= e=0A> that handles the RF specs for various countries. Could we envision do= ing the same=0A> for each router/model/version radio parameters?)=0A> =0A> = I'm going to collect your comments for ~24 hours, then start editing. My go= al is=0A> to have a draft by Monday morning, 5 Oct to refine for the 9 Oct = deadline.=0A> Thanks!=0A> =0A> Rich ------=_20151002162125000000_15184 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This= is good. Regarding my concern about asking for mandated FCC-centered contr= ol - we need less of that. It establishes a bad precedent for the means of = "protecting the airwaves".  (or reinforces a precedent that must be ch= anged soon - of establishing de-facto, anti-innovation monopolies that deri= ve from regulatory mandates). And it creates a problematic "us vs. them" de= bate where there is none.

=0A

 

=0A<= p style=3D"margin:0;padding:0;font-family: 'times new roman'; font-size: 10= pt; word-wrap: break-word;">A vast majority of folks want interoperability = of all kinds of communications, and that includes sharability of the wirele= ss medium.  That means finding approaches for coexistence and innovati= on, without mandates for the technological solution based on a particular i= mplementation of hardware or systems architecture. An evolutionary approach= .

=0A

 

=0A

So we don't have to specify alternative rules in detail.  And by g= oing into detail too much, we only lose support.

=0A

 

=0A

What have to demonstrate= is that there is *at least one* better approach, while also pointing out w= hat 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 sugge= sted in the letter should be presented as open to further improvement that = achieves the shared goals.

=0A

 

=0A=

This is why emphasizing "mandates" and punishm= ents is probably counterproductive. The goals that stand behind the propose= d mandates should be emphasized, the mandates left to be developed in detai= l based on those goals.

=0A

 

=0A

The battle here is part of a longer term, necessa= ry reframing of regulatory practice.  Current regulation is based on m= eans rather than ends, and doesn't consider what is technologically possibl= e. And it is centered on control of what capabilities are delivered in fixe= d function devices, rather than in how those devices are used or how they i= ntegrate into systems. As an absurd example, we certainly would like to pre= vent people from being electrocuted.  But does that mean we must speci= fy 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? &n= bsp;Or that the only battery charging that is allowed must be done at stati= ons owned by the vendor of the vehicle?

=0A

=  

=0A

That longer term reframing must t= ake into account the characteristics of the trillions of wireless nodes tha= t will be deployed in the next 25 years.  There's been no study of tha= t by the FCC (though some of us have tried, as I did at the TAC when I was = on it) at all.

=0A

 

=0A

That can't be accomplished in this NPRM.  The battle = is to prevent this regulation from being deployed, because it is a huge ste= p backwards.  Fortunately, we *don't* need to rewrite the regulation, = so quickly.

=0A

 

=0A

We need to argue that they need to go back to the drawing boa= rd with a new perspective.  The approach proposed should focus that ef= fort, but it need not be adopted now.  It might turn out even worse...=  So the goal is to stop the NPRM.

=0A

=  

=0A