Hi Owen, I think the problem is the scale to which the scenario I outlined is common. It's in the tens of thousands of records (probably over 100,000 if I had to guess, based on my knowledge of ARIN's database size). So let's get data.
ARIN STAFF: How many POCs are invalid that are only associated (directly or via the OrgID) with indirectly associated number registrations and with no number registrations at all? Thanks, David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: Owen DeLong [mailto:o...@delong.com] > Sent: Tuesday, April 14, 2015 10:09 AM > To: David Huberman > Cc: arin-ppml@arin.net > Subject: Re: [arin-ppml] Policy idea: POC Validation > > Seems to me that the problem in this case is not ARIN, it is the way your > particular service provider works. > > Choices include: > > 1. Work with your service provider to change their process. > 2. Change service providers. > > What am I missing? > > Owen > > > On Apr 13, 2015, at 1:36 PM, David Huberman > <david.huber...@microsoft.com> 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.