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

On Fri, Sep 27, 2013 at 8:49 AM, Tore Anderson <tore at fud.no> wrote:

> - I find the new graphics slightly confusing. There is drawn a link
> between the Sponsoring LIR to between the RIPE NCC and the End User, as
> expected, but also between the Sponsoring LIR and the 1st and 2nd level
> End Users (i.e. between the End User holding the allocation and its
> downstream End Users). Why is that? I don't see that the Sponsoring LIR
> has any responsibilities on this level? Also, is there some significance
> to be read into the fact that the line between the 2nd level End User
> and its End Site is dotted, while between the 1st level End User and its
> End Site it is solid?
>

+1 to that.

Although this is a bit like bike shedding, I think there should be a
descriptive explanation right next to the graph, which would be helpful to
n00bs (like me, really).


- I find the precise definition of the term "End User" to be hollowed
> out to some extent. In the proposed model, the 1st level End User is for
> all practical purposes operating as an LIR - the only significant
> difference seems to be related to which organisation it needs to pay for
> the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the
> implied meaning of "End User" is the "final" recipient, i.e., someone
> who is actually *using* the addresses, while a 1st level End User
> certainly meets the definition of IR in section 2.1. I would therefore
> consider instead calling this role a "Sponsored LIR" or something along
> those lines.
>

I agree. This is made even more difficult by apparently changing the scope
of the policy from the leftmost 64 bits to all 128 bits, and by restricting
suballocations to the smallest atoms to a /64, appears to reduce the IPv6
address space from 128 bits to 64 bits.

Section 1, 1.1 Overview has this current sentence that is removed in the
proposal:

"All bits to the left of /64 are in scope."

In one of the previous posts, making things easier for e.g. using separate
IP addresses for SSL is an argument for this proposal, but as I read it
right now, I would have to sub-allocate a /64 for each SSL certificate,
rather than say a /128.

I feel reasonably sure that this is not the intention of the authors.
-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20130927/3925cf24/attachment.html>