[address-policy-wg] proposal to remove IPv6 PI

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 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.
 
What I'm missing from your rationale for having those opinions?

There are many ways to do that regarding the fees, for example:
1) Fee depending on the "size" of the allocation (categories, as it was some years ago)
2) Single fee for all
3) 2 fees categories (those receiving more than /32 and those receiving less than that)
4) etc.
 
I think we need to recall that we have been already under 1, and that 4 out of 5 RIRs are still there. So I don't really think is an issue at all.

Regards,
Jordi
 
 

-----Mensaje original-----
De: address-policy-wg <address-policy-wg-bounces at ripe.net> en nombre de "Sascha Luck [ml]" <apwg at c4inet.net>
Fecha: miércoles, 16 de mayo de 2018, 18:55
Para: Gert Doering <gert at space.net>
CC: <address-policy-wg at ripe.net>
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.