<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">tl;dr: 2016-04 adds ambiguity and uncertainty to the policy text, is micro-managing the NCC against common intent and paves the way to use cases, according to RIPE NCC's Impact Analysis, the initial wording was trying to keep out. Hi Sander, </div> <blockquote type="cite"> <blockquote type="cite">[Jordi] I think we are in-sync, but your response clearly demonstrates that there is a need for clarifying the text. -> Policy proposal “Providing another entity with separate addresses (not prefixes)” -> a /64 is a prefix </blockquote> Technically, because the router is the PI holder's, you're not delegating a /64. You're allowing a customer to do i.e. SLAAC on a /64 of the PI holder.</blockquote> and there we are again (besides, it's about (sub-) assigning, not delegating, v6 addresses). 2016-04 started because of the RIPE NCC started to take the view that “a single DHCP leaseon wifi is a "subassignment" to another entity” [1], or, more precisely [2]: “As an example, some Freifunk Communities in Germany have been had their PI request declined because some 1-digit-number of subnets would have been used as IPv6 prefixes on public WIFIs. This usage of the IP space in the End User’s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "assigned" to a user device of the public WIFI network as the device would get an IP address via SLAAC (or any other means for that matter). This interpretation seems rather extreme and history shows that it's not even shared by every member of the RIPE NCC.” I've learned that … <blockquote type="cite">when in doubt the RIPE NCC will check the rationale behind a policy proposal to make decisions </blockquote> … but if the RIPE NCC does read the rationale behind a policy proposal, why is there a need adding more ambiguos text to an already rather clear policy? Adding more text to the policy on what is not supposed to be a sub-assignment than there is already for the definition of what an assignment is is not really helping things. The more specific the text, the more problems you'll end up with, as can be seen in Monday's exchange already. On the grounds of … <blockquote type="cite">The NCC reads both. This has explicitly been discussed before, and both the NCC and the working group confirmed that we don't want policy text that is too specific because reality is more complex than policy, and if we would try to make the policy complexity match that of reality then we would end up with horrible policy.</blockquote> … 2016-04 heads in this (“horrible policy”) direction: “Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment.” By definition [3], any /128 is a prefix, thus “addresses (not prefixes)” contradicts itself. Therefore, by trying to clarify things, 2016-04 with the current wording just creates more ambiguity and uncertainty. (Next stop would be the question if a leased line is a "link operated by" oneself or the company one ordered it from.) "Please stop being a lawyer." Sorry, I didn't start this nit-picking. To me, common sense – and the current policy's definition of "assign" – clearly shows that having a visitor's device pick an IPv6 address off my guest WiFi is not a (sub-) assignment by words nor spirit of the current policy. <blockquote type="cite"> The community has agreed not to micro-manage the NCC, and the NCC has promised to apply common sense when implementing policy.</blockquote> If so, why did we end up here? There is the RIPE NCC happily violating their own rules continuously (most/all(?) RIPE Meetings since roughly a decade), in – by their definition – sub-assigning their PIv6 space — and at the same time denying this to others when requesting new PIv6 space, “because of policy”. I think Gert Döring was a too lazy on summarizing my concerns as "we do not need this, the NCC is interpreting the policy all wrong"; there's something seriously wrong when a policy is implemented randomly. Any policy, anywhere. Especially when the administrator imposes random (that is: not covered by the policy) restrictions on adress space request applications, which the administrator itself is not adhering to for itself. So, while this sounds like RIPE NCC bashing, that's not my intend; but if the RIPE NCC just needs a statement that "WiFi is permitted use for PIv6", why can't we agreed on this, here, and tell the RIPE NCC? <blockquote type="cite">There have been many cycles of micromanaging the NCC to writing vague policy and letting the NCC sort out the details. In both cases the NCC was blamed for everything.</blockquote> But this is not the case here. Current policy, <a class="moz-txt-link-freetext" href="https://www.ripe.net/publications/docs/ripe-684">https://www.ripe.net/publications/docs/ripe-684</a>, is cristal clear already: <blockquote type="cite">2.6. Assign To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. […] 7. IPv6 Provider Independent (PI) Assignments To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”. […] The PI assignment cannot be further assigned to other organisations. </blockquote> The Wifi case (and that's all I care about, as that's the driver for 2016-04) is simply solved, since nothing is assigned or delegated here anyway: RA announces a prefix, the devices pick some rather random IPs. And this access point is part of the resource holder's infrastructure, there are no "other parties" involved. An iOS or Android device is no "Internet infrastructure [the End User] operate[s]"; it's a client device, not infrastructure. Case over. To me at least, that's "common sense". "A single DHCP lease on wifi is a 'subassignment' to another entity" is not. <blockquote type="cite">After many years of hard work we have reached a balance where the working group and the NCC work together to make policy that is one the one hand giving guidance to the NCC about what the community wants, but also leaves some room for the NCC (along with the accompanying responsibility) to adapt to changes and to apply some common sense. </blockquote> So, what went wrong there in the first place ([1], [2])? Why is the RIPE NCC "suddenly" applying odd interpretations to new PIv6 applications, while at the same time not adhering to those interpretations for their own use of their PIv6 space? <blockquote type="cite">Other organisations in the internet constellation have moved to a more legalese mindset, but I think as the RIPE community we are proud that we have evolved enough that we don't need that anymore and can actually work together pleasantly without setting everything in stone. </blockquote> I totally agree. So, why do we even consider 2016-04, which is adding more legalese to a policy that, with common sense applied, does not need any fixing? (On the impact analysis, this might be more a PDP-related issue, but anyway: why is there a »RIPE NCC's Understanding of the Proposed Policy« but no »RIPE NCC's Understanding of the Current Policy«? And on »it is the RIPE NCCs understanding that assignments as described above are dynamic in nature, either by varying the prefix or interface identifier (IID) over time«: Is 3 years still »dynamic«? »Any permanent and static assignments of a prefix would still be considered a sub-assignment as per clause 2.6, “Assign” of the IPv6 address allocation and assignment policy. Consequently the RIPE NCC will not provide IPv6 PI assignments for such deployment plans.« Well, the proposed clause 2.6 already forbids »providing another entity with […] prefixes […]«. Yes, wording is important on policy documents; commentary isn't read by the applicant.) And with legalese added comes new uses (see Impact Analysis): “If this proposal is accepted, it is the RIPE NCC’s understanding that for an IPv6 assignment, the provision of separate addresses to customers of the assignment holder will not be considered a sub-assignment. […] The RIPE NCC will consider […] in line with this policy and not a sub-assignment as long as the subnet size does not exceed a /64. […] Further it is possible that, despite the intention of the proposer, broadband providers will request and receive IPv6 PI assignments as long they comply with the requirement to only provide separate addresses to customers.” Therefore, in order to fix an odd RIPE NCC interpretation regarding WiFi-on-PIv6, much broader use cases for PIv6 will be opened by 2016-04. “To use an extreme example, even a broadband provider with millions of customers would qualify for an IPv6 PI assignment as long as he would follow the policy requirements.” Thus, in a nutshell, I'm still against 2016-04, as it addresses a non-issue (with common-sense applied at least) and opens the box of pandora without any need at all (see Impact Analysis on 2016-04). Regards, -kai [1] <a class="moz-txt-link-freetext" href="https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-October/011838.html">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-October/011838.html</a> [2] <a class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2016-04/?version=1">https://www.ripe.net/participate/policies/proposals/2016-04/?version=1</a> [3] <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc4291#section-2.3">https://tools.ietf.org/html/rfc4291#section-2.3</a> </body> </html>