[arin-ppml] Policy idea: POC Validation

Mon Apr 13 17:30:42 EDT 2015

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:owen at delong.com] Sent: Monday, April 13, 2015 1:30 PM To:
>> David Huberman Cc: arin-ppml at 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.Huberman at 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-bounces at arin.net
>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted
>>>> Mittelstaedt Sent: Monday, April 13, 2015 12:12 PM To:
>>>> arin-ppml at 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 at arin.net). Unsubscribe
>>>>> or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml Please
>>>>> contact info at 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 at arin.net). Unsubscribe or
>>>> manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
>>>> info at 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 at arin.net). Unsubscribe or
>>> manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
>>> info at 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 at arin.net). Unsubscribe or manage your
> mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
> info at arin.net if you experience any issues.