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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
