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

Hi again Jan, :-)

On 9/27/13 9:08 AM, Jan Ingvoldstad wrote:
> On Fri, Sep 27, 2013 at 8:49 AM, Tore Anderson <tore at fud.no
> <mailto: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've already responded to Tore's e-mail. If you still think it's 
confusing, please let me know.

>
>
>     - 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.

The scope of the policy has not been changed. In the current policy 
assignments lower than a /64 are not permitted. Therefore, nothing is 
changed.

>
> 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.

You are right, it was not our intention to remove that line from section 
1.1. However, even with the old policy, my understanding was that you 
should have assigned a /64 for the SSL certificate and not a /128.

I am not sure that removing that line makes any difference, let's see 
what the others think and we could add it back if it really changes the 
policy scope.

cheers,
elvis