Marius / Bill / et al;
This means that all coordinators should have an AMPR e-mail system running, or at least access to an AMPR e-mail system.
Nothing a .forward file couldn't also fix for you :)
Shouldn't the coordinators all have an ampr.org Email address? That would allow easily handling multiple coordinator contacts as well as changing coordinators or email addresses.
This thread really has become so far off the original track you'd think it's another government run railroad. While I think I'm one of, if not the only coordinator that uses an *.ampr.org email (and has for about 2 decades now) let me try to get the thread back on it's original track.
The thread if you dig back enough I believe goes towards making ip allocation requests more automated, not all of a sudden after 2+ decades of allocating IP space to attack the position of or the logistics of the coordinators (or do we prefer to just shoot each other in the foot?) So how do we accomplish this? Before I get into that, let me clarify something we're overlooking here;
Coordinators are scoped out and picked by Brian Kantor. No coordinator or coordinator want-to-be can simply enter themselves into the portal and get coordinator privileges. If BK is fine with who he selects as coordinators than we should (as guests on his network) be satisfied with his decision and not question that in what he wishes to do. If you run down the list of those who are coordinators, many of them have been doing so for well over 10 if not over 20 years. I fail to see where all of a sudden this is an issue? Are we that bored where we as 'inventors' have run out of things to invent so we begin to unconsciously attack others? I'd be more concerned from a security point of view about non-amateurs getting into our network from non-44net means than what occurs within our own network... and yes this has occurred! Rather than subliminally insult the intelligence of BK by hinting that his selection of coordinators is not one to be appreciated also shows by action that the use he gives us all a corner of his 44/8 network is unappreciated. </rant>
<$0.02> Now.. as to the automation of requesting subnets, we would need a very detailed system to accomplish this. One that just adds subnets by means of a request could hurt others, even if the requester uses a cert-based identifier schema. I've had a bunch request /16 subnets for the purposes of running commercial SIP trunk hosting, commercial video streaming, etc. An automated system that would do this at will would harm others.
We'd also need to come up with a way to auto-determine when someone decides to leave 44-net so their block could go back into the pool and DNS taken out so incoming frames to UCSD can be halted from entering the encap system. All too often are people overly anxious to get on the amprnet, but when they decide it's either not for them or they find something else to occupy their time 99% of the time they fail to inform their coordinator that they've decided to leave.
As I stated yesterday, while I'm not against the idea, it'd have to be very carefully thought out and properly engineered before implemented. I can envision more bumps in this road than smoothness. When a human element exists, its extremely difficult for a robot to "guess". </$0.02>