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