[Make-wifi-fast] FCC vs Wifi response discuss via videoconference today friday nov 13

Fri Nov 13 12:14:00 EST 2015

We are going to have a hangout on air videoconference on
http://vuc.me/savewifi at 1pm EST, 6pm uk, today, friday, nov 13, to
discuss possible responses to:

https://www.fcc.gov/blog/clearing-air-wi-fi-software-updates

The revised guidelines

https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g%3D%3D&desc=594280%20D02%20U-NII%20Device%20Security%20v01r03&tracking_number=39498

still seem quite problematic.

It would be good to have more confirmed attendees. There are 15 seats
reserved, only 7 confirmed as I write. Please confrim a reservation
via

http://vuc.me/savewifi

which has more details on the video conference or via email.

There has been some mixed press coverage thus far of:

On Thu, Nov 12, 2015 at 9:08 PM, Lauren Weinstein <lauren4321 at gmail.com> wrote:
> There's virtually no incentive for manufacturers to bother with any
> finer-grained control than just locking users out completely. It simplifies
> their customer support, it complies with the FCC. From their standpoint,
> what's not to like?
>
> On Thu, Nov 12, 2015 at 12:01 PM, Christopher Waid <chris at thinkpenguin.com>
> wrote:
>>
>> Of course this doesn't fix the problem. They don't understand it or they
>> are intentionally avoiding solving the problem. The problem is the result of
>> what manufacturers will have to do to comply. It's not an issue of
>> interpretation. It is that it can't be solved some other way. Narrowing it
>> to indicate they don't mean to require the lock down doesn't mean
>> manufacturers won't ultimately have to lock it down in practice. Narrowing
>> it is just not going to change anything because of the way things are
>> designed and manufactured. If it's less costly to take a short cut and
>> implement DRM that's what manufacturers will have to do for a variety of
>> reasons.
>>
>> We have no sane way to comply with these rules regardless of how narrow
>> they make it.
>>
>> On 2015-11-12 01:29 PM, Wayne Workman wrote:
>>>
>>> I want to make it glaringly clear that in the past, 1930s through
>>> early 50s, the FCC has been misused to prevent technology from
>>> developing, has been used to cripple technology, and has been used to
>>> prevent a shift of power in technology.
>>>
>>> One needs to look no further for proof than the development of FM
>>> radio. I have a book that talked about it at some length, but I've
>>> managed to find a Wikipedia article on the subject here for you all:
>>>
>>> https://en.m.wikipedia.org/wiki/Edwin_Howard_Armstrong [6]
>>>
>>> In a nutshell, RCA was in kahoots with the FCC and blocked FM by
>>> putting it on an absurd spectrum range, and then deemed pre-existing
>>> patents owned by Edwin invalid after he perfected the technology, and
>>> stole it from Edwin. After years and years of legal battles and loss,
>>> Edwin committed suicide, stepping out of a high-rise window.
>>>
>>> I bring this up because of the wording used in the FCC comment. It's
>>> worded like they are just going to do what they originally intended
>>> anyways.
>>>
>>> And it's still not entirely clear to me exactly what their proposed
>>> rules fixes. It smells very fishy.
>>> On Nov 12, 2015 11:56 AM, "Lauren Weinstein" <lauren4321 at gmail.com>
>>> wrote:
>>>
>>>> That's a rather carefully worded statement. In particular:
>>>>
>>>> _the proposal is not intended to encourage manufacturers to prevent
>>>> all modifications or updates to device software._
>>>>
>>>> can be interpreted in a number of ways, with the word "ALL" being
>>>> key.
>>>>
>>>> L
>>>>
>>>> On Thu, Nov 12, 2015 at 9:50 AM, Chip Rosenthal <chip at unicom.com>
>>>> wrote:
>>>>
>>>>> An FCC blog post just went up on this issue.
>>>>>
>>>>> ---
>>>>>
>>>>> Clearing the Air on Wi-Fi Software Updates
>>>>>
>>>>> by: Julius Knapp, Chief, Office of Engineering & Technology
>>>>> November 12, 2015 - 12:09 PM
>>>>> https://www.fcc.gov/blog/clearing-air-wi-fi-software-updates [1]
>>>>>
>>>>> This week marked the closing of the reply comment period in the
>>>>> Commission’s radio device approval modernization rulemaking. The
>>>>> comments and replies are largely supportive of the Commission’s
>>>>> proposals, but one particular element generated thousands of
>>>>> comments from individuals concerned that the proposal would
>>>>> encourage manufacturers to prevent modifications or updates to the
>>>>> software used in devices such as wireless local area networks
>>>>> (e.g., Wi-Fi routers). I’m pleased that this issue attracted
>>>>> considerable attention and thoughtful submissions into the record
>>>>> and would like to make it clear that the proposal is not intended
>>>>> to encourage manufacturers to prevent all modifications or updates
>>>>> to device software.
>>>>>
>>>>> ---
>>>>>
>>>>> Interestingly, it mentions clarifying the U-NII rules already in
>>>>> effect.
>>>>>
>>>>> --
>>>>> Chip Rosenthal * 512-573-5174 [2] * KE5VHV *
>>>>> http://www.unicom.com/ [3]
>>>>> Austin #OpenGov and #CivicHacking events:
>>>>> http://www.open-austin.org/calendar [4]
>>>>>
>>>>> _______________________________________________
>>>>> bufferbloat-fcc-discuss mailing list
>>>>> bufferbloat-fcc-discuss at lists.redbarn.org
>>>>> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>>>>> [5]
>>>>
>>>>
>>>> _______________________________________________
>>>> bufferbloat-fcc-discuss mailing list
>>>> bufferbloat-fcc-discuss at lists.redbarn.org
>>>> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>>>> [5]
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] https://www.fcc.gov/blog/clearing-air-wi-fi-software-updates
>>> [2] tel:512-573-5174
>>> [3] http://www.unicom.com/
>>> [4] http://www.open-austin.org/calendar
>>> [5] http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>>> [6] https://en.m.wikipedia.org/wiki/Edwin_Howard_Armstrong
>>>
>>> _______________________________________________
>>> bufferbloat-fcc-discuss mailing list
>>> bufferbloat-fcc-discuss at lists.redbarn.org
>>> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>
>
>
> _______________________________________________
> bufferbloat-fcc-discuss mailing list
> bufferbloat-fcc-discuss at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>