At my request, we're cleaning out obsolete entries from the portal.
A reminder is sent after 3 and 6 months with no login.
A warning is sent after 9 months with no login.
A notice is sent after 12 months with no login.
After 15 months, the user, their network allocations, and any gateways belonging to them are deleted.
At the current time, there are 3 gateways and 70 allocations to be so deleted. - Brian
A reminder every 3 to 6 months is excessive. Once a gateway is set up and working, there's just no reason to log in ... ever. So sending emails when there's nothing wrong is a sure way to train people to ignore the emails.
Suggestion: Do what commercial subscription companies do. Send an email only when action is needed and do it with increasing frequency. What worked well at my last company was: 60, 30, 15, 7, 1 days.
Michael N6MEF
At my request, we're cleaning out obsolete entries from the portal.
A reminder is sent after 3 and 6 months with no login.
A warning is sent after 9 months with no login.
A notice is sent after 12 months with no login.
After 15 months, the user, their network allocations, and any gateways belonging to them are deleted.
On Thu, Jun 18, 2015 at 8:47 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ At my request, we're cleaning out obsolete entries from the portal.
A reminder is sent after 3 and 6 months with no login.
A warning is sent after 9 months with no login.
A notice is sent after 12 months with no login.
After 15 months, the user, their network allocations, and any gateways belonging to them are deleted.
At the current time, there are 3 gateways and 70 allocations to be so deleted. - Brian
Say a gateway operator has a stable system that has been running without fault for 3 years. What does a portal login have to do with this? Why would this allocation be deleted?
Tom KD7LXL
Couldn't we check the traffic and see if any traffic from the user to internet has flowed via the amprgw box for a given allocation?
I know I have little reason to login for my allocation since its directly connected.
On June 18, 2015 11:58:23 AM EDT, Tom Hayward esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Jun 18, 2015 at 8:47 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ At my request, we're cleaning out obsolete entries from the portal.
A reminder is sent after 3 and 6 months with no login.
A warning is sent after 9 months with no login.
A notice is sent after 12 months with no login.
After 15 months, the user, their network allocations, and any gateways belonging to them are deleted.
At the current time, there are 3 gateways and 70 allocations to be so deleted. - Brian
Say a gateway operator has a stable system that has been running without fault for 3 years. What does a portal login have to do with this? Why would this allocation be deleted?
Tom KD7LXL
I would propose that also any API login for a specific user should be taken into account. Using API actually means that something is active behind that user.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Thursday, June 18, 2015 18:47 To: 44net@hamradio.ucsd.edu Subject: [44net] portal purge
(Please trim inclusions from previous messages) _______________________________________________ At my request, we're cleaning out obsolete entries from the portal.
A reminder is sent after 3 and 6 months with no login.
A warning is sent after 9 months with no login.
A notice is sent after 12 months with no login.
After 15 months, the user, their network allocations, and any gateways belonging to them are deleted.
At the current time, there are 3 gateways and 70 allocations to be so deleted. - Brian
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Thu, Jun 18, 2015 at 9:12 AM, Marius Petrescu marius@yo2loj.ro wrote:
I would propose that also any API login for a specific user should be taken into account. Using API actually means that something is active behind that user.
Marius, YO2LOJ
I'll second this idea.
And as is customary for the 44net list, I'd like to go off on a tangential feature request: As part of a gateway registration, require the administrator to define an IP address within each allocation that will respond to an ICMP ping. By default, it could be the first address in the allocation, but be flexible and allow them to choose any address in the allocation. This gives you the opportunity to test connectivity to their network. If the specified address still responds to ping, don't expire the allocation. They're obviously maintaining it.
Tom KD7LXL
Realistically, if this is a one time purge to narrow down the subnets needed for ip ip encap as part of a migration, would it be so wrong to send out an email that says we're planning a migration, and please login or your tunnels will not be migrated?
I'd say this if done With sufficient notice should be acceptable. Worst case, some ones stuff breaks and they have to login and then it's back working.
Again, only if the root reason for this is to migrate off of the current architecture. I'm not speaking to the portal in general.
On June 18, 2015 12:12:01 PM EDT, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ I would propose that also any API login for a specific user should be taken into account. Using API actually means that something is active behind that user.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Thursday, June 18, 2015 18:47 To: 44net@hamradio.ucsd.edu Subject: [44net] portal purge
(Please trim inclusions from previous messages) _______________________________________________ At my request, we're cleaning out obsolete entries from the portal.
A reminder is sent after 3 and 6 months with no login.
A warning is sent after 9 months with no login.
A notice is sent after 12 months with no login.
After 15 months, the user, their network allocations, and any gateways belonging to them are deleted.
At the current time, there are 3 gateways and 70 allocations to be so deleted.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-- Bryan Fields 727-409-1194 http://bryanfields.net
On Thu, Jun 18, 2015 at 07:12:01PM +0300, Marius Petrescu wrote:
I would propose that also any API login for a specific user should be taken into account. Using API actually means that something is active behind that user.
Marius, YO2LOJ
That seems wise. I'll ask Chris if he can make that change if it isn't already in effect. - Brian
On Thu, Jun 18, 2015 at 09:22:14AM -0700, Brian Kantor wrote:
On Thu, Jun 18, 2015 at 07:12:01PM +0300, Marius Petrescu wrote:
I would propose that also any API login for a specific user should be taken into account. Using API actually means that something is active behind that user.
Marius, YO2LOJ
That seems wise. I'll ask Chris if he can make that change if it isn't already in effect.
Chris says it's an easy change but points out that the primary reason for requesting people to log in at least once a year is to verify that we have current contact data for them. An automated cron login to the API doesn't do that. Since ICANN requires yearly confirmation of contact data, I feel that we are not placing an undue burden on users of our network to verify their email address at least once a year.
If we all feel that four reminders a year is too many, we could cut out the three month reminder, but I think the six and nine month reminder isn't burdensome. Cutting it back to remind once a year is too sparse; a single such email is easily overlooked. - Brian
On Thu, Jun 18, 2015 at 10:01 AM, Brian Kantor Brian@ucsd.edu wrote:
Chris says it's an easy change but points out that the primary reason for requesting people to log in at least once a year is to verify that we have current contact data for them. An automated cron login to the API doesn't do that. Since ICANN requires yearly confirmation of contact data, I feel that we are not placing an undue burden on users of our network to verify their email address at least once a year.
Which ICANN requirement is this? I'm only familiar with WDRP, which is a requirement for registrars to maintain ICANN accreditation. I don't think AMPR is a registrar or ICANN accredited, so I must be totally out of context.
Also, how do I connect to the AMPR WHOIS server to read this information?
Tom KD7LXL
On Thu, Jun 18, 2015 at 10:14:00AM -0700, Tom Hayward wrote:
Which ICANN requirement is this? I'm only familiar with WDRP, which is a requirement for registrars to maintain ICANN accreditation. I don't think AMPR is a registrar or ICANN accredited, so I must be totally out of context.
ARIN requires that I verify my contact info once a year; they say it's a requirement placed on them by ICANN.
Also, how do I connect to the AMPR WHOIS server to read this information?
The whois server is under development and not yet deployed. I'm not up on the progress of that project. The intent was to have it run on the portal, where the registration database is operated so that it can have access to the necessary data. - Brian
On Thu, Jun 18, 2015 at 10:25 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Jun 18, 2015 at 10:14:00AM -0700, Tom Hayward wrote:
Which ICANN requirement is this? I'm only familiar with WDRP, which is a requirement for registrars to maintain ICANN accreditation. I don't think AMPR is a registrar or ICANN accredited, so I must be totally out of context.
ARIN requires that I verify my contact info once a year; they say it's a requirement placed on them by ICANN.
Sorry for dragging this further, but I'm just trying to understand...
How is AMPR/ARDC related to ARIN? I was under the impression 44/8 is legacy space and not governed by ARIN.
Also, how do I connect to the AMPR WHOIS server to read this information?
The whois server is under development and not yet deployed. I'm not up on the progress of that project. The intent was to have it run on the portal, where the registration database is operated so that it can have access to the necessary data.
Okay, the reason I ask is because it was my understanding ICANN only accepted contact data via WHOIS.
Tom KD7LXL
On Thu, Jun 18, 2015 at 10:29:07AM -0700, Tom Hayward wrote:
How is AMPR/ARDC related to ARIN? I was under the impression 44/8 is legacy space and not governed by ARIN.
Correct, but ARIN is the registry of networks and we are listed with them as legacy space so that we show as active and that they don't conclude that the netspace is abandoned and reissue it to someone else. - Brian
On 6/18/15 1:39 PM, Brian Kantor wrote:
Correct, but ARIN is the registry of networks and we are listed with them as legacy space so that we show as active and that they don't conclude that the netspace is abandoned and reissue it to someone else.
Brian, I think this is just simply misplaced fear of the unknown. ARIN is really powerless as our space comes from NSF/Postel/IANA.
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
Note it says ARDC, not ARIN administered.
This would be outside the scope of what ARIN is permitted to do. There is simply no way ARIN can place requirements on space they do not hold rights to from IANA. It would be unprecedented an without any legal basis.
ARIN has been sued successfully for refusing to admin legacy space before (check out what Bob Evans sued over).
ARDC has the upper hand in this. There is _nothing_ to be scared of from ARIN, they have no power to do anything.
The whois server is under development and not yet deployed. I'm not up on the progress of that project. The intent was to have it run on the portal, where the registration database is operated so that it can have access to the necessary data.
- Brian
Brian, The rwhois server project I built has been idle since the next step requires work from your side. (I've added a few blocks at peoples request)
whois -h 44.4.64.10 -p 4321 <ip block in question here>
1) If you can allow the 44.4.64.10 IP SQL access to your db so that I can write the software that can translate whats in the DB into rwhois records that will allow me to populate the server. It doesn't need to reside on the amprgw server for that access.
2) We also need you to add a referral whois entry for the 44/8 block to point to the rwhois server so that anyone who does a whois will ultimately get forwarded to the server to resolve the request.
https://www.arin.net/resources/request/reassignments_rwhois.html
Tim Osburn www.osburn.com 206.812.6214 W7RSZ
On 6/18/15 4:18 PM, Tim Osburn wrote:
- We also need you to add a referral whois entry for the 44/8 block to
point to the rwhois server so that anyone who does a whois will ultimately get forwarded to the server to resolve the request.
https://www.arin.net/resources/request/reassignments_rwhois.html
ARIN will not allow this for a Direct Assignment, we need to change it to a Direct Allocation. The Tech committee is in full support of this, as we voted on it about a year ago now and nothing changed.
Access to the database is up to Chris, since it resides on his machine and he's responsible for its design and maintenance. It might be that an API is more appropriate than direct access.
We had discussed adding additional attributes to the DB to hold whois information so that the portal could be used to edit the info, but that hasn't been done because we never came up with a spec for those attributes. It's complicated by the fact that we have about 60 directly routed subnets and about 475 tunneled, all of which need to be in the rwhois DB. If you could work with Chris on that as his time permits, it would be good.
Negotiating with ARIN has been complicated in the past because we have to be very careful not to endanger our legacy status. - Brian
On Thu, Jun 18, 2015 at 01:18:42PM -0700, Tim Osburn wrote:
The rwhois server project I built has been idle since the next step requires work from your side. (I've added a few blocks at peoples request)
whois -h 44.4.64.10 -p 4321 <ip block in question here>
- If you can allow the 44.4.64.10 IP SQL access to your db so that I
can write the software that can translate whats in the DB into rwhois records that will allow me to populate the server. It doesn't need to reside on the amprgw server for that access.
- We also need you to add a referral whois entry for the 44/8 block to
point to the rwhois server so that anyone who does a whois will ultimately get forwarded to the server to resolve the request.
https://www.arin.net/resources/request/reassignments_rwhois.html
On 6/18/15 1:01 PM, Brian Kantor wrote:
Chris says it's an easy change but points out that the primary reason for requesting people to log in at least once a year is to verify that we have current contact data for them. An automated cron login to the API doesn't do that. Since ICANN requires yearly confirmation of contact data, I feel that we are not placing an undue burden on users of our network to verify their email address at least once a year.
As far as I can tell from the ICANN policies is that ARDC needs to maintain contact info once per year. There is no "flow down" requirement that our users need to give this to us as ARDC is not a Regional Internet Registry (RIR).
That said, I'm in favor of us having a registry of people using subnets, but it's not a requirement from ICANN/IANA/ARIN.
73's
I find it a little odd to see all the responses to Brian's Post.
While the point of logging in to the Portal once a year has the secondary benefit of telling a computer that you're alive and well, the primary point seems to be identifying those users who have gone away and didn't bother to tell anyone. Let's face it, there are a lot of people who go away and don't say a word and then the allocations start to clutter up in the Portal again.
Seriously, how long does it take to log into the Portal, do nothing, and log out... once a year? Less than 10 seconds? I can't believe how many people think this is such a huge inconvenience.
Bill
On Fri, Jun 19, 2015 at 1:20 PM, William Lewis kg6baj@n1oes.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ I find it a little odd to see all the responses to Brian's Post.
While the point of logging in to the Portal once a year has the secondary benefit of telling a computer that you're alive and well, the primary point seems to be identifying those users who have gone away and didn't bother to tell anyone. Let's face it, there are a lot of people who go away and don't say a word and then the allocations start to clutter up in the Portal again.
Hit the nail on the head. There is so much cruft in the DNS tables that I imported the information into a database and ran the FCC database against it. There were roughly 1800 entries out of 3700-ish that matched expired/cancelled/revoked callsigns. And that's just for the US alone - not including active licensees who just lost interest in 44net. As BrianK would point out, there is no way that the DNS table should be this big.
If one doesn't have a good idea of their current utilization, how can one do capacity planning?
Seriously, how long does it take to log into the Portal, do nothing, and log out... once a year? Less than 10 seconds? I can't believe how many people think this is such a huge inconvenience.
I don't have a problem with that at all. But sending me an email every 3 months telling me I need to log in is the wrong way to accomplish it.
Send emails 60, 30, 15, 7, 1 days from expiry. It works for millions of folks who use subscription-oriented software products.
Michael N6MEF
-
Brian Kantor -
Bryan Fields -
Don Fanning -
Marius Petrescu -
Michael E Fox (N6MEF) -
Tim Osburn -
Tom Hayward -
William Lewis