Jimmy I would have to +1 David here; wholeheartedly Sir. RD On Apr 15, 2015 12:23 PM, <[email protected]> wrote:
> Send ARIN-PPML mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Equality in address space assignment (David Huberman) > 2. Re: Policy idea: POC Validation (David Huberman) > 3. Re: Policy idea: POC Validation (Ted Mittelstaedt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Apr 2015 16:00:54 +0000 > From: David Huberman <[email protected]> > To: Jimmy Hess <[email protected]> > Cc: "ARIN PPML \([email protected]\)" <[email protected]> > Subject: Re: [arin-ppml] Equality in address space assignment > Message-ID: > < > dm2pr03mb398cf9a4e3d8ddc11b511ed9b...@dm2pr03mb398.namprd03.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > Jimmy, > > 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. > > The problem I think I have is the results of those practices. > 1) Lock-in by large providers > 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. > > 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. > > 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. > > 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. > > Thanks for listening, > David > > David R Huberman > Principal, Global IP Addressing > Microsoft Corporation > > > -----Original Message----- > > From: Jimmy Hess [mailto:[email protected]] > > Sent: Tuesday, April 14, 2015 4:24 PM > > To: David Huberman > > Cc: ARIN PPML ([email protected]) > > Subject: Re: [arin-ppml] Equality in address space assignment > > > > On Tue, Apr 14, 2015 at 4:34 PM, David Huberman > > <[email protected]> wrote: > > > > > How is RIPE and APNIC?s policy unfair, but ARIN?s policy of ?you must > > > be THIS large a network to participate? fair? > > > What is the technical basis for not allowing small networks to get PI > space? > > > > It's unfair, because non first time requestors have to hold resources, > And > > they have to show efficient utilization of existing resources. > > > > "All first time requestors can get a /24" is essentially saying.... > > > > "We don't care if you waste 253 IP addresses, because your network > design > > only required a /29." > > > > > > Doesn't require a technical basis. It is undesirable for any > > networks to have PI > > space, as it grows the routing tables, but > > > > This is a good non-technical resource management choice. It makes sense > to > > require small networks with no direct allocation yet to meet criteria to > show > > that they have reached a size milestone of proven business and growth > > projections with > > sufficient confidence to show that the allocation of a /24 is needed, > > and absolutely necessary to meet short term or immediate needs. > > > > Consider that there are many more small networks than large ones. > > There are many very small networks which might have a proven case for > > 10 IP addresses and a claim to need 200 "soon". > > > > It makes no sense that they can get a /24 for ARIN, and then stop > growing, > > and hold onto > > that entire /24 forever; As long as the small organization exists, > > the allocation of the /24 > > is an irrevocable choice, with no incentive for the small org. to > renumber > > back to PA space and release unnecessary resources. > > > > On the other hand, if the small org obtains a /24 of PA space > instead, or a > > /28 of PA space, Either less IP space will be wasted by the small > network, > > Or the ISP holding the PA block can reclaim addresses at a later > date. > > > > Furthermore, for the larger networks, there should be a small number of > > those, so there is less possible waste. > > > > It would also be much better for the public for these resources to go to > an > > ISP as PA space, where the /24 could be divided up more fairly according > to > > actual need; with fewer global routing table entries. > > > > Operators already managing large PA address space are also more likely > to > > have mature organizational frameworks to ensure the right internal > address > > management practices are in place to avoid wasting or unnecessarily > utilizing > > scarce IPs. > > > > To the 50000 or so would-be first time requestors who might like a > /24; if > > there was no previous resource requirement.... > > they might very well wind up wasting 75% of their allocation by only > using > > 25% of the IPs. > > > > > > > Decades of RIPE and APNIC policy didn?t break the internet. > > > > Non Sequitur. > > Decades of ARIN policy didn't break the internet, either. > > > > > > > David > > -- > > -JH > > ------------------------------ > > Message: 2 > Date: Wed, 15 Apr 2015 16:05:51 +0000 > From: David Huberman <[email protected]> > To: Owen DeLong <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [arin-ppml] Policy idea: POC Validation > Message-ID: > < > dm2pr03mb398c0786d9d0bc519e878649b...@dm2pr03mb398.namprd03.prod.outlook.com > > > > Content-Type: text/plain; charset="utf-8" > > 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:[email protected]] > > Sent: Tuesday, April 14, 2015 10:09 AM > > To: David Huberman > > Cc: [email protected] > > 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 > > <[email protected]> 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:[email protected]] > > >> Sent: Monday, April 13, 2015 1:30 PM > > >> To: David Huberman > > >> Cc: [email protected] > > >> 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 > > >> <[email protected]> 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: [email protected] > > >>>> [mailto:[email protected]] > > >>>> On Behalf Of Ted Mittelstaedt > > >>>> Sent: Monday, April 13, 2015 12:12 PM > > >>>> To: [email protected] > > >>>> 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 ([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. > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 15 Apr 2015 09:22:39 -0700 > From: Ted Mittelstaedt <[email protected]> > To: [email protected] > Subject: Re: [arin-ppml] Policy idea: POC Validation > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > I like this solution a lot! It will, of course, result in the > offending ISPs POCs being spammed to death by their own automated > systems which auto-fill the SWIPs with information they seem to pull > out of thin air. > > But sacrifices have to be made! > > Ted > > On 4/14/2015 11:08 AM, William Herrin wrote: > > On Mon, Apr 13, 2015 at 5:31 PM, Martin Hannigan<[email protected]> > wrote: > >> Did ARIN/you consider a consultation instead and simply adding a NACK > button > >> to the confirmation and reassigning the block back to the ISP in > question or > >> re designate to the online account owner? > > > > Hi Marty, > > > > That's a fantastic idea. But instead of deregistering the block (which > > would add chaos to the process for the right-org-wrong-POC case) do > > two things: > > > > 1. Feed the fact of the NACK back to the ISP with a message that the > > POC reports a registration mistake (requests contact for correction) > > and a gentle reminder that they are asked to publish accurate records > > as a condition of retaining allocations. Mistakes will be made. How > > will the folks who made the mistake find out if they don't get any > > feedback? > > > > 2. Use the data to build a stochastic model that separates routine > > bookkeeping error from orgs who are more on the negligence/fraud end > > of SWIP management. > > > > Regards, > > Bill Herrin > > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > [email protected] > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 118, Issue 19 > ****************************************** >
_______________________________________________ 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.
