<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I think that if it’s a cache that is serving the IX (i.e. the IX member networks) over the IX peering VLAN, that’s perfectly valid.<div><br></div><div>Owen</div><div><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Apr 18, 2024, at 20:35, Fernando Frediani <fhfrediani@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div>
<div class="moz-cite-prefix">On 18/04/2024 21:34, Matt Peterson
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAFN0R254BiNoLf6SzALG7-i_Xurcw6yWkPX-0L25zPRksK_cUw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><clip>
<div><br>
</div>
<div>If the policy needs revision <i>(John's comments did not
provide enough of a background story - it's unclear if this
a yet another IPv4 land grab approach, and/or IXP's evolving
into hosting content caches, and/or the historical industry
acceptable usage that Ryan shares), </i>maybe consider
micro-allocations for IXP usage as unannounced prefixes and
for routed prefixes, an IXP applies under NRPM 4.3 <i>(end
user assignments). <br>
</i></div>
</div>
</blockquote><p>I have a similar conversation recently with someone willing to
use IXP allocations to assign to content caches and on this point
I think that IXP pool should not be for that. Even knowing the
positive impact a hosted content directly connected to a IXP makes
it is their business to being their own IP address not the IXP and
to be fair if you think of any CDN service they all have total
means to do that. Therefore IXP allocations should be used for IXP
own usage, so internal Infrastructure and to connect members and
things should not be mixed up.<br>
</p><p>Regards<br>
Fernando<br>
</p>
<blockquote type="cite" cite="mid:CAFN0R254BiNoLf6SzALG7-i_Xurcw6yWkPX-0L25zPRksK_cUw@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>--Matt</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</div>
_______________________________________________<br>ARIN-PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<br>Unsubscribe or manage your mailing list subscription at:<br>https://lists.arin.net/mailman/listinfo/arin-ppml<br>Please contact info@arin.net if you experience any issues.<br></div></blockquote></div><br></div></body></html>