After being off the list for a while I decided to read the archives a bit for this month. I've read the thoughts about the network and I'm pretty worried about this secnario: ISP sets up VPN server on network. ISP offers pay-for-access model to anyone, but doesn't mention TCWUG, just makes a pretty map. Users have no knowledge of TCWUG and what the network is coming from TCWUG gets -$0- and falls fast into disarray with glut of new users. I've also done some thinking on how to mitigate that situation and I've come up with a bunch of blanks. Most of them revolve on how to provide open access to individuals while denying abusive access. I think the situation might be best worked out with the following: Two access levels, Supporting and Freeloader: Supporting pays money, perhaps yearly, perhaps monthly. They get equal access along with any other supporters and in theory the money requested assists with network upgrades to meet that demand. Some sort of QoS is involved but is mostly non restrictive. Perhaps some way to provide a minimum amount to each user, but the excess is first come first serve to supporters. Freeloaders get essentially "Scavenger" access. It's run-off excess energy from Supporters, Network Founders, Major Network Sponsors, Admins and the sort. This way, the network can still be considered a public service and potentially still a nonprofit (?) but just providing a different level of service to those who pay. Scavenger access is an idea that's been used in internet2 land to apply to specific organizations 'non-primary-mission' traffic. More can be found here: http://qbone.internet2.edu/qbss/ Supporters who decide to stop paying become Freeloaders. No 'extra' charges should be put on someone to make the conversion back and forth. Either category should require a method of identification by an Admin to recieve a login. Perhaps Freeloaders can be auth-free, but I'm worried the abuse will get so bad it won't be worth it. Perhaps let auth-free users only get to specific resources and other auth-free users. So, three levels of bits. Supporting users 'mandatory bandwidth allocation' bits, Supporting users 'extra bandwidth thats available' bits, and the Freeloaders scavenger bits. Of course, I have no experience implementing QBSS on anything yet. I've yet had a chance to break the closest cisco router I've got my grubby hands enabled on. And, I don't know what sort of QoS can be done on Linux or *BSD to further these means. This sort of proposal also assumes that we are looking at an embedded platform with either host_ap or the freebsd (i think) non-free orinoco ap driver. I also assume that a decently hard to avoid authentication protocol is used. I wish I could have made it to the recent meeting, but ran into issues where I couldn't make it. (colo box drive finally took a dive, spent a few hours with a friend configuring a new machine from scratch and putting in the most recent backup. Luckily I was able to get the old box to come up enough that I could rsync recent data to the new machine.) -- Scott Dier <dieman at ringworld.org> http://www.ringworld.org/