On Fri, Sep 27, 2013 at 8:49 AM, Tore Anderson <tore@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