[arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement

Thu Feb 16 12:11:28 EST 2017

I have two operational perspectives wrt re-allocation/re-assignments.

first:
-----
+1 Owen, Joe Provo, james machado -- Randomly re-allocating / re-assigning
addresses to
some random person / email / mailing location at my company is a problem.

When we Peer the point-to-point is sometimes out of the Peers IP space.

The Peer will sometimes reassign detail the IP space to a random OrgID with
our company in the name
(in this case the contact is good, but the space is often held by the wrong
OrgID),

OR the Peer will reassign simple it to some random mailing address with our
compnay in the name
creating a customer C###### orgID,
(In this case there is no email address to validate,
but still held by the wrong OrgID, and possibly wrong mailing address.)

OR the Peer will reassign detail it to some random google mail and e-mail
address.

In this last case the orgID is not under our control.
We only find out about this during the annual POC review.
I get an email from someone in our Peering dept saying why is ARIN poking
me?
It is only then when I find the OrgID, and take it over, and fix the
contact.
To move the resources to the correct OrgID is more difficult, as the SWIP
is owned by the Peer
who is sometime unresponsive.

I believe the source of all of these issues is the same problem.
If we can solve that, it would be good.
If we can checking with the down stream to make sure the information is
correct
then we can avoid bad data getting in there.

Second:
-----------
With the experience of working at an ISP with business customers, I find
customers fall into three buckets:
1. Already have a relationship with ARIN (know and can provide their
correct OrgID/POC)
2. Have an IP person who would know about all their IP space, and can make
sure they are looped in
3. What is an IP admin? ARIN who?  You have my contact info from my circuit
order. Can I get my /26 now?

Depending on who places the order for service, you may sort them into the
wrong bucket

For customer of type 1, ARIN should verify them, and it should be fine.

For customers of type 2, there needs to be a process to get them as the
contact removed
and updated to the right person

For customers of type 3, the ISP should do the verification, or there
should be no validation.
Yes, they are still a customer, yes their circuit/bill goes to that
location,
yes we have that email as a contact.

I think verification at time of issuing makes sense.
I think reaffirming what bucket they are in at the time of issuing makes
sense.
In cases where the customer doesn't want to deal with ARIN, it should be
clear
What ISP record (e.g. outage contact, billing contact) and that the ISP will
continue to verify this information based on records held by the ISP (If at
all).

___Jason

On Wed, Feb 15, 2017 at 9:42 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> Andrew,
>
> There are 2 kinds of reassignments that I use simple and detailed. All the
> issues that are described in this draft only exist in the detailed
> re-assignment. An ORG could use the simple option and not have POC
> validation issues. Is there a reason that simple re-assignments were left
> out of the problem statement?
>
> 1) Yes and Yes. Even bad data has value.
> 2) Everyone has some responsibility, it shouldn't be lumped on any one
> group.
> 3) Leading question that can only be answered by Staff.
> 4) No. I would be in favor of marking the record as stale or switching the
> record to Simple and removing the POC.
> 5) Yes.
>
> Thanks,
>
> Kevin Blumberg
>
> -----Original Message-----
> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew
> Dul
> Sent: Tuesday, February 14, 2017 9:40 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC
> Validation Requirement
>
> There has been some good discussion about this draft.
>
> At this time, it seems like perhaps there is disagreement within the
> community on the purpose and use of reassignment records.  As we have gone
> past IPv4 run-out, perhaps now is the time to consider if reassignment
> records provide the same level of value to the Internet community that they
> used to provide.  Doing reassignments was one of the primary ways that a
> service provider showed utilization to ARIN.  This could also be done by
> having an organization share these records directly with ARIN during a
> resource request.
>
> I'd like to throw out a few open ended questions that perhaps will guide
> the AC as it considers this draft:
>
> 1. Do you think reassignment records provide value to the Internet
> community from an operational perspective?  Do they provide the same value
> if they are not accurate?  At what point does the "record set" as a whole
> become invaluable because the data in the records isn't representative of
> current reassignments?
>
> 2. Who do you think should be responsible for ensuring that resource
> records are accurate?  The organization doing the reassignment?  ARIN?
> Someone else?
>
> 3. Given we are past IPv4 run-out, do reassignment records provide the
> same value to ARIN for the purposes of determining utilization?  Should
> other methods be used to determine utilization going forward?
>
> 4. Would you support the concept of removing reassignment records for
> which a POC has not been validated after a certain period of time?  1
> year?  2 years?  x years?
>
> 5. Would you support the idea that a new reassignment could not be added
> to the database without the approval of the POC who is receiving the
> resource by reassignment?
>
> Thanks for your input
>
> Andrew
>
>
>
> On 12/20/2016 10:09 AM, ARIN wrote:
> >
> >
> > ##########
> >
> > ARIN-2016-8: Removal of Indirect POC Validation Requirement
> >
> > Problem Statement:
> >
> > There are over 600,000 POCs registered in Whois that are only
> > associated with indirect assignments (reassignments) and indirect
> > allocations (reallocations). NRPM 3.6 requires ARIN to contact all
> > 600,000+ of these every year to validate the POC information. This is
> > problematic for a few reasons:
> >
> > 1) ARIN does not have a business relationships with these POCs. By
> > conducting POC validation via email, ARIN is sending Unsolicited
> > Commercial Emails. Further, because of NRPM 3.6.1, ARIN cannot offer
> > an opt-out mechanism. Finally, ARIN's resultant listing on anti-spam
> > lists causes unacceptable damage to ARIN's ability to conduct ordinary
> > business over email
> >
> > 2) ARIN has previously reported that POC validation to reassignments
> > causes tremendous work for the staff. It receives many angry phone
> > calls and emails about the POC validation process. I believe the ARIN
> > staff should be focused on POC validation efforts for directly issued
> > resources, as that has more value to internet operations and law
> > enforcement than end-user POC information.
> >
> > Policy statement:
> >
> > Replace the first sentence of 3.6.1:
> >
> > "During ARIN's annual Whois POC validation, an email will be sent to
> > every POC in the Whois database."
> >
> > with
> >
> > "During ARIN's annual Whois POC validation, an email will be sent to
> > every POC that is a contact for a direct assignment, direct
> > allocation, reallocation, and AS number, and their associated OrgIDs."
> >
> > Timetable for implementation: Immediate
> > _______________________________________________
> > 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.
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170216/ae86ecb7/attachment.htm>