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

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:

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

Scott Dier <dieman at>