[arin-ppml] 2914-19

Tue Nov 11 12:23:17 EST 2014

+1 with Mr. Daniel, spot on.

Best,

-M<


On Tue, Nov 11, 2014 at 12:18 PM, Rudolph Daniel <rudi.daniel at gmail.com> 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, <arin-ppml-request at arin.net> wrote:
>>
>> Send ARIN-PPML mailing list submissions to
>>         arin-ppml at arin.net
>>
>> 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
>>         arin-ppml-request at arin.net
>>
>> You can reach the person managing the list at
>>         arin-ppml-owner at arin.net
>>
>> 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 <David.Huberman at microsoft.com>
>> To: Jason Schiller <jschiller at google.com>
>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment
>> Message-ID:
>>
>> <b9f16d51e39048a298e57299ea51bc4b at 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 <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<mailto: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>
>> [mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:info at arin.net> if you experience any
>> issues.
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason
>> Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|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 <jschiller at google.com>
>> To: David Huberman <David.Huberman at microsoft.com>
>> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] 2014-19 and evidence of deployment
>> Message-ID:
>>
>> <CAC4yj2Xu1OB6HcGAuA6kekyG=9dp7hDdqdZgKTDBN5Yd_zF4TQ at 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 <
>> 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:
>> <http://lists.arin.net/pipermail/arin-ppml/attachments/20141111/a537a2f2/attachment.html>
>>
>> ------------------------------
>>
>> _______________________________________________
>> ARIN-PPML mailing list
>> ARIN-PPML at arin.net
>> 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 (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.