<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 27, 2013 at 8:49 AM, Tore Anderson <span dir="ltr"><<a href="mailto:tore@fud.no" target="_blank">tore@fud.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- I find the new graphics slightly confusing. There is drawn a link<br>
between the Sponsoring LIR to between the RIPE NCC and the End User, as<br>
expected, but also between the Sponsoring LIR and the 1st and 2nd level<br>
End Users (i.e. between the End User holding the allocation and its<br>
downstream End Users). Why is that? I don't see that the Sponsoring LIR<br>
has any responsibilities on this level? Also, is there some significance<br>
to be read into the fact that the line between the 2nd level End User<br>
and its End Site is dotted, while between the 1st level End User and its<br>
End Site it is solid?<br></blockquote><div><br></div><div>+1 to that.<br><br></div><div>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).<br>
<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- I find the precise definition of the term "End User" to be hollowed<br>
out to some extent. In the proposed model, the 1st level End User is for<br>
all practical purposes operating as an LIR - the only significant<br>
difference seems to be related to which organisation it needs to pay for<br>
the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the<br>
implied meaning of "End User" is the "final" recipient, i.e., someone<br>
who is actually *using* the addresses, while a 1st level End User<br>
certainly meets the definition of IR in section 2.1. I would therefore<br>
consider instead calling this role a "Sponsored LIR" or something along<br>
those lines.<br></blockquote><div><br></div><div>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.<br>
<br></div><div>Section 1, 1.1 Overview has this current sentence that is removed in the proposal:<br><br>"All bits to the left of /64 are in scope."<br><br></div><div>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.<br>
<br></div><div>I feel reasonably sure that this is not the intention of the authors.<br></div></div>-- <br>Jan
</div></div>