+1 with Mr. Daniel, spot on. Best,
-M< On Tue, Nov 11, 2014 at 12:18 PM, Rudolph Daniel <[email protected]> wrote: > 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. > > Rudi Daniel > ICT consulting > 784 430 9235 > > On Nov 11, 2014 8:44 AM, <[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: 2014-19 and evidence of deployment (David Huberman) >> 2. Re: 2014-19 and evidence of deployment (Jason Schiller) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 11 Nov 2014 12:11:45 +0000 >> From: David Huberman <[email protected]> >> To: Jason Schiller <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> Message-ID: >> >> <b9f16d51e39048a298e57299ea51b...@dm2pr03mb398.namprd03.prod.outlook.com> >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> 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]<mailto:[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]> >> [mailto:[email protected]<mailto:[email protected]>] On >> Behalf Of Martin Hannigan >> Sent: Monday, November 10, 2014 8:55 PM >> To: John Santos >> Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected]<mailto:[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]<mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected]<mailto:[email protected]> if you experience any >> issues. >> >> >> >> -- >> _______________________________________________________ >> Jason >> Schiller|NetOps|[email protected]<mailto:[email protected]>|571-266-0006 >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.arin.net/pipermail/arin-ppml/attachments/20141111/9467d227/attachment-0001.html> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 11 Nov 2014 07:43:34 -0500 >> From: Jason Schiller <[email protected]> >> To: David Huberman <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment >> Message-ID: >> >> <CAC4yj2Xu1OB6HcGAuA6kekyG=9dp7hddqdzgktdbn5yd_zf...@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> 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 >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.arin.net/pipermail/arin-ppml/attachments/20141111/a537a2f2/attachment.html> >> >> ------------------------------ >> >> _______________________________________________ >> ARIN-PPML mailing list >> [email protected] >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> End of ARIN-PPML Digest, Vol 113, Issue 14 >> ****************************************** > > > _______________________________________________ > 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.
