Hi Tore, On 9/30/13 9:02 PM, Tore Anderson wrote:
* 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.
again, assignments are removed from the proposed text. they will be able to sub-allocate. I agree that we may need to give this 'sort of IR' a name, associate member doesn't sound right though. Keep firing suggestions ;)
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.
It will probably be some kind of IR, just not an LIR nor an End User.
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.
It's not really a spade, that organisation will be able to use the address space or sub-allocate (parts of) it to other organisations. However, these will have the same right (use or sub-allocate). What do we do then? call everyone an 'associate' ?
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).
It's up to /29 for LIRs. How did you get to the numbers 28 or 49? It's either /48 if the organisation is sure that they will not need more; or a /32 if they do plan to sub-allocate to other customers. Adding intermediary numbers does not make any sense, allowing intermediary numbers may cause all kinds of problems: - billing issues, if at some time the AGM will decide to bill based on the size (as it used to do with IPv4 in the past) - filtering issues - aggregation issues
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).
I already answered in my previous message. See 5.2.1 from the proposed text.
Tore
Elvis