Hello Mr. Beck, I'm an area resident and a member of the Twin Cities Wireless Users Group (www.tcwug.org). I was reviewing the Minneapolis wireless RFP and had a few comments/concerns and questions/suggestions: Comments and Concerns: 1.) the state should not prohibit city-initiated wireless networks as happened in Pennsylvania. Cities should not need to get permission from private companies in order to build infrastructure. 2.) ultimately, the city should own/control the system, although it may make sense to contract the day-to-day operations out to a private company (the system itself shouldn't become private property or be sold to a private corporation). This appears to be the case with the current RFP. Questions and Suggestions: 3.) what about visitors to Minneapolis? Some form of access should be available to visitors (i.e. nonsubscribers). Perhaps non-subscribers could have a bandwidth limited connection (e.g. 128 kbps or 256kbps). 4.) what about people who want to contribute to/participate in the system without requiring subscribing and monthly fees? For this I suggest that current broadband users could make their connections publicly available to anyone authorized to use the Mpls system, and in return they would receive authorization to use the Mpls system. (For example, users with Speakeasy.net DSL subscriptions are permitted and encouraged in their TOS to share their connections.) The authorization check could be handled by contacting a central auth server. The broadband users wishing to make this kind of arrangement could pick up a customizable wireless device such as the Linksys WRT54G that was preloaded with one of the free WRT54G firmwares. The preloaded firmware would be set up to handle the authentication needs. A WRT54G usually costs between $45-$75. (I should mention that part of this idea of users putting up an open AP and in return getting access to other APs came from something I heard or read about a year ago, but I don't recall where. It may have been a Robert Cringely article.) (Other Linux based systems like the Soekris kits could be used). 5.) security: use a VPN over 802.11b/g instead of WEP/WPA. Using the VPN should be optional, but a captive portal that only permits HTTP/HTTPS traffic could periodically (say every 10-15 minutes) remind users that they are not using a VPN secured connection, and give them info how to use the VPN. 6.) How about roaming devices between access points? Something like SOWN's TransparentMobility system would be very very nice (http://www.sown.org.uk/index.php/TransparentMobility). Using the SOWN system, you can roam between access points without losing your open connections. This is very important for things like VPN, VOIP , or SSH sessions. The SOWN software is open source and freely available from Sourceforge.net. 7.) it'd be good to have a way to allow wireless enthusiasts to participate at a higher level in the system 8.) radio frequency coordination issues (using 802.11b/g for client connections, and 802.11a or physical cabling for backbone links). 9.) bandwidth management software is necessary to prevent one client from using too many resources. Tools include Frottle, Wondershaper and others. 10.) Coverage testing: Pages 32-35 of the RFP are technical questions that include the requirement of no dead spots. One concern I have is the existance of dead spots can vary based on tree foliage cover and client card capabilities. Winter coverage would likely be best, which could be a problem if coverage tests are performed in the winter only to find that summer coverage is spotty. Also, a 100 mw Cisco 350 PCMCIA card will work in many more locations than a cheap $10 after rebate SMC wireless card. I would hope that the coverage evaluation teams look at run-of-the-mill/middle-of-the-pack wireless devices when they determine coverage needs. This would probably mean testing coverage with several common PDAs (Palm/PocketPC), laptops with integrated wireless cards, and common add-on PCMCIA cards. Coverage testing with VOIP Wifi phones like the Cisco CP-7920 would also be appropriate. 11.) the requirement for "No special client software required for service, other than provided by the above standard operating systems." SOWN's system mentioned above could handle that and provide roaming capabilities without disrupting active connections. There is a discussion about some of these issues archived at: http://shadowknight.real-time.com/pipermail/tcwug-list/2005-May/thread.html along with a proposal for how to integrate "primary" Mpls-provided access points with "participant" access points that addresses the issues of support, billing, TOS, and quality of service: http://shadowknight.real-time.com/pipermail/tcwug-list/2005-May/002250.html Thanks, Haudy Kazemi ---copy/paste--- Any questions regarding this RFP should be submitted in writing to the CITY OF MINNEAPOLIS’ sole contact person: Mr. William E. Beck Director, BIS Business Development CITY OF MINNEAPOLIS 350 South Fifth Street, Room 127 Minneapolis, MN 55415 Email: broadband at ci.minneapolis.mn.us Fax: 612-673-2719 All questions are due no later than Monday, May 16, 2005, at 4:00 p.m. Central Daylight Time. Questions will be answered in writing and published on the CITY OF MINNEAPOLIS’ web site by Tuesday, May 31, 2005. The contact person above is the only individual that can be contacted about the project by Respondents before proposals are submitted. That contact MUST be in writing. The department contact cannot vary the terms of the RFP. ---end of copy/paste---