<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Fernando: Owen is correct, the type of abuse you’re hypothesizing has not, in fact, occurred, in 32 years of IXPs. <div><br></div><div>Since you’re the one proposing to impose a cost on everyone else, the burden falls on you to prove that is solves an actual problem, not on Owen to prove that it does not. <br id="lineBreakAtBeginningOfSignature"><div dir="ltr"> <div> -Bill</div><div><br></div></div><div dir="ltr"><br><blockquote type="cite">On Apr 22, 2024, at 7:44 AM, Fernando Frediani <fhfrediani@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>It seems you kind of disregards the basics of IP assignment and
mix up things and what they were made for and thought for. It is
not because something looks convenient, that is something right.
When conveniences prevail over the main point we start to miss the
discussion propose. What you are saying below looks more a
personal preference if you were in charge of an IX to make it
develop than what is the main point of the discussion how
resources from a special pool should be treated.<br>
IXPs are not Broadband Services Providers nor RIRs and are not
meant to distribute IP space to anyone. IXPs need the IPs to build
its core services in order to interconnect ASNs locally.
Organizations connecting to an IXP have the ability to go directly
to the RIR and get resources from there through different ways and
that's how it should continue.</p>
<p>Fernando<br>
</p>
<div class="moz-cite-prefix">On 22/04/2024 00:06, Owen DeLong wrote:<br>
</div>
<blockquote type="cite" cite="mid:CB7C4F6F-3950-423A-AED2-8E66B96FBC24@delong.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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
<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>
<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" moz-do-not-send="true"><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 moz-txt-link-freetext" href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">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" moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
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.<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 (<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>
<span>_______________________________________________</span><br><span>ARIN-PPML</span><br><span>You are receiving this message because you are subscribed to</span><br><span>the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).</span><br><span>Unsubscribe or manage your mailing list subscription at:</span><br><span>https://lists.arin.net/mailman/listinfo/arin-ppml</span><br><span>Please contact info@arin.net if you experience any issues.</span><br></div></blockquote></div></body></html>