<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;">A small probability of abuse is generally not seen as a reason to deny legitimate users.<div><br></div><div>I think we can generally count on IXPs not to distribute large portions of their resources to cache providers that do not bring significant value to the users of the IX with those resources. To the best of my knowledge, there is no problem of abuse to date. As such, I think your concern here has about as much credibility as those crying about election fraud in the US.</div><div><br></div><div>Owen</div><div><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Apr 18, 2024, at 22:31, 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><p>By doing this it creates a short path to some specific type of
Internet companies over the others to have access to scarce
resources via someone else's right (the IX) to request those
addresses for the minimum necessary to setup an IX, not to 'give a
hand' to third parties. It would start to distort the purpose of
the pool.<br>
</p><p>Content providers members are members like any other connected to
that IX. Why make them special to use these resources if other
members (e.g: Broadband Internet Service Providers) connected to
that same IX cannot have the same privilege ?<br>
They and any other IX member, regardless of their business, can
get their own allocations with their own resources.</p><p>Fernando<br>
</p>
<div class="moz-cite-prefix">On 19/04/2024 02:13, Owen DeLong wrote:<br>
</div>
<blockquote type="cite" cite="mid:3EBCE08A-0CFF-48C4-AA4B-E48CEC34CB0F@delong.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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
<a class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"><fhfrediani@gmail.com></a> 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 moz-txt-link-freetext" href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">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" moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:info@arin.net" moz-do-not-send="true">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 (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div>
</blockquote>
</div>
<br>
</div>
</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>