I certainly didn’t get that vibe from Owen. However, Fernando, your recommendation is a policy change. I would be against that at this point.
I firmly believe that IX’s should be able to use a /24 for services and additional 4.4 space for their IX LAN. There is zero in the current iteration of the policy to prohibit this. -Chris > On Apr 22, 2024, at 6:49 PM, Fernando Frediani <fhfredi...@gmail.com> wrote: > > 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. > > 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. > > 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. > Fernando > > On 22/04/2024 16:57, Owen DeLong wrote: >> 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. >> >> 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. >> >> My point is that I do not know of any IXPs currently abusing their addresses >> for any of the purposes you stated would occur. >> >> I’m not supporting or proposing any change to current IXP related policy. >> I’m stating that the policy is sufficient as is. >> >> 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. >> >> 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. >> >> Owen >> >> >>> On Apr 21, 2024, at 22:45, Fernando Frediani <fhfredi...@gmail.com> >>> <mailto:fhfredi...@gmail.com> 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 <fhfredi...@gmail.com> >>>>> <mailto:fhfredi...@gmail.com> 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 <fhfredi...@gmail.com> >>>>>>> <mailto:fhfredi...@gmail.com> 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 (ARIN-PPML@arin.net >>>>>>>> <mailto:ARIN-PPML@arin.net>). >>>>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>>>>>> Please contact i...@arin.net <mailto:i...@arin.net> if you experience >>>>>>>> any issues. >>>>>>> _______________________________________________ >>>>>>> ARIN-PPML >>>>>>> You are receiving this message because you are subscribed to >>>>>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net >>>>>>> <mailto:ARIN-PPML@arin.net>). >>>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>>>>> Please contact i...@arin.net <mailto:i...@arin.net> if you experience >>>>>>> any issues. >>>>>> >>>>> _______________________________________________ >>>>> ARIN-PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net >>>>> <mailto:ARIN-PPML@arin.net>). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any >>>>> issues. >>>> >>> _______________________________________________ >>> ARIN-PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net >>> <mailto:ARIN-PPML@arin.net>). >>> Unsubscribe or manage your mailing list subscription at: >>> https://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any >>> issues. >> > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
