<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div style="font-family: MarkerFelt-Thin; font-size: 32px; line-height: 42px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(130, 98, 83, 0.0976563); -webkit-composition-frame-color: rgba(191, 107, 82, 0.496094); "><br></div><div style="font-family: MarkerFelt-Thin; font-size: 32px; line-height: 42px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(130, 98, 83, 0.0976563); -webkit-composition-frame-color: rgba(191, 107, 82, 0.496094); "><div>Good afternoon, pardon me, I've been a little under the weather; if someone could clarify for me; am I correct in understanding that some ARIN protocol</div><div>is being re-drafted? If so, long overdue, and much needed. </div><div> While this proposal appears to focus on </div><div>IPv6 block protocol, Mr. Ross sufficiently </div><div>inculcates that even though some organizations will have multiple IPv6 blocks, obtained through subsequent allocations or assignments where an existing block could not be adequately expanded or competently managed; </div><div> It is my belief these situations occur already. Even with IPv6 in place, many hosts are finding difficulty protecting their servers and clients because even hackers have found ways to infiltrate the IPv6 system. </div><div> In re-establishing draft protocol, I hope we can work out a system of checks and balances, and accountability for such cybercrimes.</div><div> Additionally, Those registrants with so many IPs? If an audit were done, how many of those IP's are truly theirs by legal acquisition? </div><div> We are ARIN. Therefore, it's our jobs to ensure safety on the Internet. I personally know of several IP hosts who have violated intellectual genre, and (c) laws, having taken over people's Domains after providing service. There are other people out here who's entire IPv6 networks get hacked. People have related stories of losing information off of all their computers, mainframe, and all software licenses.</div><div> Sirs, will any of the new protocol protect innocent everyday people, making the Internet safe for everyone, and not just those of us with technical knowledge?</div><div> I would very much appreciate an opportunity to work with your team if I can be of assistance.</div><div><br></div><div>Namaste,</div><div><i>Rev Rachelle C.Navarro</i></div><div>PhD, MS</div></div><span></span><br><span></span><br><span></span><br><span></span><br><span></span><br><span></span><br><span></span><br><span>On Apr 3, 2013, at 0:11, <a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a> wrote:</span><br><span></span><br><blockquote type="cite"><span>Send ARIN-PPML mailing list submissions to</span><br></blockquote><blockquote type="cite"><span> <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>To subscribe or unsubscribe via the World Wide Web, visit</span><br></blockquote><blockquote type="cite"><span> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br></blockquote><blockquote type="cite"><span>or, via email, send a message with subject or body 'help' to</span><br></blockquote><blockquote type="cite"><span> <a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>You can reach the person managing the list at</span><br></blockquote><blockquote type="cite"><span> <a href="mailto:arin-ppml-owner@arin.net">arin-ppml-owner@arin.net</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>When replying, please edit your Subject line so it is more specific</span><br></blockquote><blockquote type="cite"><span>than "Re: Contents of ARIN-PPML digest..."</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Today's Topics:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> 1. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs</span><br></blockquote><blockquote type="cite"><span> (David Farmer)</span><br></blockquote><blockquote type="cite"><span> 2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs</span><br></blockquote><blockquote type="cite"><span> (Owen DeLong)</span><br></blockquote><blockquote type="cite"><span> 3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs</span><br></blockquote><blockquote type="cite"><span> (David Farmer)</span><br></blockquote><blockquote type="cite"><span> 4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs</span><br></blockquote><blockquote type="cite"><span> (Owen DeLong)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>----------------------------------------------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Message: 1</span><br></blockquote><blockquote type="cite"><span>Date: Tue, 02 Apr 2013 18:24:30 -0500</span><br></blockquote><blockquote type="cite"><span>From: David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>></span><br></blockquote><blockquote type="cite"><span>To: Brandon Ross <<a href="mailto:bross@pobox.com">bross@pobox.com</a>></span><br></blockquote><blockquote type="cite"><span>Cc: John Curran <<a href="mailto:jcurran@arin.net">jcurran@arin.net</a>>, ARIN PPML <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>></span><br></blockquote><blockquote type="cite"><span>Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6</span><br></blockquote><blockquote type="cite"><span> Allocations for ISPs</span><br></blockquote><blockquote type="cite"><span>Message-ID: <<a href="mailto:515B68AE.4080906@umn.edu">515B68AE.4080906@umn.edu</a>></span><br></blockquote><blockquote type="cite"><span>Content-Type: text/plain; charset=ISO-8859-1; format=flowed</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On 3/30/13 18:06 , Brandon Ross wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Fri, 29 Mar 2013, David Farmer wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>After thinking about it for a while, if we even need any policy at</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>all, we should just have a general policy describing how IPv6 block</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>can be reduced by returning only part of a block, it should probably</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>be very generic and apply to allocations and end user assignments. It</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>might even be better if it we a separate proposal all together.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Agreed, which is why the language in this proposal allows for that, and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>that was done on purpose.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I don't want to see that separated to a separate policy proposal because</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>it is critical to making this one function as intended.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Well, yes and no, John has already fix the operational issue, the only </span><br></blockquote><blockquote type="cite"><span>effect your proposed text would have at the moment would be to restrict </span><br></blockquote><blockquote type="cite"><span>it to the first or last blocks of the larger original block.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This raise a question for me do we really need to restrict it to the </span><br></blockquote><blockquote type="cite"><span>first or last blocks? Personal, I'm ok with allowing the person making </span><br></blockquote><blockquote type="cite"><span>the return to have the flexibility to make choice of any contiguous and </span><br></blockquote><blockquote type="cite"><span>alined /40 out of the /32 they want.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Next, I'm thinking about a new subsection;</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> 6.12 Reduction or Return</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Organizations may return all or part of their allocations or</span><br></blockquote><blockquote type="cite"><span> assignments, that are not in use, to ARIN at any time with the</span><br></blockquote><blockquote type="cite"><span> following considerations;</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> a. Such a return or reduction must not result in a larger number of</span><br></blockquote><blockquote type="cite"><span> blocks being held by an organization, if possible fewer blocks</span><br></blockquote><blockquote type="cite"><span> are preferred.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> b. If a whole block is not in use, the whole block should be</span><br></blockquote><blockquote type="cite"><span> returned to ARIN.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> c. If part of a block is returned; A single contiguous nibble</span><br></blockquote><blockquote type="cite"><span> alined block, no smaller than the applicable minimum block size</span><br></blockquote><blockquote type="cite"><span> allowed by policy, should be selected and retained by the</span><br></blockquote><blockquote type="cite"><span> organization. The remainder of the original block must not be</span><br></blockquote><blockquote type="cite"><span> in use and must be returned to ARIN. It is possible for</span><br></blockquote><blockquote type="cite"><span> multiple separate blocks to be retained from a single original</span><br></blockquote><blockquote type="cite"><span> block as long as clause (a) above is also meet.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This is very generic covering both ISP/LIR allocations and end user </span><br></blockquote><blockquote type="cite"><span>assignments. The basic concept is that returns can't create additional </span><br></blockquote><blockquote type="cite"><span>block that will negatively impact aggregation. And with partial returns </span><br></blockquote><blockquote type="cite"><span>the retained portion must be a nibble alined and no smaller than policy </span><br></blockquote><blockquote type="cite"><span>allows.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Also, related to this I'd like to delete section 6.5.8.4 "Consolidation </span><br></blockquote><blockquote type="cite"><span>and return of separate assignments", delete the last sentence of 6.5.3 </span><br></blockquote><blockquote type="cite"><span>clause (c), and add a new subsection in 6.3 "Goals of IPv6 address space </span><br></blockquote><blockquote type="cite"><span>management";</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> 6.3.9 Consolidation and return</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Some organization will have multiple IPv6 blocks, obtained through</span><br></blockquote><blockquote type="cite"><span> subsequent allocations or assignments where an existing block could</span><br></blockquote><blockquote type="cite"><span> not be sufficiently expanded, or through transfers (mergers and</span><br></blockquote><blockquote type="cite"><span> acquisitions). Such organizations should consider consolidating to</span><br></blockquote><blockquote type="cite"><span> a single block, or at least minimizing the number of blocks used</span><br></blockquote><blockquote type="cite"><span> for new sub-assignments. This should not be considered a</span><br></blockquote><blockquote type="cite"><span> recommendation for large-scale active renumbering out of blocks at</span><br></blockquote><blockquote type="cite"><span> are in use. To the contrary, such consolidation is merely a goal</span><br></blockquote><blockquote type="cite"><span> and would likely occur over several years. Further, it should</span><br></blockquote><blockquote type="cite"><span> primarily be achieved through attrition and other normal</span><br></blockquote><blockquote type="cite"><span> operational change. Finally, return of a block is expected once it</span><br></blockquote><blockquote type="cite"><span> is no longer in active use.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Moving the issue of consolidation to goals cleans up the subsequent </span><br></blockquote><blockquote type="cite"><span>allocation and assignment sections. It is intended to provide goals, </span><br></blockquote><blockquote type="cite"><span>motivation and some direction regarding why someone might want to return </span><br></blockquote><blockquote type="cite"><span>addresses. Putting it in the goals section prevents it from being </span><br></blockquote><blockquote type="cite"><span>confused with the issues of making subsequent allocations and </span><br></blockquote><blockquote type="cite"><span>assignments or the new Reduction or Return section above.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This is why I was thinking about a separate proposal, because I think </span><br></blockquote><blockquote type="cite"><span>the consolidation issue is more closely linked to the return and </span><br></blockquote><blockquote type="cite"><span>reduction section than with the x-small and xx-small fee category issues.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>What do others think?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-- </span><br></blockquote><blockquote type="cite"><span>================================================</span><br></blockquote><blockquote type="cite"><span>David Farmer Email: <a href="mailto:farmer@umn.edu">farmer@umn.edu</a></span><br></blockquote><blockquote type="cite"><span>Office of Information Technology</span><br></blockquote><blockquote type="cite"><span>University of Minnesota</span><br></blockquote><blockquote type="cite"><span>2218 University Ave SE Phone: 1-612-626-0815</span><br></blockquote><blockquote type="cite"><span>Minneapolis, MN 55414-3029 Cell: 1-612-812-9952</span><br></blockquote><blockquote type="cite"><span>================================================</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Message: 2</span><br></blockquote><blockquote type="cite"><span>Date: Tue, 2 Apr 2013 17:58:02 -0700</span><br></blockquote><blockquote type="cite"><span>From: Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>></span><br></blockquote><blockquote type="cite"><span>To: David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>></span><br></blockquote><blockquote type="cite"><span>Cc: John Curran <<a href="mailto:jcurran@arin.net">jcurran@arin.net</a>>, ARIN PPML <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>></span><br></blockquote><blockquote type="cite"><span>Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6</span><br></blockquote><blockquote type="cite"><span> Allocations for ISPs</span><br></blockquote><blockquote type="cite"><span>Message-ID: <<a href="mailto:0BDA5B2D-09B6-47C5-8CBF-E3B2315A0551@delong.com">0BDA5B2D-09B6-47C5-8CBF-E3B2315A0551@delong.com</a>></span><br></blockquote><blockquote type="cite"><span>Content-Type: text/plain; charset=us-ascii</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On Apr 2, 2013, at 16:24 , David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On 3/30/13 18:06 , Brandon Ross wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On Fri, 29 Mar 2013, David Farmer wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>After thinking about it for a while, if we even need any policy at</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>all, we should just have a general policy describing how IPv6 block</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>can be reduced by returning only part of a block, it should probably</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>be very generic and apply to allocations and end user assignments. It</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>might even be better if it we a separate proposal all together.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Agreed, which is why the language in this proposal allows for that, and</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>that was done on purpose.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I don't want to see that separated to a separate policy proposal because</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>it is critical to making this one function as intended.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Well, yes and no, John has already fix the operational issue, the only effect your proposed text would have at the moment would be to restrict it to the first or last blocks of the larger original block.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>This raise a question for me do we really need to restrict it to the first or last blocks? Personal, I'm ok with allowing the person making the return to have the flexibility to make choice of any contiguous and alined /40 out of the /32 they want.j</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Since we're holding (at least) the /32 in reserve for them anyway and ideally the /28, I really don't think it matters which /40 they're using.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Next, I'm thinking about a new subsection;</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 6.12 Reduction or Return</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> Organizations may return all or part of their allocations or</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> assignments, that are not in use, to ARIN at any time with the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> following considerations;</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> a. Such a return or reduction must not result in a larger number of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> blocks being held by an organization, if possible fewer blocks</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> are preferred.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> b. If a whole block is not in use, the whole block should be</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> returned to ARIN.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> c. If part of a block is returned; A single contiguous nibble</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> alined block, no smaller than the applicable minimum block size</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> allowed by policy, should be selected and retained by the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> organization. The remainder of the original block must not be</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> in use and must be returned to ARIN. It is possible for</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> multiple separate blocks to be retained from a single original</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> block as long as clause (a) above is also meet.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I think this vastly overcomplicates what should be relatively simple...</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>How about this:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>6.12 Reduction or Return</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> ARIN will accept any return which allows an LIR to reduce their</span><br></blockquote><blockquote type="cite"><span> holdings to fit a lower tier in the fee schedule so long as:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> 1. The end result is not an increase in the number of</span><br></blockquote><blockquote type="cite"><span> non-contiguous blocks held by the LIR.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> 2. Whole blocks are returned to the extent practicable.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> 3. Retained block(s) are within the largest reserved space</span><br></blockquote><blockquote type="cite"><span> set aside for the LIR in the ARIN database to the extent</span><br></blockquote><blockquote type="cite"><span> practicable.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I think it is better to express directly what it is that we want to happen</span><br></blockquote><blockquote type="cite"><span>in general terms and trust that ARIN and the LIRs will generally find</span><br></blockquote><blockquote type="cite"><span>a way to do the right thing so long as we do not prevent them from</span><br></blockquote><blockquote type="cite"><span>doing so.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Also, related to this I'd like to delete section 6.5.8.4 "Consolidation and return of separate assignments", delete the last sentence of 6.5.3 clause (c), and add a new subsection in 6.3 "Goals of IPv6 address space management";</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 6.3.9 Consolidation and return</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> Some organization will have multiple IPv6 blocks, obtained through</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> subsequent allocations or assignments where an existing block could</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> not be sufficiently expanded, or through transfers (mergers and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> acquisitions). Such organizations should consider consolidating to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> a single block, or at least minimizing the number of blocks used</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> for new sub-assignments. This should not be considered a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> recommendation for large-scale active renumbering out of blocks at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> are in use. To the contrary, such consolidation is merely a goal</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> and would likely occur over several years. Further, it should</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> primarily be achieved through attrition and other normal</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> operational change. Finally, return of a block is expected once it</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> is no longer in active use.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I think this is unnecessary and that the concerns driving this can be better addressed through improved operational practice.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Owen</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Message: 3</span><br></blockquote><blockquote type="cite"><span>Date: Tue, 02 Apr 2013 23:59:44 -0500</span><br></blockquote><blockquote type="cite"><span>From: David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>></span><br></blockquote><blockquote type="cite"><span>To: Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>></span><br></blockquote><blockquote type="cite"><span>Cc: John Curran <<a href="mailto:jcurran@arin.net">jcurran@arin.net</a>>, ARIN PPML <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>></span><br></blockquote><blockquote type="cite"><span>Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6</span><br></blockquote><blockquote type="cite"><span> Allocations for ISPs</span><br></blockquote><blockquote type="cite"><span>Message-ID: <<a href="mailto:515BB740.3000602@umn.edu">515BB740.3000602@umn.edu</a>></span><br></blockquote><blockquote type="cite"><span>Content-Type: text/plain; charset=ISO-8859-1; format=flowed</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On 4/2/13 19:58 , Owen DeLong wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Apr 2, 2013, at 16:24 , David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Next, I'm thinking about a new subsection;</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> 6.12 Reduction or Return</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> Organizations may return all or part of their allocations or</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> assignments, that are not in use, to ARIN at any time with the</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> following considerations;</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> a. Such a return or reduction must not result in a larger number of</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> blocks being held by an organization, if possible fewer blocks</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> are preferred.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> b. If a whole block is not in use, the whole block should be</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> returned to ARIN.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> c. If part of a block is returned; A single contiguous nibble</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> alined block, no smaller than the applicable minimum block size</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> allowed by policy, should be selected and retained by the</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> organization. The remainder of the original block must not be</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> in use and must be returned to ARIN. It is possible for</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> multiple separate blocks to be retained from a single original</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> block as long as clause (a) above is also meet.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I think this vastly overcomplicates what should be relatively simple...</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>How about this:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>6.12 Reduction or Return</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> ARIN will accept any return which allows an LIR to reduce their</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> holdings to fit a lower tier in the fee schedule so long as:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 1. The end result is not an increase in the number of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> non-contiguous blocks held by the LIR.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 2. Whole blocks are returned to the extent practicable.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 3. Retained block(s) are within the largest reserved space</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> set aside for the LIR in the ARIN database to the extent</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> practicable.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I think it is better to express directly what it is that we want to happen</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>in general terms and trust that ARIN and the LIRs will generally find</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>a way to do the right thing so long as we do not prevent them from</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>doing so.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>First, my intent was to use "organization" rather than "LIR" as I wanted </span><br></blockquote><blockquote type="cite"><span>it to be general and apply to both LIRs and end users, that is also why </span><br></blockquote><blockquote type="cite"><span>I moved it out to 6.12. Do you believe only LIR might wnat to reduce </span><br></blockquote><blockquote type="cite"><span>their holdings? You were advocating that end user annual fee be scaled </span><br></blockquote><blockquote type="cite"><span>to holding too, do you want to change the policy when that happens? Let </span><br></blockquote><blockquote type="cite"><span>keep it general and use "organization"</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Second, in your #3, what do the retained block(s) have to do with the </span><br></blockquote><blockquote type="cite"><span>reserved space? The retained block(s) are the block(s) kept by the </span><br></blockquote><blockquote type="cite"><span>organization and the reserved space is an ARIN operational issue. I </span><br></blockquote><blockquote type="cite"><span>believe we want the retained block(s) nibble aligned and no smaller than </span><br></blockquote><blockquote type="cite"><span>allowed by policy, /40 for an LIR and /48 for an end user. However, it </span><br></blockquote><blockquote type="cite"><span>would be better not to specify the minimums and get as a reference to </span><br></blockquote><blockquote type="cite"><span>applicable policy.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Do you want to allow non-nibble alined blocks to be retained? If you do </span><br></blockquote><blockquote type="cite"><span>then why not just allocate them in the first place.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Or, am I missing something?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>-- </span><br></blockquote><blockquote type="cite"><span>================================================</span><br></blockquote><blockquote type="cite"><span>David Farmer Email: <a href="mailto:farmer@umn.edu">farmer@umn.edu</a></span><br></blockquote><blockquote type="cite"><span>Office of Information Technology</span><br></blockquote><blockquote type="cite"><span>University of Minnesota</span><br></blockquote><blockquote type="cite"><span>2218 University Ave SE Phone: 1-612-626-0815</span><br></blockquote><blockquote type="cite"><span>Minneapolis, MN 55414-3029 Cell: 1-612-812-9952</span><br></blockquote><blockquote type="cite"><span>================================================</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Message: 4</span><br></blockquote><blockquote type="cite"><span>Date: Tue, 2 Apr 2013 22:08:35 -0700</span><br></blockquote><blockquote type="cite"><span>From: Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>></span><br></blockquote><blockquote type="cite"><span>To: David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>></span><br></blockquote><blockquote type="cite"><span>Cc: John Curran <<a href="mailto:jcurran@arin.net">jcurran@arin.net</a>>, ARIN PPML <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>></span><br></blockquote><blockquote type="cite"><span>Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6</span><br></blockquote><blockquote type="cite"><span> Allocations for ISPs</span><br></blockquote><blockquote type="cite"><span>Message-ID: <<a href="mailto:3E2E8083-7C91-474E-87CE-42E6B90E3D49@delong.com">3E2E8083-7C91-474E-87CE-42E6B90E3D49@delong.com</a>></span><br></blockquote><blockquote type="cite"><span>Content-Type: text/plain; charset=iso-8859-1</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On Apr 2, 2013, at 9:59 PM, David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On 4/2/13 19:58 , Owen DeLong wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On Apr 2, 2013, at 16:24 , David Farmer <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>> wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Next, I'm thinking about a new subsection;</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> 6.12 Reduction or Return</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> Organizations may return all or part of their allocations or</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> assignments, that are not in use, to ARIN at any time with the</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> following considerations;</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> a. Such a return or reduction must not result in a larger number of</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> blocks being held by an organization, if possible fewer blocks</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> are preferred.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> b. If a whole block is not in use, the whole block should be</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> returned to ARIN.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> c. If part of a block is returned; A single contiguous nibble</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> alined block, no smaller than the applicable minimum block size</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> allowed by policy, should be selected and retained by the</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> organization. The remainder of the original block must not be</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> in use and must be returned to ARIN. It is possible for</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> multiple separate blocks to be retained from a single original</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> block as long as clause (a) above is also meet.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I think this vastly overcomplicates what should be relatively simple...</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>How about this:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>6.12 Reduction or Return</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> ARIN will accept any return which allows an LIR to reduce their</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> holdings to fit a lower tier in the fee schedule so long as:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> 1. The end result is not an increase in the number of</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> non-contiguous blocks held by the LIR.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> 2. Whole blocks are returned to the extent practicable.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> 3. Retained block(s) are within the largest reserved space</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> set aside for the LIR in the ARIN database to the extent</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> practicable.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I think it is better to express directly what it is that we want to happen</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>in general terms and trust that ARIN and the LIRs will generally find</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>a way to do the right thing so long as we do not prevent them from</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>doing so.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>First, my intent was to use "organization" rather than "LIR" as I wanted it to be general and apply to both LIRs and end users, that is also why I moved it out to 6.12. Do you believe only LIR might wnat to reduce their holdings? You were advocating that end user annual fee be scaled to holding too, do you want to change the policy when that happens? Let keep it general and use "organization"</span><br></blockquote></blockquote><blockquote type="cite"><span>s/LIR/organization/g is fine by me.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I believe that only LIRs can reduce their charge tier by returning partial blocks. To save money an end-user would have to return an entire block and that's already permitted by existing policy elsewhere.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Second, in your #3, what do the retained block(s) have to do with the reserved space? The retained block(s) are the block(s) kept by the organization and the reserved space is an ARIN operational issue. I believe we want the retained block(s) nibble aligned and no smaller than allowed by policy, /40 for an LIR and /48 for an end user. However, it would be better not to specify the minimums and get as a reference to applicable policy.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>That's fine, but orthogonal to #3. My intent is to make sure that if they expand back to larger, their existing retained blocks are not from disparate reservations scattered throughout IPv6 and rather that they can expand into their single reservation. At least to the extent practicable.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Do you want to allow non-nibble alined blocks to be retained? If you do then why not just allocate them in the first place.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>No. I figured existing policy pretty well covered that elsewhere, but I'm happy to add that provision.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>How about:</span><br></blockquote><blockquote type="cite"><span> 4. All retained blocks shall fall on nibble-aligned boundaries.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Owen</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------------------------</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>ARIN-PPML mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></span><br></blockquote><blockquote type="cite"><span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>End of ARIN-PPML Digest, Vol 94, Issue 3</span><br></blockquote><blockquote type="cite"><span>****************************************</span><br></blockquote></div></body></html>