Hi Sascha, Below in-line.
Regards, Jordi -----Mensaje original----- De: address-policy-wg <[email protected]> en nombre de "Sascha Luck [ml]" <[email protected]> Fecha: sábado, 19 de mayo de 2018, 15:47 Para: <[email protected]> Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI On Wed, May 16, 2018 at 07:25:27PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >I don't see why this would mean "lower" number of LIRs? > >Actually, I think will be the contrary. I think most of the end-users will become LIRs, especially if the AGM makes a smart move about how to attract them (fee scheme, contract, etc.). I don't see why this would be desirable. If every end-user had to become a LIR, it would blow the NCC up into this humongous bureaucratic apparatus and, perhaps more importantly, make it a regional monopoly in the truest sense - every business and person needing internet resources would be *forced* to deal with the NCC. [Jordi] I'm not sure there is any monopoly issue, but this is up to the NCC to evaluate. As explained in previous emails, this is just one choice, but we have the choice to unify the policy so everything is "allocation", but still have two contracts. >I don't see also why this would create more disaggregation. >The actual end-users will become LIRs. The actual LIRs will remain as LIRs. Both of them will announce the same addressing space. >In summary: Who needs to have stable addresses and avoid renumbering if changing ISP or data center, or whatever, will be an LIRs. We are coming at this from opposite sides. What I would like to see is that businesses and people who need (portable) resources don't *have to* become LIRs. Instead they contact their friendly neighbourhood sponsoring LIR and deal through them. [Jordi] I understand your point, which has been made by several folks already. What I feel strange is that this is the only region out of 5 RIRs, having this issue. Sometime we "get accommodated" to something and even if is not the best option, we don't like to change ... However, as said, having only "allocations" doesn't force us to have a single contract. It may be end-user contract for allocations of /48 per end-site and LIR contract for /32 and up. Remember also that many (small) LIRs are *today* done by other LIRs who manage the thing for them, so again no issue from my perspective. >What I'm missing from your rationale for having those opinions? Many of the LIRs in existence today *do not want to be LIRs*. They have become LIRs mostly because it was the only way for them to get (more) IPv4 resources or they needed portable resources. These LIRs have no interest and, often, no skills in dealing with the RIPE NCC. What I am proposing is, in essence, that LIRs become "sponsoring LIRs" for all resources. No more difference between "ASSIGNED PA" and "ALLOCATED PI", everything becomes, for practical purposes, "SUB-ALLOCATED" [Jordi] That's my main point. Everything becomes "allocated", so we end the endless discussion about if sub-assigment for this or that is correct or not. This enables LIRs with an interest to become resource management services for those who do *not* have this interest. End Users can choose a LIR to provide these services, if they are not happy with it, they can chose another and -that's the important difference - take their resources with them without having to renumber. Or, if they so chose, can become LIRs themselves. I've actually heard, as an argument for NAT66, that the users in question want to deploy that so they can avoid renumbering when changing connectivity providers. This could be avoided if those resources became portable. It should also have a positive effect on ripedb data quality if all resources are under the care of LIRs with the skills and an interest in their management. It reduces harm to end users' operations if a LIR is shut down for whatever reason. End users can simply switch to another sponsoring LIR. It may solve the issues that some large (governmental) orgs are having with policies and distributed resource management. There may be a de-aggregation effect, this can possibly be mitigated by minimum sub-allocation sizes though that may be wasteful. "SUB-ALLOCATED PA" already does a lot of this but a few changes are needed: - make SUB-ALLOCATED resources portable - change the subsequent allocation criteria to take account of SUB-ALLOCATED space, so it is possible for "sponsoring LIRs" to receive additional allocations even if SUB-ALLOCATED is not 90% assigned. rgds, Sascha Luck >-----Mensaje original----- >De: address-policy-wg <[email protected]> en nombre de "Sascha Luck [ml]" <[email protected]> >Fecha: miércoles, 16 de mayo de 2018, 18:55 >Para: Gert Doering <[email protected]> >CC: <[email protected]> >Asunto: Re: [address-policy-wg] proposal to remove IPv6 PI > > Hi Gert, > > On Wed, May 16, 2018 at 06:35:32PM +0200, Gert Doering wrote: > >> In other words, decouple the "LIR" function from the "ISP" > >> function. > > > >Well, that seems to be what Jordi's idea seems to be about - but it > >is neither easy nor straightforward how to get there. We've tried > >a few years ago, and when you mix in "fees", "membership / voting rights" > >and "allocation size", things get amazingly complicated... > > I think it would actually simplify a lot of those issues. It > doesn't remove the RIR->LIR->End User hierarchy but it removes > the requirement that a LIR provide connectivity to an End User. > (Basically, every LIR becomes a "sponsoring LIR") > > This removes the need for ISPs or hosters to be LIRs where they > neither want to nor have the necessary skills or the time. > > The outcome would most likely be a lot fewer LIRs with a lot > higher fees but they can of course recoup these via fees to their > end users. > > The only negative I can see is deaggregation of IPv6 space but I > think that particular boat sailed a long time ago... > > rgds, > Sascha Luck > > > > >(And if you are *not* looking at these aspects, removing the PA/PI > >label isn't actually achieving much, except replacing it by a "block > >for member" vs. "block for non-member" label, no?) > > > >Gert Doering > > -- APWG chair > >-- > >have you enabled IPv6 on something today...? > > > >SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > >D-80807 Muenchen HRB: 136055 (AG Muenchen) > >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
