Hi, On Thu, Oct 19, 2017 at 10:55:33PM +0000, Leo Vegoda wrote:

"Although the IPv6 address space is huge, it's still finite. Users only needing a /48 (or less) for their organisation would also block a full /29 prefix when forced to become LIR which seems unproportioned."

But some years ago, the RIPE NCC stated that it was using a bisection approach to allocate from its /12: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-July/006176.h...

Is that still the case and if it is, it would be good to understand how each new /32 allocation blocks a /29.

Since the initial allocation today can be a /29 with "no questions asked", this is not so much a matter of "reserving 3 additional bits, in addition to the allocation" as of "the allocations are this size today". (Not exactly sure what happens if a LIR steps up and says "I only want a /32!!" - Marco, can you comment on that? Will the NCC still *block* the /29, or might it happen that other /32s out of that /29 will eventually be allocated to someone else?) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Anno domini 2017 Andrea Cima scripsit: Hi Andrea,

The RIPE NCC currently reserves a /26 for every allocation up to a /29. For allocations larger than a /29, the next three bits are reserved.

This is based on a policy requirement that the RIPE NCC should maximise the potential for subsequent allocations to be contiguous with previous allocations: https://www.ripe.net/publications/docs/ripe-684#aggregation

Could you elaborate on what you do behind the scenes for an PI assignment? I guess you reserve more than the /48 for a possible subsequent assignment? Thanks! Best Max -- Alles sollte so einfach wie möglich gemacht sein. Aber nicht einfacher. (Einstein)

Hi Gert, all, Sorry, I thought that you also consider the opinions in the meeting, so just repeating myself, I’m against this proposal. I know, a policy can probably never be perfect at once, but I will prefer, in this case, having a better solution than an intermediate step to a better one, as otherwise we are complicating the interpretation of many other aspects in the overall IPv6 policy. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Gert Doering <gert@space.net> Responder a: <gert@space.net> Fecha: miércoles, 8 de noviembre de 2017, 9:46 Para: Marco Schmidt <mschmidt@ripe.net> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Dear Working Group, On Thu, Oct 19, 2017 at 03:08:07PM +0200, Marco Schmidt wrote: > Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the Review Phase. I'm a bit disappointed by the reactions of the WG on this - one voice of support on the list, silence otherwise. Then, quite vocal opposition at the RIPE meeting in dubai (to the current version, v2.0, while still in favour of the general idea to loosen up the IPv6 PI policy somewhat). Afterwards, silence again. But if it's not on the list, it did not happen, as per the ever-repeated explanation at the meetings. So, does this mean "the WG supports the current form of this proposal", and "the outburst at the RIPE meeting was not meant as sustained opposition"? So: > We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg@ripe.net> before 17 November 2017. Please speak up *here* if you have opinions on this proposal. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

What I’m not supporting is the *current* text (this version, as I understand we are discussing this version). I feel that the current version is solving partially Max case, but even in his case, if he decides to provide /64 for each hot-spot customer, this proposal will not work. I think Jan comments (in the meeting, hopefully he can repeat here) are very relevant, and I’ve a draft policy proposal in that direction, I’m waiting for my co-author review to submit it. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Gert Doering <gert@space.net> Responder a: <gert@space.net> Fecha: miércoles, 8 de noviembre de 2017, 10:26 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Hi, On Wed, Nov 08, 2017 at 10:12:59AM +0100, JORDI PALET MARTINEZ wrote: > Sorry, I thought that you also consider the opinions in the meeting, so just repeating myself, I???m against this proposal. I find my "before we enter discussion" slide on this quite unambiguous. The discussion at the meeting is relevant to get a feel for the room, and help the proposer to get guidance in which direction the proposal should be developed. For the sake of openness and transparency, the *list* is what is relevant. But besides that, your statement is not helping. You have voiced support at the May meeting for the general proposal, and now oppose "the proposal", without further qualifying. So what, do you support loosening up the IPv6 PI policy, and just do not agree with the v2.0 wording, or do you generally oppose any move into that direction? > I know, a policy can probably never be perfect at once, but I > will prefer, in this case, having a better solution than an > intermediate step to a better one, as otherwise we are complicating > the interpretation of many other aspects in the overall IPv6 policy. There are no perfect policies. There are workable compromises that iteratively get adjusted to changed community requirements. The IPv6 PI policy is a good example: it's a compromise, because we did not know 10+ years ago what a "perfect!" policy would have looked like (and 10+ years ago, what people assumed would be needed is different from the landscape today) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi, On Wed, Nov 08, 2017 at 10:33:36AM +0100, JORDI PALET MARTINEZ wrote:

I think Jan comments (in the meeting, hopefully he can repeat here) are very relevant, and I???ve a draft policy proposal in that direction, I???m waiting for my co-author review to submit it.

Multiple parallel proposals touching the same area of the same policy document are never a good idea. So if you want to work on the IPv6 PI policy, please join forces with Max (or wait for his proposal to finish, either way). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Wed, Nov 08, 2017 at 10:47:09AM +0100, JORDI PALET MARTINEZ wrote:

So, in the morning of 25th I???ve prepared a draft version and my co-author hasn???t provided any input back. I just resent it to him and my next step is to send a copy to the co-chairs and Max in private in a few seconds, so we can move on from there.

Before coming up with finished new proposal text it might be a good idea to present your approach to the list and discuss the general direction, and only then come up with a specific text to take WG feedback into account. This is not the IETF where things have to start with elaborate drafts, we are at liberty to discuss first. Speeds up things a bit :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Wed, Nov 08, 2017 at 11:20:34AM +0100, JORDI PALET MARTINEZ wrote:

Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) (that's music?)

Thanks. So, basically, we have two possible approaches here: proposed by Max (active proposal): keep the IPv6 PI policy as somewhat restrictive, trying to find wording that permits "some generally accepted" use-cases where other people's devices can get numbers from someone's IPv6 PI block or, proposed by Jordi (new direction): completely remove the restrictions on "letting other people use parts of someone's IPv6 PI block" both would work to solve the (real) problem at hand, and Jordi's approach would certainly much easier than trying to come up with unambiguous wording to "permit some, disallow other" use cases. Thanks for your proposal, and now let's see what the community wants :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Gert Doering wrote:

both would work to solve the (real) problem at hand, and Jordi's approach would certainly much easier than trying to come up with unambiguous wording to "permit some, disallow other" use cases.

this is a restatement of the long-standing question about whether the RIPE community should continue with the idea of differentiating between PA and PI address space. If we're going to go down this road, this is a substantial change to make, with far-reaching consequences, and it needs a good deal more attention than a couple of lines in the ipv6 policy doc. Nick

JORDI PALET MARTINEZ wrote:

Fully agree, and I’ve been working around that idea for about a year already … I’ve something in the kitchen, but still not mature enought.

I’m waiting for NCC budget figures to be able to make a proposal that is sustainable in the long term. I know “money” is not related to policies, but in this case, even if is only rational behind the proposal text, I think it is a must.

Nevertheless, my opinion is that that change may take, as you said, a longer period of discussion, and I will like to make sure, meanwhile, cases such as Max one, aren’t “in hold” for deploying IPv6.

if you're planning to change this universally some time in the future, it would be simpler and easier to make a step change (i.e. Max's suggestions) in the ipv6 assignment policy now rather than making a fundamental change there first and catching up with other bits of policy later on. Nick

JORDI PALET MARTINEZ wrote:

I don’t think reaching consensus in the PI/PA change will be so easy in the “near future” (considering that it may require a long implementation time), and a middle way proposal looks feasible to me.

but it's not a middle way: it's removing the block on sub-assigning to other parties, which is the thing that distinguishes PI from PA. Nick

Hi Gert, Nick & Jordi, I don’t think that the fear from past times is something that we should keep in this discussion these days.. If you have a look at which speed hosters / ISP are opening up new LIR’s for the /22 IPv4 … and are able to get their own v6 /29, just because they need the v4 anyway .… I have serious doubt if someone would even consider to get a ‘cheap’ /48 PI just to game the system. It would have my vote to remove as much of the IPv6 PI restrictions as possible, but keep the /48 PI limit without documentation … The goal of aggregation is noble for the DFZ, but if you have a look at the current v6 space and what people are de-aggregating their v6 prefixes into .. you would probably have to agree with me that this discussion doesn’t apply to the real world anymore. The discussion of financial cost for v6 space is nothing if you look at the cost for getting v4 .. and if someone wants to do the documentation for PI space .. rather than becoming a LIR.. where you can get a /29 without any questions or documentation .. Go for it .. If you have that amount of customers .. I think you would be an LIR already .. Just have a look how certain companies are doing more specific announcements of their /32 in /48’s .. or even smaller… If customers want to implement v6 .. using PI space for their internal infra .. or even host a server or 200 on that /48 .. let them have fun with it.. The reality is that is not where the pollution in the routing table will come from imho .. I do think that a proposal to change the PI v6 requirements should be a separate discussion and policy proposal. Regards, Erik Bais On 08/11/2017, 17:14, "address-policy-wg on behalf of Gert Doering" <address-policy-wg-bounces@ripe.net on behalf of gert@space.net> wrote: Hi, On Wed, Nov 08, 2017 at 03:54:42PM +0000, Nick Hilliard wrote: > JORDI PALET MARTINEZ wrote: > > I don???t think reaching consensus in the PI/PA change will be so easy > > in the ???near future??? (considering that it may require a long > > implementation time), and a middle way proposal looks feasible to > > me. > > but it's not a middle way: it's removing the block on sub-assigning to > other parties, which is the thing that distinguishes PI from PA. Which is one of the things. Other things are "how big will that bag of numbers be" and "what costs are attached to it". Especially the "how big will that bag of numbers be" will certainly be something we'll have to discuss next, shall we decide to open up PI for "more liberate use" (like, will "I want to assing a million /64 to DSL users" be a sufficient reason to get "larger than a /48"?). Consequences to all we do... Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

That’s why I suggested that the limit can be only /64 if we want to have a in PI at the time being. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Nick Hilliard <nick@foobar.org> Responder a: <nick@foobar.org> Fecha: miércoles, 8 de noviembre de 2017, 16:55 Para: <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) JORDI PALET MARTINEZ wrote: > I don’t think reaching consensus in the PI/PA change will be so easy > in the “near future” (considering that it may require a long > implementation time), and a middle way proposal looks feasible to > me. but it's not a middle way: it's removing the block on sub-assigning to other parties, which is the thing that distinguishes PI from PA. Nick ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Gert Doering wrote:

On Wed, Nov 08, 2017 at 05:16:32PM +0100, JORDI PALET MARTINEZ wrote:

...

...

That???s why I suggested that the limit can be only /64 if we want to have a in PI at the time being.

A /64 for what? per customer?

... which is why Jordi's approach is a big deal. We either have PI or we don't, but I don't think its demise should be handled by slipping some innocuous looking test into the ipv6 policy spec. Changing the terms of PI is a significant change in the direction of the RIPE community and the RIPE NCC and shouldn't be approached in a piecemeal sort of way. Nick

Dne 8.11.2017 v 16:54 Nick Hilliard napsal(a):

it's removing the block on sub-assigning to other parties, which is the thing that distinguishes PI from PA.

Nick, I think this is a wrong interpretation of the problem. There's actually no distinction between PI and PA, the rule is that "sub-assignments are forbidden" regardless of PI/PA nature of the addresses. The only difference is that with PI, the it is the RIPE NCC evaluating the rules, which seem to be too strict in considering what should count as sub-assignment. But if we try to fix this, let's keep the fix working both for PI and PA addresses. Just because the problem is not visible in PA world does not mean it does not exist there. I elaborated more on the PA side of the problem here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-November/0119... -- Ondřej Caletka

* Gert Doering <gert@space.net> [2017-11-08 11:43]:

Hi,

On Wed, Nov 08, 2017 at 11:20:34AM +0100, JORDI PALET MARTINEZ wrote:

...

Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) (that's music?)

Thanks.

So, basically, we have two possible approaches here:

proposed by Max (active proposal): keep the IPv6 PI policy as somewhat restrictive, trying to find wording that permits "some generally accepted" use-cases where other people's devices can get numbers from someone's IPv6 PI block

or,

proposed by Jordi (new direction): completely remove the restrictions on "letting other people use parts of someone's IPv6 PI block"

I support 2016-04. It solves real problems that people have right now and is easy to understand. By all means try to succeed with the masterstroke of unifying PI and PA but I don't think this should block the current proposal as it probably will require "quite a bit" of discussions and revisions. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

Hi Elvis, I think the number of sub-assignments is something that can be very different in different cases and we may end-up with a new case that will not fit the policy. My rational to /64 is that actual IETF work direction is very consistent with a /64 to be used in a single interface (a host having VMs, for example) and I think this match very well what it may be the difference between PI and PA (while we keep it). https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-hos... Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Elvis Daniel Velea <elvis@velea.eu> Responder a: <elvis@velea.eu> Fecha: miércoles, 8 de noviembre de 2017, 12:12 Para: <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Hi Jordi, Excuse the briefness of this mail, it was sent from a mobile device. > On Nov 8, 2017, at 02:20, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote: > > b. Arguments Opposing the Proposal > It can be argued that this proposal could increase the number of PI request to RIPE NCC. > > Mitigation/counter-argument: This is not an issue and should not be considered as a “bad-effect”. > > The resulting policy could be used to circumvent the allocation policy, avoiding creating a LIR. > > Mitigation/counter-argument: This seems not to have sense as there must be a justification process anyway, and because the starting point is /48, an ISP willing to connect customers, will really want to be an LIR. Furthermore, if we want to be restrictive on this, we could add a limitation that the maximum sub-assignment can be /64. how about... if we want to be restrictive - instead of limiting the size of the prefix, we limit the number of sub-assignments one can make from a PI? elvis ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

On 08.11.2017 11:20, JORDI PALET MARTINEZ wrote:

Ok, here is it then. Hopefully we have a lot of fun and good noise ;-) (that's music?)

The main idea is to allow what Max (and many other people) needs in PI, but not having restrictions.

For that, what I’m proposing is:

1) Change the actual definition of Assign in 2.6, to: 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, with the exception of Provider Independent (PI).

To me, this wording makes things even worse. This makes PIv6 more adorable (less restricted) and will lead to more confusion instead of less.

2) Remove last paragraph in 7. IPv6 Provider Independent (PI) Assignments So, REMOVE: The PI assignment cannot be further assigned to other organisations.

I'm happy with the "no subassignent" restriction (as in: you cannot enter a bigger prefix in the RIPE DB, even as an LIR), I challenge NCC's interpretation of allowing third party users use my PI space temporary being a sub-assignment (guest WiFi/Freifunk case).

Rationale:

a. Arguments Supporting the Proposal This proposal will avoid the situations of breaking existing policy when a network using PI is using the addressing space for point-to-point links or in cases such as providing connectivity to employee or visitor devices (BYOD), hot-spots, and similar situations. At this way, regardless of if a single /128 or /64 is sub-assigned, and independently of what technology is used for that (SLAAC, DHCPv6, DHCPv6-PD), the restriction is no longer an issue.

My employees are part of my organisation, no issue there. Visitors are what is objected by the NCC, as they are not part of the organisation that holds the PI assignment. But then the RIPE NCC is in breach with it's own interpretation when using their PI space on a RIPE Meeting's public network (wired & wireless): not every WiFi user at a RIPE Meeting is an employee of the RIPE NCC. So, next time we'll see the RIPE NCC requesting a temporary PA (v4 and v6) from the providing ISP for the Meeting's network? Similarily, as my family isn't me, I may not allow them to use PI space assigned to me? But then, what's PI good for anyway? Any service that's setup/operated/funded by the assignee (the holder of (PI) space) should be considered proper use of these Internet resources, as far as the IR is concerned.

b. Arguments Opposing the Proposal It can be argued that this proposal could increase the number of PI request to RIPE NCC.

Mitigation/counter-argument: This is not an issue and should not be considered as a “bad-effect”.

The resulting policy could be used to circumvent the allocation policy, avoiding creating a LIR.

Mitigation/counter-argument: This seems not to have sense as there must be a justification process anyway, and because the starting point is /48, an ISP willing to connect customers, will really want to be an LIR. Furthermore, if we want to be restrictive on this, we could add a limitation that the maximum sub-assignment can be /64.

So I need a /48 per WiFi I use (as each requires an /64 and two "sub-assignments" therefore would exceed the limit)? Does not look like it solves any issue ;) Still: I don't think ripe-684 needs an update. At fault is the RIPE NCC's, highly inconsistent, interpretation of the term "sub-assignment". ripe-684's definition of "assign" states (in 2.6): "Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties". If a /128 for a device that doesn't belong to the organisation holding a IPv6 assigment is a "sub-assignment", there is *no* way for *any* organisation to (in accordance of RIPE NCC's interpretation) provide externals with public IPv6 addresses. By any means. Regardless if the organisation is an IR or not. (Well, an IR could formally "assign" address space from their allocated, unassigned pool, if the End User comes with "Internet infrastructure they operate"; different story.) I somewhat doubt that RIPE NCC teaches this interpretation to (old and) new LIRs for evaluating PA requests. But then there is no justification to interpret the definition of "assign" in 2.6 differently for PI. As I don't think the intent of ripe-684 was to prevent the use of IPv6 on guest or even public WiFi, in coworking spaces, hotels or at meetings, the sane thing to do is to abolish this interpretation of an /128 being a "sub-assignment" within the RIPE NCC. It's nowhere in the policy text; on the contrary: This "/128 is a sub-assignment" interpretation even contradicts ripe-684. Quoting 5.4.1. ("Assignment address space size"): "End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site)." If the policy document(!) itself considers a /64 as the minimal size of an assignment to End Users, there is no ground for interpreting a /128 as one, sub or otherwise. On the principle of don't fix it if it ain't broken, I'm therefore still againt this proposal. Let's fix the real issue, not complicate a proper policy text.

Thoughts?

Yepp, voiced ;) Regards, -kai

Hi, On Wed, Nov 08, 2017 at 05:48:42PM +0100, Maximilian Wilhelm wrote:

[...]

...

I feel that the current version is solving partially Max case, but even in his case, if he decides to provide /64 for each hot-spot customer, this proposal will not work.

Actually the NCC IA interpretation is rather clear on this one - as Marco (IIRC) confirmed while the WG session. /64 assignments to hosts aren't a problem with the current policy text / interpretation.

Precision of language: "... with the proposed new policy text". (Sorry to be nit-picking here) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On Wed, Nov 8, 2017 at 3:29 AM, Nick Hilliard <nick@foobar.org> wrote:

Gert Doering wrote:

...

So:

...

...

We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg@ripe.net> before 17 November 2017.

Please speak up *here* if you have opinions on this proposal.

Looks sensible. I support the proposal.

Nick

I agree; It seems to me that the extreme position that WiFi hotspot type use of PI is in violation because you are sub-assigning addresses for use by outside parties, is missing the point that from a policy perspective a sub-assignment has to have some level of permanence and dedication to it. The transient or temporary use of some addresses by a customer, a business partner, or even the general public, does not rise to the point of making a sub-assignment from a policy perspective, because it lacks permanence and in most cases is not dedicated to a specific external use, or in other words its dynamic or changing. To count as a sub-assignment from a policy perspective the use number resources by an outside party (a customer, a business partner, the general public, etc...) has to be dedicated to the use by a specific external individual or entity for a substantive period of time, like months or years, not just a few hours or days. While I support the concept of this policy, because of the unique-prefix-per-host work nearing completion in the IETF, I like to see language about prefixes and subnets removed from the policy and maybe replaced with language based on the temporary non-dedicated (dynamic) use instead. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

I strongly agree with the intention and am fine with the proposed solution. Richard Sent by mobile; excuse my brevity and the wall of text Gmail appends by default.

Hi all, same here! I strongly agree with the proposal as stated by Max. His latest version is fine for me. Richard Hartmann wrote at 25.11.2017 22:13:

I strongly agree with the intention and am fine with the proposed solution.

Richard

Sent by mobile; excuse my brevity and the wall of text Gmail appends by default.

Best Regards. Matthias Kluth Senior Network Consultant HeLi NET Telekommunikation GmbH & Co. KG Hafenstr. 80-82 D-59067 Hamm Tel.: +49 (0)2381 / 874-4502 Fax: +49 (0)2381 / 874-4551 Mobil: +49 (0)173 / 5411102 Email: mk@helinet.de Web: http://www.helinet.de -- HeLi NET Telekommunikation GmbH & Co. KG Sitz der Gesellschaft: Hamm - Amtsgericht Hamm HRA 1881 Komplementaerin: HeLi NET Verwaltung GmbH Sitz der Gesellschaft: Hamm - Amtsgericht Hamm HRB 2781 Geschaeftsfuehrung: Dipl.-Kfm. Ralf Schuette

Hi all, I also support this proposal, Regards, Arash Naderpour On Sat, Nov 25, 2017 at 10:30 PM, Gert Doering <gert@space.net> wrote:

Dear AP WG,

...

Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in

On Thu, Oct 19, 2017 at 03:08:07PM +0200, Marco Schmidt wrote: the Review Phase. [..]

...

We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg@ripe.net> before 17 November 2017.

The chairs have convened, and come to the conclusion that we do not have had enough input yet.

We've heard a few voices on the list that state "this proposal is good, go forward with it". We've heard a few voices at the RIPE meeting that wanted "something else" - of those, only Jordi has made it to the list, and the resonance to his alternative was not met with unanimous support either (Elvis wants it, Nick opposes it, no other clear statements on that aspects).

Max has brought up the topic at DENOG9 last week, to elicit more people into adding input into this discussion - which would be helpful in evaluating (rough) consensus.

Thus, we've decided that we will extent the review period by four weeks.

Marco will send the formal announcement early next week.

Gert Doering -- APWG chair -- have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On 15 Jan 2018, at 10:21, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote:

Obviously, I don’t agree, just because for me, “consensus” is having no objections

Jordi, whatever definition of consensus someone chooses is up to them. That doesn't mean it's right or the one that everybody else has to adopt. [We decide the definition of consensus by consensus. :-)] Consensus does not mean there have to be no objections. That's unanimous consensus. There's a difference. An important difference. Maybe something is getting lost in translation? ie the Spanish for "consensus" means something similar to the definition you're using. There can be consensus in RIPE (and other fora such as IETF and ICANN) even when there are objections. RFC7282 goes into this in great detail. If we relied on unanimous consensus for decisions, nothing would ever get done because anyone would have a veto that could block progress. And in a very diverse community like RIPE, it'll be impossible for everyone to agree on everything.

Hi, On Mon, Jan 15, 2018 at 12:34:34PM +0100, Joao Damas wrote:

Well, that feels like just a way of cutting a discussion short. One might want to read on the Dutch polder-model as an example of how to cooperate with recognised differences.

APWG works on "rough consensus" and "all objections have been *addressed*" - which does not require "the person raising the objection is convinced and withdraws his or her objection". We try to convince :-) - but since this does not always work, it's called "rough" consensus. Besides this, there is different types of objections - "I fully object to changing anything in this general direction, ever!" - "I think this is good, but I disagree with the wording, because..." - "I think this is good, and I see the need for a change, but the proposed policy change is not the right way to do it / is too limited, we should aim for a larger and more encompassing change" Type 1 objections can not be "postponed" - if you go somewhere against strong objection to the general direction, you need convincing, counter arguments, and occasionally you end up at "withdraw due to no consensus" (and sometimes the consensus is rougher than usual). Type 2 objections are usually dealt with by going through a few review cycles with new text, incorporating such input into new versions of the document. This is what we've had here: there was feedback to earlier policy text, and Max did quite a few rounds based on that feedback, together with RS, to come up with text that is clear to RS and to the WG. Type 3 objections can be handled by taking notice of them, and starting a new policy proposal with the larger change after this one is done. Jordi's is - as I explained in my summary mail without detailling these categories - "type 3". The WG has discussed his alternative idea, and there was not enough backing to change 2016-04 into something more general - instead there was support to finish 2016-04 *now*, instead of leaving those impacted by the current policy shortcomings waiting further, until we have consensus on how a larger policy change would look like. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi Jim, I agree that is not “unanimity”, but I don’t think there is consensus on this proposal, and even less I think is fair to extend the review period “because” a proposal has been brought in the last minute to another fora, when the chairs already declared “that we don’t have consensus”. See this message: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2017-November/0122... Is something that we should do for every policy proposal that don’t reach consensus? Is this meaning that we will always “extend” the PDP timeline *until* we reach consensus? Then, my reading is that EVERY policy proposal can always reach consensus, is just a matter of finding enough folks (or virtual voices) that register into the mailing list and support the proposal vs non-supporters. Not sure if you see my point? Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Jim Reid <jim@rfc1035.com> Fecha: lunes, 15 de enero de 2018, 12:05 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: [address-policy-wg] what does consensus mean > On 15 Jan 2018, at 10:21, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote: > > > Obviously, I don’t agree, just because for me, “consensus” is having no objections Jordi, whatever definition of consensus someone chooses is up to them. That doesn't mean it's right or the one that everybody else has to adopt. [We decide the definition of consensus by consensus. :-)] Consensus does not mean there have to be no objections. That's unanimous consensus. There's a difference. An important difference. Maybe something is getting lost in translation? ie the Spanish for "consensus" means something similar to the definition you're using. There can be consensus in RIPE (and other fora such as IETF and ICANN) even when there are objections. RFC7282 goes into this in great detail. If we relied on unanimous consensus for decisions, nothing would ever get done because anyone would have a veto that could block progress. And in a very diverse community like RIPE, it'll be impossible for everyone to agree on everything. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi, On Mon, Jan 15, 2018 at 01:09:27PM +0100, JORDI PALET MARTINEZ via address-policy-wg wrote:

I agree that is not ???unanimity???, but I don???t think there is consensus on this proposal, and even less I think is fair to extend the review period ???because??? a proposal has been brought in the last minute to another fora, when the chairs already declared ???that we don???t have consensus???.

At the end of the original review period, we had three options - withdraw, because no clear support either way from the community - change text, and come up with a new review period - explain that we need more input, and extend the review period especially with the "we did not clear enough guidance", we regularily do this (extending discussion or review periods). Always with a clear explanation why this has been done.

Is this meaning that we will always ???extend??? the PDP timeline *until* we reach consensus?

If extending the timeline leads to fruitful discussions that eventually leads to consensus, this is a desirable outcome.

Then, my reading is that EVERY policy proposal can always reach consensus, is just a matter of finding enough folks (or virtual voices) that register into the mailing list and support the proposal vs non-supporters.

Not sure if you see my point?

Well, yes. If an active proposer manages to get enough friends in here, and also finds ways to shut down opposing voices by blackmail, bribery, enough beer, or other ways, then you can get every proposal through. I do not think this accurately reflects the process for 2016-04, though. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On 15 Jan 2018, at 12:09, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote:

Then, my reading is that EVERY policy proposal can always reach consensus, is just a matter of finding enough folks (or virtual voices) that register into the mailing list and support the proposal vs non-supporters.

Not sure if you see my point?

That's very true. I don't even understand what point you're trying to make. :-) Your reading/understanding of the PDP is flawed Jordi. RIPE642 explicitly says a proposal may not reach consensus. Or even get to a point where a consensus decision needs to be taken. So it's simply wrong to say every proposal can always reach consensus. Common sense should tell you that too. You should also be aware that we've had policy proposals which have died one way or another. They didn't reach consensus. QED. And yes, in theory it's possible for a charlatan to "stack the deck" by having their (ficticious) friends express support for a proposal. [That's an unwelcome side effect of having an open community with no membership/eligibility criteria.] This is where the sound judgement of the WG's chair comes in. They should be able to detect these kinds of manipulations and take appropriate action. There are further checks and balances too. The appeals procedure mean a dodgy consensus determination can be scrutinised by the WGCC and the RIPE chairman.

On Tue, Jan 16, 2018 at 11:40 AM, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote:

1) When you believe you agree with a policy proposal and declare it to the list (so chairs can measure consensus), do you “agree” only with the “policy text” or with the arguments written down in the policy proposal, or with the NCC interpretation (impact analysis), or all of them?

Obviously, if I state only that I agree, I agree that the policy proposal as written is acceptable, and should be implemented, in light of whatever arguments and analysis have been made.

2) What if the text in those 3 pieces are presenting contradictions or can be easily be interpreted in different ways?

In that case, I have probably not seen the contradictions, or don't think that they are contradictions. -- Jan

On 16 Jan 2018, at 11:19, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote:

My view is, in addition to that, if the contradictions are discovered during the PDP process, consensus can’t be declared until we can address them.

Nope. If the WG decides that it's OK for a proposal to have a contradiction or be confusing then there's a consensus for that PoV. It would of course be bad if a WG reached that conclusion. But if that's what they decide, it shouldn't prevent a consensus declaration. If a WG makes stupid choices, that's initially the WG's problem. And maybe that state of affairs would encourage someone to present a new proposal which will correct those bad decisions. Policy proposals (and policies) don't have to be perfect. The just have to be good enough.

Hi Jim, See below. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Jim Reid <jim@rfc1035.com> Fecha: martes, 16 de enero de 2018, 12:12 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] what does consensus mean > On 16 Jan 2018, at 10:40, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote: > > 1) When you believe you agree with a policy proposal and declare it to the list (so chairs can measure consensus), do you “agree” only with the “policy text” or with the arguments written down in the policy proposal, or with the NCC interpretation (impact analysis), or all of them? Depends. IIRC in the past I think I've just supported the proposal and not cared about the arguments behind it or the impact analysis. [Jordi] This has been my main way to evaluate a proposal always, read the policy text and decide upon that, because at the end, is the only one that can be enforced. > 2) What if the text in those 3 pieces are presenting contradictions or can be easily be interpreted in different ways? I would raise those issues and be crystal-clear about where the confusions or ambiguities were. And most likely talk to the WG chairs before taking those concerns to the list. [Jordi] I’m talking with the chairs about that since yesterday, even if I also think is a debate for the list, not just the chairs. Jordi, I think it's not helpful to continue this discussion. If you remain unhappy with the consensus declaration on 2016-04, please use the appeals machinery provided in the PDP instead of wasting everyone's time exploring rat-holes. [Jordi] I think it makes sense to avoid an appeal if we can clarify the situation before that. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi Gert, The problem in this case is that I don't think the IA is sharing our understanding ... at least from some of us, and thus contradicting the policy text, which you say is not possible. 1) Policy text say: "... separate addresses (not prefixes) ...". 2) Max proposal say: "... or anything alike where devices of non-members of the organisation would get assigned an IP out of the organisation’s prefix ..." 3) Max proposal say: "... Explicitly allowing another entity to be provided with addresses from a subnet ..." 4) Max proposal say: "... A subnet in the spirit of this policy is a prefix from the PI/PA assignment with a prefix length of /64 or longer ..." 5) Max proposal say: "... or for housing/hosting for servers in data centres ..." 6) IA say: "... There are cases where a /64 is needed per customer to provide a separate address ..." 7) IA say: "... 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. Any permanent and static assignments of a prefix would still be considered a sub-assignment ..." 8) IA say: "... by using single IPv6 addresses for End User devices and services ..." My point is that up to a /64 is a single prefix, so this contradicts 1 (not prefixes) above, vs 4 and 6. So, may be the right wording is "not multiple prefixes". Also, 1 say "addresses", but 2 say "an IP" and 3 say "addresses". 5 seem to indicate that this is acceptable in data centres, but 7 says permanent and static ... I don't see how a data centre can do temporary addresses? Further to that, email exchange with Marco/co-chairs, get me very confused ... as it is not clear to me if it is possible, if we pass this policy proposal, if from a single /64 prefix, a guest device can use a single /128 or, because the device needs multiple addresses (do we remember that devices in addition to the SLAAC or DHCP address make up automatically privacy addresses?), or if the device is running VMs, can use the same prefix with different addresses for those VMs ? Not to talk about a more complex case, such a device connecting to a hot stop and doing tethering to other devices from the same user ... If ONLY a single address can be used, technically is impossible to make this policy work, unless we have a mechanisms that MANDATE that the devices must use only SLAAC or only DHCPv6 and they MUST disable privacy addresses, and they MUST NOT run VMs. Is that realistic? Can we state in clear words (not referring to the complete policy proposal document), not a long page, just a few paragraphs, what do we have consensus on? My view, and Max could confirm if his view was this one, or if he will agree on that, up to a single /64 is ok, and you use one or multiple addresses of it, for one or multiple devices, but only in temporary "periods" of time (which match the usage in hot-spots, guest and employees BYOD in corporate networks, VPNs, temporary usage in data centers). I think the only case that is not temporary, and I agree, is the point-to-point link, which clearly should be allowed. I'm not sure if I'm missing any other possible cases, just trying to scope as much as possible all the possibilities thru a few examples. I don't know if this requires a new round with the policy returning it to the list or whatever is needed, or if it requires passing the policy even if it is clear (in my opinion) that is an "impossible to apply policy" (and thus consensus is irreal) and then I'm happy to make a new policy proposal, but my view is that it doesn't make any sense if we can clarify it now with a very simple modification of the policy text that Max proposed (even if it need 4 additional weeks for review period or whatever), that we could approve now something "imposible" and restart with a new policy. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Gert Doering <gert@space.net> Fecha: miércoles, 17 de enero de 2018, 18:09 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] what does consensus mean Hi, On Tue, Jan 16, 2018 at 11:40:28AM +0100, JORDI PALET MARTINEZ via address-policy-wg wrote: > 1) When you believe you agree with a policy proposal and declare it to the list (so chairs can measure consensus), do you ???agree??? only with the ???policy text??? or with the arguments written down in the policy proposal, or with the NCC interpretation (impact analysis), or all of them? People sometimes explicitely mention this ("I agree with the aims of the proposal and the way it is written"). Sometimes they don't agree with all of it ("I agree with the aims of the proposal but the text needs more work"). And sometimes they state "support", which I take as an indication that they agree both with the aim and the wording of the proposal. > 2) What if the text in those 3 pieces are presenting contradictions or can be easily be interpreted in different ways? We've had proposals where the IA brought up very much inintended consequences (contradicting the rationale, the IA cannot "contradict the policy text"), and this was addressed by a new round of policy text and new IA. Which is, basically, why we have the IA in the first place: ensure that the NCC shares our understanding of what we're asking the colleagues to do. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

In my opinion there are 3 points to clarify: 1) Temporary always ? clearly not for point-to-point links, no-sense for data centers? 2) Single address (/128) for a single device (so the device can't use privacy? Utopia!), or do we allow if the devices get a single-prefix, it uses multiple addresses out of that prefix (so we allow VMs in the device also) 3) Can the device use any technology (such as prefix sharing, eg. RFC7278), to also use addresses from a single prefix for other devices (same user) Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Sander Steffann <sander@steffann.nl> Fecha: viernes, 19 de enero de 2018, 11:58 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, Marco Schmidt <mschmidt@ripe.net> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] what does consensus mean Hi Jordi, > 1) Policy text say: "... separate addresses (not prefixes) ...". > 2) Max proposal say: "... or anything alike where devices of non-members of the organisation would get assigned an IP out of the organisation’s prefix ..." > 3) Max proposal say: "... Explicitly allowing another entity to be provided with addresses from a subnet ..." > 4) Max proposal say: "... A subnet in the spirit of this policy is a prefix from the PI/PA assignment with a prefix length of /64 or longer ..." > 5) Max proposal say: "... or for housing/hosting for servers in data centres ..." > 6) IA say: "... There are cases where a /64 is needed per customer to provide a separate address ..." > 7) IA say: "... 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. Any permanent and static assignments of a prefix would still be considered a sub-assignment ..." > 8) IA say: "... by using single IPv6 addresses for End User devices and services ..." > > [...] > > 5 seem to indicate that this is acceptable in data centres, but 7 says permanent and static ... I don't see how a data centre can do temporary addresses? Now that is indeed a contradiction that I agree with. Here the NCC's interpretation is more strict than what the policy says, and that should be corrected. Marco, can you look at this again from the NCC's perspective? Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi,

1) Temporary always ? clearly not for point-to-point links, no-sense for data centers?

Indeed, this is what I asked Marco.

2) Single address (/128) for a single device (so the device can't use privacy? Utopia!), or do we allow if the devices get a single-prefix, it uses multiple addresses out of that prefix (so we allow VMs in the device also)

The policy talks about single-address increments. It doesn't say "one address", it says "separate addresses" (plural), which allows for privacy extensions etc.

3) Can the device use any technology (such as prefix sharing, eg. RFC7278), to also use addresses from a single prefix for other devices (same user)

Technology used is out of scope here. Cheers, Sander

On 16/01/2018 10:02, Jim Reid wrote:

And yes, in theory it's possible for a charlatan to "stack the deck" by having their (ficticious) friends express support for a proposal.

Actually, if "rough consensus" is applied properly (and you could criticise what I'm about to say by saying is overly theoretical), I don't think stacking the audience with supporters does achieve rough consensus. Rough consensus should never be about counting noses. That's because I don't think that "rough consensus" is primarily about how many supporters a proposal has, I think it's about primarily about the nature and quality of the objection. If there are no objections, that's unanimous approval, which is a subset of rough consensus. If there are objections, the number of objections isn't a first order concern (although that can be a signal of something else). If the objections are recognised as being serious, valid concerns that haven't been properly addressed, then the Chairs should find that "rough consensus" has not yet been achieved. And it shouldn't really matter how few people object, except insofar as a signal (if nobody has been persuaded, why is that? Perhaps this signals an underlying flaw in the objection, that allows it to be legitimately discarded). If the only objections are invalid (e.g. out of scope) or have been properly addressed, then it is possible to find a rough consensus notwithstanding that some (or even many) people still have (invalid) objections or aren't willing to accept that their point has been dealt with. In the present case, Sander wrote:

Short summary: - a problem was discovered in the IPv6 policy - we see consensus that this policy proposal solves that problem - we recognise that you would like an even better solution - and we'll happily work with you to achieve that! - but because this proposal solves the original problem we don't want to delay it

To me, that reads as an admirably clear and succinct explanation in the category "we've dealt with your objection, now we're moving on". Of course, what constitutes an "invalid" objection is hard to describe and extremely difficult to define completely, perhaps not even possible. But I'm sure we can all think of examples. Here's one: "I don't think this policy should be approved because RIPE has no legitimate authority to make policy; that is the purview of governments" would, IMO, be an invalid objection, on the grounds that the central question it poses (does RIPE has legitimate policy-making authority?) is out of scope for a discussion about whether X should be approved (possibly on other, more complicated grounds too). If someone packed the floor / mailing list, with hundreds of people who agreed with that proposition, I think the proper course of action for a APWG Chair would be to ignore all of them. There's a time and a place for that kind of discussion. During a PDP is not it. This does invest an awful lot of responsibility in the WG Chairs (or, for matters considered by the community as a whole, the RIPE Chair), to discern and discriminate between a valid of objection and an invalid one. It is requires a lot of rather subjective judgement, not on the matter at hand, but on the nature of the discussion and our community and its purpose and values and what we consider a legitimate frame of discussion. While I happen to think that having a conversation that attempts to broaden a common understanding of the kinds of things that Chairs ought to consider invalid objections would be beneficial, not least for the WG Chairs and especially future Chairs, this can only be a discussion of principles and norms, it can never be turned into a rigid set of rules. This model will always rest heavily on the judgment of the Chairs. I'm OK with that. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA

Thanks Malcolm, I think this is a perfect definition of consensus and it shows that "more voices" not necessarily means "consensus". However, I really think, regardless if there are or not objections, consensus can't be achieved on "non-sense" or "unrealistic" proposals which can't be enforced. Part of the problem is because it looks like instead of giving priority to the "policy text", we also obey the policy proposal, the IA, and so, which are not in the "policy manual". I'm going to talk about this in a new thread to avoid mixing things with this concrete policy proposal. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Malcolm Hutty <malcolm@linx.net> Fecha: martes, 16 de enero de 2018, 12:11 Para: Jim Reid <jim@rfc1035.com>, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] what does consensus mean On 16/01/2018 10:02, Jim Reid wrote: > And yes, in theory it's possible for a charlatan to "stack the deck" by having their (ficticious) friends express support for a proposal. Actually, if "rough consensus" is applied properly (and you could criticise what I'm about to say by saying is overly theoretical), I don't think stacking the audience with supporters does achieve rough consensus. Rough consensus should never be about counting noses. That's because I don't think that "rough consensus" is primarily about how many supporters a proposal has, I think it's about primarily about the nature and quality of the objection. If there are no objections, that's unanimous approval, which is a subset of rough consensus. If there are objections, the number of objections isn't a first order concern (although that can be a signal of something else). If the objections are recognised as being serious, valid concerns that haven't been properly addressed, then the Chairs should find that "rough consensus" has not yet been achieved. And it shouldn't really matter how few people object, except insofar as a signal (if nobody has been persuaded, why is that? Perhaps this signals an underlying flaw in the objection, that allows it to be legitimately discarded). If the only objections are invalid (e.g. out of scope) or have been properly addressed, then it is possible to find a rough consensus notwithstanding that some (or even many) people still have (invalid) objections or aren't willing to accept that their point has been dealt with. In the present case, Sander wrote: > Short summary: > - a problem was discovered in the IPv6 policy > - we see consensus that this policy proposal solves that problem > - we recognise that you would like an even better solution > - and we'll happily work with you to achieve that! > - but because this proposal solves the original problem we don't want to delay it To me, that reads as an admirably clear and succinct explanation in the category "we've dealt with your objection, now we're moving on". Of course, what constitutes an "invalid" objection is hard to describe and extremely difficult to define completely, perhaps not even possible. But I'm sure we can all think of examples. Here's one: "I don't think this policy should be approved because RIPE has no legitimate authority to make policy; that is the purview of governments" would, IMO, be an invalid objection, on the grounds that the central question it poses (does RIPE has legitimate policy-making authority?) is out of scope for a discussion about whether X should be approved (possibly on other, more complicated grounds too). If someone packed the floor / mailing list, with hundreds of people who agreed with that proposition, I think the proper course of action for a APWG Chair would be to ignore all of them. There's a time and a place for that kind of discussion. During a PDP is not it. This does invest an awful lot of responsibility in the WG Chairs (or, for matters considered by the community as a whole, the RIPE Chair), to discern and discriminate between a valid of objection and an invalid one. It is requires a lot of rather subjective judgement, not on the matter at hand, but on the nature of the discussion and our community and its purpose and values and what we consider a legitimate frame of discussion. While I happen to think that having a conversation that attempts to broaden a common understanding of the kinds of things that Chairs ought to consider invalid objections would be beneficial, not least for the WG Chairs and especially future Chairs, this can only be a discussion of principles and norms, it can never be turned into a rigid set of rules. This model will always rest heavily on the judgment of the Chairs. I'm OK with that. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi Nick, I participate on IETF, and I know RFC7282, however I fail to see in our PDP that we are bound to that RFC? I also just read again the PDP, and my understanding is that we are doing something different than what the process say, following https://www.ripe.net/publications/docs/ripe-642 I don’t see how a policy proposal that at the end of the review phase (maximum 4 weeks), has not reached consensus, as the only alternative is a “new” review phase, with a new version of the proposal:

From the PDP: “The WG chair can also decide to have the draft RIPE Document edited and start a new Review Phase with a new version of the proposal.”

Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Nick Hilliard <nick@foobar.org> Fecha: lunes, 15 de enero de 2018, 12:17 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification) JORDI PALET MARTINEZ via address-policy-wg wrote: > Obviously, I don’t agree, just because for me, “consensus” is having > no objections, not a “democracy voting”. APWG aims to follow the IETF approach to consensus, as defined in rfc7282. This explicitly allows for consensus to be declared even if there are outstanding objections. Nick ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi Sander, I know Gert and you very well, and I don’t have any doubt that it was not done in a “malicious” way, but I think the PDP has not been followed correctly. Again, is not a matter of this concrete proposal, is a generic concern on the PDP application. Regards, Jordi -----Mensaje original----- De: Sander Steffann <sander@steffann.nl> Fecha: lunes, 15 de enero de 2018, 13:28 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification) Hi Jordi, > I participate on IETF, and I know RFC7282, however I fail to see in our PDP that we are bound to that RFC? As Jim has said, the definition of consensus is determined by consensus :) And for this working group the chairs apply consensus roughly based on that RFC. > I also just read again the PDP, and my understanding is that we are doing something different than what the process say, following > > https://www.ripe.net/publications/docs/ripe-642 > > I don’t see how a policy proposal that at the end of the review phase (maximum 4 weeks), has not reached consensus, as the only alternative is a “new” review phase, with a new version of the proposal: > > From the PDP: > “The WG chair can also decide to have the draft RIPE Document edited and start a new Review Phase with a new version of the proposal.” In RIPE the chairs are allowed to use common sense and their own judgement when chairing a working group. Please don't try to make rules for everything, we're not lawyers, we're people trying to get work done in the best interests of this community. Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

The point is not only the PDP, as I believe we are still on time to correct the policy proposal, which I think is broken and contradicting itself. See my last email on the details, and a proposed text to resolve it, which according to the PDP, we can still apply I think, without the need to wait for the concluding phase and then the appeal. Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Jim Reid <jim@rfc1035.com> Fecha: lunes, 15 de enero de 2018, 14:24 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification) > On 15 Jan 2018, at 12:49, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote: > > I think the PDP has not been followed correctly. In that case Jordi, you can use the PDP to raise those concerns. Though I think you're actually complaining about Gerd's consensus declaration on 2016-04 rather than whether the PDP has been followed or not. I quote from Section 3.2 of the PDP: Anyone who believes that the proposal has not been handled correctly or that the WG chair has made an incorrect determination of consensus should first raise the matter with the WG chair. If the dispute cannot be resolved with the WG chair, the Appeals Procedure can be invoked. And from Section 4: 4. Appeals Procedure If a grievance cannot be resolved with the chair of the WG the matter can be brought to the attention of the Working Group Chairs Collective (WGCC). Anyone may submit an appeal. This must be submitted to the relevant WG mailing list(s) and to the Policy Announce Mailing List (policy-announce@ripe.net). The appeal will also be published by the RIPE NCC at appropriate locations on the RIPE web site. Any appeal should include a detailed and specific description of the issues and clearly explain why the appeal was submitted. An appeal must be submitted no later than four weeks after the appealable action has occurred. AFAICT it's you who isn't following the PDP. :-) You don't seem to have discussed your objections to the consensus determination with the WG co-chairs or indicated that those discussions failed to resolve your complaint. No matter. If we've passed that point, you can still appeal to the WGCC. But that requires a detailed and specific description of the issues and an explanation of why the appeal was necessary. That hasn't happened. At least not yet. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Hi Sander, My reading of PDP 2.4 is not that we can’t make changes (which I believe are in the same direction of the proposal, look for my questions below, so no substantial changes, only making sure that we have in the text what we want). My reason to re-raise those now, is because they become evident when you compare the proposed 2.6 change with the policy proposal arguments AND specially the impact analysis, contradictions which for some reason, I didn’t discover before (so disagree with you, those points aren’t the same I raised before, may be similar, but the reason now is the contradictory text), and this seems to be in the scope of PDP 2.4. The author of the proposal and the NCC could confirm their intent: 1) Is the proposal looking for disallowing a /64 ? If so, then the impact analysis is broken and NCC is looking to implement something different than what the proposal is asking for. 2) The proposal clearly is NOT intended for “permanent” broadband services, but his is NOT stated in the proposed text change. I doubt that the NCC can enforce a policy that don’t have that stated in the policy text. Can the NCC confirm that? 3) I also believe that the policy isn’t pretending to be used in data centers. Can this be clarified? Regarding a possible appeal. The procedure talks about “unless there are exceptional extenuating circumstances”. I think it is the case for an impact analysis contradicting the proposal. Is up the chairs to decide that, of course and I understand that you may need to wait until the end of the last call to decide on that (this is the reason why I understand that the appeal doesn’t make sense now, unless you have already taken a decision). If you believe is not the case, then, please let me know how to send the appeal to the “Working Group Chairs Collective (WGCC)”, I guess there is a mailing list for that? Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Sander Steffann <sander@steffann.nl> Fecha: lunes, 15 de enero de 2018, 15:58 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification) Hi Jordi, > The point is not only the PDP, as I believe we are still on time to correct the policy proposal, which I think is broken and contradicting itself. > > See my last email on the details, and a proposed text to resolve it, which according to the PDP, we can still apply I think We don't make any substantial changes in/after last call. Any "final changes" would be typo's. clearing up language etc. This is not the time to make changes to the core of the policy proposal. And besides: you're not coming up with new arguments. These are the same arguments that you have voiced before. You have been heard in previous phases of the PDP, we seriously considered their merit, extended the review phase (and please stop complaining about not making any textual changes for the extended review phase, as I explained that is the discretion of the working group chairs) to see if there was support for your approach, and reached the conclusion that there wasn't. Your ideas have been heard and seriously considered, but despite that we determined that there is rough consensus to continue with the current version and leave the changes you want for a future policy proposal. In the language of the RFC: we have addressed your objections, but not accommodated them. > , without the need to wait for the concluding phase and then the appeal. No need to wait. You can appeal the decision to declare consensus right now if you think our judgement was wrong. Feel free to do so. I'm confident we made the right decision, but we're human so if you think we made a mistake then let's ask the Working Group Chairs Collective what they decide. As far as I'm concerned reviewing the policy proposal is done. We have rough consensus on the content and have moved to last call. If new objections come up with supporting arguments and they can't be addressed then we will declare lack of consensus at the end of last call. Raising the same objections as before is not going to block consensus in this phase: we already consider those objections addressed. Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Below, in-line. Saludos, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Sander Steffann <sander@steffann.nl> Fecha: lunes, 15 de enero de 2018, 17:37 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification) Hi, > My reading of PDP 2.4 is [..] Please stop being a lawyer. I have told you how we do things in this working group. Please listen to what the chairs are telling you. > My reason to re-raise those now, is because they become evident when you compare the proposed 2.6 change with the policy proposal arguments AND specially the impact analysis, contradictions which for some reason, I didn’t discover before (so disagree with you, those points aren’t the same I raised before, may be similar, but the reason now is the contradictory text), and this seems to be in the scope of PDP 2.4. I think you are mis-interpreting the policy proposal. I see no such contradiction. > The author of the proposal and the NCC could confirm their intent: > 1) Is the proposal looking for disallowing a /64 ? If so, then the impact analysis is broken and NCC is looking to implement something different than what the proposal is asking for. The policy is explicitly not mentioning prefix lengths but clarifying intentions. Delegating a prefix is still not allowed. The NCC explains in the impact analysis that having only a single device/user/etc on a subnet (i.e. RFC8273) is treated the same as having multiple users on a subnet: both are not considered assignments and are therefore permitted. [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 > 2) The proposal clearly is NOT intended for “permanent” broadband services, but his is NOT stated in the proposed text change. I doubt that the NCC can enforce a policy that don’t have that stated in the policy text. Can the NCC confirm that? The proposal adds a one-paragraph extension to the existing policy to allow connecting devices to a network: "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. [...and some examples...]". There are more use-cases than you and I can think of, and trying to enumerate which ones are allowed and which ones aren't is bad overengineering. This has been discussed before. And these days it's not viable to provision broadband customers without delegating (DHCPv6-PD) address space to them anyway. [Jordi] Again, we are in-sync, but I don’t agree that DHCPv6-PD is the only way, and the actual proposal text doesn’t state it, even if the argument of the proposal explain it. Can the NCC confirm if they apply the policy text or the “arguments” of the policy proposal? I think it is the policy text, so we are missing something. > 3) I also believe that the policy isn’t pretending to be used in data centers. Can this be clarified? Where did you get that idea? "connecting a server or appliance to an assignment holder's network" is one of the explicit examples of what is allowed. [Jordi] I fully understand that text, but still think that is not the same if I run a host/server in a hotspot, with many VMs, using RFC8273 or DHCPv6-PD or a manual or proprietary mechanisms, which I fully understand within the intent of the policy (and I agree), vs running a complete data center (which typically is using non-temporary addresses/prefixes). Again, I think it may be clear in the argument of the proposal, but not in the policy text. Which one is used by NCC to evaluate a request? > Regarding a possible appeal. The procedure talks about “unless there are exceptional extenuating circumstances”. > > I think it is the case for an impact analysis contradicting the proposal. I think you are reading more into this proposal that what is actually there, and based on that have misinterpreted it. > Is up the chairs to decide that, of course and I understand that you may need to wait until the end of the last call to decide on that (this is the reason why I understand that the appeal doesn’t make sense now, unless you have already taken a decision). You're misunderstanding what we are suggesting you appeal to. We're suggesting you appeal the decision that there was consensus at the end of the review phase and that the proposal was ready to go to last-call. If you don't agree with that decision then you can appeal it. At the end of last-call there will be another decision about whether we have consensus or not, based on the feedback received during last-call. That decision has (of course) not been made yet, but as I said in my previous email I so far haven't seen any reasons that block that consensus *yet*. We'll have to wait for the end of last-call to make a final judgement :) [Jordi] Believe me, I’m not interested in appealing, I’m interested in reaching consensus on a text that is coherent. My reading of the actual situation is that even if it may look that we have consensus, when you re-read everything and put it together towards implementing the policy, it doesn’t work. The text is not concrete enough so to be enforced in the evaluation (again, unless the NCC read the arguments and not the policy text). > If you believe is not the case, then, please let me know how to send the appeal to the “Working Group Chairs Collective (WGCC)”, I guess there is a mailing list for that? Sure: RIPE WG Chairs <wg-chairs@ripe.net> Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Understood, even do, I will love to heard that from the NCC, because the disadvantage is that then to interpret the policy text, you need to read “all” the policy proposals, which I don’t think is very nice or useful. Despite that, I still believe that my proposed text (or something a bit lighter, in the middle) is not changing the proposal goal, so not changing the consensus “status”, neither doing the “micro-management” that you mention, so it is acceptable as last call changes, of course if Max agree. The benefit is that then it is very clear what we are looking for and a newcomer don’t need to look for the policy proposal, just read the policy text. Here is again the text already lighter: “Providing another entity with separate addresses (up to /64) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example, letting visitors and/or employees (BYOD) connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties.” To make it easy to compare, this is the existing proposal text: “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. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-¬to-point links with 3rd parties.” Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Sander Steffann <sander@steffann.nl> Fecha: lunes, 15 de enero de 2018, 18:46 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification) Hi Jordi, > [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 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. And Max is correct: when in doubt the RIPE NCC will check the rationale behind a policy proposal to make decisions, and they have clearly and explicitly stated that this is how they will interpret and implement it. Therefore there is no discrepancy between the text and the impact. > The text is not concrete enough so to be enforced in the evaluation (again, unless the NCC read the arguments and not the policy text). 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. The community has agreed not to micro-manage the NCC, and the NCC has promised to apply common sense when implementing policy. We also have a dedicated slot in the working group session where the NCC gives feedback on how things are going, where they have encountered any issues and where reality has changed so much that maybe the working group might want to look into changing policy. 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. 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. 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. Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

What I’m trying to avoid is what I read as a contradiction among the policy text, the argumentation and the impact analysis, so I don’t really care about a fix number and I agree to let “it free” to avoid technology issues. According to that, I guess this may work: “Providing another entity with separate addresses (or a complete single prefix) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example, letting visitors and/or employees (BYOD) connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties.” The point is to avoid “(not prefixes)”, because I think not prefixes also excludes a single prefix. Another alternative (I think is easier to understand the previous one, but just in case): “Providing another entity with separate addresses (not multiple prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example, letting visitors and/or employees (BYOD) connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties.” Saludos, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Sander Steffann <sander@steffann.nl> Fecha: lunes, 15 de enero de 2018, 22:11 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification) Hi Jordi, > “Providing another entity with separate addresses (up to /64) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example, letting visitors and/or employees (BYOD) connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties.” An explicit choice was made in this version that specifying fixed boundaries (like a /64) should be avoided to avoid dependencies on specific technology. Please compare version 1 and version 2 of this proposal. Your suggested change would therefore be a partial reversion to a version that didn't have consensus, which would not be appropriate at this point in the process. Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

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,

...

[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

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.

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 lease//on 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 …

when in doubt the RIPE NCC will check the rationale behind a policy proposal to make decisions

… 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 …

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.

… 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.

The community has agreed not to micro-manage the NCC, and the NCC has promised to apply common sense when implementing policy.

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?

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.

But this is not the case here. Current policy, https://www.ripe.net/publications/docs/ripe-684, /is/ cristal clear already:

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.

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.

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.

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?

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.

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] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-October/01183... [2] https://www.ripe.net/participate/policies/proposals/2016-04/?version=1 [3] https://tools.ietf.org/html/rfc4291#section-2.3

Hi, On Mon, Jan 15, 2018 at 01:49:58PM +0100, JORDI PALET MARTINEZ via address-policy-wg wrote:

I know Gert and you very well, and I don???t have any doubt that it was not done in a ???malicious??? way, but I think the PDP has not been followed correctly.

Again, is not a matter of this concrete proposal, is a generic concern on the PDP application.

We've been doing this numerous times, and nobody from the community has ever objected to "extending one of the periods to get more discussion going, or more input", or filed a formal appeal based on such procedure. So, please make up your mind what is bothering you - us not following the PDP properly - a policy proposal not to your liking - the PDP as excercised here leading to an outcome not to your liking - your own policy proposal not yet submitted to the machinery, so a somewhat competing (if inferior in your opinion) proposal advancing - the WG chairs beeing bloody idiots (this will change soon anyway) none of this will change our decision, but it would make it more easy to the rest of the readers to understand why you're so angry *right now*, while neither the announcement of the extention nor the voices of support in the four weeks following said announcement seem to have bothered you in the least. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: Hi Jordi,

none of this will change our decision, but it would make it more easy to the rest of the readers to understand why you're so angry *right now*, while neither the announcement of the extention nor the voices of support in the four weeks following said announcement seem to have bothered you in the least.

[Jordi] I’m not angry at all, I just realized now that the text is not consistent. I think it has been clear in my previous email to Sander. I think now is clear that we all have the same view, but the text don’t look correct to me, unless the NCC don’t care and in the evaluation they will read the arguments of the policy proposal, which I believe are confirming what I’m saying (trying to summarize: up to /64, temporary, not for broadband, not for “permanent” datacenter services).

As said before somewhere (I'm not sure wether on a RIPE meeting or here on the list), the RS folks said, that they use the proposal text as well as the summary/rationale as guidance what is allowed and what isn't. Maybe Ingrid, Andrea, Marco, * from the NCC can comment on that? So to quote the proposal summary (last paragraph): --snip-- Intended use cases for IPv6 PI space in the spirit of this policy proposal are the use in (public) WIFI networks (like the WIFI at RIPE meetings), as transfer networks on PNIs or other PTP-links/VPNs to users or customers, or for housing/hosting for servers in data centres. The use of IPv6 PI space for DSL/cable/FFTH/etc. subscribers is explicitly not an intended use case for this policy proposal. --snip-- That's quite clear IMHO (and does not fully match with your summary). The obvious and long discussed goal of this whole thing still is to make PI space useable again for "the little guy", community projects, etc. As you well know the motivation to do so has risen with public WIFI networks + SLAAC in mind, but any other means of address assignment to clients (as you mentioned and the IA states) are OK as well. This is the RIPE AP, it should not mention technical details which are subject to change anyway. Best Max -- "Does is bother me, that people hurt others, because they are to weak to face the truth? Yeah. Sorry 'bout that." -- Thirteen, House M.D.

Dear Max, On 2018-01-15 18:23:42 CET, Maximilian Wilhelm wrote:

As said before somewhere (I'm not sure wether on a RIPE meeting or here on the list), the RS folks said, that they use the proposal text as well as the summary/rationale as guidance what is allowed and what isn't.

Maybe Ingrid, Andrea, Marco, * from the NCC can comment on that?

Yes, this is correct. Whenever there is a question about the interpretation of RIPE Policies, we can refer to proposal summary as well to the impact analysis to ensure the correct understanding of the policy and its intent. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Dear Jordi, Thank you for your question. On 2018-01-15 11:21:10 CET, Jordi Palet Martinez wrote:

Furthermore, I will like a clarification from NCC about what I mention in the mike, I think is this comment:

One of the opposing remark was that this would prevent "unique prefix per host" style allocations, but that was addressed by Marco at the APWG meeting already - the RS interpretation is "this would work".

My comment during the Address Policy WG session at RIPE 75 was referring to configuration mechanisms where a /64 is needed per customer to provide a separate address, for instance by using dedicated (V)LANs to connect WiFi customers. Such mechanisms will be considered in line with the policy. Section A of the impact analysis provides more details on our understanding for these cases. https://www.ripe.net/participate/policies/proposals/2016-04 I hope this clarifies. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

On 15 Jan 2018, at 13:21, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote:

Hi Marco,

I feel then contradictory this:

... detailed nit-picking of policy proposal deleted ... Jordi, we're past the point where substantive discussion of 2016-04 takes place. That's supposed to stop once a proposal reaches Last Call. I quote from Section 3.2 of the PDP again: At these stages of the process – i.e. after the WG chair has declared initial consensus or the proposal is in Last Call – complaints should not be about the policy proposal itself unless there are exceptional extenuating circumstances.

On Mon, Jan 15, 2018 at 11:21 AM, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> wrote:

This basically means that I can also do the same every month when I speak in about IPv6 in a conference, for any subsequent proposal that I submit, and get hundreds of “support voices” even if there is objection (for example to remove PI),

If mentioning your PDP in talks gathers hundreds of public support statements, your PDP is already the most popular one ever. Having seen the amount of "please speak up for this" vs the actual outcome, I would say that eleven support statements is already a lot.

or even more, I could register tons of emails and speak up in favor of my own proposal, and of course, there is nothing in the PDP that disallows that (if anyone is able to demonstrate that is my own voice cloned).

That would be malicious; and potentially illegal in some jurisdictions. Richard