David, In the 06/2014 NRPM <https://www.arin.net/policy/archive/nrpm_20140626.pdf> we had exactly the current policy minus paragraph 7.
At that time, we had a policy experience report <https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf> where ARIN staff explained 4.5 has criteria for getting additional addresses for an existing MDN but no criteria for getting addresses for a new MDN. ARIN staff communicated that they were using only the Immediate Need 4.2.1.6 for allocations to new MDNs We needed 2014-18 to encourage ARIN to open up the criteria for NEW MDNs to include the minimum. I am suggesting further 2014-19 to extend it to also consider a 3 month supply if there is an applicable supporting 1 year use history. I suspect if we struck paragraph 7, ARIN would go back to their previous practice of only applying immediate need, and looking for connectivity agreements, and giving a /21 or enough to meet 30 day need. If you want to completely remove the proof of deployment, I think you would still need to keep the second half of paragraph 7... "7. When an organization declares they are adding a new discrete network site, the new networks shall be allocated: - the minimum allocation size under section 4.2.1.5 - more than the minimum allocation size if the organization can demonstrate additional need using the immediate need criteria (4.2.1.6) - a 3-month supply of address space may be requested if the new MDN can show an applicable demonstrated one-year utilization history." Is that in line with what you are proposing? I assume you would conclude that most organization that declare they have a new MDN are not committing fraud, and will be using the address within 3 months, and if not in 3 months or more, ARIN is free to reclaim (if they believe the organization is not working in good faith) under section 12. Is that about right? __Jason On Tue, Nov 11, 2014 at 7:11 AM, David Huberman < [email protected]> wrote: > J- > > What if paragraph 7 were struck entirely from existing 4.5 text? Wouldn't > that leave the staff able to issue blocks to new MDNs under the same rules > as everyone else in section 4, while at the same time removing the > documentation requirement? > > Thinking out loud. > > David R Huberman > Microsoft Corporation > Principal, Global IP Addressing > ------------------------------ > *From:* Jason Schiller <[email protected]> > *Sent:* Tuesday, November 11, 2014 3:46:18 AM > *To:* David Huberman > *Cc:* Martin Hannigan; John Santos; [email protected] > > *Subject:* Re: [arin-ppml] 2014-19 and evidence of deployment > > While I appreciate this discussion, I believe there is a real need to > change policy. > > Previously a new MDN could only qualify under and get an initial > allocation sized block. > > This was extended to include more than the initial allocation sized > block under immediate need. > > I believe there is another case (besides immediate need) where more than > the initial allocation sized block is justified. That is when there is a > demonstrated past 1 year growth history that supports a future looking 3 > month growth of a new MDN. Such is the case when an existing MDN is > split. Hence 2014-19. > > I don't want to get hung up on the proof of deployment text that already > exists. > > Those of you that think this should be changed, please provide suitable > text, and we can run the two policy proposals in parallel. > > If you think this is unnecessary tinkering, then I would expect we will > not rat hole on the pre-existing "proof of deployment" text when discussion > 2014-19 as we did in the previous meeting. > > Thank you. > > > __Jason > > > On Tue, Nov 11, 2014 at 12:08 AM, David Huberman < > [email protected]> wrote: > >> In my world view, policy should never assume the requestor is lying. The >> same should hold true for ARIN staff. >> >> No one ever mandated ARIN with stopping the scammers. I believe it was >> Rob Seastrom who posted here a long time ago and basically said that ARIN >> staff are entrusted to do the best job they can in running the registry, >> but the community shouldn't have expectations that ARIN staff can figure >> out who's lying and who's not. >> >> But because ARIN got burned by large-scale hijacking in the early 2000s, >> it has operated under "trust but verify" ever since. And this fosters the >> antagonism towards the registry which I think is wholly avoidable. "Trust >> but verify" is a bad way to run an RIR, in my experience. >> >> I hope we can focus on policy language which always assumes a request is >> bona fide, and let's stop worrying about the 1% of requestors who are >> lying. That way, network engineers can spend less time dealing with ARIN, >> and more time running their networks. >> >> David R Huberman >> Microsoft Corporation >> Principal, Global IP Addressing >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Martin Hannigan >> Sent: Monday, November 10, 2014 8:55 PM >> To: John Santos >> Cc: [email protected] >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> >> On Mon, Nov 10, 2014 at 6:17 PM, John Santos <[email protected]> wrote: >> > On Mon, 10 Nov 2014, Martin Hannigan wrote: >> > >> >> > >> >> > "7. Upon verification that the organization has shown evidence of >> >> > deployment of the new discrete network site, [such as, but not >> >> > limited to the >> >> > following: a network design showing existing and new discreet >> >> > networks and supporting documentation that the proposed design in >> >> > in progress such as contracts for new space or power, new equipment >> >> > orders, publicly available marketing material describing the >> >> > offering in a new location, or some other significant capital >> >> > investment in the project,] the new networks shall be >> >> > allocated: >> >> > >> >> >> >> Let's go back to the original point I made in the last two PPC and >> >> ARIN meetings. How can a company contract for real estate, energy or >> >> network without knowing if they had IP addresses to operate their >> >> business (in this current environment of v4 scarcity and policy >> >> wonkery?)? >> > >> > Any company with a business plan is taking risks and has to have a >> > fall back plan (even if the plan is "pack it in") for any conceivable >> > eventuality. You want ARIN to guarantee that they can get IPv4 before >> > they've found a site, bought any equipment, signed any contracts with >> > suppliers or customers, or even made any public announcements of their >> > plans to establish a new site? >> >> Let me get this straight. So one should have a business plans that >> accounts for spending money that may not actually get to generate any >> revenue? ARIN has been assigning addresses without this requirement for a >> decade plus. The ability to forward look (guarantee) has been shrunk and >> now ARIN is targeting MDN for discriminatory policies and removing any >> ability to forward look, a normal practice in "business". >> The risk of not getting addresses because ARIN is using clueless >> requirements is very high, not average. This isn't a simple excercise of >> "win some lose some". There are real dollars at stake (whether you operate >> a single rack or 1000 racks regardless of how much "power" you >> use) and real risks. >> >> This proposal is best summed up as 'wasteful tinkering'. >> >> Best, >> >> -M< >> _______________________________________________ >> 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 > > -- _______________________________________________________ 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.
