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