* Gert Doering
On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote:
Q: How would that work? A: We could end up with two levels of RIPE NCC membership, e.g. "full" like we have today, and "associate". Both would be fully-blown LIRs, but to keep the operational overhead in NCC billing/finance low, the membership fee for these "associate" members would be charged by the NCC to the full members who are sponsoring them (just like with PI).
I'm not exactly sure what the difference between an "associate member" and today's "consumer of resources provided by a sponsoring LIR" would then be, except for the title on the contract. On the contrary, some enterprises just don't want to deal with the RIPE NCC if they can make a contract with their friendly neighbouring LIR instead...
The difference would be that an "associate member" (which is just an idea, and outside the scope of APWG anyway) would be an LIR, and would therefore be able to assign address space to its customer in turn. PI holders currently cannot assign address space to their customers, and that's what I understand this proposal to be all about changing, but it does it in a way that defines a new "breed" of End User who a) does not at all fit the original definition of an End User, while b) does completely fit the definition of an Internet Registry. Put it another way, the new (1st level) type of End User created by the proposal appears to me to be an LIR in all but name. So what I'm thinking is that it's better to call a spade a spade as far as address policy go, and instead have the NCC/AGM/Board decide exactly how they want to go about charging for the different flavours of spades. But that's just my €0.02. Like I said earlier, this should not be mistaken for opposition to the current proposal, just a suggestion.
So I'm not sure it's worth abandoning the established concept of sponsoring LIR right away (especially since doing away with it would affect IPv4 PI as well...). It wouldn't make a difference anyway :-) - if we want to give people the option to take a /48 because it's big enough for them, we'd then still have "two standard sizes"...
Or we could simply tell the requesters to pick their favourite number between 28 and 49... as long as policy says it's should be possible to extend up to and including /29 it doesn't really matter what they start out with as far as keeping delegations aggregated go (and routing is another matter entirely).
So, yes, another avenue could be "abandon /48 assignments/allocations", but *that* brings up another can of worms (what about an enterprise that has 5 locations that all have local ISP upstreams and want to do BGP multihoming? 5x /48 suits them well today, 1x /32 with someone blocking more-specifics from that because no site is announcing the /32 aggregate would not be that good).
But that's the route6 object, not the inet6num. If someone is filtering on the inet6num without accepting more specifics they're already asking for trouble (their users would surely complain about lack of connectivity to the more-specifics inside 2a02:26f0::/32, for starters). Tore