<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>That´s not the point Bill. As per my last message, this wish or
intent he talks about looks more a convenience to get this into a
more flexible scenario and divert the propose of the pool to
supply addresses and support the emergence of IXPs with allowing
them to act as RIRs and supply addresses to third parties which
have the ability to get them direcetlly from the RIR. If the
problem is that there is no IP space left for them to do directly
with the RIR this other way cannot be an easier way to turning
this pool into something that has never thought for and divert its
propose.</p>
<p>Addresses from this pool have always been meant to be used for
IXP Infrastructure and for connecting members in the LAN.<br>
</p>
<p>Fernando<br>
</p>
<div class="moz-cite-prefix">On 22/04/2024 02:56, Bill Woodcock
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:C5EE9225-142B-4804-A8EE-ADEFB8D72B4D@pch.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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 <a class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"><fhfrediani@gmail.com></a> 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"
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>
<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 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>
<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
(<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</span><br>
<span>Unsubscribe or manage your mailing list subscription
at:</span><br>
<span><a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br>
<span>Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any
issues.</span><br>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>