<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 29, 2011, at 7:14 PM, Brett Frankenberger wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Sun, May 29, 2011 at 02:43:11PM -0700, Owen DeLong wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">On May 29, 2011, at 12:15 PM, Brett Frankenberger wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On Sun, May 29, 2011 at 10:39:23AM -0700, Owen DeLong wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I actually do think that Bill's language might be closer to community intent.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I was trying to do the minimal surgical language change, but, I would like<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">to get feedback from the community as to which language they think is<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">preferable.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">So an organization with a largely unused legacy /8 would be limited to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">one transfer per year? (Even though, after transferring one /16, they<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">would be able to, for example, transfer another /16 (i.e. the /16<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">adjacent to the one they first transferred) without causing any further<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">deaggregation?)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">No... They would not be limited. The limitation being expressed would<br></blockquote><blockquote type="cite">be on the recipients, not the supplier. So, for example, an organization<br></blockquote><blockquote type="cite">that needed a /14 and wanted to get it from the organization with a<br></blockquote><blockquote type="cite">largely unused legacy /8 would need to get a /14 from them, or take<br></blockquote><blockquote type="cite">4 years to transfer it in /16 sized chunks that were not contiguous. What<br></blockquote><blockquote type="cite">would not be allowed would be to satisfy their need for a /14 by carving<br></blockquote><blockquote type="cite">up the /18 into 4 separate /16 sized chunks (or an even larger number<br></blockquote><blockquote type="cite">of even smaller chunks).<br></blockquote><br>Now I'm confused . The language below says "No organization shall<br>offer ... more than one address block per year where said address block<br>is smaller than its original registered size". <br><br></div></blockquote><div><br></div>You are correct. I missed that in the original and would probably remove</div><div>it from what I actually would include in the policy.</div><div><br></div><div><blockquote type="cite"><div>So Organization A with a lightly used /8 offers a /16 to Organization B<br>(which has justified it's need for a /16) and the transfer is<br>completed. The transferred /16 is smaller than the original registered<br>size (the /8), of course.<br><br>Now Organization A wants to transfer another /16 from the same /8 to<br>Organization C (which has justified need for a /16). That /16, of<br>course, is smaller than the originally registered /8 from which it<br>came. How is that transfer going to be allowed (assuming less than one<br>year has elapsed) -- they're offering a second address block that is<br>smaller than its originally registered size?<br><br></div></blockquote>What I would think makes more sense as policy would be:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><div>Organizations may transfer multiple address blocks but</div></div></div><div><div><div>no organization shall receive more than one address block</div><div>per year where said address block is smaller</div></div></div><div><div><div>than its original registered size.</div></div></div></blockquote><div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"></blockquote></blockquote></blockquote></blockquote></div></blockquote><blockquote type="cite"><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"></blockquote></blockquote></blockquote></blockquote></div></blockquote></blockquote><span></span><div><br></div>I believe that accomplishes the intent without undue restrictions on the</div><div>suppliers.</div><div><br><blockquote type="cite"><div>Moreover, in subsequent posts, Matthew Kaufman asked:<br> Org A getting the even-numbered /24 from a /8 and Org B getting the<br> odd-numbered /24 from a /8 is just as bad as Org 1 - Org 65536 each<br> getting one /24 from a /8.<br>and you replied:<br> Which would not be allowed by the proposed policy in either case.<br><br></div></blockquote>Either case meant Bill's or my original language.</div><div><br><blockquote type="cite"><div>So assuming "the proposed policy" means Bill's language (which I've<br>left below), you seem to now be saying that an Org with a legacy /8<br>can't carve it up into numerous blocks and transfer one block each to<br>each of several different organizations.<br><br></div></blockquote>No, the point is that you can carve up to numerous different organizations</div><div>(see modification above), but, cannot carve up into numerous different</div><div>chunks to the same recipient.</div><div><br><blockquote type="cite"><div>Right after stating, in response to me (see above) that it would not be<br>limited.<br><br>What am I missing?<br><br></div></blockquote><div><br></div>You didn't miss anything. I misread Bill's language the first time through</div><div>and your diligence caused me to re-examine it and propose a corrected</div><div>version above. Does that seem to do what you think is right?</div><div><br></div><div>Owen</div><div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On May 29, 2011, at 6:53 AM, William Herrin wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">If you want to get close to the original intent, try something along<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the lines of, "Organizations may transfer multiple address blocks but<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">no organization shall offer nor shall any organization receive more<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">than one address block per year where said address block is smaller<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">than its original registered size."<br></blockquote></blockquote></blockquote></blockquote><br> -- Brett<br></div></blockquote></div><br></body></html>