18 Jun
2015
18 Jun
'15
4:47 p.m.
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
18 Jun
18 Jun
4:56 p.m.
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.
4:58 p.m.
On Thu, Jun 18, 2015 at 8:47 AM, Brian Kantor <Brian(a)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
5:05 p.m.
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(a)gmail.com> wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>On Thu, Jun 18, 2015 at 8:47 AM, Brian Kantor <Brian(a)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
>
5:12 p.m.
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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
5:19 p.m.
On Thu, Jun 18, 2015 at 9:12 AM, Marius Petrescu <marius(a)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
5:21 p.m.
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(a)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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
--
Bryan Fields
727-409-1194
http://bryanfields.net
5:22 p.m.
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
6:01 p.m.
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:
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
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.
6:14 p.m.
On Thu, Jun 18, 2015 at 10:01 AM, Brian Kantor <Brian(a)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
6:25 p.m.
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
6:29 p.m.
On Thu, Jun 18, 2015 at 10:25 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
Okay, the reason I ask is because it was my understanding ICANN only
accepted contact data via WHOIS.
Tom KD7LXL
(Please trim inclusions from previous messages)
_______________________________________________
On Thu, Jun 18, 2015 at 10:14:00AM -0700, Tom Hayward wrote:
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.
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.
6:39 p.m.
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
19 Jun
19 Jun
8:21 p.m.
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.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
18 Jun
18 Jun
9:18 p.m.
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
9:54 p.m.
On 6/18/15 4:18 PM, Tim Osburn wrote:
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
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.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
10:26 p.m.
New subject: rwhois server
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>
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
19 Jun
19 Jun
8:32 p.m.
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
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
9:20 p.m.
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
20 Jun
20 Jun
12:40 a.m.
On Fri, Jun 19, 2015 at 1:20 PM, William Lewis <kg6baj(a)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?
1:14 a.m.
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
3454
days inactive
3456
days old
20 comments
8 participants
participants (8)
-
Brian Kantor -
Bryan Fields -
Don Fanning -
Marius Petrescu -
Michael E Fox (N6MEF) -
Tim Osburn -
Tom Hayward -
William Lewis