On Sat, Jun 20, 2015 at 6:54 PM, Richard Chycoski ve7cvs@chycoski.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ The Canadian system is even more vague, as callsigns do not expire (unless you do, and even then the government doesn't keep good track of them - someone has to tell them), and yes, some people have multiple call signs. I live/work in the US now, but still operate under a Canadian callsign (need to go sit those Extra exams - so many things to do - so little time!).
Yeah, I was afraid of that... I got a feeling it will be like that for most countries as well.
I don't think there's a problem in getting people to check in yearly, but I agree with the idea of only starting to warn people 90 days before expiration.
I as well would agree with the 90 day soft notices. Could also use it as a opportunity to opt in to the listserv which gives a mail every month as a soft ping. May give people incentive to stay active and explore hamwan/mesh/ax.25 architecture here. Change is in the air and I suspect with that a growth in hobby related wireless data communications - especially as the maker movement advances. All we should be concerned with is interoperability and address routing.
I found it interesting that the AMPR gateway only allowed traffic for IP's registered in DNS. Is there a reason for this? Especially as we're starting to subnet to larger blocks and move away from geographically connected networks.
Users have a soft landing, and can (after their system stops working) just sign in again and get 'the power turned back on', and its less overhead for the maintainers - no need to re-enter data when the user finally realises that the lights are out (at least in most cases).
This seem reasonable. In a way, this would be the fuse after the time based dead man's switch is triggered.
I *would* say that entries and subnets would be subject to reallocation after the six month hard cutoff, so anyone who leaves things too long may need to reconfigure their network.
I know I would after 6 months. I try not to collect machine anymore but I do generate plenty of e-waste.
Hams can wander off for several years, and then go - oh, time to get started again! - and then reconnect with the community.
I know I have and it happens to everybody.
Anything that can be done to make this painless is a good thing.
So, BrianK mentioned that about 5 years ago, a time stamp was added to the DNS table and recorded when a record was updated.
What if we were to import everything in, set a incremental TTL on records so that the newest records had one or two years but the oldest records had maybe 3-9 months. 3 months for anything over 5 years and progressively more over the next 4. So that in essence, in around a year or two, the problem cleans itself up.
When the TTL on records is reached, it goes into the soft landing for 6 months then after 6 months it is wiped completely for reallocation. I don't even think RBL/spamlists tend to keep records for a year or two. Even if it did, age weighs into it's bayes filtering.
It wouldn't be a 'rip the bandaid off' transition - but there will be some pain for people as the hairs are pulled.
It would also get those older network operators to ping in rather than treat it as inheritable space. One can't own a frequency, but they certainly can park a call sign for generations.
For it to work however some of the old networks are going to have to check into the portal and ping their network space. If those regional coordinators are on top of their allocations, maybe they can register their /16 or whatever then notify their network. Then we can put in a feature to transfer allocations to other hams like you can with domain names and registrar transfers.. I know in Europe, they got their network maps dialed in. Much more than we have here in North America.
We'd just need to reach a reasonable consensus, announce it here and on the website, do the work then let it bake.
I'll be happy to help with the programming, I've done this kind of work many times. I also program in SQL, Perl, PHP, Python, C, *nix shell(s), and *way* too many other languages since 1972 - including at least a dozen assemblers, but let's not go there! - full resumé upon request. (No, I'm not looking for another day job, I have one! :-)
I'm just a Sr. SE with a CCNP. But most of the day, I'm known as 'Jack'. My manager sells me as a DevOp. And my company's mission is to bring joy to the world through innovation. Really, I want the world we were promised by Pop. Sci. decades ago.
I'm sure I can introduce you to Chris who maintains the portal and the svn. Maybe we can both sell him on Github. ;)