<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’m not the one who is mixed up here. I know exactly what the policy intent was, I was very involved in creating the policy.<div><br></div><div>IXPs are meant to provide value to the peers which gather at the IXP by facilitating the efficient delivery of traffic amongst participants in the IXP. One way to do that is direct peering relationships through the IXP fabric. However, that is not the only valid mechanism for doing so. Additional services such as route servers, caches, etc. can also bring value to participants and it is not the role of the RIRs to dictate to IXPs which of those particular things are or are not valid use of the IXPs addressing.</div><div><br></div><div>My point is that I do not know of any IXPs currently abusing their addresses for any of the purposes you stated would occur.</div><div><br></div><div>I’m not supporting or proposing any change to current IXP related policy. I’m stating that the policy is sufficient as is.</div><div><br></div><div>You are the one arguing for a change. That change is not, IMHO, supported by the record and multiple other people have commented on the potential harmful effects of a change.</div><div><br></div><div>As such, I fail to see how you can claim I am arguing for a more flexible scenario. I. am arguing to preserve the status quo.</div><div><br></div><div>Owen</div><div><br id="lineBreakAtBeginningOfMessage"><div style="font-size: 17px;"><br><blockquote type="cite"><div>On Apr 21, 2024, at 22:45, 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>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>
</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>