Re: [sig-policy] prop-133-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Adam,

 

Responding below, in-line.

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/2/20 11:54, "Adam Gosling"  escribió:

 

Hi Jordi

 

My comments are inline

 


New version:

2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user, for exclusive use within the infrastructure they operate.

 

This is not simply clarifying the text. The existing text is explicit. This 
relaxes the policy.

 

-> And this is also intended. The problem statement says it clearly (unless my 
English is much more broken than I know):

 

“The current text uses a “must” together with “documented purposes”. As a 
consequence, if there is a request with a documented purpose, and in the future 
the assigned space is used for some other purposes, it will violate the policy.

 

For example, a university may document in the request, that the assigned 
addressing space will be used for their own network devices and serves, but 
afterwards they also sub-assign to the students in the campus (still same 
infrastructure). This last purpose was not documented, so it will fall out of 
the policy.”

 

Your proposal text mentions “As a consequence, if there is a request with a 
documented purpose, and in the future the assigned space is used for some other 
purposes, it will violate the policy”.

This is not an error. I’m quite certain the very restrictive wording is 
deliberate. The community expected Members to use the resources for *exactly* 
the demonstrated need and to return them if that demonstrated need no longer 
exists. This is evident in the text at 4.1. License Renewal, which says; 
“Licenses to organizations shall be renewable on the following conditions: - 
The original basis of the delegation remains valid”.

-> The problem here is that this excessive restriction makes the policy 
unusable. You can’t ask the members to know in advance *exactly* what is the 
“complete purpose” of the resources, because organizations change and they need 
to evolve their networks. I’m not removing completely the restriction, just 
making it clear that the original intend was “you get resources for your own 
use, not to sub-assign to other”. However, an organization that yesterday asked 
resources for its network, was not having WiFi, now setups a WiFi for employees 
and even visitors (using their own devices), will be violating the policy if 
that was NOT DOCUMENTED in the original request. Note than in IPv4 in general, 
they will use NAT (not always), but in IPv6 they are always using global 
addresses. This is a problem that can be easily resolved with this proposal, 
and doesn’t create additional problems, neither opens the door to using the 
resources for third parties beyond your network. So still *under the original* 
intend. The original intend was not “we want the RIR to make sure to know at 
all the time exactly for what are you using your resources in your own 
network”, but just *to make sure* that they are not used in *other networks*.

-> Note that this has already been adapted already in all the RIRs and is easy 
to understand why. The IPv6 policy from all the regions was jointly created by 
APNIC, ARIN and RIPE NCC communities. We have seen several changes to resolve 
wording issues, clarifications, or just because we didn’t have the experience 
(for example, in this case, no NAT), to visualize all the possible issues of 
each specific word. From that perspective, for me it is a clarification because 
it doesn’t want to change the original intend.

However, I suspect this activity already happens in practice. So I’m supportive 
of the spirit of this change if the community agrees that delegation of 
resources for generic ‘own infrastructure’ usage is currently acceptable. 

-> I will be happy to remove that as well, but experience shows that doing many 
changes at once, makes more difficult to reach consensus.

I would specifically like to caution the removal of the “may not be 
sub-assigned”. This is the *definition* for ‘assigned’ space at APNIC. In the 
impact assessment, the Secretariat says, “assigned address space cannot be 
sub-assigned to other networks”. Who says? If this is only a technical 
limitation of MyAPNIC and it is no longer stated explicitly in the policy, then 
it allows for open interpretation/argument. 

-> I proposed this change while speaking with Sunny yesterday about their 
assessment, so it was not a “blind” change from my side. I’m happy either way, 
if from the English language perspective, it is better to explicitly 
“duplicate” the text, but within my knowledge, I agree with the assessment that 
“exclusive” is good enough.

Is the Secretariat confident the “exclusive use within infrastructure they 
operate” phrase means the same thing? Please just be careful of unintended 
consequences to Section 4.0.

-> I think the section 4.0/4.1 must be read as “justified need” according to 
the actual policy. Otherwise, each time we make a change 

Re: [sig-policy] prop-133-v001: Secretariat impact assessment

[Adam Gosling]

Hi Jordi

My comments are inline

> 
> New version:
> 
> 2.2.3. Assigned address space
> Assigned address space is address space that is delegated to an LIR, or
> end-user, for exclusive use within the infrastructure they operate.

This is not simply clarifying the text. The existing text is explicit. This 
relaxes the policy.
Your proposal text mentions “As a consequence, if there is a request with a 
documented purpose, and in the future the assigned space is used for some other 
purposes, it will violate the policy”.

This is not an error. I’m quite certain the very restrictive wording is 
deliberate. The community expected Members to use the resources for *exactly* 
the demonstrated need and to return them if that demonstrated need no longer 
exists. This is evident in the text at 4.1. License Renewal, which says; 
“Licenses to organizations shall be renewable on the following conditions: - 
The original basis of the delegation remains valid”.

However, I suspect this activity already happens in practice. So I’m supportive 
of the spirit of this change if the community agrees that delegation of 
resources for generic ‘own infrastructure’ usage is currently acceptable. 

I would specifically like to caution the removal of the “may not be 
sub-assigned”. This is the *definition* for ‘assigned’ space at APNIC. In the 
impact assessment, the Secretariat says, “assigned address space cannot be 
sub-assigned to other networks”. Who says? If this is only a technical 
limitation of MyAPNIC and it is no longer stated explicitly in the policy, then 
it allows for open interpretation/argument. 

Is the Secretariat confident the “exclusive use within infrastructure they 
operate” phrase means the same thing? Please just be careful of unintended 
consequences to Section 4.0.

Regards,

Adam



> 
> Please, update the version number of this proposal with this change, which I 
> guess it clears your impact assesment as well.
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 14/2/20 14:48, "Srinivas Chendi"  nombre de su...@apnic.net> escribió:
> 
>Dear SIG members,
> 
>Here is the Secretariat impact assessment for proposal “prop-133-v001: 
>Clarification on Sub-Assignments” and the same is also published at:
> 
> https://www.apnic.net/community/policy/proposals/prop-133/
> 
>Staff comments
>--
> 
>This proposal appears to be straightforward. APNIC notes the expansion 
>policy text to elaborate on IPv6 assignment, and it is unlikely to 
>change current practices for evaluating IPv6 requests.
> 
>The proposed text “and may not be sub-assigned to other networks.” is 
>redundant as assigned address space cannot be sub-assigned to other 
>networks.
> 
> 
>Technical comments
>--
> 
>No comments.
> 
> 
>Legal comments
>--
> 
>No comments.
> 
> 
>Implementation
>--
> 
>within 3 months.
> 
> 
>Regards
>Sunny
> 
> 
>On 20/01/2020 10:18 am, Bertrand Cherrier wrote:
>> Dear SIG members
>> 
>> The proposal "prop-133-v001: Clarification on Sub-Assignments" has been
>> sent to the Policy SIG for review.
>> 
>> (This is a new version of "prop-124" proposal abandoned after APNIC 48
>> as it did not reach consensus at APNIC 46, APNIC 47, and APNIC 48.)
>> 
>> It will be presented during the Open Policy Meeting at APNIC 49 in
>> Melbourne, Australia on Thursday, 20 February 2020.
>> 
>> We invite you to review and comment on the proposal on the mailing list
>> before the meeting.
>> 
>> The comment period on the mailing list before an APNIC meeting is an
>> important part of the policy development process. We encourage you to
>> express your views on the proposal:
>> 
>>  * Do you support or oppose this proposal?
>>  * Does this proposal solve a problem you are experiencing? If so, tell
>>the community about your situation.
>>  * Do you see any disadvantages in this proposal?
>>  * Is there anything in the proposal that is not clear?
>>  * What changes could be made to this proposal to make it more effective?
>> 
>> Information about this proposal is available at:
>> http://www.apnic.net/policy/proposals/prop-133
>> 
>> Regards
>> 
>> Sumon, Bertrand, Ching-Heng
>> APNIC Policy SIG Chairs
>> 
>> 
>> 
>> prop-133-v001: Clarification on Sub-Assignments
>> 
>> 
>> 
>> Proposer: Jordi Palet Martinez
>> jordi.pa...@theipv6company.com 
>> 
>> 
>>1. Problem statement
>> 
>> Note that this proposal is ONLY relevant when end-users obtain direct
>> assignments from APNIC, or when a LIR obtains, also from APNIC, and 
>> assignment
>> for exclusive use within its infrastructure.
>> Consequently, this is NOT relevant in case of LIR allocations.
>> 
>> The intended goal of assignments is for usage by end-users 

Re: [sig-policy] prop-133-v001: Secretariat impact assessment

[Srinivas Chendi]

Hi Jordi,

Thanks for the new version. SIG Chairs will soon post version 2 of this 
proposal to the mailing list for community discussion.

Regards
Sunny

On 16/02/2020 12:24 pm, JORDI PALET MARTINEZ wrote:
> Hi Sunny, all,
> 
> I agree that we can improve this removing the redundant text (as I've added 
> "exclusive" it is now clearly duplicating the meaning).
> 
> So, I think we should make a new version using this "shortened" text:
> 
> Actual:
> 
> 2.2.3. Assigned address space
> Assigned address space is address space that is delegated to an LIR, or
> end-user, for exclusive use within the infrastructure they operate, and may
> not be sub-assigned to other networks.
> 
> New version:
> 
> 2.2.3. Assigned address space
> Assigned address space is address space that is delegated to an LIR, or
> end-user, for exclusive use within the infrastructure they operate.
> 
> Please, update the version number of this proposal with this change, which I 
> guess it clears your impact assesment as well.
> 
> Regards,
> Jordi
> @jordipalet
>   
>   
> 
> El 14/2/20 14:48, "Srinivas Chendi"  nombre de su...@apnic.net> escribió:
> 
>  Dear SIG members,
>  
>  Here is the Secretariat impact assessment for proposal “prop-133-v001:
>  Clarification on Sub-Assignments” and the same is also published at:
>  
>   https://www.apnic.net/community/policy/proposals/prop-133/
>  
>  Staff comments
>  --
>  
>  This proposal appears to be straightforward. APNIC notes the expansion
>  policy text to elaborate on IPv6 assignment, and it is unlikely to
>  change current practices for evaluating IPv6 requests.
>  
>  The proposed text “and may not be sub-assigned to other networks.” is
>  redundant as assigned address space cannot be sub-assigned to other
>  networks.
>  
>  
>  Technical comments
>  --
>  
>  No comments.
>  
>  
>  Legal comments
>  --
>  
>  No comments.
>  
>  
>  Implementation
>  --
>  
>  within 3 months.
>  
>  
>  Regards
>  Sunny
>  
>  
>  On 20/01/2020 10:18 am, Bertrand Cherrier wrote:
>  > Dear SIG members
>  >
>  > The proposal "prop-133-v001: Clarification on Sub-Assignments" has been
>  > sent to the Policy SIG for review.
>  >
>  > (This is a new version of "prop-124" proposal abandoned after APNIC 48
>  > as it did not reach consensus at APNIC 46, APNIC 47, and APNIC 48.)
>  >
>  > It will be presented during the Open Policy Meeting at APNIC 49 in
>  > Melbourne, Australia on Thursday, 20 February 2020.
>  >
>  > We invite you to review and comment on the proposal on the mailing list
>  > before the meeting.
>  >
>  > The comment period on the mailing list before an APNIC meeting is an
>  > important part of the policy development process. We encourage you to
>  > express your views on the proposal:
>  >
>  >   * Do you support or oppose this proposal?
>  >   * Does this proposal solve a problem you are experiencing? If so, 
> tell
>  > the community about your situation.
>  >   * Do you see any disadvantages in this proposal?
>  >   * Is there anything in the proposal that is not clear?
>  >   * What changes could be made to this proposal to make it more 
> effective?
>  >
>  > Information about this proposal is available at:
>  > http://www.apnic.net/policy/proposals/prop-133
>  >
>  > Regards
>  >
>  > Sumon, Bertrand, Ching-Heng
>  > APNIC Policy SIG Chairs
>  >
>  > 
> 
>  >
>  > prop-133-v001: Clarification on Sub-Assignments
>  >
>  > 
> 
>  >
>  > Proposer: Jordi Palet Martinez
>  > jordi.pa...@theipv6company.com 
>  >
>  >
>  > 1. Problem statement
>  >
>  > Note that this proposal is ONLY relevant when end-users obtain direct
>  > assignments from APNIC, or when a LIR obtains, also from APNIC, and
>  > assignment
>  > for exclusive use within its infrastructure.
>  > Consequently, this is NOT relevant in case of LIR allocations.
>  >
>  > The intended goal of assignments is for usage by end-users or LIRs in
>  > their own infrastructure (servers, equipment, interconnections, 
> employees,
>  > guest devices, subcontractors, only within that infrastructure),
>  > not for sub-assignment in other networks.
>  >
>  > The current text uses a “must” together with “documented purposes”. As 
> a
>  > consequence, if there is a request with a documented purpose, and in 
> the
>  > future the assigned space is used for some other purposes, it will
>  > 

Re: [sig-policy] prop-133-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I agree that we can improve this removing the redundant text (as I've added 
"exclusive" it is now clearly duplicating the meaning).

So, I think we should make a new version using this "shortened" text:

Actual:

2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user, for exclusive use within the infrastructure they operate, and may
not be sub-assigned to other networks.

New version:

2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user, for exclusive use within the infrastructure they operate.

Please, update the version number of this proposal with this change, which I 
guess it clears your impact assesment as well.

Regards,
Jordi
@jordipalet
 
 

El 14/2/20 14:48, "Srinivas Chendi"  escribió:

Dear SIG members,

Here is the Secretariat impact assessment for proposal “prop-133-v001: 
Clarification on Sub-Assignments” and the same is also published at:

 https://www.apnic.net/community/policy/proposals/prop-133/

Staff comments
--

This proposal appears to be straightforward. APNIC notes the expansion 
policy text to elaborate on IPv6 assignment, and it is unlikely to 
change current practices for evaluating IPv6 requests.

The proposed text “and may not be sub-assigned to other networks.” is 
redundant as assigned address space cannot be sub-assigned to other 
networks.


Technical comments
--

No comments.


Legal comments
--

No comments.


Implementation
--

within 3 months.


Regards
Sunny


On 20/01/2020 10:18 am, Bertrand Cherrier wrote:
> Dear SIG members
> 
> The proposal "prop-133-v001: Clarification on Sub-Assignments" has been
> sent to the Policy SIG for review.
> 
> (This is a new version of "prop-124" proposal abandoned after APNIC 48
> as it did not reach consensus at APNIC 46, APNIC 47, and APNIC 48.)
> 
> It will be presented during the Open Policy Meeting at APNIC 49 in
> Melbourne, Australia on Thursday, 20 February 2020.
> 
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
> 
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
> 
>   * Do you support or oppose this proposal?
>   * Does this proposal solve a problem you are experiencing? If so, tell
> the community about your situation.
>   * Do you see any disadvantages in this proposal?
>   * Is there anything in the proposal that is not clear?
>   * What changes could be made to this proposal to make it more effective?
> 
> Information about this proposal is available at:
> http://www.apnic.net/policy/proposals/prop-133
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> 
> prop-133-v001: Clarification on Sub-Assignments
> 
> 
> 
> Proposer: Jordi Palet Martinez
> jordi.pa...@theipv6company.com 
> 
> 
> 1. Problem statement
> 
> Note that this proposal is ONLY relevant when end-users obtain direct
> assignments from APNIC, or when a LIR obtains, also from APNIC, and 
> assignment
> for exclusive use within its infrastructure.
> Consequently, this is NOT relevant in case of LIR allocations.
> 
> The intended goal of assignments is for usage by end-users or LIRs in
> their own infrastructure (servers, equipment, interconnections, employees,
> guest devices, subcontractors, only within that infrastructure),
> not for sub-assignment in other networks.
> 
> The current text uses a “must” together with “documented purposes”. As a
> consequence, if there is a request with a documented purpose, and in the
> future the assigned space is used for some other purposes, it will
> violate the policy.
> 
> For example, a university may document in the request, that the assigned
> addressing space will be used for their own network devices and serves, 
but
> afterwards they also sub-assign to the students in the campus
> (still same infrastructure). This last purpose was not documented, so it
> will fall out of the policy.
> 
> 
> 2. Objective of policy change
> 
> Clarification of the text, by rewording it.
> 
> 
> 3. Situation in other regions
> 
> This situation, has already been corrected in AFRINIC,