<div dir="ltr"><div><div>I have two operational perspectives wrt re-allocation/re-assignments.<br></div><div><br></div><div>first:</div><div>-----</div><div>+1 Owen, Joe Provo, james machado -- Randomly re-allocating / re-assigning addresses to</div><div>some random person / email / mailing location at my company is a problem. </div></div><div><br></div><div>When we Peer the point-to-point is sometimes out of the Peers IP space.</div><div><br></div><div>The Peer will sometimes reassign detail the IP space to a random OrgID with our company in the name</div><div>(in this case the contact is good, but the space is often held by the wrong OrgID), </div><div><br></div><div>OR the Peer will reassign simple it to some random mailing address with our compnay in the name</div><div>creating a customer C###### orgID,</div><div>(In this case there is no email address to validate, </div><div>but still held by the wrong OrgID, and possibly wrong mailing address.)</div><div><br></div><div>OR the Peer will reassign detail it to some random google mail and e-mail address.</div><div><br></div><div>In this last case the orgID is not under our control. </div><div>We only find out about this during the annual POC review. </div><div>I get an email from someone in our Peering dept saying why is ARIN poking me?</div><div>It is only then when I find the OrgID, and take it over, and fix the contact.</div><div>To move the resources to the correct OrgID is more difficult, as the SWIP is owned by the Peer</div><div>who is sometime unresponsive.</div><div><br></div><div>I believe the source of all of these issues is the same problem. </div><div>If we can solve that, it would be good.<br></div><div>If we can checking with the down stream to make sure the information is correct</div><div>then we can avoid bad data getting in there.</div><div><br></div><div><br></div><div>Second:</div><div>-----------</div><div>With the experience of working at an ISP with business customers, I find customers fall into three buckets:</div><div>1. Already have a relationship with ARIN (know and can provide their correct OrgID/POC)</div><div>2. Have an IP person who would know about all their IP space, and can make sure they are looped in</div><div>3. What is an IP admin? ARIN who? You have my contact info from my circuit order. Can I get my /26 now?</div><div><br></div><div>Depending on who places the order for service, you may sort them into the wrong bucket</div><div><br></div><div>For customer of type 1, ARIN should verify them, and it should be fine.</div><div><br></div><div>For customers of type 2, there needs to be a process to get them as the contact removed </div><div>and updated to the right person</div><div><br></div><div>For customers of type 3, the ISP should do the verification, or there should be no validation. </div><div>Yes, they are still a customer, yes their circuit/bill goes to that location,</div><div>yes we have that email as a contact.</div><div><br></div><div><br></div><div>I think verification at time of issuing makes sense.</div><div>I think reaffirming what bucket they are in at the time of issuing makes sense. </div><div>In cases where the customer doesn't want to deal with ARIN, it should be clear</div><div>What ISP record (e.g. outage contact, billing contact) and that the ISP will</div><div>continue to verify this information based on records held by the ISP (If at all).</div><div><br></div><div>___Jason</div><div> </div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 9:42 PM, Kevin Blumberg <span dir="ltr"><<a href="mailto:kevinb@thewire.ca" target="_blank">kevinb@thewire.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andrew,<br>
<br>
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?<br>
<br>
1) Yes and Yes. Even bad data has value.<br>
2) Everyone has some responsibility, it shouldn't be lumped on any one group.<br>
3) Leading question that can only be answered by Staff.<br>
4) No. I would be in favor of marking the record as stale or switching the record to Simple and removing the POC.<br>
5) Yes.<br>
<br>
Thanks,<br>
<br>
Kevin Blumberg<br>
<span class="im HOEnZb"><br>
-----Original Message-----<br>
From: ARIN-PPML [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@<wbr>arin.net</a>] On Behalf Of Andrew Dul<br>
</span><span class="im HOEnZb">Sent: Tuesday, February 14, 2017 9:40 PM<br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
</span><div class="HOEnZb"><div class="h5">Subject: Re: [arin-ppml] Draft Policy ARIN-2016-8: Removal of Indirect POC Validation Requirement<br>
<br>
There has been some good discussion about this draft.<br>
<br>
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.<br>
<br>
I'd like to throw out a few open ended questions that perhaps will guide the AC as it considers this draft:<br>
<br>
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?<br>
<br>
2. Who do you think should be responsible for ensuring that resource records are accurate? The organization doing the reassignment? ARIN?<br>
Someone else?<br>
<br>
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?<br>
<br>
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?<br>
<br>
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?<br>
<br>
Thanks for your input<br>
<br>
Andrew<br>
<br>
<br>
<br>
On 12/20/2016 10:09 AM, ARIN wrote:<br>
><br>
><br>
> ##########<br>
><br>
> ARIN-2016-8: Removal of Indirect POC Validation Requirement<br>
><br>
> Problem Statement:<br>
><br>
> There are over 600,000 POCs registered in Whois that are only<br>
> associated with indirect assignments (reassignments) and indirect<br>
> allocations (reallocations). NRPM 3.6 requires ARIN to contact all<br>
> 600,000+ of these every year to validate the POC information. This is<br>
> problematic for a few reasons:<br>
><br>
> 1) ARIN does not have a business relationships with these POCs. By<br>
> conducting POC validation via email, ARIN is sending Unsolicited<br>
> Commercial Emails. Further, because of NRPM 3.6.1, ARIN cannot offer<br>
> an opt-out mechanism. Finally, ARIN's resultant listing on anti-spam<br>
> lists causes unacceptable damage to ARIN's ability to conduct ordinary<br>
> business over email<br>
><br>
> 2) ARIN has previously reported that POC validation to reassignments<br>
> causes tremendous work for the staff. It receives many angry phone<br>
> calls and emails about the POC validation process. I believe the ARIN<br>
> staff should be focused on POC validation efforts for directly issued<br>
> resources, as that has more value to internet operations and law<br>
> enforcement than end-user POC information.<br>
><br>
> Policy statement:<br>
><br>
> Replace the first sentence of 3.6.1:<br>
><br>
> "During ARIN's annual Whois POC validation, an email will be sent to<br>
> every POC in the Whois database."<br>
><br>
> with<br>
><br>
> "During ARIN's annual Whois POC validation, an email will be sent to<br>
> every POC that is a contact for a direct assignment, direct<br>
> allocation, reallocation, and AS number, and their associated OrgIDs."<br>
><br>
> Timetable for implementation: Immediate<br>
> ______________________________<wbr>_________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to the ARIN<br>
> Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>