<div dir="ltr"><div dir="ltr">So working on this a bit more, I suggest the following policy text;<div><br></div><div><div dir="ltr">Add to the end of section 2.4;<br><br>LIRs may also assign address space to other organizations or customers that request it for use in operational networks.<br><br>Change section 8.5.2 as follows;<br><br>ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use in operational networks.<br><br>Delete all but the first two sentences of 4.2.3.3, leaving;<br><br>4.2.3.3. Contiguous Blocks<br><br>IP addresses are allocated to ISPs in contiguous blocks, which should remain intact. Fragmentation of blocks is discouraged</div><div dir="ltr"><br></div><div>This text makes an editorial change to the text to be added to 2.4, restores the original text of 8.5.2, making an editorial change to it that is consistent with the editorial change made the new 2.4 and delete most of 4.2.3.3 as that text is impractical given today realities. The editorial changes remove the possible implication that use is required in any particular operational network, such as the LIR's or the providers network.</div><div><br></div><div>Thanks</div><div dir="ltr"><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 1, 2019 at 5:13 PM David Farmer <<a href="mailto:farmer@umn.edu">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"><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>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>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">===============================================<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>