[arin-ppml] ARIN-Prop 153

Sun May 29 16:27:46 EDT 2011

My opinion is that Bill Herrin's  effort seems closer to the current ARIN
policy...however I do not really support the proposal right now.

rd

On May 29, 2011, at 6:53 AM, William Herrin wrote:
>
> > On Fri, May 27, 2011 at 9:31 AM, ARIN <info at arin.net> wrote:
> >> ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
> >>
> >> Such transferred number resources may only be
> >> received under RSA as a single aggregate, in the exact amount which they
> >> can justify under current ARIN policies by organizations that are within
> >> the ARIN region.
>
> > If you want to get close to the original intent, try something along
> > the lines of, "Organizations may transfer multiple address blocks but
> > no organization shall offer nor shall any organization receive more
> > than one address block per year where said address block is smaller
> > than its original registered size."
> >
> > Regards,
> > Bill Herrin
> >
> >
> >
> > --
> > William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> > Falls Church, VA 22042-3004
> > _______________________________________________
> > 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.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 29 May 2011 14:15:06 -0500
> From: Brett Frankenberger <rbf+arin-ppml at panix.com>
> To: Owen DeLong <owen at delong.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in
>        NRPM 8.3
> Message-ID: <20110529191506.GA28505 at panix.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote:
> > I actually do think that Bill's language might be closer to community
> intent.
> > I was trying to do the minimal surgical language change, but, I would
> like
> > to get feedback from the community as to which language they think is
> > preferable.
>
> So an organization with a largely unused legacy /8 would be limited to
> one transfer per year?  (Even though, after transferring one /16, they
> would be able to, for example, transfer another /16 (i.e. the /16
> adjacent to the one they first transferred) without causing any further
> deaggregation?)
>
> > On May 29, 2011, at 6:53 AM, William Herrin wrote:
> >
> > > If you want to get close to the original intent, try something along
> > > the lines of, "Organizations may transfer multiple address blocks but
> > > no organization shall offer nor shall any organization receive more
> > > than one address block per year where said address block is smaller
> > > than its original registered size."
>
>     -- Brett
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 29 May 2011 13:03:39 -0700
> From: Matthew Kaufman <matthew at matthew.at>
> To: Owen DeLong <owen at delong.com>
> Cc: John Curran <jcurran at arin.net>,     "arin-ppml at arin.net List"
>        <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in
>        NRPM 8.3
> Message-ID: <4DE2A69B.9010309 at matthew.at>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 5/28/2011 12:13 PM, Owen DeLong wrote:
> > On May 28, 2011, at 7:47 AM, John Curran wrote:
> >
> >> To answer your question we would first need to know how to handle the
> >> transfer of a smaller block than the party actually qualifies for, and
> >> whether it is as a circumvention of policy.  For example: a party (X),
> >> needing a /15 for 12 months growth, will get told by ARIN that they
> >> will actually only receive a /17 (because we're only providing space
> >> to meet 3 months of need).  If X instead opts to get space from party
> >> (Y), who is is willing to transfer their /16 to X, does ARIN approve
> >> the transfer fully knowing that it is not an exact match but is actually
> >> less then X's documented need?  Or do we tell X that they need to find
> >> a willing party Z who has two contiguous /16's available in order to
> >> meet X's *exact* need?
> >>
> > The intent of the policy would be that ARIN would decline the particular
> > transfer due to mismatch and could reiterate the need to find a /15
> > or blocks which can be assembled into a /15 (contiguous bit-aligned
> > /16s would qualify, disjoint or non-bit-aligned /16s would not, but
> > 8 contiguous bit-aligned /18s would also qualify, for example).
> >
>
> Ok, now I absolutely, positively, oppose this policy as being as huge
> distorting force on any possible transfer market *and* forcing either
> unregistered transfers or legal action or more.
>
> Consider the following case:
>
> Organization A is in immediate need of a /19 of space in order to
> continue their operations through the IPv6 transition. They've gone
> ahead and had ARIN sign off on this need, because they don't want any
> delays if and when a /19 comes up in the market. But if they can't get
> at least one or two /24s in the next few weeks, they're going to start
> losing customers.
>
> But the market has been really tight the last few weeks or months, and
> only some /24s have been up recently... certainly no /19s. They find a
> seller with a /24, and decide they must act now.
>
> Do they:
> A) Go back to ARIN and explain how the /19 of need magically evaporated,
> send in paperwork to justify the /24, transfer it, knowing they'll be
> locked out of getting the additional space they need for some time.
>
> B) Wait for a /19 to become available
>
> C) Transfer the /24 but don't tell ARIN, so their /19 of need is still
> in the system
>
> A few weeks later, a /19 does become available and they can afford it.
>
> If they chose (A) above, do they:
>
> 1) Purchase the /19 but delay filing the transfer with ARIN
>
> 2) Purchase the /19 but never file the transfer with ARIN
>
> 3) Engage in a lease of the /19 and never tell ARIN
>
> 4) Sue ARIN to force recognition of both transfers
>
> 5) Simply pass up the opportunity to get the space they need
>
> If they chose (B) above, do they:
>
> 6) purchase the /19 and register the transfer with ARIN
>
> 7) not act, because not having the /24 in the meantime has cost them
> their business
>
> If they chose (C) above, do they:
>
> 8) Purchase the /19 and register the transfer with ARIN
>
> 9) Purchase the /19 and not register the transfer, in case they need
> more space in the allotted time interval?
>
>
> >> If we do approve the /16 transfer to X, then a subsequent request for
> >> a transfer to meet their residual need is both quite likely and would
> >> not be circumvention of policy.  If we reject the transfer due to being
> >> smaller than the documented need, then the "end-run" described above
> >> cannot occur.
> >>
> >> Which interpretation best matches your policy intent?
> >>
> > Rejecting the transfer and, as I expected, said end-run would be blocked
> > by ARIN.
>
>
> Unacceptable answer to the point of being ridiculous. Clearly the
> "residual need" might be much much larger than the initial transfer (see
> the case above)
>
> Matthew Kaufman
>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 29 May 2011 13:09:20 -0700
> From: Matthew Kaufman <matthew at matthew.at>
> To: Brett Frankenberger <rbf+arin-ppml at panix.com>
> Cc: "arin-ppml at arin.net List" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in
>        NRPM 8.3
> Message-ID: <4DE2A7F0.1080004 at matthew.at>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 5/28/2011 9:36 AM, Brett Frankenberger wrote:
> > On Sat, May 28, 2011 at 01:25:20AM +0200, Matthew Kaufman wrote:
> >> On May 28, 2011, at 1:09 AM, Owen DeLong wrote:
> >>
> >>> Given the time ARIN takes to evaluate and turn around a request, I
> don't think that's actually true. I also
> >>> trust that staff would become suspicious and investigate such
> situations appropriately as well.
> >> What's "suspicious" about it? I tell ARIN "look, I need 660,000
> >> addresses... I found someone with that many, but they're in a bunch
> >> of different blocks. Over the next few hours you'll be getting a
> >> bunch of transfer request forms with associated justification"
> >>
> >> "Here's my justification that I need 660,000 addresses... which of
> >> course also justifies the 65536 for this /16"
> > So they transfer the /16.
> >
> >> "Here's my justification that I still need over 594k addresses...
> >> which of course is sufficient to justify the 131072 for this /15"
> > Except that need over the next 12 months is not the only criteria.
> > Efficient utilization of all previous allocations is also a
> > requirement.
> >
> > Assuming the /16 that they just got (with the first transfer) hasn't
> > yet been actually used, this transfer would be rejected under NRPM
> > 4.2.4.1 (unless their need is so immediate that they are able to
> > immediately utilize 80% of that first /16).
>
> Lets assume that their need is so immediate that they can immediately
> use 80% of the first /16. Or immediately enough... they can simply write
> the purchase contract to allow the transfers to be spread out over just
> enough time to achieve this (even the Nortel-Microsoft deal is written
> with subsequent transfer language)
>
> > If we assume their rate of usage is constant over the one year
> > justification period, then they need around one /16 per 1.2 months, so
> > we'd expect it to take about a month to utilize the the first /16 to
> > the 80% threshold and be eligible to request more space.
>
> Maybe this long, even so it doesn't matter (see above)
>
> > Of course, this might not be an issue.  The transfer agreement between
> > the two parties might specify payment for all 660K addresses up front,
> > and require the seller to then transfer them to the purchaser, one
> > aggregate at a time, as requested by the purchaser and approved by
> > ARIN.
>
> Exactly. For all we know this has *already happened* for some huge
> amount of the address space, and we just haven't seen the transfers
> trickle through yet.
>
> Of course if the seller doesn't really need the space, there's not much
> preventing the buyer from starting to use it before the transfers are
> approved... which just reduces the accuracy of the whois database.
>
> >
> > If "one aggregate" really is what we want, I don't see how to get there
> > except limiting recipients to one transfer per some period of time.
>
> Right, which is unfair to a recipient who thinks they can only find /24s
> but then next week finds some /16s on the market that are what they
> really needed, only they took one of the /24s in desperation.
>
> Matthew Kaufman
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 29 May 2011 13:10:28 -0700
> From: Matthew Kaufman <matthew at matthew.at>
> To: John Curran <jcurran at arin.net>
> Cc: "arin-ppml at arin.net List" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in
>        NRPM 8.3
> Message-ID: <4DE2A834.30302 at matthew.at>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 5/28/2011 1:20 PM, John Curran wrote:
> >
> > The exact match constraint will obviously make finding acceptable address
> > space much more difficult, due to the need to find not just any available
> > space up to the documented need, but instead require finding a party
> which
> > has the exact amount of space available and as a contiguous block.
> >
>
> Agreed. I suppose if Owen's intent here is to allow transfers but break
> the market so badly that they can't actually happen (and hope that
> nobody just does them without notifying ARIN), this might succeed.
>
> Matthew Kaufman
>
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 29 May 2011 16:12:17 -0400
> From: Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
> To: matthew at matthew.at
> Cc: John Curran <jcurran at arin.net>,     "arin-ppml at arin.net List"
>        <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in
>        NRPM 8.3
> Message-ID: <BANLkTik-2tZa0sOD8g5kCW7_Y4tXp0bf_g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, May 29, 2011 at 4:03 PM, Matthew Kaufman <matthew at matthew.at>
> wrote:
> > On 5/28/2011 12:13 PM, Owen DeLong wrote:
> >>
> >> On May 28, 2011, at 7:47 AM, John Curran wrote:
> >>
> >>> To answer your question we would first need to know how to handle the
> >>> transfer of a smaller block than the party actually qualifies for, and
> >>> whether it is as a circumvention of policy. ?For example: a party (X),
> >>> needing a /15 for 12 months growth, will get told by ARIN that they
> >>> will actually only receive a /17 (because we're only providing space
> >>> to meet 3 months of need). ?If X instead opts to get space from party
> >>> (Y), who is is willing to transfer their /16 to X, does ARIN approve
> >>> the transfer fully knowing that it is not an exact match but is
> actually
> >>> less then X's documented need? ?Or do we tell X that they need to find
> >>> a willing party Z who has two contiguous /16's available in order to
> >>> meet X's *exact* need?
> >>>
> >> The intent of the policy would be that ARIN would decline the particular
> >> transfer due to mismatch and could reiterate the need to find a /15
> >> or blocks which can be assembled into a /15 (contiguous bit-aligned
> >> /16s would qualify, disjoint or non-bit-aligned /16s would not, but
> >> 8 contiguous bit-aligned /18s would also qualify, for example).
> >>
> >
> > Ok, now I absolutely, positively, oppose this policy as being as huge
> > distorting force on any possible transfer market *and* forcing either
> > unregistered transfers or legal action or more.
> >
> > Consider the following case:
> >
> > Organization A is in immediate need of a /19 of space in order to
> continue
> > their operations through the IPv6 transition. They've gone ahead and had
> > ARIN sign off on this need, because they don't want any delays if and
> when a
> > /19 comes up in the market. But if they can't get at least one or two
> /24s
> > in the next few weeks, they're going to start losing customers.
> >
> > But the market has been really tight the last few weeks or months, and
> only
> > some /24s have been up recently... certainly no /19s. They find a seller
> > with a /24, and decide they must act now.
> >
> > Do they:
> > A) Go back to ARIN and explain how the /19 of need magically evaporated,
> > send in paperwork to justify the /24, transfer it, knowing they'll be
> locked
> > out of getting the additional space they need for some time.
> >
> > B) Wait for a /19 to become available
> >
> > C) Transfer the /24 but don't tell ARIN, so their /19 of need is still in
> > the system
> >
> > A few weeks later, a /19 does become available and they can afford it.
> >
> > If they chose (A) above, do they:
> >
> > 1) Purchase the /19 but delay filing the transfer with ARIN
> >
> > 2) Purchase the /19 but never file the transfer with ARIN
> >
> > 3) Engage in a lease of the /19 and never tell ARIN
> >
> > 4) Sue ARIN to force recognition of both transfers
> >
> > 5) Simply pass up the opportunity to get the space they need
> >
> > If they chose (B) above, do they:
> >
> > 6) purchase the /19 and register the transfer with ARIN
> >
> > 7) not act, because not having the /24 in the meantime has cost them
> their
> > business
> >
> > If they chose (C) above, do they:
> >
> > 8) Purchase the /19 and register the transfer with ARIN
> >
> > 9) Purchase the /19 and not register the transfer, in case they need more
> > space in the allotted time interval?
> >
> >
> >>> If we do approve the /16 transfer to X, then a subsequent request for
> >>> a transfer to meet their residual need is both quite likely and would
> >>> not be circumvention of policy. ?If we reject the transfer due to being
> >>> smaller than the documented need, then the "end-run" described above
> >>> cannot occur.
> >>>
> >>> Which interpretation best matches your policy intent?
> >>>
> >> Rejecting the transfer and, as I expected, said end-run would be blocked
> >> by ARIN.
> >
> >
> > Unacceptable answer to the point of being ridiculous. Clearly the
> "residual
> > need" might be much much larger than the initial transfer (see the case
> > above)
> >
> > Matthew Kaufman
> > _______________________________________________
> > 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.
> >
>
> Good points all around. With that said, I oppose ARIN-prop-153.
>
> --
> Jeffrey Lyon, Leadership Team
> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net
> Black Lotus Communications - AS32421
> First and Leading in DDoS Protection Solutions
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 71, Issue 245
> ******************************************
>

-- 

Rudi Daniel
*danielcharles consulting<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>
**1-784 498 8277<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>
*
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110529/7582defa/attachment.htm>