A small probability of abuse is generally not seen as a reason to deny legitimate users.
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. Owen > On Apr 18, 2024, at 22:31, Fernando Frediani <[email protected]> wrote: > > 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]> >>> <mailto:[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] >>>> <mailto:[email protected]>). >>>> Unsubscribe or manage your mailing list subscription at: >>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact [email protected] <mailto:[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] >>> <mailto:[email protected]>). >>> Unsubscribe or manage your mailing list subscription at: >>> https://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact [email protected] <mailto:[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.
