[arin-ppml] 2014-19 and evidence of deployment

Tue Nov 11 07:43:34 EST 2014

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 <
David.Huberman at microsoft.com> 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 <jschiller at google.com>
> *Sent:* Tuesday, November 11, 2014 3:46:18 AM
> *To:* David Huberman
> *Cc:* Martin Hannigan; John Santos; arin-ppml at arin.net
>
> *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 <
> David.Huberman at microsoft.com> 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: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Martin Hannigan
>> Sent: Monday, November 10, 2014 8:55 PM
>> To: John Santos
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment
>>
>> On Mon, Nov 10, 2014 at 6:17 PM, John Santos <JOHN at egh.com> 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 (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.
>>
>
>
>
>  --
>  _______________________________________________________
>  Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20141111/a537a2f2/attachment.htm>