<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Because of an off-list conversation I'd like to add I think the expectations of RFC2008 still exist in our policy manual today;</div><div dir="ltr"> </div><div dir="ltr"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>4.2.1.1. Purpose</div><div><br></div><div><span>ARIN</span> allocates blocks of IP addresses to ISPs for the purpose of reassigning and reallocating that space to <b>their customers.</b></div><div><br></div><div>4.2.3.3. Contiguous Blocks</div><div><br></div><div>IP addresses are allocated to ISPs in contiguous blocks, which should remain intact. Fragmentation of blocks is discouraged. To avoid fragmentation, <b>ISPs are encouraged to require their customers to return address space if they change ISPs.</b> <b>Therefore, if a customer moves to another service provider or otherwise terminates a contract with an ISP, it is recommended that the customer return the network addresses to the ISP and renumber into the new provider’s address space.</b> The original ISP should allow sufficient time for the renumbering process to be completed before requiring the address space to be returned.</div></blockquote><div dir="ltr"><div dir="ltr"><div dir="ltr"></div></div></div></div><div dir="ltr"><br></div><div>Now ARIN's ability to enforce this is very limited, since ISPs can make reassignments entirely by their own policy without any <span class="gmail-il">ARIN</span> review against NRPM today, we even eliminated ARIN review of large reassignments. So, I'm not sure a policy change is actually required, as there is noting ARIN can do about address leases absent connectivity when they are made as reassignments.</div><div><br></div><div>However, I think clarifying that leases without connectivity are valid and are documented with reassignments and reallocations might return some peace and quiet to PPML</div><div><br></div><div>Also maybe everything after the second sentence of 4.2.3.3 should be deleted as impractical in a post-free-pool world. That is "To avoid fragmentation..."</div><div><br></div><div>Thanks.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 1, 2019 at 4:02 PM Scott Leibrand <<a href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1 to everything David just said.<br><div><br></div><div>Do y'all have what you need to draft another version of this proposal tightening up the language to be consistent with this? Or does someone here need to propose text?</div><div><br></div><div>-Scott</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 1, 2019 at 1:32 PM David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 1, 2019 at 9:50 AM Scott Leibrand <<a href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Should we make 2019-18 clearly say that reallocation or reassignment to non-connected networks who will themselves make operational use of the leased addresses is considered efficient use? Basically, keep the “use” requirement around reassignments the same as it is now, and just state clearly that non-connected reassignments are ok?<br>
<br>
Scott<br></blockquote><div><br></div><div>I support language like this, but I do not support removal of the "use" requirement, someone has to be using the addresses, if not there is no basis for an assignment or allocation, or reassignment or reallocation.</div><div><br></div><div>Furthermore, RFC2008 introduced the address lending model, and this has been the primary model of acquiring address space for regular users ever since. RFC2008 does expects the relationship to be more than just for address space, it expects connectivity is being provided as well. Furthermore, that the address will be returned when the connectivity ceases. However, the reason for this is aggregation, if the user of the address space isn't connected then the provider can't aggregate.</div><div><br></div><div>However, in a world without a free-pool aggregation as a primary concern has effectively gone out the window. We are now routing ever smaller bits and pieces of address space, we have to, it's called recycling. Further, we have decided that routing policy is not ARIN or the other RIR's business, and aggregation is routing policy. Therefore address space as the only relationship between the leasor and leasee, while not ideal, it is impractical for this to be a policy violation any longer.</div><div><br></div><div>If I've been using address space for years and I want to change my provider and my provider is willing to allow me, probably for a fee, to keep using the address space they have loaned me for years, the facts on the ground today make it impractical for this to be a policy violation. Further, it that isn't a policy violation, then a new address only lease transaction shouldn't be either.</div><div><br></div><div>Guys we live is a post-free-pool world some ideas have to change with the facts on the ground. Address leasing absent connectivity is a fact of life in a post-free-pool world.</div><div>That doesn't mean I willing to give up on some kind of basic "use" requirement, again someone has to be using the addresses, if not there is no basis for an assignment or allocation, or a reassignment or reallocation either.</div><div><br></div><div>Thanks</div></div><div><br></div>-- <br><div dir="ltr">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div></div></div></div></div></div></div>