[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)

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