[arin-ppml] ARIN-PPML Digest, Vol 118, Issue 19
Rudolph Daniel
rudi.daniel at gmail.com
Wed Apr 15 12:44:33 EDT 2015
Jimmy I would have to +1 David here; wholeheartedly Sir.
RD
On Apr 15, 2015 12:23 PM, <arin-ppml-request at arin.net> wrote:
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
>
> 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
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> 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 <David.Huberman at microsoft.com>
> To: Jimmy Hess <mysidia at gmail.com>
> Cc: "ARIN PPML \(ppml at arin.net\)" <ppml at arin.net>
> Subject: Re: [arin-ppml] Equality in address space assignment
> Message-ID:
> <
> DM2PR03MB398CF9A4E3D8DDC11B511ED9BE50 at 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:mysidia at gmail.com]
> > Sent: Tuesday, April 14, 2015 4:24 PM
> > To: David Huberman
> > Cc: ARIN PPML (ppml at arin.net)
> > Subject: Re: [arin-ppml] Equality in address space assignment
> >
> > On Tue, Apr 14, 2015 at 4:34 PM, David Huberman
> > <David.Huberman at microsoft.com> 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 <David.Huberman at microsoft.com>
> To: Owen DeLong <owen at delong.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Policy idea: POC Validation
> Message-ID:
> <
> DM2PR03MB398C0786D9D0BC519E878649BE50 at 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:owen at delong.com]
> > Sent: Tuesday, April 14, 2015 10:09 AM
> > To: David Huberman
> > Cc: arin-ppml at 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.Huberman at 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:owen at delong.com]
> > >> Sent: Monday, April 13, 2015 1:30 PM
> > >> To: David Huberman
> > >> Cc: arin-ppml at 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.Huberman at 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-bounces at arin.net
> > >>>> [mailto:arin-ppml-bounces at arin.net]
> > >>>> On Behalf Of Ted Mittelstaedt
> > >>>> Sent: Monday, April 13, 2015 12:12 PM
> > >>>> To: arin-ppml at 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 at arin.net).
> > >>>>> Unsubscribe or manage your mailing list subscription at:
> > >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > >>>>> Please contact info at 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 at arin.net).
> > >>>> Unsubscribe or manage your mailing list subscription at:
> > >>>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > >>>> Please contact info at 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 at arin.net).
> > >>> Unsubscribe or manage your mailing list subscription at:
> > >>> http://lists.arin.net/mailman/listinfo/arin-ppml
> > >>> Please contact info at arin.net if you experience any issues.
> > >
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 15 Apr 2015 09:22:39 -0700
> From: Ted Mittelstaedt <tedm at ipinc.net>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy idea: POC Validation
> Message-ID: <552E904F.7020909 at ipinc.net>
> 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<hannigan at gmail.com>
> 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
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 118, Issue 19
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150415/a10908ab/attachment.htm>
More information about the ARIN-PPML
mailing list