Hi there, on 16.05.2018 17:33, JORDI PALET MARTINEZ via address-policy-wg wrote: > So, to make sure I understood your point. You think that a single /128 prefix > is ok to be sub-assigned (as per the current policy), but a single /64 prefix > is not? > Or you will agree in a change that only fix that?
I think that the current text serves it's purpose and _can_ be understood in the way it was intended to (i. e. countering the, non-standard, RIPE NCC idea that using SLAAC or DHCPv6 constitutes an act of sub-assigning addresses, forbidden as per section 2.6). If you read it while suffering from an overdose of technical writings, a normal reaction could be "R U kidding me? Addresses, even plural, but not prefixes — does not compute". I do *not* agree that _that paragraph_ needs another band-aid. I think that rough consensus should be sought on what uses by the assignment holder of assigned IPv6 space are considered ok. Afterwards, amending the policy at least should be more easy — if still considered necessary by then. > Regarding the specific wording, you're totally right and we should decide > *if* there is a way to re-formulate it. I think we should keep it as it is, take a step back and consider what issue, if any, there is. Frankly, I do not see one ATM; policy texts should not try to micromanage the readers mind, IMO. > That's the reason I initially suggested, even when discussing 2016-04, that > the text should be only in the IPv6 PI section ... the consensus was in the > other direction. Well, the current policy does allow »minor« third-party-usage for any (note the word) assigned IPv6 space. Previously, adopting RIPE NCCs view on SLAAC being an act of address assignment, no-one was allowed to run a Guest WiFi or similar with RIPE area assigned IPv6 space, PA or PI — as sub-assignments were (and are) forbidden and providing a third party with single addresses out of an assignment holder's addresses constituted a sub-assignment according to RIPE NCC (this is now fixed per policy in ripe-699's section 2.6). So, if you agree with RIPE NCCs view, 2.6 is the correct location. If not, the policy maybe was fine and the issue lay elsewhere. > This is the big problem in my opinion, and I actually forgot the mention it > before. I think policy must be as much as possible, a text which has only one > interpretation, even if that means it is longer. Otherwise, and I explained > this in emails when discussing 2016-04, people that "follows" the policy > process has advantage in terms of interpretation vs a newcomer that will read > only the *policy text*, but not the impact analysis, and all the discussions > used to clarify the policy text. I totally disagree with you on this. The more words go into a policy, the more loopholes are opened, which then have to backfill with new wordings, leading to pages after pages of policy text. A policy text should be easy to understand (especially for non-native speakers of the english language ;)), give a guideline on what use case it expects to cover and at all costs refrain from giving examples. The thing with examples is that, from my experience, they invite people to game the rules. Please don't overengineer the policies. Regards, -kai
