There's 2 broken things in this example:
1) ISP X doing a REASSIGN DETAIL swip record with just any old
information they happened to pull out of their rears. In this case,
the contact info of the unsuspecting network engineer.
ARIN can't make policy to correct that. The fact is that she should
have lit up ISP X as well as you. Presumably, you and her learned
from that and presumably ISP X also learned from that. Maybe in the
future you tell ISP X you won't be buying anymore circuits until they
get enlightened in this area? That often is very effective, you know.
This is an ISP X <--> customer relation SNAFU
and they could have just as easily SWIPed it with the company
accountant's contact info because that's where the bill was supposed to go.
If I go to the DMV and register my cat as a driver then get pulled over,
do I have grounds to scream at the DMV for being dumb enough to give a
drivers license to a cat? When it was my foolishness that did it? The
DMV can't fix this anymore than ARIN can.
2) Multiple unconsolidated POCs. This happened once more because ISP X
didn't properly file the SWIP using an existing POC ID. However, I do
believe that it IS REASONABLE for ARIN to consolidate POCs that have the
identical contact info.
If "some random guy on the Internet" brings it to ARIN's attention that
there are 5 JOHN SMITH POCs in whois that have the identical email
address, telephone number, and address then I think ARIN should
consolidate them without going through the rigamarole of asking
permission. It doesn't matter who notices them - obviously they are
the same person.
That would cut down on the multiple emails to a POC
I guess the way I look at it is that not verifying SWIP POCs just
degrades the quality of the whois database, and makes it useless for
fixing network problems or tracking wrongdoing. We cannot always
count on the direct ISP even responding properly. That ISP may respond
to ARIN because ARIN has a lever to pound on them if they don't, but
why would they respond to anyone else on the Internet who is emailing
them about a problem they are having with a subscriber? My experience
is they generally don't.
I can tell you that Law Enforcement has gotten very good at issuing
subpoenas to networks to get the names of IP address holders, so
it isn't like the true criminal can really hide. But, there's a
big grey area of antisocial behavior that isn't criminal but is
very objectionable, and providing some accountability tends to keep
that down to a dull roar.
I know it loads extra work on you guys but it seems to me that providing
a directory of who has IP in use, even if they are a customer of
some larger ISP who is "responsible" for the IP, is a core function of
a Registrar and I think we need to really discuss this thoroughly.
Is there any way ARIN can fix any of this through internal operations
changes? Maybe tell every caller who calls in on this kind of problem
to submit it via email or something?
Ted
On 4/13/2015 1:36 PM, David Huberman wrote:
Hi Owen,
I can give you a great example that's timely. My company ordered
some circuits from ISP X recently. ISP X has a policy that they only
do REASSIGN DETAIL. They registered the reassignments with POC data
that points to a network engineer who ordered the circuit. It's the
way their system works.
The engineer emailed me very angry that her information was in ARIN
Whois - and in fact, in Whois many times with multiple iterations of
her POC -- POC1, POC2, POC3, POC4, POC5, etc all with the same
information pointing to her. It even included her direct phone
number, which happened to be her mobile phone, and she was upset
about that.
Luckily for her, she knew who ARIN was, she knew who the hostmaster
was in our company (me!), and I knew how to get it fixed.
BTW, in order to get it fixed, I chose to do what I thought was the
right thing: I asked ARIN to "consolidate" the reassignment records
into my main OrgID. ARIN *would not do it* without the explicit
written permission of ISP X. (Luckily for us, ISP X consented.)
Hope that helps, David
David R Huberman Principal, Global IP Addressing Microsoft
Corporation
-----Original Message----- From: Owen DeLong
[mailto:o...@delong.com] Sent: Monday, April 13, 2015 1:30 PM To:
David Huberman Cc: arin-ppml@arin.net Subject: Re: [arin-ppml]
Policy idea: POC Validation
David,
I don’t see the angry phone call as the problem. I see it as a
symptom.
The problem is the incorrect registrations. I want us to find out
about those incorrect registrations and resolve them. I certainly
don’t want to simply remove the symptom (angry phone call) by
masking the problem (incorrect registration).
Owen
On Apr 13, 2015, at 1:23 PM, David Huberman
<david.huber...@microsoft.com> wrote:
Hi Ted,
Thanks for the reply.
By "indirect resource registration records", I meant reassignment
records.
ISP has a /17. They reassign a /28 to a customer, and decide to
put customer POC information on it. That POC only exists because
of the /28 - it isn't a POC for any directly registered allocation,
assignment, or AS number. These are the POCs who are complaining
en masse to ARIN after receiving POC Validation communications. My
reasoning for removing POC validation for these types of POCs is
that ISPs have the option to not register POCs at all -- they can
choose "REASSIGN SIMPLE" as a path for registering SWIP
information, and that doesn't have any POC info. Secondly, I'm not
convinced there's a significant value in up-to-date POC information
for reassigned numbers. In the end, the ISP (the direct
registrant) is the party responsible for the IP addresses and use.
(And in 90%+ of cases, the ISP is responsible for routing in the
DFZ, too. For the cases where a reassigned block is announced by
th
e customer, there's a customer ASN easily found in the routing
tables, and that contact information is more germane than a SWIP
record.)
I hope that's clearer.
David
David R Huberman Principal, Global IP Addressing Microsoft
Corporation
-----Original Message----- From: arin-ppml-boun...@arin.net
[mailto:arin-ppml-boun...@arin.net] On Behalf Of Ted
Mittelstaedt Sent: Monday, April 13, 2015 12:12 PM To:
arin-ppml@arin.net Subject: Re: [arin-ppml] Policy idea: POC
Validation
As one of the initiators of this policy I must state that none
of us who worked on this ever assumed the POC Validation Policy
would be the END of the process.
The idea was that when a POC was marked invalid, that ARIN
would institute an investigation into the number resources held
by the invalid POC and if they did locate the actual holder,
they would give that holder 30 days to supply valid POC contact
info for whois that would replace the bogus invalid contact
info.
If the holder wasn't forthcoming, ARIN will delete the POC.
Resources that have no POC's justifying their existence are
then freed up
for reassignment.
If ARIN is not doing this, then it is completely understandable
that you would be getting large numbers of phone calls from
people annoyed that their email addresses are still in whois.
So, ARIN can start doing this and thereby make the people happy
who are complaining, and at the same time, freeing up resources
that are held by stale or bogus POC data.
You said "indirect resource registration records"
What exactly is that?
In my opinion, ANY POC that is in whois that is associated in
any way with an organization or individual who has IP
addresses, and is being used as justification for holding
resources, must remain in the validation
list.
It seems quite obvious and apparent that POCs that ARIN has
judged to be invalid, and is in the process of investigating,
would be calling and complaining. In general people who are
doing things they shouldn't be doing, don't like to be
investigated would certainly would
complain.
That can be solved easily by deleting their records and
thereby freeing up resources. Then you don't contact them
again and the community gets back the IP addressing they have
held.
Does not a POC that is being contacted by ARIN have the right
to have their information deleted? If they are calling in and
complaining that their records are in there, they obviously
want them removed. So, ARIN can remove them and stop bothering
them.
You need to define the difference between "indirect resource
registration records" and "associated with an active directly
registered
number resource"
before anyone can really make a judgement on this policy
proposal
change.
It just seems very simple to me. If they are a POC they are
there because their existence is justifying some IP address
holding in some way, there is some connection. If their POC is
no longer justifying an IP address holding and there is no
connection whatsoever to an IP address holding, then take their
POC out and doing so will automatically
quit contacting them.
Ted
On 4/13/2015 11:11 AM, David Huberman wrote:
Hello,
Richard Jimmerson's Policy Experience Report indicated that
50% of the
phone calls that RSD receives are about POC validation, and
that they receive many angry emails and calls from POCs who are
only associated with indirect resource registration records. In
response, I offer the following change to the NRPM :
Existing text:
3.6 Annual Whois POC Validation 3.6.1 Method of Annual
Verification During ARIN's annual Whois POC validation, an
email will be sent to every
POC in the Whois database. Each POC will have a maximum of 60
days to respond with an affirmative that their Whois contact
information is correct and complete. Unresponsive POC email
addresses shall be marked as such in the database. If ARIN
staff deems a POC to be completely and permanently abandoned or
otherwise illegitimate, the
POC record shall be marked invalid.
ARIN will maintain, and make readily available to the
community, a current list of number resources with no valid
POC; this data will be subject to the current bulk Whois
policy.
I propose we make the first sentence read:
"During ARIN's annual Whois POC validation, an email will be
sent to every
POC in the Whois database that is associated with an active
directly registered number resource."
Thoughts? David
David R Huberman Principal, Global IP Addressing Microsoft
Corporation
_______________________________________________ PPML You are
receiving this message because you are subscribed to the ARIN
Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe
or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml Please
contact i...@arin.net if you experience any issues.
_______________________________________________ PPML You are
receiving this message because you are subscribed to the ARIN
Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or
manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
i...@arin.net if you experience any issues.
_______________________________________________ PPML You are
receiving this message because you are subscribed to the ARIN
Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or
manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
i...@arin.net if you experience any issues.
_______________________________________________ PPML You are
receiving this message because you are subscribed to the ARIN Public
Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your
mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
i...@arin.net if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
