<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 1, 2011, at 10:44 AM, Stephen Sprunk wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 01-May-11 11:05, Owen DeLong wrote:<br><blockquote type="cite">On Apr 30, 2011, at 17:13, Stephen Sprunk <<a href="mailto:stephen@sprunk.org">stephen@sprunk.org</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">On 30-Apr-11 10:40, Owen DeLong wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Apr 30, 2011, at 8:29 AM, Matthew Kaufman wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">And then once you've justified 980 addresses to ARIN, you should clearly be able to use 8.3 transfers twice in a row, for two separate /23s... it wouldn't make much sense for ARIN to require you to resubmit all the justification paperwork you just sent them a few hours ago, would it?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Again, I disagree. The intent of this phrase was to reduce the amount of disaggregation of the routing table that will be caused by transfers. Allowing this revolving door use of the transfer policy will increase disaggregation.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Imagine you qualify to receive a /23 but there are no /23s available on the market. AIUI, the policy's intent was to prohibit you buying half of someone else's /22. However, is there any harm in ARIN fulfilling your request with my two disjoint /24s in that scenario? Keep in mind you could get my /24s (or one from me and one from someone else) anyway via two separate transfer requests.<br></blockquote></blockquote><blockquote type="cite">No, that intent went out the window early in the debate. It was replaced with an intent to prevent you from creating a /18 equivalent out of disparate /24 sized chunks of someone else's /8.<br></blockquote><br>Hmm. I was concerned about the latter as well, but I didn't realize we<br>had agreed to allow deaggregation in the first place. That makes things<br>easier.<br><br><blockquote type="cite"><blockquote type="cite">This interpretation, which could be creatively read into the policy text, could easily explain the statistics recently posted and, IMHO, doesn't violate the policy's intent or goals.<br></blockquote></blockquote><blockquote type="cite">While I would be fine with ARIN fulfilling your request with 2 /24s that were already disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc.<br></blockquote><br>How about this:<br><br>"The transferor's resources may be recursively bisected the minimum<br>number of times necessary to create one CIDR block equal to the<br>transferee's justified need."<br><br>So, if someone with a /8 wants to sell you a /20, their /8 would be<br>divided into one /9, one /10, one /11, one /12, one /13, one /14, one<br>/15, one /16, one /17, one /18, one /19 and two /20s, and then you would<br>get one of those /20s.<br><br></div></blockquote>I believe that would be acceptable, but I would need to know how staff</div><div>would interpret the language and some assurance that said statement</div><div>of interpretation would be binding. (Would staff interpretation of</div><div>the former paragraph match the example in the latter?) How would</div><div>it perform against the examples I posted a few moments ago?</div><div><br></div><div>(Since we thought we understood how staff would interpret 8.3 at</div><div>the time and it turned out not to work as we thought).</div><div><br><blockquote type="cite"><div>If you agree with that, I'll figure out how to shoehorn it into the<br>existing text of NRPM 8.3, though I'd prefer a complete restructuring.<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote>This intrigues me. Please elaborate on your desired restructuring?</div><div><br><blockquote type="cite"><div>I also see several ugly possibilities when the transferor has multiple<br>blocks of different sizes available to sell, but I'd need to see<br>examples of how you'd want those handled before I could address them (no<br>pun intended). However, assuming that aggregation has inherent value to<br>buyers, sellers will avoid them out of self-interest, so we may not need<br>to put anything into policy. Is anyone seriously concerned that<br>assumption is wrong?<br><br></div></blockquote>I posted some examples a few minutes ago. Hopefully those will</div><div>help. Let me know if you ned something else.</div><div><br></div><div>I am very concerned that your assumption about the value of aggregation</div><div>to buyers is wrong.</div><div><br></div><div>Owen</div><div><br></div></body></html>