[arin-ppml] 2914-19

Tue Nov 11 12:18:50 EST 2014

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
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20141111/afcdb980/attachment.htm>