<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 21, 2023 at 6:16 PM Delong.com <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div>On Jul 21, 2023, at 15:39, David Farmer via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>> wrote:</div><br><div><div dir="ltr"><div>So, it sounds like we are talking about a policy aimed purely at ARIN members in the 4XL and 5XL fee categories.</div></div></div></blockquote>Not that I know of, but yes, that was the example cited in the request for discussion.</div><div><blockquote type="cite"><div><div dir="ltr"><div>Furthermore, if an organization is large enough, the same statement could be made even with an 80% threshold.</div><div>So, let's do the math; if an organization has 5 /8s at 80% full, that is a /8 of free space.</div></div></div></blockquote>As a practical matter, think there are few (if any) organizations that have more than 2 /8s.</div><div><blockquote type="cite"><div><div dir="ltr"><div>Also, a similar statement, relatively speaking, could be made about anyone in the XL or higher fee category having more than a /16 of free space.</div></div></div></blockquote><div><br></div>Sure, someone with 5 /24s at 80% utilization has a /24 worth of free space.</div><div><br></div><div>These don’t seem like unreasonable ratios as a practical matter, however.</div></div></blockquote><div><br></div><div>Unfortunately, the inquiry said the following:</div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><font size="2"><span style="font-family:arial,sans-serif">The crux of the issue is there are very large orgs that could have a /8 or more of unused space, yet still qualify for more based on the current policy (<span id="m_2454534933473780414m_9172425134802370272m_-146830857448821170gmail-docs-internal-guid-95580fa7-7fff-a496-a6fc-458bb8498e39" style="color:rgb(29,28,29);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">"</span><span style="color:rgb(29,28,29);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">must have efficiently utilized</span><span style="color:rgb(29,28,29);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"> </span><span style="color:rgb(29,28,29);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">at least 50%</span><span style="color:rgb(29,28,29);font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">"</span>). Smaller orgs with more immediate needs are in competition for the space, and prices are driven up.<br></span></font></div></div></blockquote></div></div></div></blockquote>By focusing the conversation on larger organizations, this seems to blame larger organizations for rising prices and says smaller organizations have more immediate needs. If we want smaller organizations with two /24s and only one used to be able to justify a transfer of a /24, we need to accept organizations with two /8s justifying the transfer of a /8. It's only fair. If we want to change everything to 80%, I'm okay with that, but how does that impact the situation as described in the inquiry? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div><div dir="ltr"><div>We could set a maximum transfer unit, change the percentage, or whatever. But unless someone has a way to detect futures contracts and make them illegal, it's not going to be that hard to work around any changes to the policy that we make.</div></div></div></blockquote><div><br></div>Sadly, this is true as well (though I think illegal is the wrong term here… PPML doesn’t make law, we make registry policy.). However, just because a policy isn’t 100% enforceable, doesn’t mean it shouldn’t exist. Virtually none of our policies are 100% enforceable. The vast majority of policy, like the vast majority of law depends mostly on voluntary compliance… Keeping honest people honest, so to speak.</div></div></blockquote><div><br></div><div>Yeah, illegal isn't right, but unless we can make it a policy violation of some kind to enter into futures contracts, I don't see how changes are going to be effective. Enforceable or not, nothing in the current policy limits or even discourages futures contracts.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div><div dir="ltr"><div>We have the current policy because we wanted to make it easy for the small and medium guys to justify sizable blocks if they can justify them financially, as the market would add financial justification to the overall criteria.</div><div><br></div><div>Yes, the same holds true for the big guys. Why shouldn't it? From a relative perspective, it's not any easier for the big guys. Their size and the absolute values involved just make it sound easier, but it's not.</div></div></div></blockquote><div><br></div>Because at each level, 16x as much space comes for 2x the price… The big guys are effectively getting a huge discount on dominating the market. True, that rule doesn’t apply to transfer pricing… In fact, the inverse used to be true (A /17 currently goes for about $43/address, but a provider that needs and qualifies for a /17 can still buy as many /24s as they want since we eliminated the single prefix provisions).</div></div></blockquote><div><br></div><div>You are mixing fees and the market price. Big or small, ARIN's fees are only a very small part of the equation. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div><div dir="ltr"><div>Yes, the market is driving up the price for IPv4. That is what we expected. The answer is for people to start using IPv6. Not for us to try to manipulate the IPv4 marketplace by trying to pick winners and losers.<br></div></div></div></blockquote><div><br></div>I don’t think shifting the requirement for ALL organizations back up to 80% instead of 50% is picking winners or losers.</div></blockquote><div><br></div><div>Yes, but I don't think it will change the situation as it is described in the inquiry. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div><div dir="ltr"><div>The rules are the rules, and let's have one set of rules: big, medium, or small.</div></div></div></blockquote><div><br></div>Absolutely agree with this. I’m not aware of any active proposal to do otherwise.</div></blockquote><div><br></div><div>What about? "<span style="font-family:arial,sans-serif">should utilization criteria be tied to the size of the org, in other words tiered?" </span></div><div>That is not what is implied by that, at least in my opinion.<span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">But I'm glad we agree the answer to that question is no.</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div><div dir="ltr"><div>It's not that I oppose making any changes, but I don't think any changes are going to be effective and fundamentally change the fact that IPv4 prices are going up and will continue to do so regardless of any policy changes we make. More importantly, I'm worried that making changes at this point will have unintended consequences.</div></div></div></blockquote><div><br></div>As far as I’m concerned the faster IPv4 prices go up, the better. People have had plenty of time and plenty of notice that IPv4 had limitations and IPv6 is readily available. My only regret in this situation is that there’s no way to transfer the true costs of maintaining IPv4 onto the laggards that are preventing the rest of us from moving on.</div></blockquote><div><br></div><div>As I said, I don't oppose changes, but specifically on the 80% threshold, I think that would have a larger impact on the smaller guys without an appreciable impact on the big guys, which is not the intended effect as I read the inquiry.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Owen</div><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Thanks.</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 20, 2023 at 3:45 PM A N <<a href="mailto:anita.nikolich@gmail.com" target="_blank">anita.nikolich@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><font size="2"><span style="font-family:arial,sans-serif">On behalf of the ARIN AC Policy Experience Working Group, and in response to
the Policy Implementation and Experience Report presented at ARIN 51,
we're looking for input on a possible proposed revamp of NRPM Section 8.5.6 "Efficient Utilization of Previous Blocks". <br></span></font></div><div><font size="2"><span style="font-family:arial,sans-serif"><br></span></font></div><div><font size="2"><span style="font-family:arial,sans-serif">The crux of the issue is there are very large orgs that could have a /8 or more of unused space, yet still qualify for more based on the current policy (<span style="color:rgb(29,28,29);background-color:transparent;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap" id="m_2454534933473780414m_9172425134802370272m_-146830857448821170gmail-docs-internal-guid-95580fa7-7fff-a496-a6fc-458bb8498e39">"</span><span style="color:rgb(29,28,29);background-color:transparent;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">must have efficiently utilized</span><span style="color:rgb(29,28,29);background-color:transparent;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"> </span><span style="color:rgb(29,28,29);background-color:transparent;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">at least 50%</span><span style="color:rgb(29,28,29);background-color:transparent;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">"</span>). Smaller orgs with more immediate needs are in competition for the space, and prices are driven up. <br></span></font></div><div><font size="2"><span style="font-family:arial,sans-serif"><br></span></font></div><div><font size="2"><span style="font-family:arial,sans-serif">The Working Group would like some input on this before drafting a proposal. Input or thoughts are welcome about: </span></font></div><div><font size="2"><span style="font-family:arial,sans-serif">- should the utilization be raised, and if so, to what threshold? </span></font></div><div><font size="2"><span style="font-family:arial,sans-serif">- should utilization criteria be tied to the size of the org, in other words tiered?</span></font></div><div><font size="2"><span style="font-family:arial,sans-serif">- any other thoughts.</span></font></div><div><font size="2"><span style="font-family:arial,sans-serif"><br></span></font></div><div><font size="2"><span style="font-family:arial,sans-serif">Thanks much! <br></span></font></div><div><font size="2"><span style="font-family:arial,sans-serif">Anita<br></span></font></div><div><br></div><div><br></div></div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><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></div>
_______________________________________________<br>ARIN-PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br></div></blockquote></div><br></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><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></div>