Agree. We (US IX operators) are tight knit and self police to an extent. We know whats up with 4.4 prefixes. We’ve also spoken with staff occasionally about questions they have re: IX. It’s a good relationship overall.
RS standards could be tightened a little, but thats all I cant think of besides modernizing 4.4 which I heard there may be a proposal forthcoming. HTH -M< . Woodcock <[email protected]> wrote: > Fernando: Owen is correct, the type of abuse you’re hypothesizing has not, > in fact, occurred, in 32 years of IXPs. > > 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. > > -Bill > > > On Apr 22, 2024, at 7:44 AM, Fernando Frediani <[email protected]> > wrote: > > > > 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. > 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. > > Fernando > On 22/04/2024 00:06, Owen DeLong wrote: > > 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]> > <[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]> > <[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 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. > > > _______________________________________________ > 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. > > _______________________________________________ > 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.
