Hi Tore, On 9/27/13 8:49 AM, Tore Anderson wrote:
Some comments from the top of my head (probably not exhaustive since I need some more time to digest the totality of the proposal):
- 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?
The dotted line between the RIPE NCC and End User shows that this request can be done by the Sponsoring LIR. The dotted line between the End User and End Site is there to show that there can be an infinite number of end users in between.
- The proposal should update ripe-592 section 5.6.2, bullet 2. This makes a reference to the IPv6 IXP document which this proposal retires, as I understand it. So in order to avoid this reference not pointing anywhere useful, the the original definition into ripe-592 (I believe this would be the PDO's preference), or to update the reference to point to the proposed unified IPv6 document.
hum, right.. I did not know that in the IPv4 policy there is a reference to the IPv6 assignments made to IXPs :) Do we need to change the IPv4 policy if this policy proposal is accepted?
- 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.
Well, any end-user will become some sort of an IR. I had the intent to define an other IR (lower than the LIR) but the consent amongst us, the proposers, was that this would complicate too much the proposal.
- In a similar vein, the LIRs have some NCC-provided tools at their disposal, such as for example the LIR Portal, which is the only place where at least some information can be updated. RPKI is another. Has it been thought whether the "Sponsored LIRs" will be given direct access to these tools, or if their resources will appear in the interface of the Sponsoring LIR, who will have the responsibility to maintain this information on their behalf (which would be an increased responsibility compared to sponsored PI), or something else such as LIR Portal access being one of the incentives for becoming a "proper" LIR?
This would be out of scope for this proposal, I think 2013-04 touches this service. The RIPE Database objects for current v6PI assignments can be changed by the maintainer, RPKI may be available after 2013-04 is approved. The only thing that I did not think of, and just realised now, is that if an End User needs to make more than a /48 sub-allocation, it will need to request an approval from the RIPE NCC. I am not sure how this approval can be recorded by the RIPE NCC, the Sponsoring LIR and the End User. This will probably be touched by the RIPE NCC in their Impact Analysis.
- When it comes to the counterpoint regarding taking away the incentive to become "proper" LIRs. Well - it's been possible to run consumer-based ISPs on IPv4 PI for quite a while, yet the NCC is failing to turn a deficit even though it allegedly is trying, so I'm not terribly concerned. :-) More seriously though, I don't think this is likely to be much of a problem before the same "Sponsored LIR" concept is backported to IPv4, and not necessarily then either.
I don't think this proposal will cause any problems either. But I've heard this argument so many times, we had to put it in the rationale. cheers, elvis