Re: [address-policy-wg] inconsistency in 2016-04

[Jim Reid]

> On 19 Jan 2018, at 13:41, Gert Doering  wrote:
> 
> Changing the PDP itself is not something we can do here in AP, though - that
> is something the plenary needs to agree, as the PDP governs all working
> groups.

Indeed.

It will almost certainly be far quicker and much less painful to push a new 
policy proposal through the PDP than get the PDP changed.

Jordi if you think the PDP is defective, by all means explain what the 
problem(s) is and suggest solution(s). However if you do down that path in the 
hope of resolving your unhappiness with the consensus decision on 2016-04 I 
think you may well become even more unhappy.

Another troubling data point for everyone: This proposal started in 2016. It's 
now 2018.

Re: [address-policy-wg] inconsistency in 2016-04

[Gert Doering]

Hi,

On Fri, Jan 19, 2018 at 02:28:00PM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> I know, but if unclear points or discrepancies are discovered in the actual 
> stage, how we resolve them?

Technically, if *new* (and significant) counterarguments come up in Last 
Call, the proposal can be returned to Discussion or Review Phase at the end.  

In practice, I think this only happened once.

"I read this differently from everyone else and I find it confusing" is not 
something I'd consider "new and significant", though, unless this reading
is shared by a wider group.

> I understand that the PDP may have imperfections and we never realized that, 
> not sure if it is the case.

Oh, the PDP is far from perfect.  Most annoyingly, it takes a hell of a lot
of work to get even the smallest change done, because there are so many
stages where proposals can stall...

Changing the PDP itself is not something we can do here in AP, though - that
is something the plenary needs to agree, as the PDP governs all working
groups.

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

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [address-policy-wg] inconsistency in 2016-04

[JORDI PALET MARTINEZ via address-policy-wg]

I know, but if unclear points or discrepancies are discovered in the actual 
stage, how we resolve them?

I understand that the PDP may have imperfections and we never realized that, 
not sure if it is the case.

Regards,
Jordi

-Mensaje original-
De: address-policy-wg  en nombre de Gert 
Doering 
Fecha: viernes, 19 de enero de 2018, 14:23
Para: JORDI PALET MARTINEZ 
CC: 
Asunto: Re: [address-policy-wg] inconsistency in 2016-04

Hi,

On Fri, Jan 19, 2018 at 02:19:54PM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> What I'm saying is that, if we can't change the policy text, at least we 
make sure that those cases are crystal clear in the IA.
> 
> Or is that also breaking the PDP?

The IA happens at a well-defined point in time: before the review period
starts.

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

SpaceNet AGVorstand: 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.

Re: [address-policy-wg] inconsistency in 2016-04

[Gert Doering]

Hi,

On Fri, Jan 19, 2018 at 02:19:54PM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> What I'm saying is that, if we can't change the policy text, at least we make 
> sure that those cases are crystal clear in the IA.
> 
> Or is that also breaking the PDP?

The IA happens at a well-defined point in time: before the review period
starts.

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

SpaceNet AGVorstand: 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


signature.asc
Description: PGP signature

Re: [address-policy-wg] inconsistency in 2016-04

[JORDI PALET MARTINEZ via address-policy-wg]

What I'm saying is that, if we can't change the policy text, at least we make 
sure that those cases are crystal clear in the IA.

Or is that also breaking the PDP?

Regards,
Jordi

-Mensaje original-
De: address-policy-wg  en nombre de Sander 
Steffann 
Fecha: viernes, 19 de enero de 2018, 12:45
Para: JORDI PALET MARTINEZ 
CC: 
Asunto: Re: [address-policy-wg] inconsistency in 2016-04

Hi,

> Below in-line.

Please use normal quoting, I have trouble reading your emails.

> Right, but 6) IA say: "... There are cases where a /64 is needed per 
customer to provide a separate address ..." and 8) IA say: "... by using single 
IPv6 addresses for End User devices and services ..." furthermore it say "... 
provided no prefixes will be provided to other entities ..." I think this can 
be sorted out replacing in the IA "provided no more than a single prefix will 
be provided to other entities."

No, that would drastically change the policy, and that has been looked at 
before. It was then decided that that is not the right approach.

> I used the technology as an example, what I'm referring is if the single 
prefix can be shared by other devices of the user of a hot-spot (example, the 
hotel gives me a single /64 in the WiFi, but I've several devices). The point 
here is, clarification 2 above will solve the problem for multiple addresses in 
a single prefix, 3) may solve the problem for multiple devices with the same 
prefix. For both of them we may need to clarify if Max "not prefixes" is 
meaning also a single prefix or "not multiple prefixes", which is I think the 
major contradiction with the IA or NCC interpretation according to mail 
exchange with Marco.

Sorry, what someone does with addresses is completely out of scope here.

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.

Re: [address-policy-wg] inconsistency in 2016-04

[Sander Steffann]

Hi,

> Below in-line.

Please use normal quoting, I have trouble reading your emails.

> Right, but 6) IA say: "... There are cases where a /64 is needed per customer 
> to provide a separate address ..." and 8) IA say: "... by using single IPv6 
> addresses for End User devices and services ..." furthermore it say "... 
> provided no prefixes will be provided to other entities ..." I think this can 
> be sorted out replacing in the IA "provided no more than a single prefix will 
> be provided to other entities."

No, that would drastically change the policy, and that has been looked at 
before. It was then decided that that is not the right approach.

> I used the technology as an example, what I'm referring is if the single 
> prefix can be shared by other devices of the user of a hot-spot (example, the 
> hotel gives me a single /64 in the WiFi, but I've several devices). The point 
> here is, clarification 2 above will solve the problem for multiple addresses 
> in a single prefix, 3) may solve the problem for multiple devices with the 
> same prefix. For both of them we may need to clarify if Max "not prefixes" is 
> meaning also a single prefix or "not multiple prefixes", which is I think the 
> major contradiction with the IA or NCC interpretation according to mail 
> exchange with Marco.

Sorry, what someone does with addresses is completely out of scope here.

Cheers,
Sander

[address-policy-wg] inconsistency in 2016-04

[JORDI PALET MARTINEZ via address-policy-wg]

(sorry Jim ! subject replaced)

Hi Sander,

Below in-line.

Regards,
Jordi

-Mensaje original-
De: address-policy-wg  en nombre de Sander 
Steffann 
Fecha: viernes, 19 de enero de 2018, 12:13
Para: JORDI PALET MARTINEZ 
CC: 
Asunto: Re: [address-policy-wg] what does consensus mean

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.

Right, but 6) IA say: "... There are cases where a /64 is needed per customer 
to provide a separate address ..." and 8) IA say: "... by using single IPv6 
addresses for End User devices and services ..." furthermore it say "... 
provided no prefixes will be provided to other entities ..." I think this can 
be sorted out replacing in the IA "provided no more than a single prefix will 
be provided to other entities."


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

I used the technology as an example, what I'm referring is if the single prefix 
can be shared by other devices of the user of a hot-spot (example, the hotel 
gives me a single /64 in the WiFi, but I've several devices). The point here 
is, clarification 2 above will solve the problem for multiple addresses in a 
single prefix, 3) may solve the problem for multiple devices with the same 
prefix. For both of them we may need to clarify if Max "not prefixes" is 
meaning also a single prefix or "not multiple prefixes", which is I think the 
major contradiction with the IA or NCC interpretation according to mail 
exchange with Marco.


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.

[address-policy-wg] policy text or anything else?

[JORDI PALET MARTINEZ via address-policy-wg]

Hi all,

I've changed the subject, because I want to talk here in general about our 
policy process, not any specific policy.

I've tried to find where in our process, states that in addition to the policy 
text itself, other inputs during the PDP matter.

If there is such confirmation, could the NCC tell me how to find it?

I understand that this may have been our "practice", but maybe we did wrong. 
Let me explain why I think is wrong, and consequently we need to correct it.

Let's suppose I'm an organization asking for the first time IPv6 space, I will 
find the actual policy at
https://www.ripe.net/publications/docs/ripe-684

I read across it, and I obviously will decide, based on my needs what choices 
I've to apply for.

I've not followed the PDP since the first time we discussed an IPv6 policy, so 
I'm missing all the policy proposals text, arguments, rationales, impact 
analysis, etc.

Because that, I'm applying with a different view from someone that has been for 
ages in the addressing policy list and following it, and possible not taking 
advantages of perspectives that are "in between lines" in the policy text, 
which may make a huge difference on my request vs a "follower" of the PDP.

I would agree with that (using not only the policy text, but also all the PDP 
documents) IF when I go to the ripe-684 document, I've direct links in every 
section of the policy text, pointing to the PDP documents that have been used 
to modify that section.

I hope everybody understand what I mean, not sure if is so easy to explain.

Now, is that realistic? It will make our policy text so difficult to read ... 
and a very very very long (and always increasing) document.

So, my conclusion: what it matters is only policy text, other documents are 
relevant to explain it, but not to add "modifications" to the reading of that 
text so not conflicts should be there (unless undiscovered).

I agree that we are humans and we can make mistakes, and we may need to go to 
new rounds of PDP to correct that, new proposals, or whatever, but even if it 
takes some extra work, policy text must be refined if discrepancies are 
perceived.

Regards,
Jordi



-Mensaje original-
De: address-policy-wg  en nombre de Marco 
Schmidt 
Fecha: martes, 16 de enero de 2018, 16:05
Para: 
Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment 
Clarification)

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





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

Re: [address-policy-wg] inconsistency in 2016-04 (was: what does consensus mean)

[Sander Steffann]

Hi Jim,

> PLEASE put those comments in a different thread which makes it clear you're 
> discussing detail about 2016-4 (or whatever). Thanks.
> 
> This thread's supposed to be about an entirely different topic.

Indeed, my apologies. There were so many things going on that I lost track as 
well :)

Cheers,
Sander

Re: [address-policy-wg] what does consensus mean

[Sander Steffann]

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

Re: [address-policy-wg] what does consensus mean

[Jim Reid]

> On 19 Jan 2018, at 11:08, JORDI PALET MARTINEZ via address-policy-wg 
>  wrote:
> 
> In my opinion there are 3 points to clarify:

... irrelevant points snipped ...

PLEASE put those comments in a different thread which makes it clear you're 
discussing detail about 2016-4 (or whatever). Thanks.

This thread's supposed to be about an entirely different topic.

Re: [address-policy-wg] what does consensus mean

[JORDI PALET MARTINEZ via address-policy-wg]

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  en nombre de Sander 
Steffann 
Fecha: viernes, 19 de enero de 2018, 11:58
Para: JORDI PALET MARTINEZ , Marco Schmidt 

CC: 
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.

Re: [address-policy-wg] what does consensus mean

[Sander Steffann]

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

Re: [address-policy-wg] what does consensus mean

[JORDI PALET MARTINEZ via address-policy-wg]

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  en nombre de Malcolm 
Hutty 
Fecha: martes, 16 de enero de 2018, 12:11
Para: Jim Reid , JORDI PALET MARTINEZ 

CC: 
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 

Re: [address-policy-wg] what does consensus mean

[JORDI PALET MARTINEZ via address-policy-wg]

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  en nombre de Gert 
Doering 
Fecha: miércoles, 17 de enero de 2018, 18:09
Para: JORDI PALET MARTINEZ 
CC: 
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