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= > [email protected]> > 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.
