Hi Gert, On 9/30/13 7:31 PM, Gert Doering wrote:
Hi,
(no hats)
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...
exactly, I think that there's no difference between 'associate member' and customer of 'Sponsoring LIR' (whether we call it Sub-LIR, Portable Internet Registry or get enough support to keep calling it End User)
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"...
The Sponsoring LIR concept has been a battle won after quite a few years(remember 2007-01?) . I really do not want to throw it away as I believe it's a very valuable concept and it has taken two years of intense discussions in the community.
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).
I wouldn't worry about this can of worms, see section 5.2.1 "A /32 (or larger when documented) additional allocation may be provided when different routing requirements are demonstrated." We could change this to "An additional allocation may be provided when different routing requirements are demonstrated." and leave it to the decision of the enterprise to request either a /48 or a /32 or larger.
I'm repeating the "no hats" bit, just contributing to the discussion as someone who has fought IPv6 policy for a while now :-) - and this is discussion phase, so take this all as "brain dump", not as "advice from the chair".
thanks ;)
gert
cheers, elvis