Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Gert Doering]

Hi,

On Mon, Jan 15, 2018 at 06:58:37PM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> 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.

No text changes (except fixing typos) happen in last call.  If we change
text, it goes back to a new IA and a new review phase.

Gert Doering
-- NetMaster
-- 
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] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Kai 'wusel' Siering]

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

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[JORDI PALET MARTINEZ via address-policy-wg]

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-boun...@ripe.net> en nombre de Sander 
Steffann <san...@steffann.nl>
Fecha: lunes, 15 de enero de 2018, 22:11
Para: JORDI PALET MARTINEZ <jordi.pa...@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.

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

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

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[JORDI PALET MARTINEZ via address-policy-wg]

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-boun...@ripe.net> en nombre de Sander 
Steffann <san...@steffann.nl>
Fecha: lunes, 15 de enero de 2018, 18:46
Para: JORDI PALET MARTINEZ <jordi.pa...@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 recipi

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

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

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Maximilian Wilhelm]

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.

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Gert Doering]

Hi,

On Mon, Jan 15, 2018 at 04:42:49PM +0100, JORDI PALET MARTINEZ via 
address-policy-wg wrote:
> 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?

This has been brought up a few times over the lifetime of this policy
proposal (by me and by Max at least) and it has also been answered a 
few times.

As far as I can see, all other comments relating to this issue said
"this point was relevant 10 years ago when the IPv6 PI policy was made,
but it is no longer relevant today, with people opening new LIRs every
day, to get IPv4 address space, so they can get IPv6 allocations (/29!)
without extra costs(*) - and since there are enough ISPs today that do the 
right thing, customers have a choice if one of them tries to play a 
single-address-from-PI trick"

We might be wrong.

But enough people "back then" have also said we should have never done
IPv6 PI, and we still deviced that the possible benefit outweighs the
possible drawbacks ("the routing table will explode").  Without the 
occasional risk or mistake, there is standstill, which has its own set
of risks and might be a mistake...


(*) let me emphasize that: in the RIPE region, you pay a single membership
fee, if you are a LIR.  So whether you request a /29 IPv6 or not will 
not make a financial difference - so the monetary incentive to "get a 
/48 PI and run your ISP with that" is just not there if you already
are a RIPE member for the IPv4...  - I know ARIN is different, with paying
for every chunk you receive, and paying more for larger sizes.  No idea
how LACNIC fees are structured.

Gert Doering
-- NetMaster
-- 
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] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Gert Doering]

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 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] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

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.

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

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

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

> 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 

Cheers,
Sander

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[JORDI PALET MARTINEZ via address-policy-wg]

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-boun...@ripe.net> en nombre de Sander 
Steffann <san...@steffann.nl>
Fecha: lunes, 15 de enero de 2018, 15:58
Para: JORDI PALET MARTINEZ <jordi.pa...@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

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

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

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[JORDI PALET MARTINEZ via address-policy-wg]

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-boun...@ripe.net> en nombre de Jim 
Reid <j...@rfc1035.com>
Fecha: lunes, 15 de enero de 2018, 14:24
Para: JORDI PALET MARTINEZ <jordi.pa...@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-annou...@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.

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Jim Reid]

> On 15 Jan 2018, at 12:49, JORDI PALET MARTINEZ via address-policy-wg 
>  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-annou...@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.

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[JORDI PALET MARTINEZ via address-policy-wg]

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 <san...@steffann.nl>
Fecha: lunes, 15 de enero de 2018, 13:28
Para: JORDI PALET MARTINEZ <jordi.pa...@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.

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Richard Hartmann]

On Mon, Jan 15, 2018 at 11:21 AM, JORDI PALET MARTINEZ via
address-policy-wg  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

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Sander Steffann]

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

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[JORDI PALET MARTINEZ via address-policy-wg]

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-boun...@ripe.net> en nombre de Nick 
Hilliard <n...@foobar.org>
Fecha: lunes, 15 de enero de 2018, 12:17
Para: JORDI PALET MARTINEZ <jordi.pa...@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.

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Nick Hilliard]

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

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[JORDI PALET MARTINEZ via address-policy-wg]

Hi Gert, all,

Obviously, I don’t agree, just because for me, “consensus” is having no 
objections, not a “democracy voting”.

I also feel that the way this has been done, extending the discussion, so 
allowing the proposer to participate in a conference, and then asking the 
participants to “speak up” to support his proposal, is not nice/fair. I recall 
that was mention in the list, or I heard it somewhere else …

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

Note that I’m not saying I’m the kind of person that will do that, just to make 
clear why this is not fair and is not “consensus” in my opinion. In fact, my 
concern on this, is not just related to this proposal, but the process in 
general.

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



Regards,
Jordi

-Mensaje original-
De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Gert 
Doering <g...@space.net>
Fecha: viernes, 12 de enero de 2018, 16:27
Para: Marco Schmidt <mschm...@ripe.net>
CC: <address-policy-wg@ripe.net>
Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment 
Clarification)

Dear AP WG,

so, the extended discussion phase ended some two weeks ago, and this is
our conclusion: 

 - there were some voices that state "this is not going far enough, we
   should do a proper and more encompassing IPv6 policy review".  

   We've had the question on "shall we go there?" on the list, and 
   while there was some support, there was also some opposition to a 
   more general reorganization, so we're not going to this *in the scope 
   of this proposal*.  We can (and I assume we will :) ) return to the
   wider topic with more consideration in a separate proposal.

 - there was one voice that said "we have no problem with the policy here, 
   we do not need to do anything!" - which I considered addressed due to
   the NCC stating that they need better guidance

 - there were quite a number of supportive voices
 
- some of them expressing (in their own words) that we should go 
  for the basic fix *now*, and we can always come back and improve
  things later on

Thus, I declare that we have consensus according to PDP.

With that, we move 2016-04 to Last Call.  Marco will send the formal 
announcement for that in the next days.

For reference, a list of people that voiced support or opposition (or 
something else) in the previous review phase is appended below.  This is
what I have based my decision on.

If you disagree with my interpretation of what has been said and the
conclusion I have drawn from it, please let us know.

Gert Doering,
Address Policy WG Chair


Review Phase for V2.0, starting October 19, 2017
(extended once, to December 27)

During the last Review Phase X persons stated their support for this latest
version of 2016-04:

Ondrej Caletka(with a remark about the risk of operator-abuse)
Nick Hilliard
David Farmer  (supporting the policy, but would prefer different 
language)
Sebastian Wiesinger
Erik Bais (supporting any less restrictive PI policy, as long as the
   "no documentation = /48" limit is kept)
Richard Hartmann
Sebastian Becker
Matthias Kluth
Leon Weber
Arash Naderpour
Peter Hessler 


The following persons offered remarks, or asked for clarification

Leo Vegoda, on "how does the RIPE NCC allocation algorithm work"
  (answered by Gert Doering, Andrea Cima.  Followup question by 
   Maximilian Wilhelm about PI assignment and reservations did not
   get an anwer, but since that sub-thread was mostly curiosity, I do
   not see it as directly relevant for consensus)


The following people opposed the proposal:

Jordi Palet, on the ground that "we want a better solution than just an
 intermediate step, and this would be a complication"
 
  based on this, the WG chair started a sub-discussion "where does the
  WG want

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

[Gert Doering]

Dear AP WG,

so, the extended discussion phase ended some two weeks ago, and this is
our conclusion: 

 - there were some voices that state "this is not going far enough, we
   should do a proper and more encompassing IPv6 policy review".  

   We've had the question on "shall we go there?" on the list, and 
   while there was some support, there was also some opposition to a 
   more general reorganization, so we're not going to this *in the scope 
   of this proposal*.  We can (and I assume we will :) ) return to the
   wider topic with more consideration in a separate proposal.

 - there was one voice that said "we have no problem with the policy here, 
   we do not need to do anything!" - which I considered addressed due to
   the NCC stating that they need better guidance

 - there were quite a number of supportive voices
 
- some of them expressing (in their own words) that we should go 
  for the basic fix *now*, and we can always come back and improve
  things later on

Thus, I declare that we have consensus according to PDP.

With that, we move 2016-04 to Last Call.  Marco will send the formal 
announcement for that in the next days.

For reference, a list of people that voiced support or opposition (or 
something else) in the previous review phase is appended below.  This is
what I have based my decision on.

If you disagree with my interpretation of what has been said and the
conclusion I have drawn from it, please let us know.

Gert Doering,
Address Policy WG Chair


Review Phase for V2.0, starting October 19, 2017
(extended once, to December 27)

During the last Review Phase X persons stated their support for this latest
version of 2016-04:

Ondrej Caletka(with a remark about the risk of operator-abuse)
Nick Hilliard
David Farmer  (supporting the policy, but would prefer different language)
Sebastian Wiesinger
Erik Bais (supporting any less restrictive PI policy, as long as the
   "no documentation = /48" limit is kept)
Richard Hartmann
Sebastian Becker
Matthias Kluth
Leon Weber
Arash Naderpour
Peter Hessler 


The following persons offered remarks, or asked for clarification

Leo Vegoda, on "how does the RIPE NCC allocation algorithm work"
  (answered by Gert Doering, Andrea Cima.  Followup question by 
   Maximilian Wilhelm about PI assignment and reservations did not
   get an anwer, but since that sub-thread was mostly curiosity, I do
   not see it as directly relevant for consensus)


The following people opposed the proposal:

Jordi Palet, on the ground that "we want a better solution than just an
 intermediate step, and this would be a complication"
 
  based on this, the WG chair started a sub-discussion "where does the
  WG want to go?" and there was no strong support to go to a stronger
  change (in particular for "removing the PI sub-assignment restrictions
  competely") - some support, but also very clear concern and opposition

  Comments on that sub-thread:

 Elvis Daniel Valea - asking for clarification
 Maximilian Wilhelm - "likes the idea, but thinks this will take
  longer, so go with 2016-04 v2.0 as it is *now*"
 Elvis Daniel Valea - "this is just a patch, we can do better"
  (supporting Jordi's extended proposal)
 Sebastian Wiesinger - "support 2016-04 as is, do not hold it up"
 Nick Hilliard - "this would be a substantial change and needs 
  a good deal more attention" (I read: do not go there)
(a bit more sub-sub-thread Jordi<->Nick, solidifying the "do not
 go there" stance)
 Erik Bais - "remove as much of the restriction as possible, but keep
  the /48 PI limit" - which I read as "general support"

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


Kai Siering - "we do not need this, the NCC is interpreting the policy
  all wrong".  As nobody else sees it that way, the chairs consider this
  objection addressed.



signature.asc
Description: PGP signature