Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Dave Taht <dave.taht@gmail.com>
Cc: fcc@lists.prplfoundation.org,
	make-wifi-fast@lists.bufferbloat.net, cake@lists.bufferbloat.net,
	"cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>,
	OpenWrt Development List <openwrt-devel@lists.openwrt.org>,
	Battle of the Mesh Mailing List <battlemesh@ml.ninux.org>
Subject: Re: [Cake] [OpenWrt-Devel] the cerowrt project's letter to the fcc about the wifi lockdown is nearly final
Date: Tue, 6 Oct 2015 15:49:15 +0200	[thread overview]
Message-ID: <20151006134915.GF12763@odroid> (raw)
In-Reply-To: <CAA93jw68rt5GEdEij8wJUwHBuJ-u3f0Z+OaVep1hY6VfjdQeew@mail.gmail.com>

On Tue, Oct 06, 2015 at 02:13:36AM +0200, Dave Taht wrote:
> Comment away!

There are many good points made in this text.

I like the Volkswagen example and the suggestion to require
opening up the firmware.

For the latter, had been thinking about that before briefly,
but kind of dismissed it early, basically because the reasoning in
my head was that FCC shouldn't make any requirements regarding
the form of the software at all. They should only regulate the
result.

Actually this text and the VW example convinced me :). And yes,
now I think with that we can push even further, suggesting to
require open and modifiable source code (for the wifi part at
least). The VW example gives us the opportunity and strategic
advantage to be able to demandn more without sounding
unreasonable.

~~~~~

Some quotations and remarks:

"'It is our view that the rules appear to regulate the "means" not
the "ends"'"
-> So does the alternate approach in the end, but in the opposite
   "extreme"

"This software contains built-in configurations to ensure that
radios are used in compliance with the local laws and
regulations."
-> "ensure" seems to be a too strong word to me

"is a natural target for both criminal exploitation and
cyberwarfare"
-> Just my personal taste, but I don't like using the word "war"
   for mere economical power play between nations as it seems
   to soften the original meaning of "war", meaning to kill people
   (don't like the term "cryptowars" either - maybe that taste
   might have cultural roots; the word "war" is never used in
   German language in contexts like these while it seems more
   common in the US and probably other countries too?)
   
"It is currently limiting our attempts to fix the ath9k and mt76
devices"
-> What is meant by that exactly? ath9k is open source, binary
   firmwares can't be the issue you mean here... - with "it
   is limiting", do you mean "new, emerging devices with locked
   firmwares are limiting..."? Maybe clarify the "it"?

"If the Commission does not intend to prohibit the upgrade or
replacement of firmware in Wi-Fi devices, rules would be welcomed
that actually encouraged non-destructive interpretations by
equipment vendors."
-> That one might need explanations too. Actually, I think it is
   explained later, with citatitons of vendors. But ending the
   paragraph there leaves a questions mark for quite a while.

~~~~~

Not sure how much time is left to work on the text - content wise
everything seems to be in there. Structually maybe a guiding
thread could be worked out a little more. The beginning is good
and mentions and summarizes the main points well. Some points and
explanations seem to be repeated several times after that though.
Maybe things could be "unbloated" a little here and there ;).

Also the recommendations are not quite clear at some points to me.
The "Alternate Approach" and "Recommendations" sections are clear
by mandating open and modifiable firmwares for the wifi parts at
least. But some other parts seem to allude to different
suggestions. For instance as of writing this email, the draft also
contains:

"The portion of the source code that controls the radio is very
small compared to the entirety of the underlying operating system,
Graphical User Interface, routing and switching code, and all the
other functions that make up a modern Wi-Fi router. As such,
restricting the entire firmware to carries with it a lot of
collateral damage by also preventing improvements to these other
parts."

Which seems to reverse the recommendation.


Thanks for this great draft and the work you guys have put into it
so far!

Cheers, Linus

  parent reply	other threads:[~2015-10-06 13:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-06  0:13 [Cake] " Dave Taht
2015-10-06 12:03 ` [Cake] [Bloat] " Rich Brown
2015-10-06 13:49 ` Linus Lüssing [this message]
2015-10-06 14:21   ` [Cake] [Battlemesh] [OpenWrt-Devel] " Benjamin Henrion
2015-10-06 15:17     ` Linus Lüssing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151006134915.GF12763@odroid \
    --to=linus.luessing@c0d3.blue \
    --cc=battlemesh@ml.ninux.org \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cake@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    --cc=fcc@lists.prplfoundation.org \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=openwrt-devel@lists.openwrt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox