<p dir="ltr">Jimmy I would have to +1 David here; wholeheartedly Sir.<br>
RD</p>
<div class="gmail_quote">On Apr 15, 2015 12:23 PM, <<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send ARIN-PPML mailing list submissions to<br>
<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:arin-ppml-owner@arin.net">arin-ppml-owner@arin.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ARIN-PPML digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Equality in address space assignment (David Huberman)<br>
2. Re: Policy idea: POC Validation (David Huberman)<br>
3. Re: Policy idea: POC Validation (Ted Mittelstaedt)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 15 Apr 2015 16:00:54 +0000<br>
From: David Huberman <<a href="mailto:David.Huberman@microsoft.com">David.Huberman@microsoft.com</a>><br>
To: Jimmy Hess <<a href="mailto:mysidia@gmail.com">mysidia@gmail.com</a>><br>
Cc: "ARIN PPML \(<a href="mailto:ppml@arin.net">ppml@arin.net</a>\)" <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Equality in address space assignment<br>
Message-ID:<br>
<<a href="mailto:DM2PR03MB398CF9A4E3D8DDC11B511ED9BE50@DM2PR03MB398.namprd03.prod.outlook.com">DM2PR03MB398CF9A4E3D8DDC11B511ED9BE50@DM2PR03MB398.namprd03.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Jimmy,<br>
<br>
Thank you for the well thought out counter argument. I agree with a lot of what you say. You've outlined what I think is the primary thinking behind conservation-based allocation practices that ARIN policy has been based on for 18 years now.<br>
<br>
The problem I think I have is the results of those practices.<br>
1) Lock-in by large providers<br>
2) Conservation itself is a red herring, and has been for more than a decade. 80-90% of the addresses go to 10 companies. That leaves tens of thousands of networks using just 10-20% of the addresses. This math has been shown many times on PPML in the past.<br>
<br>
Routing table growth is no longer mathematically valid, in my opinion. We are just under 600,000 routes. There are only 40,000 ASes or so (right?) in a typical DFZ. Even a doubling of that would have no discernable effect on routing. If youre running a catalyst 5xxx, it's time to upgrade.<br>
<br>
Finally, I respect the RIPE and APNIC model of addressing: everyone plays on a level field to start with. You get a block, and try and grow your business/network. At ARIN, this "you must be THIS tall" inherently favors the large ISPs and cablecos who dominate ARIN policy making (and have since the beginning), which results in lock-in, etc etc.<br>
<br>
Just my opinion. My original post was made in frustration when large ISPs got to the mic at ARIN35 decrying that removing needs-basis for small transfers was unfair. Such hypocrisy (especially from those who already bought a /8!!!) is a sore topic for me. I will continue to fight for the little guy, borne of my 10 years working with them every day at ARIN. The big guys don't need the help.<br>
<br>
Thanks for listening,<br>
David<br>
<br>
David R Huberman<br>
Principal, Global IP Addressing<br>
Microsoft Corporation<br>
<br>
> -----Original Message-----<br>
> From: Jimmy Hess [mailto:<a href="mailto:mysidia@gmail.com">mysidia@gmail.com</a>]<br>
> Sent: Tuesday, April 14, 2015 4:24 PM<br>
> To: David Huberman<br>
> Cc: ARIN PPML (<a href="mailto:ppml@arin.net">ppml@arin.net</a>)<br>
> Subject: Re: [arin-ppml] Equality in address space assignment<br>
><br>
> On Tue, Apr 14, 2015 at 4:34 PM, David Huberman<br>
> <<a href="mailto:David.Huberman@microsoft.com">David.Huberman@microsoft.com</a>> wrote:<br>
><br>
> > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must<br>
> > be THIS large a network to participate? fair?<br>
> > What is the technical basis for not allowing small networks to get PI space?<br>
><br>
> It's unfair, because non first time requestors have to hold resources, And<br>
> they have to show efficient utilization of existing resources.<br>
><br>
> "All first time requestors can get a /24" is essentially saying....<br>
><br>
> "We don't care if you waste 253 IP addresses, because your network design<br>
> only required a /29."<br>
><br>
><br>
> Doesn't require a technical basis. It is undesirable for any<br>
> networks to have PI<br>
> space, as it grows the routing tables, but<br>
><br>
> This is a good non-technical resource management choice. It makes sense to<br>
> require small networks with no direct allocation yet to meet criteria to show<br>
> that they have reached a size milestone of proven business and growth<br>
> projections with<br>
> sufficient confidence to show that the allocation of a /24 is needed,<br>
> and absolutely necessary to meet short term or immediate needs.<br>
><br>
> Consider that there are many more small networks than large ones.<br>
> There are many very small networks which might have a proven case for<br>
> 10 IP addresses and a claim to need 200 "soon".<br>
><br>
> It makes no sense that they can get a /24 for ARIN, and then stop growing,<br>
> and hold onto<br>
> that entire /24 forever; As long as the small organization exists,<br>
> the allocation of the /24<br>
> is an irrevocable choice, with no incentive for the small org. to renumber<br>
> back to PA space and release unnecessary resources.<br>
><br>
> On the other hand, if the small org obtains a /24 of PA space instead, or a<br>
> /28 of PA space, Either less IP space will be wasted by the small network,<br>
> Or the ISP holding the PA block can reclaim addresses at a later date.<br>
><br>
> Furthermore, for the larger networks, there should be a small number of<br>
> those, so there is less possible waste.<br>
><br>
> It would also be much better for the public for these resources to go to an<br>
> ISP as PA space, where the /24 could be divided up more fairly according to<br>
> actual need; with fewer global routing table entries.<br>
><br>
> Operators already managing large PA address space are also more likely to<br>
> have mature organizational frameworks to ensure the right internal address<br>
> management practices are in place to avoid wasting or unnecessarily utilizing<br>
> scarce IPs.<br>
><br>
> To the 50000 or so would-be first time requestors who might like a /24; if<br>
> there was no previous resource requirement....<br>
> they might very well wind up wasting 75% of their allocation by only using<br>
> 25% of the IPs.<br>
><br>
><br>
> > Decades of RIPE and APNIC policy didn?t break the internet.<br>
><br>
> Non Sequitur.<br>
> Decades of ARIN policy didn't break the internet, either.<br>
><br>
><br>
> > David<br>
> --<br>
> -JH<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 15 Apr 2015 16:05:51 +0000<br>
From: David Huberman <<a href="mailto:David.Huberman@microsoft.com">David.Huberman@microsoft.com</a>><br>
To: Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>><br>
Cc: "<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>" <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Policy idea: POC Validation<br>
Message-ID:<br>
<<a href="mailto:DM2PR03MB398C0786D9D0BC519E878649BE50@DM2PR03MB398.namprd03.prod.outlook.com">DM2PR03MB398C0786D9D0BC519E878649BE50@DM2PR03MB398.namprd03.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Owen,<br>
<br>
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.<br>
<br>
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?<br>
<br>
Thanks,<br>
David<br>
<br>
David R Huberman<br>
Principal, Global IP Addressing<br>
Microsoft Corporation<br>
<br>
> -----Original Message-----<br>
> From: Owen DeLong [mailto:<a href="mailto:owen@delong.com">owen@delong.com</a>]<br>
> Sent: Tuesday, April 14, 2015 10:09 AM<br>
> To: David Huberman<br>
> Cc: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
> Subject: Re: [arin-ppml] Policy idea: POC Validation<br>
><br>
> Seems to me that the problem in this case is not ARIN, it is the way your<br>
> particular service provider works.<br>
><br>
> Choices include:<br>
><br>
> 1. Work with your service provider to change their process.<br>
> 2. Change service providers.<br>
><br>
> What am I missing?<br>
><br>
> Owen<br>
><br>
> > On Apr 13, 2015, at 1:36 PM, David Huberman<br>
> <<a href="mailto:David.Huberman@microsoft.com">David.Huberman@microsoft.com</a>> wrote:<br>
> ><br>
> > Hi Owen,<br>
> ><br>
> > I can give you a great example that's timely. My company ordered some<br>
> circuits from ISP X recently. ISP X has a policy that they only do REASSIGN<br>
> DETAIL. They registered the reassignments with POC data that points to a<br>
> network engineer who ordered the circuit. It's the way their system works.<br>
> ><br>
> > The engineer emailed me very angry that her information was in ARIN<br>
> Whois - and in fact, in Whois many times with multiple iterations of her POC -<br>
> - POC1, POC2, POC3, POC4, POC5, etc all with the same information pointing<br>
> to her. It even included her direct phone number, which happened to be<br>
> her mobile phone, and she was upset about that.<br>
> ><br>
> > Luckily for her, she knew who ARIN was, she knew who the hostmaster<br>
> was in our company (me!), and I knew how to get it fixed.<br>
> ><br>
> > BTW, in order to get it fixed, I chose to do what I thought was the right<br>
> thing: I asked ARIN to "consolidate" the reassignment records into my main<br>
> OrgID. ARIN *would not do it* without the explicit written permission of ISP<br>
> X. (Luckily for us, ISP X consented.)<br>
> ><br>
> > Hope that helps,<br>
> > David<br>
> ><br>
> > David R Huberman<br>
> > Principal, Global IP Addressing<br>
> > Microsoft Corporation<br>
> ><br>
> >> -----Original Message-----<br>
> >> From: Owen DeLong [mailto:<a href="mailto:owen@delong.com">owen@delong.com</a>]<br>
> >> Sent: Monday, April 13, 2015 1:30 PM<br>
> >> To: David Huberman<br>
> >> Cc: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
> >> Subject: Re: [arin-ppml] Policy idea: POC Validation<br>
> >><br>
> >> David,<br>
> >><br>
> >> I don?t see the angry phone call as the problem. I see it as a symptom.<br>
> >><br>
> >> The problem is the incorrect registrations. I want us to find out<br>
> >> about those incorrect registrations and resolve them. I certainly<br>
> >> don?t want to simply remove the symptom (angry phone call) by masking<br>
> >> the problem (incorrect registration).<br>
> >><br>
> >> Owen<br>
> >><br>
> >>> On Apr 13, 2015, at 1:23 PM, David Huberman<br>
> >> <<a href="mailto:David.Huberman@microsoft.com">David.Huberman@microsoft.com</a>> wrote:<br>
> >>><br>
> >>> Hi Ted,<br>
> >>><br>
> >>> Thanks for the reply.<br>
> >>><br>
> >>> By "indirect resource registration records", I meant reassignment<br>
> records.<br>
> >> ISP has a /17. They reassign a /28 to a customer, and decide to put<br>
> >> customer POC information on it. That POC only exists because of the /28 -<br>
> it isn't a POC<br>
> >> for any directly registered allocation, assignment, or AS number. These<br>
> are<br>
> >> the POCs who are complaining en masse to ARIN after receiving POC<br>
> >> Validation communications. My reasoning for removing POC validation<br>
> >> for these types of POCs is that ISPs have the option to not register<br>
> >> POCs at all -- they can choose "REASSIGN SIMPLE" as a path for<br>
> >> registering SWIP information, and that doesn't have any POC info.<br>
> >> Secondly, I'm not convinced there's a significant value in up-to-date<br>
> >> POC information for reassigned numbers. In the end, the ISP (the<br>
> >> direct registrant) is the party responsible for the IP addresses and<br>
> >> use. (And in 90%+ of cases, the ISP is responsible for routing in<br>
> >> the DFZ, too. For the cases where a reassigned block is announced by<br>
> >> th<br>
> >>> e customer, there's a customer ASN easily found in the routing<br>
> >>> tables, and that contact information is more germane than a SWIP<br>
> >>> record.)<br>
> >>><br>
> >>> I hope that's clearer.<br>
> >>><br>
> >>> David<br>
> >>><br>
> >>> David R Huberman<br>
> >>> Principal, Global IP Addressing<br>
> >>> Microsoft Corporation<br>
> >>><br>
> >>>> -----Original Message-----<br>
> >>>> From: <a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a><br>
> >>>> [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>]<br>
> >>>> On Behalf Of Ted Mittelstaedt<br>
> >>>> Sent: Monday, April 13, 2015 12:12 PM<br>
> >>>> To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
> >>>> Subject: Re: [arin-ppml] Policy idea: POC Validation<br>
> >>>><br>
> >>>><br>
> >>>> As one of the initiators of this policy I must state that none of<br>
> >>>> us who worked on this ever assumed the POC Validation Policy would<br>
> >>>> be the END of the process.<br>
> >>>><br>
> >>>> The idea was that when a POC was marked invalid, that ARIN would<br>
> >>>> institute an investigation into the number resources held by the<br>
> >>>> invalid POC and if they did locate the actual holder, they would<br>
> >>>> give that holder 30 days to supply valid POC contact info for whois<br>
> >>>> that would replace the bogus invalid contact info.<br>
> >>>><br>
> >>>> If the holder wasn't forthcoming, ARIN will delete the POC.<br>
> >>>> Resources that have no POC's justifying their existence are then<br>
> >>>> freed up<br>
> >> for reassignment.<br>
> >>>><br>
> >>>> If ARIN is not doing this, then it is completely understandable<br>
> >>>> that you would be getting large numbers of phone calls from people<br>
> >>>> annoyed that their email addresses are still in whois.<br>
> >>>><br>
> >>>> So, ARIN can start doing this and thereby make the people happy who<br>
> >>>> are complaining, and at the same time, freeing up resources that<br>
> >>>> are held by stale or bogus POC data.<br>
> >>>><br>
> >>>> You said "indirect resource registration records"<br>
> >>>><br>
> >>>> What exactly is that?<br>
> >>>><br>
> >>>> In my opinion, ANY POC that is in whois that is associated in any<br>
> >>>> way with an organization or individual who has IP addresses, and is<br>
> >>>> being used as justification for holding resources, must remain in<br>
> >>>> the validation<br>
> >> list.<br>
> >>>><br>
> >>>> It seems quite obvious and apparent that POCs that ARIN has judged<br>
> >>>> to be invalid, and is in the process of investigating, would be<br>
> >>>> calling and complaining. In general people who are doing things<br>
> >>>> they shouldn't be doing, don't like to be investigated would<br>
> >>>> certainly would<br>
> >> complain.<br>
> >>>> That can be solved easily by deleting their records and thereby<br>
> >>>> freeing up resources. Then you don't contact them again and the<br>
> >>>> community gets back the IP addressing they have held.<br>
> >>>><br>
> >>>> Does not a POC that is being contacted by ARIN have the right to<br>
> >>>> have their information deleted? If they are calling in and<br>
> >>>> complaining that their records are in there, they obviously want them<br>
> removed.<br>
> >>>> So, ARIN can remove them and stop bothering them.<br>
> >>>><br>
> >>>> You need to define the difference between "indirect resource<br>
> >>>> registration records" and "associated with an active directly<br>
> >>>> registered<br>
> >> number resource"<br>
> >>>> before anyone can really make a judgement on this policy proposal<br>
> >> change.<br>
> >>>><br>
> >>>> It just seems very simple to me. If they are a POC they are there<br>
> >>>> because their existence is justifying some IP address holding in<br>
> >>>> some way, there is some connection. If their POC is no longer<br>
> >>>> justifying an IP address holding and there is no connection<br>
> >>>> whatsoever to an IP address holding, then take their POC out and<br>
> >>>> doing so will automatically<br>
> >> quit contacting them.<br>
> >>>><br>
> >>>> Ted<br>
> >>>><br>
> >>>> On 4/13/2015 11:11 AM, David Huberman wrote:<br>
> >>>>> Hello,<br>
> >>>>><br>
> >>>>> Richard Jimmerson's Policy Experience Report indicated that 50% of<br>
> >>>>> the<br>
> >>>> phone calls that RSD receives are about POC validation, and that<br>
> >>>> they receive many angry emails and calls from POCs who are only<br>
> >>>> associated with indirect resource registration records. In<br>
> >>>> response, I offer the following change to the NRPM :<br>
> >>>>><br>
> >>>>><br>
> >>>>> Existing text:<br>
> >>>>><br>
> >>>>> 3.6 Annual Whois POC Validation<br>
> >>>>> 3.6.1 Method of Annual Verification During ARIN's annual Whois POC<br>
> >>>>> validation, an email will be sent to every<br>
> >>>> POC in the Whois database. Each POC will have a maximum of 60 days<br>
> >>>> to respond with an affirmative that their Whois contact information<br>
> >>>> is correct and complete. Unresponsive POC email addresses shall be<br>
> >>>> marked as such in the database. If ARIN staff deems a POC to be<br>
> >>>> completely and permanently abandoned or otherwise illegitimate, the<br>
> >> POC record shall be marked invalid.<br>
> >>>> ARIN will maintain, and make readily available to the community, a<br>
> >>>> current list of number resources with no valid POC; this data will<br>
> >>>> be subject to the current bulk Whois policy.<br>
> >>>>><br>
> >>>>><br>
> >>>>> I propose we make the first sentence read:<br>
> >>>>><br>
> >>>>> "During ARIN's annual Whois POC validation, an email will be sent<br>
> >>>>> to every<br>
> >>>> POC in the Whois database that is associated with an active<br>
> >>>> directly registered number resource."<br>
> >>>>><br>
> >>>>> Thoughts?<br>
> >>>>> David<br>
> >>>>><br>
> >>>>> David R Huberman<br>
> >>>>> Principal, Global IP Addressing<br>
> >>>>> Microsoft Corporation<br>
> >>>>><br>
> >>>>> _______________________________________________<br>
> >>>>> PPML<br>
> >>>>> You are receiving this message because you are subscribed to the<br>
> >>>>> 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" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> >>>>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
> >>>> _______________________________________________<br>
> >>>> PPML<br>
> >>>> You are receiving this message because you are subscribed to the<br>
> >>>> 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" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> >>>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
> >>> _______________________________________________<br>
> >>> PPML<br>
> >>> You are receiving this message because you are subscribed to the<br>
> >>> 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" target="_blank">http://lists.arin.net/mailman/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>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 15 Apr 2015 09:22:39 -0700<br>
From: Ted Mittelstaedt <<a href="mailto:tedm@ipinc.net">tedm@ipinc.net</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] Policy idea: POC Validation<br>
Message-ID: <<a href="mailto:552E904F.7020909@ipinc.net">552E904F.7020909@ipinc.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
<br>
I like this solution a lot! It will, of course, result in the<br>
offending ISPs POCs being spammed to death by their own automated<br>
systems which auto-fill the SWIPs with information they seem to pull<br>
out of thin air.<br>
<br>
But sacrifices have to be made!<br>
<br>
Ted<br>
<br>
On 4/14/2015 11:08 AM, William Herrin wrote:<br>
> On Mon, Apr 13, 2015 at 5:31 PM, Martin Hannigan<<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a>> wrote:<br>
>> Did ARIN/you consider a consultation instead and simply adding a NACK button<br>
>> to the confirmation and reassigning the block back to the ISP in question or<br>
>> re designate to the online account owner?<br>
><br>
> Hi Marty,<br>
><br>
> That's a fantastic idea. But instead of deregistering the block (which<br>
> would add chaos to the process for the right-org-wrong-POC case) do<br>
> two things:<br>
><br>
> 1. Feed the fact of the NACK back to the ISP with a message that the<br>
> POC reports a registration mistake (requests contact for correction)<br>
> and a gentle reminder that they are asked to publish accurate records<br>
> as a condition of retaining allocations. Mistakes will be made. How<br>
> will the folks who made the mistake find out if they don't get any<br>
> feedback?<br>
><br>
> 2. Use the data to build a stochastic model that separates routine<br>
> bookkeeping error from orgs who are more on the negligence/fraud end<br>
> of SWIP management.<br>
><br>
> Regards,<br>
> Bill Herrin<br>
><br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
End of ARIN-PPML Digest, Vol 118, Issue 19<br>
******************************************<br>
</blockquote></div>