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 <[email protected]> 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:[email protected]] On Behalf Of Andrew > Dul > Sent: Tuesday, February 14, 2017 9:40 PM > To: [email protected] > 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 ([email protected]). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact [email protected] if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|[email protected]|571-266-0006
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
