<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Of course Owen, on every email I read from you I get the
impression that if it was up to you there would be no need for
RIRs and policies to exist or maybe to be conservative in this
impression you seem to like of the RIRs as a simple bookeeper with
no power to enforce anything, even what the community who develops
the policies set as reasonable.<br>
</p>
<p>It is of course up to the RIR, has always been and hopefully will
continue to be, to dictate certain things which some private ones
keeps refusing to comply because take out their freedom to do what
they like with something doesn't belong to them. Simply if
something is not in line with a policy set by this forum it is up
to the RIR to dictate something that may not be desired by
someone. I know that it may not be good for certain kind of
business but life is not fair in many ways. So, just save up from
recurring to this old useless mantra.<br>
</p>
<p>It doesn't matter if an IXP have abused or not. What I am putting
is there should be well defined rules on how resources can be used
and not allow this continuous "rule-less party desire" go just
because it may hit someone's desire to take advantage of the
system.<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 22/04/2024 16:57, Owen DeLong wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7C3F0B16-A310-4024-A7ED-D6589C6BE943@delong.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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
<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>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>
</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>
</body>
</html>