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.
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 ?
They and any other IX member, regardless of their business, can get
their own allocations with their own resources.
Fernando
On 19/04/2024 02:13, Owen DeLong wrote:
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.
Owen
On Apr 18, 2024, at 20:35, Fernando Frediani <[email protected]>
wrote:
On 18/04/2024 21:34, Matt Peterson wrote:
<clip>
If the policy needs revision /(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), /maybe consider micro-allocations for IXP usage as
unannounced prefixes and for routed prefixes, an IXP applies under
NRPM 4.3 /(end user assignments).
/
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.
Regards
Fernando
--Matt
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
