Re: [sig-policy] prop-124-v001: Clarification on IPv6 Sub-Assignments

[JORDI PALET MARTINEZ]

Hi all,

 

A short email to explain with a simple example what the actual policy avoids 
and what I’m trying to solve.

 

If you’re a university or enterprise having a Provider Independent assignment 
from APNIC, and then a visitor or employee or student, etc., is willing to use 
the WiFi, the existing policy doesn’t allow it, because that’s a sub-assignment 
(not being “own” infrastructure, but devices from the visitors, employees, 
students, etc.).

 

So, I’ve proposed very similar text change in all the 5 RIRs to amend that. In 
RIPE, we have already got consensus in a similar text (which is being improved, 
hopefully, with a proposal that I’ve submitted as well).

 

If you have any questions or inputs, please, let me know!


Regards,

Jordi

 

De:  en nombre de Bertrand Cherrier 

Fecha: jueves, 29 de marzo de 2018, 5:54
Para: SIG policy 
Asunto: [sig-policy] prop-124-v001: Clarification on IPv6 Sub-Assignments

 

Dear SIG members

The proposal "prop-124-v001: Clarification on IPv6 Sub-Assignments" has
been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 46 in
Noumea, New Caledonia on Wednesday, 12 September 2018.

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

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

--

prop-124-v001: Clarification on IPv6 Sub-Assignments

--

Proposer: Jordi Palet Martínez
 jordi.pa...@theipv6company.com


1. Problem Statement


When the policy was drafted, the concept of assignments/sub-assignments
did not consider a practice very common in IPv4 which is replicated and
even amplified in IPv6: the use of IP addresses for point-to-point links
or VPNs.

In the case of IPv6, instead of unique addresses, the use of unique prefixes 
(/64) is increasingly common.

Likewise, the policy failed to consider the use of IP addresses in hotspots, or 
the use of IP addresses by guests or employees in Bring Your Own Device (BYOD) 
and many other similar cases.

Finally, the IETF has recently approved the use of a unique /64 prefix per 
interface/host (RFC8273) instead of a unique address. This, for example, allows 
users to connect to a hotspot, receive a /64 such that they are “isolated” from 
other users (for reasons of security, regulatory requirements, etc.) and they 
can also use multiple virtual machines on their devices with a unique address 
for each one (within the same /64).


2. Objective of policy change
---

Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits such 
assignments, stating that “Assigned ... may not be sub-assigned”.

https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space

This proposal clarifies this situation in this regard and better define the 
concept, particularly considering new uses of IPv6 (RFC 8273), by means of a 
new paragraph.


3. Situation in other regions
---

This situation, has already been corrected in RIPE, and the policy was updated 
in a similar way, even if right now there is a small discrepancy between the 
policy text that reached consensus and the RIPE NCC Impact Analysis. A new 
policy proposal has been submitted to amend that, and the text is the same as 
presented by this proposal at APNIC. Same text has also been submitted to 
AfriNIC, LACNIC and ARIN.


4. Proposed policy solution
---

Add a new paragraph after the existing one in 2.2.3
https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space

Actual text:
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific use within the Internet infrastructure they operate. 
Assignments must only be made for specific, documented purposes and may not be 
sub-assigned.

New text:
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific use within the Internet infrastruct

Re: [sig-policy] prop-126-v001 : PDP Update

[JORDI PALET MARTINEZ]

Hi all,

 

I will like to provide some background, in case you’ve not read the complete 
proposal, about the intend.

 

Actual PDP in APNIC only rely in looking into the consensus among the 
participants of the meeting. The SIG policy list is only considered as a way to 
“cancel” that.

 

The SIG policy list can’t approve something even if the majority of the 
community think is right, that was not accepted in the meeting.

 

What it means is that the consensus is somehow discriminating those community 
members that aren’t able to pay for traveling expenses.

 

In other RIRs we “balance” both, the consensus in the list and in the meeting 
(for example this has been changed in LACNIC a few months ago), or even we only 
consider the list (RIPE NCC).

 

I thought it will be good to consider this situation also in APNIC, so to allow 
to be fair with all the members.

 

Opinions?


Regards,

Jordi

 

 

 

De:  en nombre de Bertrand Cherrier 

Fecha: jueves, 9 de agosto de 2018, 20:42
Para: SIG policy 
Asunto: [sig-policy] prop-126-v001 : PDP Update

 

Dear SIG members,

The proposal "prop-126-v001: PDP Update" has been sent to the Policy SIG
for review.

It will be presented at the Open Policy Meeting at APNIC 46 in
Noumea, New Caledonia on Thursday, 13 September 2018.

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

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

https://www.apnic.net/wp-content/uploads/2018/08/prop-126-v001.txt

prop-126-v001: PDP Update

Proposer: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
With its requirement of face-to-face participation at the OPM, the current PDP
might – at least partially – be the cause of the low levels of community 
participation
in the process by using the policy mailing list.

This proposal would allow an increased participation, by considering also the 
comments
in the list for the consensus determination. So, consensus would be determined 
balancing
the mailing list and the forum, and would therefore increase community 
participation.

Further, policy proposals are meant for the community as a whole, and not only 
APNIC
members, so this proposal suggest removing the actual “double” consensus 
required in
both groups.

Moreover, requiring 4 weeks in advance to the OPM, seems unnecessary as the 
consensus
determination can be done in two stages (SIG meeting and list), so the proposal 
looks
for just 1 week in advance to the SIG responsible for that proposal.

Finally, it completes the PDP by adding a simple mechanism for solving 
disagreements
during an appeals phase and an improved definition of ‘consensus’.
2. Objective of policy change
To allow that consensus is determined also looking at the opinions of community
members that are not able to travel to the meetings, adjust the time required
before the relevant SIG to submit the proposals, not requiring “double” 
consensus
with the APNIC members and facilitating a simple method for appeals.
3. Situation in other regions
The PDP is different in the different RIRs. This proposal is similar to the 
RIPE PDP,
possibly the region with the broadest participation in its policy proposal 
discussions,
although there are certain differences such as the mandatory use of the mailing 
list
and the meeting, which is more similar to the PDP at ARIN (another region with 
broad
community participation). LACNIC has recently adopted a similar policy proposal 
with
the same aims.
4. Proposed policy solution
PDP documnet
https://www.apnic.net/about-apnic/corporate-documents/documents/policy-development/development-process/#4

4.Proposal process

A policy proposal must go through the following chronological steps in order to 
be
adopted by APNIC.

Actual:

Step 1

Discussion before the OPM

A formal proposal paper must be submitted to the SIG mailing list and to the 
SIG Chair
four weeks before the start of the OPM. The proposal must be in text which 
clearly
expresses the proposal, with explicit mention of any changes being proposed to 
existing
policies and the reasons for those changes. The APNIC Secretariat will 
recommend a
preferred proposal format. If the four-week deadline is not met, proposals may 
still
be submitted and presented for discussion at the meeting; however, no decision 
may
be ma

[sig-policy] prop-124: Clarification on IPv6 Sub-Assignments

[JORDI PALET MARTINEZ]

Hi all,

 

Regarding this policy proposal 
(https://www.apnic.net/community/policy/proposals/prop-124).

 

I will like to understand if everybody got the issue.

 

This problem is basically the same in all the 5 RIRs and I proposed the same 
text to all (in some cases got simplified).

 

The problem is only for end-users (in IPv4 doesn't happen because we use NAT) 
which aren't allowed to provide addresses (for the connection to Internet) to 
third parties, in a few examples:

1) You're a university and you provide addresses to students

2) You're a company and provide addresses for the employees

3) You're a small hot-spot provider and of course, you want to have customers 
on it

 

So, the proposal allows to use addresses (up to /64) for temporary users, and 
not consider them as sub-assignments.

 

Opinions?

 

Questions?

 

Thanks!


Regards,

Jordi

 



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

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-126-v001 : PDP Update

[JORDI PALET MARTINEZ]

Hi Satoru,

 

Thanks for commenting the proposal.

 

I realized that there is a mistake, because in step 1, the first sentence talks 
about 1 week, while the second still is 4 weeks.

 

So, the typo is in the 2nd part.

 

It should be:

 

A formal proposal paper must be submitted to the SIG mailing list and to the 
SIG Chair one week before the start of the OPM. The proposal must be in text 
which clearly expresses the proposal, with explicit mention of any changes 
being proposed to existing policies and the reasons for those changes. The 
APNIC Secretariat will recommend a preferred proposal format. If the one-week 
deadline is not met, proposals may still be submitted and presented for 
discussion at the meeting; however, no decision may be made by the meeting 
regarding the proposal.

 

I’ve submitted a new version to update this mistake.


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: jueves, 16 de agosto de 2018, 3:08
Para: SIG policy 
Asunto: Re: [sig-policy] prop-126-v001 : PDP Update

 

Dear Proposer

 

I have a question at STEP 1 of your proposal.

 

It seems to mean that the proposer can submit their proposal

one week before the start of OPM, but there will be no discussion

or consensus call at the OPM if proposer submit the proposal 

after four-week deadline.

 

Is it correct or typo of "one-week deadline" ?

 

Regards,

 

Satoru Tusrumaki

 

 

 

 

2018-08-10 10:42 GMT+09:00 Bertrand Cherrier :

Dear SIG members,

The proposal "prop-126-v001: PDP Update" has been sent to the Policy SIG
for review.

It will be presented at the Open Policy Meeting at APNIC 46 in
Noumea, New Caledonia on Thursday, 13 September 2018.

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

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

https://www.apnic.net/wp-content/uploads/2018/08/prop-126-v001.txt

prop-126-v001: PDP Update

Proposer: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
With its requirement of face-to-face participation at the OPM, the current PDP
might – at least partially – be the cause of the low levels of community 
participation
in the process by using the policy mailing list.

This proposal would allow an increased participation, by considering also the 
comments
in the list for the consensus determination. So, consensus would be determined 
balancing
the mailing list and the forum, and would therefore increase community 
participation.

Further, policy proposals are meant for the community as a whole, and not only 
APNIC
members, so this proposal suggest removing the actual “double” consensus 
required in
both groups.

Moreover, requiring 4 weeks in advance to the OPM, seems unnecessary as the 
consensus
determination can be done in two stages (SIG meeting and list), so the proposal 
looks
for just 1 week in advance to the SIG responsible for that proposal.

Finally, it completes the PDP by adding a simple mechanism for solving 
disagreements
during an appeals phase and an improved definition of ‘consensus’.
2. Objective of policy change
To allow that consensus is determined also looking at the opinions of community
members that are not able to travel to the meetings, adjust the time required
before the relevant SIG to submit the proposals, not requiring “double” 
consensus
with the APNIC members and facilitating a simple method for appeals.
3. Situation in other regions
The PDP is different in the different RIRs. This proposal is similar to the 
RIPE PDP,
possibly the region with the broadest participation in its policy proposal 
discussions,
although there are certain differences such as the mandatory use of the mailing 
list
and the meeting, which is more similar to the PDP at ARIN (another region with 
broad
community participation). LACNIC has recently adopted a similar policy proposal 
with
the same aims.
4. Proposed policy solution
PDP documnet
https://www.apnic.net/about-apnic/corporate-documents/documents/policy-development/development-process/#4

4.Proposal process

A policy proposal must go through the following chronological steps in order to 
be
adopted by APNIC.

Actual:

Step 1

Discussion before the OPM

A formal proposal paper must be submitted to the SIG mailing list and to the 
SIG Chair
four weeks before the start of the OPM. The proposal must be in text wh

Re: [sig-policy] prop-126-v001 : PDP Update

[JORDI PALET MARTINEZ]

Hi Hiroki,

Thanks for reading the proposal and providing inputs!

I understand your point. However, this is actually showing somehow, the need 
for this proposal change.

If in addition of measuring the consensus in the meeting, the PDP also measures 
the consensus in the list (step 2 in my proposal), now you will have more time 
to agree in your Japanese community.

You can collect your feedback since day one, provide it during the meeting, but 
also keep doing so, and provide it in the mailing list. Both inputs will have 
to be evaluated by the co-chairs to look for the "overall" consensus and be 
fair with those that can't come to meetings, need more time to consider the 
proposal (sometimes text is not sufficient, and the presentation in the meeting 
may clarify many aspects and different point views).

You don't think so ?

Regards,
Jordi
 
 

-Mensaje original-
De:  en nombre de Hiroki Kawabata 

Fecha: jueves, 16 de agosto de 2018, 20:33
Para: SIG policy 
Asunto: Re: [sig-policy] prop-126-v001 : PDP Update

Hi Jordi-san,

I have one comment about your proposal.

In Japanese community, JPOPF Steering team will hold the meeting to collect 
opinions
from community member after all proposals are published.
The aim of this meeting is to understand proposals in Japanese and get more 
feedbacks in Japanese.

If the dead-line will be changed one week before the start of the OPM,
we cannot get enough time to collect opinion from our community.

In this time, The submission deadline is Friday, 3 August.
and Policy SIG Chair's announce on SIG Mailing list is Wednesday 8 August.

If this is one week before the start of the OPM, do we have enough time to 
discuss on Mailing list?
I think that there are not.

Regards,
Hiroki


Subject: Re: [sig-policy] prop-126-v001 : PDP Update
From: JORDI PALET MARTINEZ 
Date: Thu Aug 16 2018 21:51:25 GMT+0900

> Hi Satoru,
> 
> Thanks for commenting the proposal.
> 
> I realized that there is a mistake, because in step 1, the first sentence 
talks about 1 week, while the second still is 4 weeks.
> 
> So, the typo is in the 2^nd part.
> 
> It should be:
> 
> A formal proposal paper must be submitted to the SIG mailing list and to 
the SIG Chair one week before the start of the OPM. The proposal must be in 
text which clearly expresses the proposal, with explicit mention of any changes 
being proposed to existing policies and the reasons for those changes. The 
APNIC Secretariat will recommend a preferred proposal format. If the one-week 
deadline is not met, proposals may still be submitted and presented for 
discussion at the meeting; however, no decision may be made by the meeting 
regarding the proposal.
> 
> I’ve submitted a new version to update this mistake.
> 
> 
> Regards,
> 
> Jordi
> 
> *De: * en nombre de Satoru Tsurumaki 

> *Fecha: *jueves, 16 de agosto de 2018, 3:08
> *Para: *SIG policy 
> *Asunto: *Re: [sig-policy] prop-126-v001 : PDP Update
> 
> Dear Proposer
> 
> I have a question at STEP 1 of your proposal.
> 
> It seems to mean that the proposer can submit their proposal
> 
> one week before the start of OPM, but there will be no discussion
> 
> or consensus call at the OPM if proposer submit the proposal
> 
> after four-week deadline.
> 
> Is it correct or typo of "one-week deadline" ?
> 
> Regards,
> 
> Satoru Tusrumaki
> 
> 2018-08-10 10:42 GMT+09:00 Bertrand Cherrier mailto:b.cherr...@micrologic.nc>>:
> 
> Dear SIG members,
> 
> The proposal "prop-126-v001: PDP Update" has been sent to the Policy 
SIG
> for review.
> 
> It will be presented at the Open Policy Meeting at APNIC 46 in
> Noumea, New Caledonia on Thursday, 13 September 2018.
> 
> 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?
 

Re: [sig-policy] prop-126-v001 : PDP Update

[JORDI PALET MARTINEZ]

Hi Hiroki,

Thanks for your response.

Regarding the AMM "double-consensus". My persective is that policies affect 
"all" the community, not just the members.

So why then the AMM has the right to "change" the community decision?

In fact, the AMM has already a way to "protect" the community if something is 
really broken, which is the EC endorsement (the EC is elected by the members, 
right?).

In fact this is the way it happens in all the other RIRs. Never the "members" 
can have more "power" than the community as a whole.

Regards,
Jordi
 
 

-Mensaje original-
De:  en nombre de Hiroki Kawabata 

Fecha: martes, 4 de septiembre de 2018, 21:44
Para: SIG policy 
Asunto: Re: [sig-policy] prop-126-v001 : PDP Update

Hi Jordi-san,

Thank you for your comment. (sorry for my late response)

> If in addition of measuring the consensus in the meeting,
> the PDP also measures the consensus in the list (step 2 in my proposal),
> now you will have more time to agree in your Japanese community.

I think that it is better to confirm consensus on the mailing list.

** the step3(you proposed)
===
Discussion after the OPM

Proposals that have reached consensus at the OPM will be circulated
on the appropriate SIG mailing list for a period.
This is known as the “comment period”. The duration of
the “comment period” will be not shorter than four weeks and not
longer than eight weeks.  The decision to extend more than four weeks,
including the duration of the extension, will be determined
at the sole discretion of the SIG Chair.
===

Because we do not have enough time to discuss before the OPM,
even if the proposal does not reach consensus at OPM,
I think that it is better to collect opinions on the mailing list.

On the other hand, according to the step3 which you proposed,
I understand the AMM will be removed. The opportunity to discuss
about policy proposal and express opinions as APNIC member will be lost.

Depending on the policy proposal, it may be necessary to judge
as APNIC member. We think that it is necessary to be left process
to confirm consensus at AMM.

Regards,
Hiroki

    
    Subject: Re: [sig-policy] prop-126-v001 : PDP Update
From: JORDI PALET MARTINEZ 
Date: Fri Aug 17 2018 11:48:13 GMT+0900

> Hi Hiroki,
> 
> Thanks for reading the proposal and providing inputs!
> 
> I understand your point. However, this is actually showing somehow, the 
need for this proposal change.
> 
> If in addition of measuring the consensus in the meeting, the PDP also 
measures the consensus in the list (step 2 in my proposal), now you will have 
more time to agree in your Japanese community.
> 
> You can collect your feedback since day one, provide it during the 
meeting, but also keep doing so, and provide it in the mailing list. Both 
inputs will have to be evaluated by the co-chairs to look for the "overall" 
consensus and be fair with those that can't come to meetings, need more time to 
consider the proposal (sometimes text is not sufficient, and the presentation 
in the meeting may clarify many aspects and different point views).
> 
> You don't think so ?
> 
> Regards,
> Jordi
>   
>   
> 
> -Mensaje original-
> De:  en nombre de Hiroki Kawabata 

> Fecha: jueves, 16 de agosto de 2018, 20:33
> Para: SIG policy 
> Asunto: Re: [sig-policy] prop-126-v001 : PDP Update
> 
>  Hi Jordi-san,
>  
>  I have one comment about your proposal.
>  
>  In Japanese community, JPOPF Steering team will hold the meeting to 
collect opinions
>  from community member after all proposals are published.
>  The aim of this meeting is to understand proposals in Japanese and 
get more feedbacks in Japanese.
>  
>  If the dead-line will be changed one week before the start of the 
OPM,
>  we cannot get enough time to collect opinion from our community.
>  
>  In this time, The submission deadline is Friday, 3 August.
>  and Policy SIG Chair's announce on SIG Mailing list is Wednesday 8 
August.
>  
>  If this is one week before the start of the OPM, do we have enough 
time to discuss on Mailing list?
>  I think that there are not.
>  
>  Regards,
>  Hiroki
>  
>  
>  Subject: Re: [sig-policy] prop-126-v001 : PDP Update
>  From: JORDI PALET MARTIN

Re: [sig-policy] Prop124 version 4

[JORDI PALET MARTINEZ]

Hi Satoru,

 

Thanks for commenting on this.

 

The current proposal text has not examples, I think it is quite neutral in this 
aspect:

 

Providing addressing space to third party devices including addresses for 

point-to-point links and/or non-permanently providing addressing space to third 

parties, for use on a network managed and operated by the assignment holder, 

shall not be considered a sub-assignment.

 

The provision of addressing space for permanent or semi-permanent connectivity, 

such as broadband services, is still considered a sub-assignment.

 

I think having the examples in the “objective” of the policy proposal is needed 
to clarify the reason for it. You don’t think so?


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:02
Para: SIG policy 
Asunto: Re: [sig-policy] Prop124 version 4

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-124,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed on this proposal.

However, also many concerning comment was expressed to explain the specific 
examples.

For this matter, the same opinion was given also at JPOPM34.

 

  - It is better to stop specific examples because they tend to fall into 
discussion of adding / not applying / not applicable.

  - I think that specific examples should be stated in the guidelines rather 
than policies.


Regards,

Satoru Tsurumaki

 

 

2018-09-09 18:37 GMT+11:00 Bertrand Cherrier :

Dear SIG members

A new version of the proposal "prop-124: Clarification on IPv6 Sub-Assignments"
has been sent to the Policy SIG for review.

Information about earlier versions is available from:

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

You are encouraged to express your views on the proposal:

· Do you support or oppose the proposal?

· Is there anything in the proposal that is not clear?

· What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

prop-124-v004: Clarification on IPv6 Sub-Assignments

Proposer: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
When the policy was drafted, the concept of assignments/sub-assignments
did not consider a practice very common in IPv4 which is replicated and
even amplified in IPv6: the use of IP addresses for point-to-point links
or VPNs.

In the case of IPv6, instead of unique addresses, the use of unique
prefixes (/64) is increasingly common.

Likewise, the policy failed to consider the use of IP addresses in hotspots,
or the use of IP addresses by guests or employees in Bring Your Own Device
(BYOD) and many other similar cases.

One more case is when an end-user contracts a third-party to do some services
in their own network and they need to deploy their own devices, even servers,
network equipment, etc. For example, security surveillance services may require
that the contractor provides their own cameras, recording system, even their
own firewall and/or router for a dedicated VPN, etc. Of course, in many cases,
this surveillance system may need to use the addressing space of the end-user.

Finally, the IETF has recently approved the use of a unique /64 prefix per
interface/host (RFC8273) instead of a unique address. This, for example,
allows users to connect to a hotspot, receive a /64 such that they are
“isolated” from other users (for reasons of security, regulatory
requirements, etc.) and they can also use multiple virtual machines
on their devices with a unique address for each one (within the same /64).
2. Objective of policy change
Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits
such assignments, stating that “Assigned ... may not be sub-assigned”.

https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space

This proposal clarifies this situation in this regard and better define the
concept, particularly considering new uses of IPv6 (RFC 8273), by means of
a new paragraph.
3. Situation in other regions
This situation, has already been corrected in RIPE, and the policy was updated
in a similar way, even if right now there is a small discrepancy between the
policy text that reached consensus and the RIPE NCC Impact Analysis. A new
policy proposal has been submitted to amend that, and the text is the same
as presented by this proposal at APNIC. Same text has also been submitted
to AfriNIC, LACNIC and ARIN.
4. Proposed policy solution
Add a new paragraph after the existing one in 2.2.3
https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space

Actual text:
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user,
for specific use within the Internet infrastructure they operat

Re: [sig-policy] prop-125-v001: Validation of "abuse-mailbox" and other IRT emails

[JORDI PALET MARTINEZ]

Hi Satoru, all,

 

Thanks again for your contribution.

 

There are many ways to protect a whois “email” from spam. For example, you can 
request a manual intervention to actually “see” the email.

 

I think this is an operational issue outside of the scope of the PDP, and 
should be sorted out by the staff.

 

Also, this concern is the same for any email published in the whois, not just 
our policy proposal, right?


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:04
Para: SIG policy 
Asunto: Re: [sig-policy] prop-125-v001: Validation of "abuse-mailbox" and other 
IRT emails

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-125,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed on this proposal.

 

  - Agree, you should.

  - When mail address is posted in whois DB, a lot of SPAM is sent. We should 
take some measures.


Regards,

Satoru Tusrumaki

 

 

2018-08-17 14:52 GMT+11:00 Sumon Ahmed Sabir :

Dear SIG members,

The proposal "prop-125-v001: Validation of "abuse-mailbox" and other IRT 
emails" has been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 46 in
Noumea, New Caledonia on Thursday, 13 September 2018.

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

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

--

prop-125-v001: Validation of "abuse-mailbox" and other IRT emails

--

Proposer: Jordi Palet Martínez - jordi.pa...@theipv6company.com
  Aftab Siddiqui - aftab.siddi...@gmail.com


1. Problem Statement

APNIC implemented mandatory IRT references on 8 November 2010. This means it is 
mandatory to register an Incident Response Team (IRT) object for each resource 
record in the APNIC Whois Database. The policy mandates IRT references for each 
inetnum, inet6num and aut-num objects, however in many cases, those contain 
out-of-date, inaccurate, non-existent or not actively monitored abuse-mailbox 
information.

In practice, this contact becomes ineffective to report abuses and generally 
gives rise to security issues and costs for the victims.

This proposal aims to solve the problem and ensure the existence of a proper 
abuse-mailbox contact and the process for its utilization.

2. Objective of policy change
-
The Internet community is based on collaboration. In many cases, however, this 
is not enough and we all need to be able to contact those LIRs which may be 
experiencing a problem in their networks and may not be aware of the situation.

This proposal aims to solve this problem by means of a simple, periodic 
verification of IRT object emails, and establishes the basic rules for 
performing such verification and thus avoids unnecessary costs to third parties 
who need to contact the persons responsible for solving the abuses of a 
specific network.

The proposal guarantees that the cost of processing the abuse falls on the LIR 
whose client is causing the abuse (and from whom they receive financial 
compensation for the service), instead of falling on the victim, as would be 
the case if they had to resort to the courts, thus avoiding costs (lawyers, 
solicitors, etc.) and saving time for both parties.

3. Situation in other regions
-
A similar proposal is being discussed in LACNIC and being prepared for AfriNIC 
and RIPE NCC.

Currently, ARIN conducts an annual POC (point of contact) validation and RIPE 
NCC validates the “abuse-mailbox:” attribute annually (ripe-705).

4. Proposed policy solution
---
1. About the "abuse-mailbox", “email”, “admin-c” and “tech-c”

Emails sent to "abuse-mailbox", “email”, “admin-c” and “tech-c” must require 
manual intervention by the recipient at some time, and may not be filtered, as 
in certain cases this might prevent the reception of the abuse reports, for 
example a case of spam, as it would include the spam message itself o

Re: [sig-policy] prop-126-v001 : PDP Update

[JORDI PALET MARTINEZ]

Hi again Satoru, all,

 

Answers below, in-line, and thank again for your contribution.


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:04
Para: SIG policy 
Asunto: Re: [sig-policy] prop-126-v001 : PDP Update

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-126,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed about the point of confirming consensus 
on ML.

 

A question of doubt and concern was expressed, in that it discontinues AMM 
consensus and changes the proposal's deadline.

 

(Consensus on ML)

 - I support to take a consensus confirmation with ML instead of AMM.

 - I support on the point of view that this proposal will expand  the 
opportunities to the remote participant to discussing about proposal.

 - For consensus confirmation in ML, only proposal which reached consensus in 
OPM are eligible and the proposal which not reached consensus are not eligible. 
it is not good to lose the opportunity to state a opinion at the ML about the 
proposal which not reach consensus.

 

Let me clarify this. I’m not suggesting a ML confirmation of the consensus. 
What I suggest is that it is discriminatory to look for consensus ONLY in the 
SIG, because there is many people not able to come to meetings and they are 
part of the community. So, what I’m suggesting is that the consensus should be 
measured in both, the SIG and the ML.

 

(Consensus at AMM)

 - The meaning of taking consensus in AMM is for members to clarify the pros 
and cons about APNIC’s implementation. This is not a simple substitution from 
AMM to ML.

 - In addition to the past, how about added a confirmation of consensus in ML ?

 

Clarification in the AMM is good to have, but not “mandating” the consensus on 
the AMM. If we accept that the consensus can be reached in the SIG and the ML, 
then the AMM members that disagree with the proposal, are able to express their 
concerns in the ML.

 

(Change of deadline of proposal)

 - For the purpose of this proposal, it is better to have a longer online 
discussion period. Why shorten the deadline by proposal? The proposer should 
clarify the intention of wanting to move the deadline.

 

I don’t think it makes sense to have a requirement of a proposal to be send to 
the ML 4 weeks before the meeting, if we are opting for looking for consensus 
also in the list. Only a very small percentage of the community is present in 
the meetings, so the “weight” of the ML over those present in the meeting must 
be higher. I will be ok to ask for a “longer” period for discussion/comments in 
the ML if that’s what the community believe, but keeping just one week for 
submission deadline.

 

(Other)

 - It is better to be able to measure the effect after change

 

Not sure to understand this point.


Regards,

Satoru Tsurumaki

 

 

2018-08-10 12:42 GMT+11:00 Bertrand Cherrier :

Dear SIG members,

The proposal "prop-126-v001: PDP Update" has been sent to the Policy SIG
for review.

It will be presented at the Open Policy Meeting at APNIC 46 in
Noumea, New Caledonia on Thursday, 13 September 2018.

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

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

https://www.apnic.net/wp-content/uploads/2018/08/prop-126-v001.txt

prop-126-v001: PDP Update

Proposer: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
With its requirement of face-to-face participation at the OPM, the current PDP
might – at least partially – be the cause of the low levels of community 
participation
in the process by using the policy mailing list.

This proposal would allow an increased participation, by considering also the 
comments
in the list for the consensus determination. So, consensus would be determined 
balancing
the mailing list and the forum, and would therefore increase community 
participation.

Further, policy proposals are meant for the community as a whole, and not only 
APNIC
members, so this proposal suggest removing the actual “double” consensus 
required in
both groups.

Moreover, requiring 4 weeks in advance to the OPM, seems unnecessary as the 
consensus
determination can be do

Re: [sig-policy] Prop124 version 4

[JORDI PALET MARTINEZ]

Hi Owen, all,

 

In previous versions I tried to make a shorter text and didn’t worked.

 

Let me try to explain each part:

 
“Providing addressing space to third party devices including addresses for 
point-to-point links”

 

This covers the case of a subcontractor with devices siting on the holders 
network may be for several years, and in this case they are “permanently” 
connected (during the duration of the contract), explained in my problem 
statement as:

 

One more case is when an end-user contracts a third-party to do some services 
in their own network and they need to deploy their own devices, even servers, 
network equipment, etc. For example, security surveillance services may require 
that the contractor provides their own cameras, recording system, even their 
own firewall and/or router for a dedicated VPN, etc. Of course, in many cases, 
this surveillance system may need to use the addressing space of the end-user.

 

Of course, the 2nd part of the sentence is for the point-to-point links, I 
think that’s very obvious.

 
“and/or non-permanently providing addressing space to third Parties”
 

This covers the other cases, BYOD (employee or guest of a corporation, student 
of a university, visitor in a hot-spot, etc.), which are more commonly for some 
hours or minutes, even days.

 
“The provision of addressing space for permanent or semi-permanent 
connectivity, 
such as broadband services, is still considered a sub-assignment.”

 

We want to make sure that ISPs, typically offering broadband services, aren’t 
end-users, as they should be LIRs.


Regards,

Jordi

 

 

 

De: Owen DeLong 
Fecha: martes, 11 de septiembre de 2018, 15:29
Para: JORDI PALET MARTINEZ 
CC: Satoru Tsurumaki , SIG policy 

Asunto: Re: [sig-policy] Prop124 version 4

 

Aside from the question of examples or not examples, I offer the following 
suggestion… The wording is quite awkward and difficult to parse. So much so, I 
am not 100% certain of the intent.

 

I offer the following suggestion for a rewrite hoping that I have captured the 
intent accurately:

 

===

 

Providing IP number resources to third party devices, including addresses for 
point-to-point links or addresses provided on an impermanent basis, for use on 
a network managed and operated by the assignment holder shall not be considered 
a sub-assignment.

 

Providing IP number resources for permanent or semi-permanent connectivity, 
such as broadband services is still considered a sub-assignment.

 

===

 

Owen

 



On Sep 10, 2018, at 20:55 , JORDI PALET MARTINEZ  
wrote:

 

Hi Satoru,

 

Thanks for commenting on this.

 

The current proposal text has not examples, I think it is quite neutral in this 
aspect:

 

Providing addressing space to third party devices including addresses for 

point-to-point links and/or non-permanently providing addressing space to third 

parties, for use on a network managed and operated by the assignment holder, 

shall not be considered a sub-assignment.

 

The provision of addressing space for permanent or semi-permanent connectivity, 

such as broadband services, is still considered a sub-assignment.

 

I think having the examples in the “objective” of the policy proposal is needed 
to clarify the reason for it. You don’t think so?


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:02
Para: SIG policy 
Asunto: Re: [sig-policy] Prop124 version 4

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-124,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed on this proposal.

However, also many concerning comment was expressed to explain the specific 
examples.

For this matter, the same opinion was given also at JPOPM34.

 

  - It is better to stop specific examples because they tend to fall into 
discussion of adding / not applying / not applicable.

  - I think that specific examples should be stated in the guidelines rather 
than policies.


Regards,

Satoru Tsurumaki

 

 

2018-09-09 18:37 GMT+11:00 Bertrand Cherrier :

Dear SIG members

A new version of the proposal "prop-124: Clarification on IPv6 Sub-Assignments"
has been sent to the Policy SIG for review.

Information about earlier versions is available from:

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

You are encouraged to express your views on the proposal:

· Do you support or oppose the proposal?

· Is there anything in the proposal that is not clear?

· What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

prop-124-v004: Clarification on IPv6 Sub-Assignments

Proposer: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
When the policy was dr

Re: [sig-policy] Prop124 version 4

[JORDI PALET MARTINEZ]

Hi Owen,

 

For me (and a couple of other folks that I checked around this morning), your 
wording is more difficult to read.

 

This may be because we aren’t native English speakers.

 

Also, your wording has an “or” and I was using “and/or” to make sure to allow 
the cases when the holder needs “both” (has an external contractor using 
on-site devices and has employees visiting the network).

 

Nevertheless, I think I’m fine either way if we replace the “or” with the 
“and/or”.


Regards,

Jordi

 

 

 

De: Owen DeLong 
Fecha: miércoles, 12 de septiembre de 2018, 4:17
Para: JORDI PALET MARTINEZ 
CC: Satoru Tsurumaki , SIG policy 

Asunto: Re: [sig-policy] Prop124 version 4

 

Rather than explain each part of your text, I think it would be more useful if 
you explained where my text doesn’t convey the same intent.

 

Owen

 



On Sep 10, 2018, at 22:16 , JORDI PALET MARTINEZ  
wrote:

 

Hi Owen, all,

 

In previous versions I tried to make a shorter text and didn’t worked.

 

Let me try to explain each part:

 

1.   “Providing addressing space to third party devices including addresses 
for 

point-to-point links”

 

This covers the case of a subcontractor with devices siting on the holders 
network may be for several years, and in this case they are “permanently” 
connected (during the duration of the contract), explained in my problem 
statement as:

 

One more case is when an end-user contracts a third-party to do some services 
in their own network and they need to deploy their own devices, even servers, 
network equipment, etc. For example, security surveillance services may require 
that the contractor provides their own cameras, recording system, even their 
own firewall and/or router for a dedicated VPN, etc. Of course, in many cases, 
this surveillance system may need to use the addressing space of the end-user.

 

Of course, the 2nd part of the sentence is for the point-to-point links, I 
think that’s very obvious.

 

2.   “and/or non-permanently providing addressing space to third Parties”

 

This covers the other cases, BYOD (employee or guest of a corporation, student 
of a university, visitor in a hot-spot, etc.), which are more commonly for some 
hours or minutes, even days.

 

3.   “The provision of addressing space for permanent or semi-permanent 
connectivity, 

such as broadband services, is still considered a sub-assignment.”

 

We want to make sure that ISPs, typically offering broadband services, aren’t 
end-users, as they should be LIRs.


Regards,

Jordi

 

 

 

De: Owen DeLong 
Fecha: martes, 11 de septiembre de 2018, 15:29
Para: JORDI PALET MARTINEZ 
CC: Satoru Tsurumaki , SIG policy 

Asunto: Re: [sig-policy] Prop124 version 4

 

Aside from the question of examples or not examples, I offer the following 
suggestion… The wording is quite awkward and difficult to parse. So much so, I 
am not 100% certain of the intent.

 

I offer the following suggestion for a rewrite hoping that I have captured the 
intent accurately:

 

===

 

Providing IP number resources to third party devices, including addresses for 
point-to-point links or addresses provided on an impermanent basis, for use on 
a network managed and operated by the assignment holder shall not be considered 
a sub-assignment.

 

Providing IP number resources for permanent or semi-permanent connectivity, 
such as broadband services is still considered a sub-assignment.

 

===

 

Owen

 




On Sep 10, 2018, at 20:55 , JORDI PALET MARTINEZ  
wrote:

 

Hi Satoru,

 

Thanks for commenting on this.

 

The current proposal text has not examples, I think it is quite neutral in this 
aspect:

 

Providing addressing space to third party devices including addresses for 

point-to-point links and/or non-permanently providing addressing space to third 

parties, for use on a network managed and operated by the assignment holder, 

shall not be considered a sub-assignment.

 

The provision of addressing space for permanent or semi-permanent connectivity, 

such as broadband services, is still considered a sub-assignment.

 

I think having the examples in the “objective” of the policy proposal is needed 
to clarify the reason for it. You don’t think so?


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: martes, 11 de septiembre de 2018, 14:02
Para: SIG policy 
Asunto: Re: [sig-policy] Prop124 version 4

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum.

 

I would like to share key feedback in our community for prop-124,

based on a meeting we organised on 22nd Aug to discuss these proposals.

 

Many supporting opinions were expressed on this proposal.

However, also many concerning comment was expressed to explain the specific 
examples.

For this matter, the same opinion was given also at JPOPM34.

 

  - It is better to stop specific examples because they tend to fall into 
discussion of adding / not applying / not applicable.

  - I

Re: [sig-policy] Comments on Prop 124, 125, 126

[JORDI PALET MARTINEZ]

Hi Shiva,

 

Thanks a lot for your comments.

 

Just to be clear, I understand then that you support the 3 policy proposals.

 

Regarding your points for prop-126:

1. I’m not opposed to that, however, I think it is an operational aspect of the 
PDP, and as well as in other policies, doesn't need to go into the text. For 
example, none of the other RIRs have what you say, but most of them actually do 
a “diff” so participants can see the differences among the actual text and 
changes with each version. I’ve also sent in several occasions, when the policy 
was very complex, my own “on-line-diff” so the people can see all the changes.

 

I’m sure APNIC will be happy to provide it by default from now on ;-)

 

2. Not sure to capture your idea here, but I think we agree. I think any 
discussion and local, country, or regional level is always good, of course. And 
if the policy gets discussed in country mailing list and then they can provide 
their feedback to the SIG one, it will help to understand if there is 
consensus, not just in the SIG meeting, which is one of the aims of the 
proposal.


Regards,

Jordi

 

 

 

De:  en nombre de Shiva Upadhyay 

Fecha: jueves, 13 de septiembre de 2018, 6:38
Para: 
Asunto: Re: [sig-policy] Comments on Prop 124, 125, 126

 

Dear All,

 

Following are my comments and suggestions on the policy proposal 124, 125 and 
126 in my personal capacity.

 

Prop 124-

In IPv4 under the NAT, end users, universities etc - which are not authorised 
to sub-allocate IP blocks they receive from APNIC or NIR - can distribute 
private IP address from the reserved block for other business purposes but not 
as an ISP. The situation with IPv6 it is totally different as there is no such 
thing like NAT as in IPv4. Here end users, universities, organisation etc are 
not allowed to further allocate the IP resources APNIC allocates them. However, 
they can allocate global public IP address space to the device under them with 
using the NAT. As the real-time scenarios and examples mentioned in the 
proposal justify the need for this policy amendment, the IPv6 allocation policy 
needs to be updated as per the author. 

 

Prop 125-

 

This proposal aims to keep the WHOIS important abuse objects up to date. 
However, this could also be achieved by asking affiliates to either update the 
existing contact details or submit fresh ones while generating the renewal 
request. APNIC or NIRs could also warn the affiliates if any complaints have 
been noticed in the past. It will ease the work for APNIC staff and NIRs.

 

prop 126-

 

As this proposal will help in increasing the number of participants, we would 
like to submit a few suggestions to be included in the PDPs: 


1. In upcoming APNIC meetings, Proposal may be submitted in a tabular format, 
where required. Also, the previous versions of the proposals could be submitted 
in track change mode so as to make it easy for participants to compare various 
parameters and previous versions. The author may also submit the statistics, 
reports etc related to the incidents or observations which they are relying 
upon or using as a reference or justification for the amendment or requirement 
of the new policy. 


2.  The proposed proposal could also be discussed at OPMs of National Internet 
Registries. OPMs could be conducted after the submissions of proposals. This 
will also help to increase the number of participants in discussions from the 
NIR registries affiliate’s members and others.

 

Regards,

 

Shiva

 

 

On Wednesday, 12 September, 2018, 5:15:29 AM IST, 
 wrote: 

 

 

Send sig-policy mailing list submissions to

sig-policy@lists.apnic.net

 

To subscribe or unsubscribe via the World Wide Web, visit

https://mailman.apnic.net/mailman/listinfo/sig-policy

or, via email, send a message with subject or body 'help' to

sig-policy-requ...@lists.apnic.net

 

You can reach the person managing the list at

sig-policy-ow...@lists.apnic.net

 

When replying, please edit your Subject line so it is more specific

than "Re: Contents of sig-policy digest..."

 

 

Today's Topics:

 

  1. Re:  Prop124 version 4 (Owen DeLong)

 

 

--

 

Message: 1

Date: Tue, 11 Sep 2018 16:45:07 -0700

From: Owen DeLong 

To: JORDI PALET MARTINEZ 

Cc: SIG policy 

Subject: Re: [sig-policy] Prop124 version 4

Message-ID: 

Content-Type: text/plain; charset="utf-8"

 

 

 

> On Sep 11, 2018, at 16:19 , JORDI PALET MARTINEZ  
> wrote:

> 

> Hi Owen,

>  

> For me (and a couple of other folks that I checked around this morning), your 
> wording is more difficult to read.

> 

 

> This may be because we aren?t native English speakers.

 

Interesting? Probably be. As a native English speaker, frankly, your version 
simply doesn?t parse. The grammar doesn?t really work.

 

Examples:

 

?Providing

[sig-policy] consensus definition

[JORDI PALET MARTINEZ]

Hi all,

As introduced in the meeting, here is the definition for consensus that I've 
compiled for the PDP update in LACNIC last May.

2. Definition of ‘Consensus’
Achieving ‘consensus’ does not mean that proposals are voted for and against, 
nor that the number of ‘yes's’, ‘no's’ and ‘abstentions’ – or even participants 
– are counted, but that the proposal has been discussed not only by its 
author(s) but also by other members of the community, regardless of their 
number, and that, after a period of discussion, all critical technical 
objections have been resolved.

In general, this might coincide with a majority of members of the community in 
favor of the proposal, and with those who are against the proposal basing their 
objections on technical reasons as opposed to ‘subjective’ reasons. In other 
words, low participation or participants who disagree for reasons that are not 
openly explained should not be considered a lack of consensus.

Objections should not be measured by their number, but instead by their nature 
and quality within the context of a given proposal. For example, a member of 
the community whose opinion is against a proposal might receive many ‘emails’ 
(virtual or real) in their support, yet the chairs might consider that the 
opinion has already been addressed and technically refuted during the debate; 
in this case, the chairs would ignore those expressions of support against the 
proposal.

For information purposes, the definition of ‘consensus’ used by the RIRs and 
the IETF is actually that of ‘rough consensus’, which allows better clarifying 
the goal in this context, given that ‘consensus’ (Latin for agreement) might be 
interpreted as ‘agreed by all’ (unanimity). More specifically, RFC7282, 
explains that “Rough consensus is achieved when all issues are addressed, but 
not necessarily accommodated.”

Regards,
Jordi
 
 



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



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] comments regarding prop-126 (PDP Update)

[JORDI PALET MARTINEZ]

Hi all,

I think the clearest message form the SIG meeting today is that we must keep 
the 4 weeks period for the submission before the meeting.

I will like to know if you will agree with something mid-term in between 1 week 
and 4 weeks. Does the community think that 2 or 3 weeks may be sufficient?

My other question. I guess there will be some minutes or I can look at the 
video from the meeting, but it will be much better, I think, if all the people 
that contributed with their opinion, can state clearly here in the list their 
comments on each step (1, 2, 3) and even the appeals process.

This will take you only 5 minutes, and if I get sufficient comments during the 
day, I can submit a new version already tonight, so we can keep the ball 
rolling.

Thanks again to all those that have contributed!

Regards,
Jordi
 
 



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



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

[JORDI PALET MARTINEZ]

HI Aftab,

 

Thanks for providing inputs!

 

My reading of the actual policy is that it actually enforces the multihoming 
“in a reasonable future”. 

An organization will also be eligible if it can demonstrate that it will
meet the above criteria upon receiving an ASN (or within a reasonably
short time thereafter).

So, the question I’m trying to solve is what if I can’t or don’t want to 
multihome? I’m an SME, I want to have my own IPv6 PI announced with my own ASN, 
however I’m fine not multihoming.


Regards,

Jordi

 

 

 

De:  en nombre de Aftab Siddiqui 

Fecha: jueves, 24 de enero de 2019, 2:28
Para: Policy SIG 
Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

 

Hi Jordi,

We updated this requirement after a year-long discussion within the community. 
It doesn't enforce you to multi-home but suggests you should in the future. I 
don't see this as a roadblock in receiving PI address space. 

 

Regards,

Aftab A. Siddiqui

 

 

On Tue, Jan 22, 2019 at 11:14 AM Bertrand Cherrier  
wrote:

Dear SIG members,

The proposal "prop-128-v001: Multihoming not required for ASN" has been
sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 47 in
Daejeon, South Korea on Wednesday, 27 February 2019.

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-128
Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

prop-128-v001: Multihoming not required for ASN

Proposers: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
When the ASN assignment policy was originally designed, the reliability
of networks was not so good as today. So, at that time, it was making
sense to make sure that and ASN holder is multihomed.

However, today this is not necessarily a reasonable requirement, and
even in some cases, some networks may require an ASN and not willing
to be multihomed (because the cost, or remote locations that have only
a single upstream, etc.), and their SLA requirements don’t need that
redundancy.

The deployment of IPv6 also increase the need for organizations which
are not ISPs, to obtain IPv6 PI in order to have stable addresses,
and in that situation, ideally, they should announce their PI space
with their own ASN. In most cases, they don’t have to be multihomed.
2. Objective of policy change
To ensure that organizations which have their own routing policy and
the need to interconnect with other organizations, can do it.

Interconnect is used here with the commonly understood meaning of
establishing a connection between two (administratively) separate
networks.
3. Situation in other regions
ARIN and LACNIC don’t require multihoming. RIPE requires it. AfriNIC has
a policy equivalent to APNIC, but I’m submitting a proposal similar to
this one to change it as well as in the case of RIPE.
4. Proposed policy solution
Current Policy text

12.1. Evaluation of eligibility

An organization is eligible for an ASN assignment if:
- it is currently multihomed, or
- it holds previously-allocated provider independent address space and
intends to multihome in the future.

An organization will also be eligible if it can demonstrate that it will
meet the above criteria upon receiving an ASN (or within a reasonably
short time thereafter).

Requests for ASNs under these criteria will be evaluated using the
guidelines described in RFC1930 'Guidelines for the creation, selection
and registration of an Autonomous System' (AS).

Proposed text

12.1. Evaluation of eligibility

An organization is eligible for an ASN assignment if:
- it is multihomed or
- has the need to interconnect with other AS.

An organization will also be eligible if it can demonstrate that it will
meet any
of the above criteria upon receiving an ASN (or within a reasonably
short time thereafter).

Requests for ASNs under these criteria will be evaluated using the
guidelines described in RFC1930 'Guidelines for the creation, selection
and registration of
an Autonomous System' (AS).
5. Advantages / Disadvantages
Advantages:
Fulfilling the objectives above indicated.

Disadvantages:
None foreseen.
6. Impact on resource holders
None.
7. References
https://www.arin.net/policy/nrpm.html#five
https://www.lacnic.net/683/2/lacnic/
https://www.ripe.net/publications/docs/ripe-679

*  sig-policy:  APNIC SIG on resource management poli

Re: [sig-policy] prop-124-version 5: Clarification on IPv6 Sub-Assignments

[JORDI PALET MARTINEZ]

Dear Satoru, all,

 

First of all, thanks a lot for your inputs!

 

Let me try to clarify this.

 

The text of the problem statement has been the same (maybe minor variations) 
across the 4 previous versions, so it is difficult to understand what is not 
clear now, which can have been addressed before.

 

In any case, what it matters in a policy proposal, is the policy text and the 
objective of the change.

 

What happens with current policy is that if you’re an enterprise with assigned 
addressing space, you can only use it for your own infrastructure and within it.

 

If you want to have a “guest” WiFi (visitors in the company, students in a 
University), or you need to provide it via VPN, or point-to-point links, it is 
not allowed. The problem statement just provides more examples and cases, but 
everything boils down to the same.

 

I don’t think that was the intended purpose of the original policy, but that 
text has been carried out from IPv4 policies, and in most of the cases, there 
you don’t have the same problem because you’re providing to the visitors or 
students private addressing space behind a NAT.

 

Let me know please, if this is clearer as a “short” for the problem statement 
and objective of the policy change.


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: viernes, 22 de febrero de 2019, 12:29
Para: Policy SIG 
Asunto: Re: [sig-policy] prop-124-version 5: Clarification on IPv6 
Sub-Assignments

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.

 

I would like to share a feedback in our community for prop-124,

based on a meeting we organized on 12th Feb to discuss these proposals.

 

Many participants expressed a neutral for the proposal with reasons that

the problem in the current policy is something vague.

 

And a few opposing comments were expressed with same reason as above.

 

 

Best Regards,

 

Satoru Tsurumaki

JPOPF-ST

 

2019年1月10日(木) 13:28 Bertrand Cherrier :

Dear SIG members,

We wish you all the best for this new year !

A new version of the proposal "prop-124: Clarification on IPv6
Sub-Assignments"
has been sent to the Policy SIG for review.

Information about earlier versions is available from:

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

You are encouraged to express your views on the proposal:

· Do you support or oppose the proposal?

· Is there anything in the proposal that is not clear?

· What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

prop-124-v005: Clarification on IPv6 Sub-Assignments

Proposer: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
When the policy was drafted, the concept of assignments/sub-assignments
did not consider a practice very common in IPv4 which is replicated and
even amplified in IPv6: the use of IP addresses for point-to-point links
or VPNs.

In IPv4, typically, this is not a problem because the usage of NAT.

In the case of IPv6, instead of unique addresses, the use of unique
prefixes (/64) is increasingly common.

Likewise, the policy failed to consider the use of IP addresses in
hotspots hotspots (when is not an ISP, for example, associations or
community networks), or the use of IP addresses by guests or employees
in Bring Your Own Device (BYOD) and many other similar cases.

One more case is when an end-user contracts a third-party to do some
services in their own network and they need to deploy their own devices,
even servers, network equipment, etc. For example, security surveillance
services may require that the contractor provides their own cameras,
recording system, even their own firewall and/or router for a dedicated
VPN, etc. Of course, in many cases, this surveillance system may need
to use the addressing space of the end-user.

Finally, the IETF has recently approved the use of a unique /64 prefix
per interface/host (RFC8273) instead of a unique address. This, for
example, allows users to connect to a hotspot, receive a /64 such that
they are “isolated” from other users (for reasons of security, regulatory
requirements, etc.) and they can also use multiple virtual machines on
their devices with a unique address for each one (within the same /64).
2. Objective of policy change
Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits
such assignments, stating that “Assigned ... may not be sub-assigned”.

This proposal clarifies this situation in this regard and better define
the concept, particularly considering new uses of IPv6 (RFC8273), by means
of new text.

It also clarifies that the usage of sub-assignments in ISPs, data centers
and similar cases is not allowed.
3. Situation in other regions
This situation, has already been corrected in RIPE, and the policy was
updated in a similar way, even if right now there is a small discrepancy
between the polic

Re: [sig-policy] Version 3 - prop-126 PDP Update

[JORDI PALET MARTINEZ]

Hi Satoru, and again thanks a lot for the inputs,

 

Let me try to explain this.

 

The PDP is by definition a community matter.

 

The AMM is a smaller subset than the community, which in turn is represented by 
the EC.

 

In a bottom-up approach, it doesn’t make sense that a decision taken by the 
community as a whole, it can be turn-down by only part of the community.

 

Furthermore, as a “protection” measure, in case of a policy that may pose a 
strong problem for APNIC, the EC is still able to hear the membership and/or by 
their own decision, return the policy to the SIG for further discussion.

 

In addition to that, before the EC takes a determination, we have a last-call.

 

I think if you look at the current PDP diagram at 
https://www.apnic.net/community/policy/process/policy-development-process/

 

is easy to understand why doesn’t make sense to have the “double” (actually 
quadruple) consensus determination:
SIG
AMM
Final Call
EC
Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: viernes, 22 de febrero de 2019, 12:29
Para: Policy SIG 
Asunto: Re: [sig-policy] Version 3 - prop-126 PDP Update

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.

 

I would like to share a feedback in our community for prop-126,

based on a meeting we organized on 12th Feb to discuss these proposals.

 

Many participants expressed a supporting for the proposal.

But a few opposing comments were expressed with concern that

losing opportunities for remarks of APNIC members by losing

consensus call at AMM.

 

Best Regards,

 

Satoru Tsurumaki

JPOPF-ST

 

 

2019年1月18日(金) 9:23 Bertrand Cherrier :

Dear SIG members

A new version of the proposal "prop-126: PDP Update"
has been sent to the Policy SIG for review.

Information about earlier versions is available from:

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

You are encouraged to express your views on the proposal:

· Do you support or oppose the proposal?

· Is there anything in the proposal that is not clear?

· What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

prop-126-v003: PDP Update

Proposer: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
With its requirement of face-to-face participation at the OPM, the
current PDP might – at least partially – be the cause of the low
levels of community participation in the process by using the
policy mailing list.

This proposal would allow an increased participation, by explicitly
considering also the comments in the list for the consensus
determination. So, consensus would be determined balancing the
mailing list and the forum, and would therefore increase
community participation.

Further, policy proposals are meant for the community as a whole,
and not only APNIC members, so this proposal suggest removing
the actual “double” consensus required in both groups.

Finally, it completes the PDP by adding a simple mechanism for
solving disagreements during an appeals phase and an improved
definition of ‘consensus’, as well as a complete definition of
the “consensus” and “last-call”.
2. Objective of policy change
To allow that consensus is determined also looking at the opinions
of community members that are not able to travel to the meetings,
adjust the time required before the relevant SIG to submit the
proposals, not requiring “double” consensus with the APNIC members
and facilitating a simple method for appeals.
3. Situation in other regions
The PDP is different in the different RIRs. This proposal is similar
to the RIPE PDP, possibly the region with the broadest participation
in its policy proposal discussions, although there are certain
differences such as the mandatory use of the mailing list and the
meeting, which is more similar to the PDP at ARIN (another region
with broad community participation). LACNIC has recently adopted
a similar policy proposal with the same aims.
4. Proposed policy solution
Section 4. Proposal process

A policy proposal must go through the following chronological steps
in order to be adopted by APNIC.

Step 1

Actual:

Discussion before the OPM

A formal proposal paper must be submitted to the SIG mailing list and to
the SIG Chair
four weeks before the start of the OPM. The proposal must be in text
which clearly
expresses the proposal, with explicit mention of any changes being
proposed to existing
policies and the reasons for those changes. The APNIC Secretariat will
recommend a
preferred proposal format. If the four-week deadline is not met,
proposals may still
be submitted and presented for discussion at the meeting; however, no
decision may
be made by the meeting regarding the proposal. The proposal will need to
be resubmitted
in time for the following meeting if the author wishes to pursue the
proposal.

Proposed:
Discussion before the OPM

A f

Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

[JORDI PALET MARTINEZ]

Hi again Satoru, and once more many thanks for the inputs,

 

If we keep “it holds previously-allocated provider independent address space”, 
then it means an organization, for example, deploying only IPv6, will not be 
able to get an ASN.

 

Or even an organization willing to get IPv4, can’t get it from APNIC. Should 
them then wait for available IPv4 space and not have their own ASN meanwhile?

 

Or should they “promise” “I will multihome” and actually never do it? (there is 
no a concrete time term defined in the policy).

 

Or going to the extreme. Should the organization get IPv4 PI, but actually not 
use it?

 

Or should the organization request IPv6 PI today and tomorrow an ASN ? It is 
artificial!

 

If we really want to ensure that those organizations multihome, we really need 
to fix in how much time, and that was already changed in proposal 114. I think 
this proposal improves that, going to the point where probably prop-114 wanted 
to be (but sometimes you need to go step by step …).

 

In general, I don’t think restricting non-scarce resources as ASN is a good 
thing, and if that happens APNIC should report it back to the community and 
then we may consider it back.

 

Current text is artificial in the sense that already prop-114 expressed. People 
can just lie “I will …”.


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: viernes, 22 de febrero de 2019, 12:30
Para: Policy SIG 
Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.

 

I would like to share a feedback in our community for prop-128,

based on a meeting we organized on 12th Feb to discuss these proposals.

 

Substantial support expressed, subject to not deleting the 

"it holds previously-allocated provider independent address space" 

described in the current policy text.

 

* In this proposal, "it holds previously-allocated provider independent 

address space" is erased. it should keep it in order to prevent unnecessary

application of AS number.

 

* In the case of IPv6, the NAT disappears and the global address is assigned

to all device in the organization. If each organization uses a PI address

that is not locked in to a upper provider, there is a great merit that

there is no need to procure the second transit.

 

*There are areas where have only one transit as pointed out by the proposer.

This proposal has the effect that policy conforms to the actual situation

as a result.

 

 

Best Regards,

 

Satoru Tsurumaki

JPOPF-ST

 

2019年1月22日(火) 9:14 Bertrand Cherrier :

Dear SIG members,

The proposal "prop-128-v001: Multihoming not required for ASN" has been
sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 47 in
Daejeon, South Korea on Wednesday, 27 February 2019.

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-128
Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

prop-128-v001: Multihoming not required for ASN

Proposers: Jordi Palet Martínez
jordi.pa...@theipv6company.com
1. Problem Statement
When the ASN assignment policy was originally designed, the reliability
of networks was not so good as today. So, at that time, it was making
sense to make sure that and ASN holder is multihomed.

However, today this is not necessarily a reasonable requirement, and
even in some cases, some networks may require an ASN and not willing
to be multihomed (because the cost, or remote locations that have only
a single upstream, etc.), and their SLA requirements don’t need that
redundancy.

The deployment of IPv6 also increase the need for organizations which
are not ISPs, to obtain IPv6 PI in order to have stable addresses,
and in that situation, ideally, they should announce their PI space
with their own ASN. In most cases, they don’t have to be multihomed.
2. Objective of policy change
To ensure that organizations which have their own routing policy and
the need to interconnect with other organizations, can do it.

Interconnect is used here with the commonly understood meaning of
establishing a connection between two (administratively) separate
networks.
3. Situation in other regions
ARIN and LACNIC don’t require multihoming. RIPE requires it. AfriNIC has
a policy equivalent to APNIC, but I’m submitting

Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

[JORDI PALET MARTINEZ]

Hi Owen,

 

To make it short I’m not going to go into all the details, as I don't think is 
needed.

 

The point is, I’ve no doubt that the staff is smart to allow two consecutive 
requests for addresses first and one instant after the ASN. However, this is 
totally artificial in my opinion. No need for that.

 

Second main issue. Yes, people can commit fraud, but policies should not 
“facilitate that” if we can avoid it. Asking people to say “I will multihome”, 
is not coherent if not verified, so let’s try to avoid “promises”.


Regards,

Jordi

 

 

 

De: Owen DeLong 
Fecha: viernes, 22 de febrero de 2019, 19:00
Para: JORDI PALET MARTINEZ 
CC: Satoru Tsurumaki , Policy SIG 

Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

 

 



On Feb 21, 2019, at 22:20 , JORDI PALET MARTINEZ  
wrote:

 

Hi again Satoru, and once more many thanks for the inputs,

 

If we keep “it holds previously-allocated provider independent address space”, 
then it means an organization, for example, deploying only IPv6, will not be 
able to get an ASN.

 

Why can’t they get previously-allocated IPv6 Provider Independent space?

 

Or even an organization willing to get IPv4, can’t get it from APNIC. Should 
them then wait for available IPv4 space and not have their own ASN meanwhile?

 

If they don’t have address space to advertise, what, exactly, are they going to 
use the AS Number for in the mean time?

 

I’m not opposed to deleting the phrase, but I am truly curious if you have an 
actual use case where removing it is harmful.

 

Or should they “promise” “I will multihome” and actually never do it? (there is 
no a concrete time term defined in the policy).

 

Ideally, no.

 

Or going to the extreme. Should the organization get IPv4 PI, but actually not 
use it?

 

This part still doesn’t make sense to me. The phrase mentioned does not specify 
IPv4, yet you seem to be assuming that is a requirement. Am I missing something?

 

Or should the organization request IPv6 PI today and tomorrow an ASN ? It is 
artificial!

 

Previously doesn’t necessarily mean separation by days. I think that the RIR 
staff can be trusted to accept applications contemporaneously and issue the 
addresses first, followed by he ASN, thus meeting the requirement in the policy.

 

If you have a better way to address the issue they are bringing up, then 
propose that and let’s discuss it as a community.

 

As I understand their message, the concern is issuing ASNs that have no actual 
use/need. I don’t think anyone is trying to put up artificial barriers to 
entry, but there is a desire to ensure that ASN acquisition doesn’t become some 
form of network fashion statement.

 

If we really want to ensure that those organizations multihome, we really need 
to fix in how much time, and that was already changed in proposal 114. I think 
this proposal improves that, going to the point where probably prop-114 wanted 
to be (but sometimes you need to go step by step …).

 

I seem to recall Skeeve put forth a proposal to eliminate the multihoming 
requirement some years back because it was becoming problematic in a number of 
situations where peering was desirable, but multihoming couldn’t necessarily be 
achieved (or at least had a longer than permitted time frame).

 

At the time, I had suggested the use of “Multihomed or otherwise demonstrate a 
unique routing policy.” which actually pretty well covers any situation in 
which you would need an ASN.

 

In general, I don’t think restricting non-scarce resources as ASN is a good 
thing, and if that happens APNIC should report it back to the community and 
then we may consider it back.

 

Having trouble parsing this sentence. If restriction of the resources occurs, 
it will be through policy, so I’m not sure what APNIC would need to report back 
to the community.

 

Current text is artificial in the sense that already prop-114 expressed. People 
can just lie “I will …”.

 

People can commit fraud in a number of ways in a variety of circumstances. I 
don’t think that the answer in most situations is to permit all the benefits by 
removing the rules to make it impossible to commit fraud (or at least 
pointless). It’s sort of like saying “Everyone on this freeway is always doing 
200Kph, therefore we should raise the speed limit to 200Kph.” If someone 
obtains resources from a falsified application, then they are committing fraud 
and I’m sure the APNIC legal team is quite capable of addressing that situation 
should sufficient evidence come to light.

 

Owen




Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: viernes, 22 de febrero de 2019, 12:30
Para: Policy SIG 
Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.

 

I would like to share a feedback in our community for prop-128,

based on a meeting we organized on 12th F

Re: [sig-policy] prop-124-version 5: Clarification on IPv6 Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Abdul,

 

Responding to you and Owen, as it seems you have the same feeling/questions.

 

There is no text in the existing policy that I’m suggesting to amend, that say 
that the sub-assignment needs to be registered.

 

There is no text that excludes the point-to-point links from that policy text 
(in fact Owen said “generally”).

 

There is no text that indicates if it is ok to use and end-user assignment for 
a Data Center and then sub-allocate to hosting or housing customers, even if 
you don’t register them at the RIR level, however, when I asked all the RIRs 
about that, all them responded that a DC for services to third parties is 
considered a case for LIR space, not end-user one.

 

Last, but not least, this issue started in RIPE, because some community 
networks offering free hotspot services, couldn’t get from the RIPE NCC that 
end-user addressing space, so a policy modification was required.

 

Then, I submitted a policy proposal to all the other 4 RIRs, to clarify the 
same question, because all that text was basically the same in all the regions, 
and as one of the ARIN AC members (Chris Woodfield) already indicated in this 
list on his email from 11th January), “ARIN recently adopted a proposal to 
solve the same problem statement”.


Regards,

Jordi

 

 

 

De:  en nombre de "Md. Abdul Awal" 

Fecha: miércoles, 27 de febrero de 2019, 1:37
Para: 
Asunto: Re: [sig-policy] prop-124-version 5: Clarification on IPv6 
Sub-Assignments

 

I agree with Owen and would like to express opposition to this proposal.

I believe the term "sub-assignment" has the indication of making official sub 
distribution of addresses by and LIR/ISP to their client organizations. The 
concerns addressed in this proposal seem to be covered already within the 
current texts in the quoted section of current policy. Or, at least not 
explicitly supports any of the situation mentioned in the proposal.

BR//Awal

On 22/2/19 4:09 PM, Owen DeLong wrote:

I express opposition to this policy change. 

 

There seems to me a misunderstanding of the term sub assignments in the 
proposal.

 

A subassignment is an issuance of a portion of your prefix to an external third 
party recorded at the RIR level or provided in a public database (e.g. whois, 
rwhois, or RDAP).

 

Point to point prefixes are generally exempt from being reported to the 
registry. In the case of a guest WiFi or VPN, again, these are not generally 
considered to be external subassignments subject to reporting.

 

The intent of the policy as written as I understand it (and staff, please 
clarify if APNIC is applying different interpretation) is to cover situations 
where an LIR (whether service provider or otherwise) is making recorded 
delegations of smaller blocks of address space to external entities (e.g. when 
an ISP assigns a /48 to a customer end site). It is not intended to and does 
not (to the best of my knowledge) preclude any of the use cases you have 
mentioned.

 

Owen

 



On Feb 21, 2019, at 21:46 , JORDI PALET MARTINEZ  
wrote:

 

Dear Satoru, all,

 

First of all, thanks a lot for your inputs!

 

Let me try to clarify this.

 

The text of the problem statement has been the same (maybe minor variations) 
across the 4 previous versions, so it is difficult to understand what is not 
clear now, which can have been addressed before.

 

In any case, what it matters in a policy proposal, is the policy text and the 
objective of the change.

 

What happens with current policy is that if you’re an enterprise with assigned 
addressing space, you can only use it for your own infrastructure and within it.

 

If you want to have a “guest” WiFi (visitors in the company, students in a 
University), or you need to provide it via VPN, or point-to-point links, it is 
not allowed. The problem statement just provides more examples and cases, but 
everything boils down to the same.

 

I don’t think that was the intended purpose of the original policy, but that 
text has been carried out from IPv4 policies, and in most of the cases, there 
you don’t have the same problem because you’re providing to the visitors or 
students private addressing space behind a NAT.

 

Let me know please, if this is clearer as a “short” for the problem statement 
and objective of the policy change.


Regards,

Jordi

 

 

 

De:  en nombre de Satoru Tsurumaki 

Fecha: viernes, 22 de febrero de 2019, 12:29
Para: Policy SIG 
Asunto: Re: [sig-policy] prop-124-version 5: Clarification on IPv6 
Sub-Assignments

 

Dear Colleagues,

 

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.

 

I would like to share a feedback in our community for prop-124,

based on a meeting we organized on 12th Feb to discuss these proposals.

 

Many participants expressed a neutral for the proposal with reasons that

the problem in the current policy is something vague.

 

And a few opposing comments were expressed with same reason as above.

Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Aftab,

 

We are dealing with similar problems also in other regions, so regardless if 
this has been visible or not for the secretariat, the problem exists.

 

As explained in the problem statement, the actual text (I’m going to speak in a 
generic way for all the cases, IPv4, IPv6 and ASN), doesn’t clarify if this is 
only intra-RIR or also intra-RIR. This is the key part.

 

The actual text doesn’t contemplate the cases related to re-organization of 
companies (typically big groups), or relocation from one region to another. 
This is also very important.

 

Also, doesn’t clarify if this is also acceptable for a partial acquisition. I 
know this probably is being correctly interpreted by the secretariat, but 
because the problem indicated in the previous two paragraphs, I’m taking the 
opportunity to clarify that in the text.

 

Now, to better understand it, I can present several examples.

 
A big multinational operator, working in several regions, has excess of IPv4 
addresses in one region (RIR), so is using some of them in another region. With 
the actual text, it is not clear they can “re-organize” the correct 
registration of those addresses.
An operator has business covering transit, service provider and data-centers. 
They decide to sell only part of it, let’s say the data-centers. So, this is a 
very clear case for a “partial M&A”, it may be in the same regions or among 
regions, but there are more complex cases.
A company has a data center, using VMs in one region, let’s say Europe. They 
decide to relocate to Asia, with a new company, because they have better 
business opportunities, or less taxes or lower costs, or whatever. Because all 
is about VMs, you can do this “on-line”, it will take a few hours/days, this 
can be done by several means, and when all is done “keep” the VMs in sync and 
in a few minutes, shut down the old VMs and keep only the new ones, with the 
original addressing space they had in Europe. Of course, this may be the 
complete company, or only a division of it (creating a new company).
 

Please, let me know if this is sufficiently clear.

 

I’m happy to include those examples in a new version of the policy proposal if 
that helps.


Regards,

Jordi

 

 

 

De:  en nombre de Aftab Siddiqui 

Fecha: viernes, 15 de marzo de 2019, 15:21
Para: Sumon Ahmed Sabir 
CC: Policy SIG 
Asunto: Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of 
transfer policies

 

If I may ask the author.

 

- Explain the problem statement.

- Can you provide an example where this "unclear policy of M&A" created a 
problem?

- Did you ask Secretariat if this is actually a problem? Did they provide any 
stats?


Regards,

Aftab A. Siddiqui

 

 

On Thu, Mar 14, 2019 at 11:59 PM Sumon Ahmed Sabir  wrote:

 

Dear SIG members,

The proposal "prop-130-v001: Modification of transfer policies"
has been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

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

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

* sig-policy: APNIC SIG on resource management policy * 
___ sig-policy mailing list 
sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Sumon,

 

I’m sure I’ve responded.

 

I just looked at the email archive, just in case, and my response is there:

 

https://mailman.apnic.net/mailing-lists/sig-policy/archive/2019/03/msg3.html

 

 

Regards,

Jordi

 

 

 

De:  en nombre de Sumon Ahmed Sabir 

Fecha: martes, 19 de marzo de 2019, 14:37
Para: 
CC: Policy SIG 
Asunto: Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of 
transfer policies

 

 

Dear Jordi,

 

May we have some discussion about the proposed policy? Could you please respond?

 

regards,

 

Sumon

 

On Fri, Mar 15, 2019 at 8:20 PM Aftab Siddiqui  wrote:

If I may ask the author.

 

- Explain the problem statement.

- Can you provide an example where this "unclear policy of M&A" created a 
problem?

- Did you ask Secretariat if this is actually a problem? Did they provide any 
stats?


Regards,

Aftab A. Siddiqui

 

 

On Thu, Mar 14, 2019 at 11:59 PM Sumon Ahmed Sabir  wrote:

 

Dear SIG members,

The proposal "prop-130-v001: Modification of transfer policies"
has been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

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

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

* sig-policy: APNIC SIG on resource management policy * 
___ sig-policy mailing list 
sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Amendment of SIG Charter

[JORDI PALET MARTINEZ]

Hi Paul, all,

 

I feel that this proposed charter is not good enough.

 

Let me try to explain it.

 

In RIPE we have a WG for every kind of “topic”, for example, addressing, abuse, 
routing, etc. The PDP updates are discussed in the “plenary” (we have recent 
small update and this was not really clear).

 

However, in all the other regions, all the “topics” are within the same 
“unique” WG. There is an exception for ARIN (if I’m correct) where the PDP is 
not part of this “policy discussion group”.

 

The proposed charter, may fail to cover for example the PDP update, but I feel 
there are many other topics that may be in the future in the same situation.

 

So why not something more generic in the line of:

“The Policy SIG charter is to develop policies which relate to the management 
and use of Internet address resources within the Asia Pacific region, including 
any topics under the scope of the Policy manual or updates of it”.


Regards,

Jordi

 

 

 

El 9/5/19 23:51, "Paul Wilson"  escribió:

 

Dear Sumon and all,

To reduce confusion over ISP/LIR/etc terminology, perhaps the charter could be 
stated more simply, along these lines:

“The Policy SIG charter is to develop policies which relate to the management 
and use of Internet address resources within the Asia Pacific region. …”

 

My 2c, with best regards,

 


Paul Wilson, Director-General, APNIC d...@apnic.net
http://www.apnic.net @apnicdg

On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote:

 

Thank you very much Aftab and Owen for your constructive feedback. We will 
definitely consider those views.

 

If any one has any different perspective please jump in and share your thoughts.

 

Sincerely,

 

Sumon

 

  

 

On Mon, May 6, 2019 at 10:52 AM Owen DeLong  wrote:

Aftab, I think you misread the proposed language. 

 

First, neither the current version nor the proposed version refer to members at 
all, but to the actions of the APNIC, NIRs, and ISPs. The one change I think 
should be made there is to replace ISPs with LIRs since not all LIRs are 
technically ISPs, though that is certainly the most common case.

 

As to your “not limited to” or “services related to resources”, I fail to see 
how that is not addressed by the proposed “…and related services”.

 

I support the language proposed by Sumon whether or not he chooses to take my 
NIR suggestion.

 

Owen

 



On May 5, 2019, at 03:21 , Aftab Siddiqui  wrote:

 

Thanks Sumon bhai for the initiative, 

 



Revised text suggest that all members/resource holders in APNIC are ISPs only, 
I would suggest to make it "APNIC and NIR members or resource holders in Asia 
Pacific region". Because not all members are resource holders.

 

Secondly, when you start mentioning topics in the charter then it may create 
confusion moving forward that only these topics can be covered so how about 
adding "not limited to" or "services related to resources" or something like 
that. 



 

 

Regards,

Aftab A. Siddiqui

 

 

On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir  wrote:

Dear Members,



In the last APNIC meeting in Daejoan there was a discussion that there is a 
perception 

That Policy SIG discusses only about “Address Policy”. On the other hand there 
is a understanding 

that Policy SIG covers a wider range of registry issues, RPKI or any other 
topics that requires a

procedures and rules. 



To avoid confusion and to bring clarity in the Policy Charter few proposals 
came in. That either we can change the Name of the Policy SIG to cover wider 
range or to amend the Policy-SIG Charter to bring clarity about the scope of 
Policy SIG.



After discussions chairs feels that we can make some changes in the SIG Charter 
to bring clarity:





Current SIG Charter https://www.apnic.net/community/policy/policy-sig/ says:





‘The Policy SIG charter is to develop policies and procedures which relate to 
the management and 

use of Internet address resources by APNIC, NIRs, and ISPs within the Asia 
Pacific region.”



And here is the possible changes proposed:



 “The Policy SIG charter is to develop policies which relate to the management 
and use of Internet  address resources by APNIC, NIRs, and ISPs within the Asia 
Pacific region.  These include policies for resource allocation, recovery and 
transfer, and for resource registration within whois, reverse DNS, RPKI and 
related services.”



Please share your views, comments or suggestions in this regard.





Sincerely,



Sumon, Bertrand and Ching-Heng

Chairs, Policy-SIG

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing li

Re: [sig-policy] Amendment of SIG Charter

[JORDI PALET MARTINEZ]

Just to make it clear. Do you believe that the PDP update is out of the scope?

 

I think that the PDP is not related to resource management, but the 
“self-management” of the way the community discusses the resource management 
and agree on the way it should be managed.

 

And for me as more we restrict the wording, more risks to wrongly get things 
that today are in-scope, to be left out.


Regards,

Jordi

 

 

 

El 11/5/19 1:27, "Owen DeLong"  escribió:

 

That’s not more generic, Jordi, it’s just more words.

 

There’s nothing within the scope of the policy manual or its updates that 
doesn’t relate to the management and use of internet address resources.

 

Owen

 



On May 10, 2019, at 09:30 , JORDI PALET MARTINEZ  
wrote:

 

Hi Paul, all,

 

I feel that this proposed charter is not good enough.

 

Let me try to explain it.

 

In RIPE we have a WG for every kind of “topic”, for example, addressing, abuse, 
routing, etc. The PDP updates are discussed in the “plenary” (we have recent 
small update and this was not really clear).

 

However, in all the other regions, all the “topics” are within the same 
“unique” WG. There is an exception for ARIN (if I’m correct) where the PDP is 
not part of this “policy discussion group”.

 

The proposed charter, may fail to cover for example the PDP update, but I feel 
there are many other topics that may be in the future in the same situation.

 

So why not something more generic in the line of:

“The Policy SIG charter is to develop policies which relate to the management 
and use of Internet address resources within the Asia Pacific region, including 
any topics under the scope of the Policy manual or updates of it”.


Regards,

Jordi

 

 

 

El 9/5/19 23:51, "Paul Wilson"  escribió:

 

Dear Sumon and all,

To reduce confusion over ISP/LIR/etc terminology, perhaps the charter could be 
stated more simply, along these lines:

“The Policy SIG charter is to develop policies which relate to the management 
and use of Internet address resources within the Asia Pacific region. …”

 

My 2c, with best regards,

 


Paul Wilson, Director-General, APNIC d...@apnic.net
http://www.apnic.net @apnicdg

On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote:

 

Thank you very much Aftab and Owen for your constructive feedback. We will 
definitely consider those views.

 

If any one has any different perspective please jump in and share your thoughts.

 

Sincerely,

 

Sumon

 

  

 

On Mon, May 6, 2019 at 10:52 AM Owen DeLong  wrote:

Aftab, I think you misread the proposed language. 

 

First, neither the current version nor the proposed version refer to members at 
all, but to the actions of the APNIC, NIRs, and ISPs. The one change I think 
should be made there is to replace ISPs with LIRs since not all LIRs are 
technically ISPs, though that is certainly the most common case.

 

As to your “not limited to” or “services related to resources”, I fail to see 
how that is not addressed by the proposed “…and related services”.

 

I support the language proposed by Sumon whether or not he chooses to take my 
NIR suggestion.

 

Owen

 




On May 5, 2019, at 03:21 , Aftab Siddiqui  wrote:

 

Thanks Sumon bhai for the initiative, 

 



Revised text suggest that all members/resource holders in APNIC are ISPs only, 
I would suggest to make it "APNIC and NIR members or resource holders in Asia 
Pacific region". Because not all members are resource holders.

 

Secondly, when you start mentioning topics in the charter then it may create 
confusion moving forward that only these topics can be covered so how about 
adding "not limited to" or "services related to resources" or something like 
that. 



 

 

Regards,

Aftab A. Siddiqui

 

 

On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir  wrote:

Dear Members,




In the last APNIC meeting in Daejoan there was a discussion that there is a 
perception 

That Policy SIG discusses only about “Address Policy”. On the other hand there 
is a understanding 

that Policy SIG covers a wider range of registry issues, RPKI or any other 
topics that requires a

procedures and rules. 




To avoid confusion and to bring clarity in the Policy Charter few proposals 
came in. That either we can change the Name of the Policy SIG to cover wider 
range or to amend the Policy-SIG Charter to bring clarity about the scope of 
Policy SIG.




After discussions chairs feels that we can make some changes in the SIG Charter 
to bring clarity:







Current SIG Charter https://www.apnic.net/community/policy/policy-sig/ says:







‘The Policy SIG charter is to develop policies and procedures which relate to 
the management and 

use of Internet address resources by APNIC, NIRs, and ISPs within the Asia 
Pacific region.”




And here is the possible changes proposed:




 “The Policy SIG charter is to develop p

Re: [sig-policy] Amendment of SIG Charter

[JORDI PALET MARTINEZ]

I’m not interpreting the PDP as part of that, however, I’m fine if the staff 
confirms that it is in-scope according to their understanding.

 

We have a recent experience of policies (resource hijacking is a policy 
violation) being declared out-of-scope in ARIN by the AC. I know the PDP is 
very different, but let’s make sure we don’t have this situation replicated in 
other APNIC.


Regards,

Jordi

 

 

 

El 11/5/19 18:05, "Owen DeLong"  escribió:

 

 


On May 11, 2019, at 06:13, JORDI PALET MARTINEZ  
wrote:

Just to make it clear. Do you believe that the PDP update is out of the scope?

 

No



I think that the PDP is not related to resource management, but the 
“self-management” of the way the community discusses the resource management 
and agree on the way it should be managed.

 

The pdp is absolutely related to the management of resources in that it is the 
process by which we develop those policies. 



And for me as more we restrict the wording, more risks to wrongly get things 
that today are in-scope, to be left out.

 

Agreed. However, in my view, your proposal is not less restrictive, just more 
verbose. 

 

Owen




Regards,

Jordi

 

 

 

El 11/5/19 1:27, "Owen DeLong"  escribió:

 

That’s not more generic, Jordi, it’s just more words.

 

There’s nothing within the scope of the policy manual or its updates that 
doesn’t relate to the management and use of internet address resources.

 

Owen

 




On May 10, 2019, at 09:30 , JORDI PALET MARTINEZ  
wrote:

 

Hi Paul, all,

 

I feel that this proposed charter is not good enough.

 

Let me try to explain it.

 

In RIPE we have a WG for every kind of “topic”, for example, addressing, abuse, 
routing, etc. The PDP updates are discussed in the “plenary” (we have recent 
small update and this was not really clear).

 

However, in all the other regions, all the “topics” are within the same 
“unique” WG. There is an exception for ARIN (if I’m correct) where the PDP is 
not part of this “policy discussion group”.

 

The proposed charter, may fail to cover for example the PDP update, but I feel 
there are many other topics that may be in the future in the same situation.

 

So why not something more generic in the line of:

“The Policy SIG charter is to develop policies which relate to the management 
and use of Internet address resources within the Asia Pacific region, including 
any topics under the scope of the Policy manual or updates of it”.


Regards,

Jordi

 

 

 

El 9/5/19 23:51, "Paul Wilson"  escribió:

 

Dear Sumon and all,

To reduce confusion over ISP/LIR/etc terminology, perhaps the charter could be 
stated more simply, along these lines:

“The Policy SIG charter is to develop policies which relate to the management 
and use of Internet address resources within the Asia Pacific region. …”

 

My 2c, with best regards,

 


Paul Wilson, Director-General, APNIC d...@apnic.net
http://www.apnic.net @apnicdg

On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote:

 

Thank you very much Aftab and Owen for your constructive feedback. We will 
definitely consider those views.

 

If any one has any different perspective please jump in and share your thoughts.

 

Sincerely,

 

Sumon

 

  

 

On Mon, May 6, 2019 at 10:52 AM Owen DeLong  wrote:

Aftab, I think you misread the proposed language. 

 

First, neither the current version nor the proposed version refer to members at 
all, but to the actions of the APNIC, NIRs, and ISPs. The one change I think 
should be made there is to replace ISPs with LIRs since not all LIRs are 
technically ISPs, though that is certainly the most common case.

 

As to your “not limited to” or “services related to resources”, I fail to see 
how that is not addressed by the proposed “…and related services”.

 

I support the language proposed by Sumon whether or not he chooses to take my 
NIR suggestion.

 

Owen

 





On May 5, 2019, at 03:21 , Aftab Siddiqui  wrote:

 

Thanks Sumon bhai for the initiative, 

 



Revised text suggest that all members/resource holders in APNIC are ISPs only, 
I would suggest to make it "APNIC and NIR members or resource holders in Asia 
Pacific region". Because not all members are resource holders.

 

Secondly, when you start mentioning topics in the charter then it may create 
confusion moving forward that only these topics can be covered so how about 
adding "not limited to" or "services related to resources" or something like 
that. 



 

 

Regards,

Aftab A. Siddiqui

 

 

On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir  wrote:

Dear Members,





In the last APNIC meeting in Daejoan there was a discussion that there is a 
perception 

That Policy SIG discusses only about “Address Policy”. On the other hand there 
is a understanding 

that Policy SIG covers a wider range of registry issues, RPKI or any other 

Re: [sig-policy] Amendment of SIG Charter

[JORDI PALET MARTINEZ]

I guess I confused you.

I was not mixing two things. One example was the PDP update in APNIC (or other 
regions), another example was the rejection because considered out-of-scope of 
the "resource hijacking proposal".

Regards,
Jordi
 
 

El 14/5/19 16:08, "Owen DeLong"  escribió:

My own opinion only and not speaking on behalf of or for the AC...

In the case of ARIN, your proposal was not to modify the PDP and addressed 
primarily the detailed operational practices of ARIN staff. It did not address 
the administration and registration of number resources, but rather the 
behavior of individuals external to ARIN with regard to how they configure 
their routers. 

In ARIN, the PDP is under the control of the board and is not modifiable 
via the PDP. 

I see no connection between your efforts here and your out of scope 
proposal there. 

Owen


> On May 14, 2019, at 06:15, Srinivas Chendi  wrote:
> 
> Hi Jordi,
> 
> Thanks for your contribution to this discussion so far.
> 
> As per the SIG Guidelines, Policy SIG Chair is responsible to accept or 
> reject a proposal and to check if it is in scope of the active SIG 
charter.
> 
> Please refer to the section 2.4 of SIG Guidelines
> https://www.apnic.net/community/participate/sigs/sig-guidelines/
> 
> 
> Accept or reject proposals for discussion at the forthcoming SIG (and 
> suggest an alternative forum if the topic is not relevant to that 
> particular SIG) [1]
> 
> [1] The Chair may decide that a proposal is not suitable for discussion 
> at the forthcoming SIG session if:
> 
> The proposal is out of scope for the SIG
> The proposal is insufficiently developed to be the basis for a 
> useful discussion
> The agenda has already been filled by topics of greater priority
> 
> 
> Regards
> Sunny
> 
>> On 14/05/2019 8:11 pm, JORDI PALET MARTINEZ wrote:
>> I’m not interpreting the PDP as part of that, however, I’m fine if the 
>> staff confirms that it is in-scope according to their understanding.
>> 
>> We have a recent experience of policies (resource hijacking is a policy 
>> violation) being declared out-of-scope in ARIN by the AC. I know the PDP 
>> is very different, but let’s make sure we don’t have this situation 
>> replicated in other APNIC.
>> 
>> 
>> Regards,
    >> 
>> Jordi
>> 
>> El 11/5/19 18:05, "Owen DeLong" > <mailto:o...@delong.com>> escribió:
>> 
>> 
>> On May 11, 2019, at 06:13, JORDI PALET MARTINEZ 
>> mailto:jordi.pa...@consulintel.es>> wrote:
>> 
>>Just to make it clear. Do you believe that the PDP update is out of
>>the scope?
>> 
>> No
>> 
>> 
>> 
>>I think that the PDP is not related to resource management, but the
>>“self-management” of the way the community discusses the resource
>>management and agree on the way it should be managed.
>> 
>> The pdp is absolutely related to the management of resources in that it 
>> is the process by which we develop those policies.
>> 
>> 
>> 
>>And for me as more we restrict the wording, more risks to wrongly
>>get things that today are in-scope, to be left out.
>> 
>> Agreed. However, in my view, your proposal is not less restrictive, just 
>> more verbose.
>> 
>> Owen
>> 
>> 
>> 
>> 
>>Regards,
>> 
>>Jordi
>> 
>>    El 11/5/19 1:27, "Owen DeLong" ><mailto:o...@delong.com>> escribió:
>> 
>>That’s not more generic, Jordi, it’s just more words.
>> 
>>There’s nothing within the scope of the policy manual or its updates
>>that doesn’t relate to the management and use of internet address
>>resources.
>> 
>>Owen
>> 
>> 
>> 
>> 
>>On May 10, 2019, at 09:30 , JORDI PALET MARTINEZ
>>mailto:jordi.pa...@consulintel.es>>
>>wrote:
>> 
>>Hi Paul, all,
>> 
>>I feel that this proposed charter is not good enough.
>> 
>>Let me try to explain it.
>> 
>>In RIPE we have a WG for every kind of “topic”, for example,
>>ad

Re: [sig-policy] Amendment of SIG Charter

[JORDI PALET MARTINEZ]

Hi Aftab,

 

If you don’t get my emails in the list, it may be due to DMARC. Email servers 
(such as mine), using DMARC, may get rejected by clients of mailing lists if 
the mailing list is keeping my email instead of using the list one.

 

It may happen that the APNIC list is not correctly configured?

 

In all the other RIRs and IETF, this has been “fixed” in mailman long time ago.


Regards,

Jordi

 

 

 

El 14/5/19 16:09, "Aftab Siddiqui"  escribió:

 

Hi Jordi,

You can always bring any topic to apnic-talk mailing list for discussion. Not 
everything has to be discussed on policy-sig mailing list. 

 

And somehow I’m not receiving your emails sent to the policy-sig mailing list 
:) 

 

On Tue, 14 May 2019 at 11:15 pm, Srinivas Chendi  wrote:

Hi Jordi,

Thanks for your contribution to this discussion so far.

As per the SIG Guidelines, Policy SIG Chair is responsible to accept or 
reject a proposal and to check if it is in scope of the active SIG charter.

Please refer to the section 2.4 of SIG Guidelines
https://www.apnic.net/community/participate/sigs/sig-guidelines/


Accept or reject proposals for discussion at the forthcoming SIG (and 
suggest an alternative forum if the topic is not relevant to that 
particular SIG) [1]

[1] The Chair may decide that a proposal is not suitable for discussion 
at the forthcoming SIG session if:

 The proposal is out of scope for the SIG
 The proposal is insufficiently developed to be the basis for a 
useful discussion
 The agenda has already been filled by topics of greater priority


Regards
Sunny

On 14/05/2019 8:11 pm, JORDI PALET MARTINEZ wrote:
> I’m not interpreting the PDP as part of that, however, I’m fine if the 
> staff confirms that it is in-scope according to their understanding.
> 
> We have a recent experience of policies (resource hijacking is a policy 
> violation) being declared out-of-scope in ARIN by the AC. I know the PDP 
> is very different, but let’s make sure we don’t have this situation 
> replicated in other APNIC.
> 
> 
> Regards,
> 
> Jordi
> 
> El 11/5/19 18:05, "Owen DeLong"  <mailto:o...@delong.com>> escribió:
> 
> 
> On May 11, 2019, at 06:13, JORDI PALET MARTINEZ 
> mailto:jordi.pa...@consulintel.es>> wrote:
> 
> Just to make it clear. Do you believe that the PDP update is out of
> the scope?
> 
> No
> 
> 
> 
> I think that the PDP is not related to resource management, but the
> “self-management” of the way the community discusses the resource
> management and agree on the way it should be managed.
> 
> The pdp is absolutely related to the management of resources in that it 
> is the process by which we develop those policies.
> 
> 
> 
> And for me as more we restrict the wording, more risks to wrongly
> get things that today are in-scope, to be left out.
> 
> Agreed. However, in my view, your proposal is not less restrictive, just 
> more verbose.
> 
> Owen
> 
> 
> 
> 
> Regards,
> 
> Jordi
> 
> El 11/5/19 1:27, "Owen DeLong"  <mailto:o...@delong.com>> escribió:
> 
> That’s not more generic, Jordi, it’s just more words.
> 
> There’s nothing within the scope of the policy manual or its updates
> that doesn’t relate to the management and use of internet address
> resources.
> 
> Owen
> 
> 
> 
> 
> On May 10, 2019, at 09:30 , JORDI PALET MARTINEZ
> mailto:jordi.pa...@consulintel.es>>
> wrote:
> 
> Hi Paul, all,
> 
> I feel that this proposed charter is not good enough.
> 
> Let me try to explain it.
> 
> In RIPE we have a WG for every kind of “topic”, for example,
> addressing, abuse, routing, etc. The PDP updates are discussed
> in the “plenary” (we have recent small update and this was not
> really clear).
> 
> However, in all the other regions, all the “topics” are within
> the same “unique” WG. There is an exception for ARIN (if I’m
> correct) where the PDP is not part of this “policy discussion
> group”.
> 
> The proposed charter, may fail to cover for example the PDP
> update, but I feel there are many other topics that may be in
> the future in the same situation.
> 
> So why not something more generic in the line of:
> 
> “The Policy SIG charter is to develop policies which relate to
> the management and use of Internet address resources within the
> Asia Pacific region, including any topics under the scope of the
> Policy manual or updates of it”.
> 
> 
> Regards,
> 
> Jordi
> 
> El 9/5/19

Re: [sig-policy] Amendment of SIG Charter

[JORDI PALET MARTINEZ]

Hi Sunny,

I understand that, however, that's the reason for having a proper charter, so 
the chairs have a "base" to take a decision.

If the text of the charter is not clear, then even if they want to accept a 
policy proposal, they can't.

Regards,
Jordi
 
 

El 14/5/19 15:15, "Srinivas Chendi"  escribió:

Hi Jordi,

Thanks for your contribution to this discussion so far.

As per the SIG Guidelines, Policy SIG Chair is responsible to accept or 
reject a proposal and to check if it is in scope of the active SIG charter.

Please refer to the section 2.4 of SIG Guidelines
https://www.apnic.net/community/participate/sigs/sig-guidelines/


Accept or reject proposals for discussion at the forthcoming SIG (and 
suggest an alternative forum if the topic is not relevant to that 
particular SIG) [1]

[1] The Chair may decide that a proposal is not suitable for discussion 
at the forthcoming SIG session if:

 The proposal is out of scope for the SIG
 The proposal is insufficiently developed to be the basis for a 
useful discussion
 The agenda has already been filled by topics of greater priority


Regards
Sunny
    
    On 14/05/2019 8:11 pm, JORDI PALET MARTINEZ wrote:
> I’m not interpreting the PDP as part of that, however, I’m fine if the 
> staff confirms that it is in-scope according to their understanding.
> 
> We have a recent experience of policies (resource hijacking is a policy 
> violation) being declared out-of-scope in ARIN by the AC. I know the PDP 
> is very different, but let’s make sure we don’t have this situation 
> replicated in other APNIC.
> 
> 
> Regards,
> 
> Jordi
> 
> El 11/5/19 18:05, "Owen DeLong"  <mailto:o...@delong.com>> escribió:
> 
> 
> On May 11, 2019, at 06:13, JORDI PALET MARTINEZ 
> mailto:jordi.pa...@consulintel.es>> wrote:
> 
> Just to make it clear. Do you believe that the PDP update is out of
> the scope?
> 
> No
> 
> 
> 
> I think that the PDP is not related to resource management, but the
> “self-management” of the way the community discusses the resource
> management and agree on the way it should be managed.
> 
> The pdp is absolutely related to the management of resources in that it 
> is the process by which we develop those policies.
> 
> 
> 
> And for me as more we restrict the wording, more risks to wrongly
> get things that today are in-scope, to be left out.
> 
> Agreed. However, in my view, your proposal is not less restrictive, just 
> more verbose.
> 
> Owen
> 
> 
> 
> 
> Regards,
> 
> Jordi
> 
> El 11/5/19 1:27, "Owen DeLong"  <mailto:o...@delong.com>> escribió:
> 
> That’s not more generic, Jordi, it’s just more words.
> 
> There’s nothing within the scope of the policy manual or its updates
> that doesn’t relate to the management and use of internet address
> resources.
> 
> Owen
> 
> 
> 
> 
> On May 10, 2019, at 09:30 , JORDI PALET MARTINEZ
> mailto:jordi.pa...@consulintel.es>>
> wrote:
> 
> Hi Paul, all,
> 
> I feel that this proposed charter is not good enough.
> 
> Let me try to explain it.
> 
> In RIPE we have a WG for every kind of “topic”, for example,
> addressing, abuse, routing, etc. The PDP updates are discussed
> in the “plenary” (we have recent small update and this was not
> really clear).
> 
> However, in all the other regions, all the “topics” are within
> the same “unique” WG. There is an exception for ARIN (if I’m
> correct) where the PDP is not part of this “policy discussion
> group”.
> 
> The proposed charter, may fail to cover for example the PDP
> update, but I feel there are many other topics that may be in
> the future in the same situation.
> 
> So why not something more generic in the line of:
> 
> “The Policy SIG charter is to develop policies which relate to
> the management and use of Internet address resources within the
> Asia Pacific region, including any topics under the scope of the
> Policy manual or updates of it”.
> 
> 
>

Re: [sig-policy] Version 4 of prop-126 PDP Update

[JORDI PALET MARTINEZ]

Hi Javed,

 

I don’t agree, let me explain why.

 

The current process only talks about the meeting and the chairs have clearly 
indicated that they take in consideration the list and the confer. Anyone from 
the community that dislikes a consensus/non-consensus decision, could create a 
trouble even in courts, because we are accepting consensus from sources not 
documented in the PDP. Rewording it resolves the problem.

 

Furthermore, the current process has not an “in-process” appeal procces. This 
will be ilegal in may legislations (may be only the AU applies, but considering 
that the community is “the entire Internet”, may be this may be declared 
illegal in another country where a member decides to claim for). The only way 
(actually) to appeal, will be going to the courts. We should not aim to that. 
We should have an internal way.

 

This is now even more relevant to be resolved, because by chance, the chairs 
have denied to accept one of the policy proposal that I’ve submited. They 
consider it out-of-scope, and my reading is that is in-scope (it has also been 
submitted and in-scope to RIPE, LACNIC and AFRINIC). I think their decision is 
wrong and this has many implications that we need to work out. The best avenue 
is having an “in-house” appeal process, of course.

 

Note that I didn’t knew, when I submitted the PDP update (which is a new 
version from a the previous year proposal), that one of my proposals will be 
considered by the chairs as out-of-scope. Clarification just so nobody believes 
that it is related to that rejection! Chairs can confirm that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/19 15:48, "Javed Khan"  escribió:

 

I do not support this proposal as I have complete trust in the current APNIC 
PDP and this community.

 

Kind regards

Javed Khan

MSCE and CCSP

 

From: sig-policy-boun...@lists.apnic.net  
on behalf of Sumon Ahmed Sabir 
Sent: Friday, 9 August 2019 2:13 AM
To: Policy SIG 
Subject: [sig-policy] Version 4 of prop-126 PDP Update 

 

 

Dear SIG members

A new version of the proposal "prop-126: PDP Update" has been sent to 
the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-126/

You are encouraged to express your views on the proposal:

  - Do you support or oppose the proposal?
  - Is there anything in the proposal that is not clear?
  - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


--

prop-126-v004: PDP Update

--

Proposer: Jordi Palet Martínez
   jordi.pa...@theipv6company.com


1. Problem Statement


With its requirement of face-to-face participation at the OPM, the current
PDP might – at least partially – be the cause of the low levels of 
community
participation in the process by using the policy mailing list.

This proposal would allow an increased participation, by explicitly 
considering
  the comments in the list for the consensus determination. So, 
consensus would
be determined balancing the mailing list and the forum, and would therefore
increase community participation.

Even if this is actually done by the chairs, it is not part of the 
actual PDP,
and thus constitutes a very clear and explicit violation of the PDP and 
the risk
is that anyone from the community could appeal any decision based on that.

Finally, it completes the PDP by adding a simple mechanism for solving 
disagreements
during an appeals phase and an improved definition of ‘consensus’, as 
well as a
complete definition of the “consensus” and “last-call”.


2. Objective of policy change
-

To allow that consensus is determined formally looking at the opinions 
of community
members that are not able to travel to the meetings and facilitating a 
simple method
for appeals.


3. Situation in other regions
-

The PDP is different in the different RIRs. This proposal is similar to 
the RIPE PDP,
possibly the region with the broadest participation in its policy 
proposal discussions,
although there are certain differences such as the mandatory use of the 
mailing list and
the meeting, which is more similar to the PDP at ARIN (another region 
with broad community
participation). LACNIC has recently adopted a similar policy proposal 
with the same aims.


4. Proposed policy solution
---

Current Text
Step 2: Consensus at the OPM
Consensus is defined as “general agreement” as observed by the Chair of 
the meeting.
Consensus must be reached first at the SIG session and afterwards at the 
Member 

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Javed,

 

I think you’re getting something wrong.

 

Policies aren’t there so APNIC can verify “everything” to “every” member. This 
will be impossible.

 

Policies are there so everybody know the rules, and try their best to avoid 
breaking them.

 

Policies are there to avoid bad-intentions from bad-Internet actors, in order 
to protect the majority (the good ones).

 

If we only accept policies when they can be verified, then we will have an 
empty policy book :-)

 

If APNIC does a verification, for whatever reason (any suspicius, a claim from 
another member, etc.), and a rule is broken, APNIC should take measures if the 
member doesn’t correct it. In some cases those measures may mean member 
closure, resource recovery, etc. This is a completely different discussion 
which has policy and service agreement implications.

 

Please, note before continue reading that this only affects end-user direct 
assignments by APNIC or the NIRs. Not clarifiying this caused some confusion in 
the discussion of the last meeting. So if you’re an ISP (I’m not sure if that’s 
your case), this proposal doesn’t affect you.

 

It only affect you, if you are getting a direct assignment from APNIC or any of 
the NIRs.

 

The fact here is that if, for example, an university, which got a direct 
assignment from APNIC, is providing the students public addresses (IPv4) or 
global addresses (IPv6), it is against the policy.

 

In the case of IPv4, the solution is easy, use NAT and private addresses (but 
not all the universities do that). However in IPv6 this is not the solution, we 
don’t have NAT.

 

I can put many other similar examples (remember again, this is only the case 
when the addresses are directly assigned to the end-user by APNIC or the NIR, 
not by an ISP): a point to point link from the university to another network, 
an employee getting addresses from a company, thir party companies offering 
services to that company or university, a municipality offering WiFi to 
citizens, etc.

 

The proposal solves both cases, the IPv4 and the IPv6 one.

 

Note that this has been already corrected in all the other RIRs (ARIN, AFRINIC, 
LACNIC and RIPE). All them had the same problem in their policy text.

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/19 16:01, "Javed Khan"  escribió:

 

I do not support this proposal. Intention is good but no one is really 
concerned nor can verify this in practice. I think the current policy text is 
good.

 

Kind regards

Javed Khan

MSCE and CCSP

 

From: sig-policy-boun...@lists.apnic.net  
on behalf of Sumon Ahmed Sabir 
Sent: Saturday, 10 August 2019 10:33 PM
To: Policy SIG 
Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments 

 

Dear SIG members

A new version of the proposal "prop-124: Clarification on Sub-Assignments"
has been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-124

You are encouraged to express your views on the proposal:

  - Do you support or oppose the proposal?
  - Is there anything in the proposal that is not clear?
  - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


--

prop-124-v006: Clarification on Sub-Assignments

--

Proposer: Jordi Palet Martínez
   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.

When the policy was drafted, the concept of assignments/sub-assignments 
did not
consider a practice very common in IPv4 which is replicated and even 
amplified
in IPv6: the use of IP addresses for point-to-point links or VPNs.

In IPv4, typically, this is not a problem if NAT is being used, because 
the assigned
addresses are only for the WAN link, which is part of the infrastructure 
or interconnection.

In the case of IPv6, instead of unique addresses, the use of unique 
prefixes
(/64) is increasingly common.

Likewise, the policy failed to consider the use of IP addresses in 
hotspots hotspots
(when is not an ISP, for example, associations or community networks), 
or the use of
IP addresses by guests or employees in Bring Your Own Device (BYOD) and 
many other
similar cases.

One more case is when an end-user contracts a third-party to do some 
services in their
own network and they need to deploy their own devices, even servers, 
network equipment,
etc.

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Owen, all,

 

Sorry the late answer … been too busy the last weeks.

 

Responses below, in-line.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/8/19 8:05, "Owen DeLong"  escribió:

 

 



On Aug 26, 2019, at 03:19 , JORDI PALET MARTINEZ  
wrote:

 

Hi Javed,

 

I think you’re getting something wrong.

 

Policies aren’t there so APNIC can verify “everything” to “every” member. This 
will be impossible.

 

Policies are there so everybody know the rules, and try their best to avoid 
breaking them.

 

Policies are there to avoid bad-intentions from bad-Internet actors, in order 
to protect the majority (the good ones).

 

If we only accept policies when they can be verified, then we will have an 
empty policy book :-)

 

If APNIC does a verification, for whatever reason (any suspicius, a claim from 
another member, etc.), and a rule is broken, APNIC should take measures if the 
member doesn’t correct it. In some cases those measures may mean member 
closure, resource recovery, etc. This is a completely different discussion 
which has policy and service agreement implications.

 

Please, note before continue reading that this only affects end-user direct 
assignments by APNIC or the NIRs. Not clarifiying this caused some confusion in 
the discussion of the last meeting. So if you’re an ISP (I’m not sure if that’s 
your case), this proposal doesn’t affect you.

 

It only affect you, if you are getting a direct assignment from APNIC or any of 
the NIRs.

 

The fact here is that if, for example, an university, which got a direct 
assignment from APNIC, is providing the students public addresses (IPv4) or 
global addresses (IPv6), it is against the policy.

 

No, this does not violate current policy. The students are part of the 
University every bit as much as employees of a company are entitled to receive 
valid public addresses for their BYO smart phones/whatever in the office.

 

The problem here is that it depends on if you consider the WiFi devices part of 
the infrastructure or not.

 

As you indicated in a previous email, this is proposal is a clarification that 
is good to have (and has been done the same in all the other RIRs for a good 
reason), it doesn’t create any issue and avoids any misinterpretation.

 

What happens (which the current text) if the students instead bring “servers” 
and have other devices behind those servers. Is that still part of the 
university infrastructure or not? What if instead of a single address a /64 is 
allocated, because they are running VMs?

 

What happens if instead of a university is a hotspot provider, may be even for 
free services to the community (community hot spot, for example a neighborhood).

 

What happens if it is a VPN service? It may be used to provide Internet 
connectivity to others, same as p2p links.

 

What happens if a DataCenter instead of becoming an LIR, uses end-user space 
directly assigned by APNIC to provide service to the customers?

 

I think all those points are perfectly clarified with the new text, and avoid 
subjective miss-interpretations.

 

That’s not sub assignment or reassignment, that’s just utilization within the 
Universities own network.

 

In the case of IPv4, the solution is easy, use NAT and private addresses (but 
not all the universities do that). However in IPv6 this is not the solution, we 
don’t have NAT.

 

NAT is not required by current policy. The policy text as it stands does not 
prohibit the (temporary) use of public addresses on LAN or WLAN segments 
controlled by the entity holding the prefix even if the device(s) are not 
owned/directly controlled by the University. Especially in the case where the 
devices are in the possession/control of employees/students of the institution 
in question.

 

Agree. I’m not saying that the policy requires NAT. I say that “typically” this 
doesn’t happen in the case of IPv4, because most of the resource-holders use 
NAT, but may be cases where we will have the same “open interpretation” with 
the current policy text, if the resource-holder decides not to use NAT and 
provide IPv4 public addresses.

 

If you think that is the case, then you have misunderstood the current policy.

 

Owen

 

I can put many other similar examples (remember again, this is only the case 
when the addresses are directly assigned to the end-user by APNIC or the NIR, 
not by an ISP): a point to point link from the university to another network, 
an employee getting addresses from a company, thir party companies offering 
services to that company or university, a municipality offering WiFi to 
citizens, etc.

 

The proposal solves both cases, the IPv4 and the IPv6 one.

 

Note that this has been already corrected in all the other RIRs (ARIN, AFRINIC, 
LACNIC and RIPE). All them had the same problem in their policy text.

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/19 16:01, "Javed Khan"  escribió:

 

I do not support this proposal. Intentio

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Javed,

 

I actually think this is in the other way around.

 

I believe you’re confusing different terms, clearly described in the 
definitions section of the policy manual:

 

2.2.1. Delegated address space

APNIC "delegates" addresses to its account holders. These delegations can be 
for use on the organization's own infrastructure (an "assignment") or for 
subsequent delegation by the organization to its customers (an "allocation").

 

2.2.2. Allocated address space

Allocated address space is address space that is distributed to IRs or other 
organizations for the purpose of subsequent distribution by them.

 

2.2.3. Assigned address space

Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific use within the Internet infrastructure they operate. 
Assignments must only be made for specific, documented purposes and may not be 
sub-assigned.

 

This policy is only relevant to “assigments”.

 

When an ISP (LIR) is getting addresses from APNIC for further distribution to 
customers, that space falls into the definition of “allocation”, so it is fine 
to further dirstribute it to other organizations.

 

When an ISP (LIR) is getting “assigned” space from ACPNIC, is not for 
re-distribution. This is what I’m triyng to clarify.

 

The fact that you are confused, I think, demonstrates that the actual text is 
subjected to multiple interpretations.

 

As an ISP/LIR, which the current text, for different people reading it, a p2p 
link may be or not considered part of the infratructure. Perhaps you can say, 
it is ok to use for a p2p if the CPE is from the ISP, but otherwise not.

 

My text clarify all the possible cases.

 

Regards,

Jordi

@jordipalet

 

 

 

El 29/8/19 2:49, "Javed Khan"  escribió:

 

Yes but the proposed text is not clear. In with the current policy text, LIRs 
are not allowed to make sub-assignments from their assigned address space 
outside of their infrastructure. So I do not support this change in policy.

 

J Khan

 

From: sig-policy-boun...@lists.apnic.net  
on behalf of Owen DeLong 
Sent: Saturday, 24 August 2019 12:45 AM
To: Simon Sohel Baroi / Global Business / 01847102243 / 

Cc: Sumon Ahmed Sabir ; Policy SIG 
Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments 

 

I think the current text isn’t really a problem because reasonable people apply 
a reasonable interpretation of intent rather than the literal meaning. 

 

The proposal brings literal meaning more in line with well understood intent. 

 

While I don’t believe there is an actual problem to solve here, I do think the 
proposal provides greater clarity in the language and therefore support it. 

 

Owen

 


On Aug 23, 2019, at 01:11, Simon Sohel Baroi / Global Business / 01847102243 / 
 wrote:

Dear Sir,

 

Also, Requesting to the Author to represent the Proposal with Example and 
Graphical Representation.

The example should have comparison with Present situation and the Propose 
Solution of the problem.

 

 

- with regards

 

SIMON.

 

On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir  wrote:

Dear SIG members

A new version of the proposal "prop-124: Clarification on Sub-Assignments"
has been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-124

You are encouraged to express your views on the proposal:

  - Do you support or oppose the proposal?
  - Is there anything in the proposal that is not clear?
  - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


--

prop-124-v006: Clarification on Sub-Assignments

--

Proposer: Jordi Palet Martínez
   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.

When the policy was drafted, the concept of assignments/sub-assignments 
did not
consider a practice very common in IPv4 which is replicated and even 
amplified
in IPv6: the use of IP addresses for point-to-point links or VPNs.

In IPv4, typically, this is not a problem if NAT is being used, because 
the assigned
addresses are only for the WAN link, which is part of the infrastructure 
or interconnection.

In the case of IPv6, instead of unique addresses, the use of unique 
prefixes
(/64) is increasingly common.

Likewise, the policy failed to consider the use of IP addresses in 

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Satoru,

Thanks for investing time in the several policy proposals.

I think that the last couple of emails could help all you to better understand 
the problem.

Clearly, if different people read the current policy text in a different way, 
it will be much better to find a way so we have a single and unique "reading" 
and no different ways to interpret it. Right?

Regards,
Jordi
@jordipalet
 
 

El 2/9/19 17:37, "Satoru Tsurumaki"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-124,based
on a meeting we organized on 21th Aug to discuss these proposals.

Many participants expressed a neutral for the proposal with reasons
that the problem in the current policy is something vague.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年8月10日(土) 23:33 Sumon Ahmed Sabir :

>
> Dear SIG members
>
> A new version of the proposal "prop-124: Clarification on Sub-Assignments"
> has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> Information about earlier versions is available from:
> https://www.apnic.net/community/policy/proposals/prop-124
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
>
> prop-124-v006: Clarification on Sub-Assignments
>
> --
>
> Proposer: Jordi Palet Martínez
>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.
>
> When the policy was drafted, the concept of assignments/sub-assignments
> did not
> consider a practice very common in IPv4 which is replicated and even
> amplified
> in IPv6: the use of IP addresses for point-to-point links or VPNs.
>
> In IPv4, typically, this is not a problem if NAT is being used, because
> the assigned
> addresses are only for the WAN link, which is part of the infrastructure
> or interconnection.
>
> In the case of IPv6, instead of unique addresses, the use of unique
> prefixes
> (/64) is increasingly common.
>
> Likewise, the policy failed to consider the use of IP addresses in
> hotspots hotspots
> (when is not an ISP, for example, associations or community networks),
> or the use of
> IP addresses by guests or employees in Bring Your Own Device (BYOD) and
> many other
> similar cases.
>
> One more case is when an end-user contracts a third-party to do some
> services in their
> own network and they need to deploy their own devices, even servers,
> network equipment,
> etc. For example, security surveillance services may require that the
> contractor provides
> their own cameras, recording system, even their own firewall and/or
> router for a dedicated
> VPN, etc. Of course, in many cases, this surveillance system may need to
> use the addressing
> space of the end-user.
>
> Finally, the IETF has recently approved the use of a unique /64 prefix
> per interface/host
> (RFC8273) instead of a unique address. This, for example, allows users
> to connect to a hotspot,
> receive a /64 such that they are “isolated” from other users (for
> reasons of security,
> regulatory requirements, etc.) and they can also use multiple virtual
> machines on their
> devices with a unique address for each one (within the same /64).
>
>
> 2. Objective of policy change
> -
>
> Section 2.2.3. (Definitions/Assigned Address Space), explicitly
> prohibits such assignments,
> stating that “Assigned ... may not be sub-assigned”.
>
> It also clarifies that the usage of sub-assignments in ISPs, data
> centers and similar cases
> is not allowed, according to the existing practices of APNIC.
>
>
> 3. Situation in other regions
> -
>
> This situation, has already been c

Re: [sig-policy] Version 4 of prop-126 PDP Update

[JORDI PALET MARTINEZ]

Hi Owen, 

 

 

El 27/8/19 8:15, "Owen DeLong"  escribió:

 

 



On Aug 26, 2019, at 03:05 , JORDI PALET MARTINEZ  
wrote:

 

Hi Javed,

 

I don’t agree, let me explain why.

 

The current process only talks about the meeting and the chairs have clearly 
indicated that they take in consideration the list and the confer. Anyone from 
the community that dislikes a consensus/non-consensus decision, could create a 
trouble even in courts, because we are accepting consensus from sources not 
documented in the PDP. Rewording it resolves the problem.

 

Furthermore, the current process has not an “in-process” appeal procces. This 
will be ilegal in may legislations (may be only the AU applies, but considering 
that the community is “the entire Internet”, may be this may be declared 
illegal in another country where a member decides to claim for). The only way 
(actually) to appeal, will be going to the courts. We should not aim to that. 
We should have an internal way.

 

While there is no appeal process, there are sufficient iterations of approval 
and ratification in the current process that I am not convinced an appeal 
process is necessary.

 

I don’t agree on that. If today chairs decide that something is out-of-scope, 
nobody has a way to change that decision. There is no way the community will be 
able to discuss the policy proposal as a “policy proposal”, because the chairs 
don’t accept it.

 

In the case of ARIN, there is a kind of appeal process with is the “petition 
process”. Here we don’t have that. And is the only region where we don’t have 
that.

 

I really think is very bad not having it.

 

I’m convinced the chairs always act on their best good faith and willingness, 
but this scheme, without a way for the community to oversee the chair’s 
decision is “per se” against the bottom-up approach.

 

Just imagine if we have a set of chairs that aren’t really acting in good 
faith, but on personal interest (please understand is just an example, not 
saying at all it is the present case). I don’t think we even have a way to 
remove them.

 

 

Calling out the (remote) possibility that some jurisdiction might have a 
problem with it is a red herring and absent actual legal doctrine within the 
APNIC service region, I think it’s a bit far fetched to put that argument 
forward.

 

Agree, but we need to understand that for sure there is a jurisdiction. And in 
my knowledge (not being a lawyer), any process that doesn’t have an implicit 
appeal process has lot of chances to be defeated in *any* jurisdiction. It is 
much better to avoid that, right ?

 

This is now even more relevant to be resolved, because by chance, the chairs 
have denied to accept one of the policy proposal that I’ve submited. They 
consider it out-of-scope, and my reading is that is in-scope (it has also been 
submitted and in-scope to RIPE, LACNIC and AFRINIC). I think their decision is 
wrong and this has many implications that we need to work out. The best avenue 
is having an “in-house” appeal process, of course.

 

You’ve been wrong about what should be in-scope before. I won’t cite the 
specifics unless you insist, but you are more than welcome to discuss your 
concerns about it with 

 

I’m not talking here about any specific policy proposal, as said before, this 
happened by chance. The inclusion of the appeal process in this PDP update was 
done one year in advance this situation, so not related to it.

 

Paul and/or the EC and I’m certain you will get an appropriate response. While 
it’s not a formal appeal process, I’m certain that if they agree with you that 
the co-chairs erred, they will discuss the situation with the co-chairs and 
come to an appropriate resolution.

 

Agree, and I talked to Paul about it. If I recall correctly, he only suggested 
to go to the open forum, not him, not the EC. However, we don’t have time 
allocated for it.

 

And furthermore, I don’t think it is savvy if this happens, that we must wait 6 
months for discussing it in a meeting.

 

If you read the PDP, there is no definition of the scope and there is a 
contradiction in the text 
(https://www.apnic.net/about-apnic/corporate-documents/documents/policy-development/development-process/),
 as it says:

“Policy proposals are proposals which have been officially submitted for the 
consideration of the APNIC community …” and then “A formal proposal paper must 
be submitted to the SIG mailing list and to the SIG Chair”, while the *actual 
process* is sending to the chairs, so they decide if is being sent to the list 
or not!

 

Should anyone ignore the actual process and just send the proposals to the list?

 

Note that I didn’t knew, when I submitted the PDP update (which is a new 
version from a the previous year proposal), that one of my proposals will be 
considered by the chairs as out-of-scope. Clarification just so nobody believes 
that it is related to that rejection! Chairs can confirm that.

 

I don’t th

Re: [sig-policy] Version 4 of prop-126 PDP Update

[JORDI PALET MARTINEZ]

Hi Javed,

 

Anything we do (all) in our personal and professional lives, is subjected to 
laws.

 

Any organization rules, is bound to laws, we like it or not.

 

Clearly, we can’t say in a policy, if we don’t like a guy, we can discriminate 
him and not provide him resources, or allow him to come to meetings, or 
whatever. Those are very obvious silly examples, just to provide an idea of 
what I mean.

 

I’m sorry, but even chairs I’m sure try their best, they can make errors, and 
the community in a bottom-up approach, must be able to resolve it.

 

Opposing to an appeal process is precisely saying “go to courts”, which I think 
is what any community want to avoid.

 

Please, see also my previous email on this. There is no way, in the PDP, the 
chairs can oppose because they believe is “out-of-scope”. This is broken and we 
must fix it.

 

Regards,

Jordi

@jordipalet

 

 

 

El 29/8/19 3:19, "Javed Khan"  escribió:

 

PDP is a community driven consensus process agreed by the community not by 
courts nor legal experts. I am confused with your reference to "courts", 
"ilegal" and "legislation". If the intention here to scare the community then 
its truly not required.

 

I think under the current PDP the Chairs have the right to make a decision 
within the scope and principles and rules as agreed by the community. If the 
Chairs rejected one of your proposal, I'm sure the Chairs would have given you 
a reason and other options. This is between you and the Chairs. These people 
are elected by the community and we trust their decision.

 

I strongly oppose for an appeal process. We build the networks without any 
"appeal" process and so we can also work together to discuss the proposals.

 

J Khan

 

From: sig-policy-boun...@lists.apnic.net  
on behalf of JORDI PALET MARTINEZ 
Sent: Monday, 26 August 2019 6:05 PM
To: Policy SIG 
Subject: Re: [sig-policy] Version 4 of prop-126 PDP Update 

 

Hi Javed,

 

I don’t agree, let me explain why.

 

The current process only talks about the meeting and the chairs have clearly 
indicated that they take in consideration the list and the confer. Anyone from 
the community that dislikes a consensus/non-consensus decision, could create a 
trouble even in courts, because we are accepting consensus from sources not 
documented in the PDP. Rewording it resolves the problem.

 

Furthermore, the current process has not an “in-process” appeal procces. This 
will be ilegal in may legislations (may be only the AU applies, but considering 
that the community is “the entire Internet”, may be this may be declared 
illegal in another country where a member decides to claim for). The only way 
(actually) to appeal, will be going to the courts. We should not aim to that. 
We should have an internal way.

 

This is now even more relevant to be resolved, because by chance, the chairs 
have denied to accept one of the policy proposal that I’ve submited. They 
consider it out-of-scope, and my reading is that is in-scope (it has also been 
submitted and in-scope to RIPE, LACNIC and AFRINIC). I think their decision is 
wrong and this has many implications that we need to work out. The best avenue 
is having an “in-house” appeal process, of course.

 

Note that I didn’t knew, when I submitted the PDP update (which is a new 
version from a the previous year proposal), that one of my proposals will be 
considered by the chairs as out-of-scope. Clarification just so nobody believes 
that it is related to that rejection! Chairs can confirm that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/19 15:48, "Javed Khan"  escribió:

 

I do not support this proposal as I have complete trust in the current APNIC 
PDP and this community.

 

Kind regards

Javed Khan

MSCE and CCSP

 

From: sig-policy-boun...@lists.apnic.net  
on behalf of Sumon Ahmed Sabir 
Sent: Friday, 9 August 2019 2:13 AM
To: Policy SIG 
Subject: [sig-policy] Version 4 of prop-126 PDP Update 

 

 

Dear SIG members

A new version of the proposal "prop-126: PDP Update" has been sent to 
the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-126/

You are encouraged to express your views on the proposal:

  - Do you support or oppose the proposal?
  - Is there anything in the proposal that is not clear?
  - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


--

prop-126-v004: PDP Update

--

Proposer: Jordi Palet Martínez
   jordi.pa...@theipv6company.com


1. P

Re: [sig-policy] Version 4 of prop-126 PDP Update

[JORDI PALET MARTINEZ]

Dear Saturo,

See responses below, in-line.
 
Regards,
Jordi
@jordipalet
 
 

El 2/9/19 17:37, "Satoru Tsurumaki"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-126, based
on a meeting we organized on 21th Aug to discuss these proposals.

Many participants expressed a supporting for the proposal with reasons
that discussions in the mailing list will be reflected more than ever,
also with the reason that expiring policy of the proposal at Step 4
sound good both author and community.

And a few question were expressed as below:
- In Step2, it seems difficult to understand the process. Which is correct?
 1. Consensus is determined...
Firstly SIG mailing list/other electronic means/the SIG session
  and then
Member Meeting
 2. Consensus is determined...
 Firstly SIG mailing list/other electronic means
   and then
 SIG Session
   Afterward
 Member Meeting

I think it is clear from my text that I was referring to 1 above. However, if 
you think that there is something that can be improved in the way is written, I 
believe is still possible at this time, as it doesn't change the "intended 
meaning". An alternative way to write the same is:

"Consensus is determined considering:
- the SIG mailing list
- other electronic means
- and the SIG session
Afterwards it must be re-confirmed at the Member Meeting.

So basically, what I'm doing in STEP 2 is just to clarify that formally the 
mailing list+other electronics means (such as CONFER)+the SIG meeting are 
considered as part of the chair's decision-making process.

- What is "other electronic means" ? Is it CONFER?
  If it is CONFER, I am concerned that CONFER does not know the exact
number of people who voted.

Today it is CONFER, tomorrow can be something different or something else. This 
is provided by the staff. I don't want to mention CONFER, just to keep the door 
open to other means that we may agree to have in the future (so we don't need 
to change it with every possible electronic mean).

I don't think is a matter of "votes", because consensus is not about "how 
many", but if there is a strong opposition with objections raised and not 
resolved vs strong support.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年8月9日(金) 3:14 Sumon Ahmed Sabir :

>
>
> Dear SIG members
>
> A new version of the proposal "prop-126: PDP Update" has been sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> Information about earlier versions is available from:
> https://www.apnic.net/community/policy/proposals/prop-126/
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
>
> prop-126-v004: PDP Update
>
> --
>
> Proposer: Jordi Palet Martínez
>jordi.pa...@theipv6company.com
>
>
> 1. Problem Statement
> 
>
> With its requirement of face-to-face participation at the OPM, the current
> PDP might – at least partially – be the cause of the low levels of
> community
> participation in the process by using the policy mailing list.
>
> This proposal would allow an increased participation, by explicitly
> considering
>   the comments in the list for the consensus determination. So,
> consensus would
> be determined balancing the mailing list and the forum, and would 
therefore
> increase community participation.
>
> Even if this is actually done by the chairs, it is not part of the
> actual PDP,
> and thus constitutes a very clear and explicit violation of the PDP and
> the risk
> is that anyone from the community could appeal any decision based on that.
>
> Finally, it completes the PDP by adding a simple mechanism for solving
> disagreements
> during an appeals phase and an improved definition of ‘consensus’, as
> well as a
> complete definition of the “consensus” and “last-call”.
>
>
> 2. Objective of policy change
> -
>
> To allow that consensus is determined formally looking at the opinions
> of community
> mem

Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Satoru, all,

There are two points here:

1) Provide clarity about Inter/Intra-RIR. It is not clear in actual policy if 
it is referring only to Intra-RIR M&A or also Inter-RIR. It seems clear that 
because there is a policy for Inter-RIR transfers, the M&As should also support 
Inter-RIR.

2) The actual policy, only talks about "mergers & acquisitions". So, taking 
advantage of the change required for 1 above, I think is nice to ensure that we 
also mention relocations and reorganizations, and both partial or complete. 
Again, allows having a clear interpretation and not leaving it to a subjective 
reading.

Regards,
Jordi
@jordipalet
 
 

El 2/9/19 17:38, "Satoru Tsurumaki"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.

I would like to share a feedback in our community for prop-130, based
on a meeting we organized on 21th Aug to discuss these proposals.

Many participants expressed a neutral for the proposal with reasons
that they don't imagine the reason why we need to change the policy.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年3月14日(木) 21:59 Sumon Ahmed Sabir :

>
>
> Dear SIG members,
>
> The proposal "prop-130-v001: Modification of transfer policies"
> has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> 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-130
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> *  sig-policy:  APNIC SIG on resource management policy   
*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
*  sig-policy:  APNIC SIG on resource management policy 
  *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Hiroki, all,

Thanks for your inputs, allow me to clarify below, in-line. 
 

El 6/9/19 16:25, "Hiroki Kawabata"  escribió:

Hi all,

About the part of IPv6, we oppose this. other parts are neutral.

We have to make efforts to aggrigate IPv6 routes and to maintain sparse 
allocation
mechanism. Since each registry has enough IPv6 prefix,
it is better to receive a new prefix from the registry, especially partial 
M&A case.

If I recall correctly, when I talked about this with the staff, they confirmed 
that already accept partial M&A cases. My text only clarifies it.

We know perfectly that even if we don't like disaggregation (and I encourage to 
avoid it), LIRs will do it anyway. Existing policy doesn't forbid it. Is only 
recommended. So not having this text, doesn't disallow it.

The other point that you raise, this is not changing sparse allocation. The 
prefixes we are discussion about, are already allocated or assigned to 
LIRs/end-users, so the APNIC internal sparse allocation doesn't change.

Last, but not least. When a company acquires another, they have the rights to 
acquire all their assets, and legally, you can't avoid that. Even if policies 
say "not", legally they have acquired all or part of the assets (including the 
right to use the addressing space).

Having a policy that doesn't allow it will not change a legal right.

About inter-RIR, there are not consensus about (M&A and/or market)transfer 
IPv6 address
between RIRs.  First of all, we think we need to discuss about it.

This has been accepted already in RIPE (long time ago). LACNIC staff confirmed, 
in the impact analysis of an equivalent policy proposal, that when a company is 
involved in an M&A, they merge "all the resources, not just IPv4".

Do you really think, you can forbid a company, never mind is from one region or 
another, to "not transfer" the resources that are part of the legal agreement 
that they have acquired (when they buy a company which is APNIC member, they 
"buy" all the contracts)? We like it or not, this is a lost battle in my 
opinion. You can't say, transfer IPv4, renumber your ASN and IPv6!

Regards,
Hiroki

---
Hiroki Kawabata
Japan Network Information Center(JPNIC)


Subject: [sig-policy] Policy Proposal: prop-130-v001: Modification of 
transfer policies
Date: Thu, 14 Mar 2019 18:59:19 +0600
From: Sumon Ahmed Sabir 

> Dear SIG members,
> 
> The proposal "prop-130-v001: Modification of transfer policies"
> has been sent to the Policy SIG for review.
> 
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
> 
> 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-130
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
> 
*  sig-policy:  APNIC SIG on resource management policy 
  *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 cr

Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy

[JORDI PALET MARTINEZ]

Hi Satoru, all,

I understand your point. I'm happy to remove the text "BCOP RIPE690 Section 
4.2, provides guidelines about this.". It was only a reference and mentioning 
it in the policy proposal introduction (which is not part of the policy text) 
is enought.

So I'm going to send an updated version in a minute, which this minor editorial 
change.

Anyway, note the this is not a "RIPE" document, it is a document that was 
written by people from 4 RIRs. We disseminated the document in all the regions 
during a couple of years before a formal publication, unfortunatelly didn't got 
responses from this region to incorporate as well a local author.

Regards,
Jordi
@jordipalet
 
 

El 2/9/19 17:39, "Satoru Tsurumaki"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-131, based
on a meeting we organized on 21th Aug to discuss these proposals.

Many participants expressed a opposing for the proposal with reasons
that the policy document should not refer the document(RIPE BCOP)
which was made and managed by out of our community and if the document
is unintentionally modified or obsolete, we cannot control it.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年8月9日(金) 18:59 Sumon Ahmed Sabir :

>
>
> Dear SIG members,
>
> The proposal "prop-131-v001: Editorial changes in IPv6 Policy" has been
> sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> 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-131
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
>
> prop-131-v001: Editorial changes in IPv6 Policy
>
> --
>
> Proposer: Jordi Palet Martínez
>jordi.pa...@theipv6company.com
>
>
> 1. Problem Statement
> 
>
> This proposal suggests multiple (mainly) editorial changes in the IPv6
> Policy.
> The intent is to remove non-necessary text, and simplify the policy.
>
> Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is
> removed,
> as it is something obvious that operators need to assign some space for
> different
> parts of their own infrastructure.
>
> Section 5.2.4.3. explicitly states that it was drafted at a time when
> there was no
> experience with IPv6 deployment, which is this is longer the case, it
> does not make
> sense to have NIR/RIR to evaluate each instance where an LIR has an End
> User whose
> end site(s) requires a shorter prefix than a /48.
>
> Finally, section 10.1.4.1. is reworded, taking advantage of some of the
> editorial
> changes in the precedent sections, so to avoid duplicating text.
>
>
>
> 2. Objective of policy change
> -
>
> Fulfil the above indicated edits.
>
>
> 3. Situation in other regions
> -
>
> A similar proposal has been submitted to RIPE.
>
>
> 4. Proposed policy solution
> ---
>
> Current Text
> 5.2.4.2. Assignment address space size
>
> ...
>
> End-users are assigned an end site assignment from their LIR or ISP. The
> exact size of
> the assignment is a local decision for the LIR or ISP to make, using a
> minimum value of
> a /64 (when only one subnet is anticipated for the end site) up to the
> normal maximum of
> /48, except in cases of extra large end sites where a larger assignment
> can be justified.
>
> ...
>
>
> New Text
> 5.2.4.2. Assignment address space size
>
> ...
>
> End Users are assigned an end site assignment from their LIR or ISP. The
> size of the
> assignment is a local decision f

Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy

[JORDI PALET MARTINEZ]

Hi Hiroki,

Just sent a response to this in the previous email.

Note this is only a minor editorial change in the policy proposal, the rest of 
the text is much more relevant than just this detail.

Regards,
Jordi
@jordipalet
 
 

El 6/9/19 15:45, "Hiroki Kawabata"  escribió:

Hi all,

We oppose this proposal. APNIC should always check references to documents
which written by other bodies, so we think that it should be kept to the 
minimum necessary.
If the goal is to simplify the policy document, how about putting it in a 
guideline document?

Regards,
Hiroki

---
Hiroki Kawabata
Japan Network Information Center(JPNIC)


Subject: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy
Date: Fri, 9 Aug 2019 15:59:08 +0600
From: Sumon Ahmed Sabir 

> Dear SIG members,
> 
> The proposal "prop-131-v001: Editorial changes in IPv6 Policy" has been
> sent to
> the Policy SIG for review.
> 
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
> 
> 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-131
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> --
> 
> prop-131-v001: Editorial changes in IPv6 Policy
> 
> --
> 
> Proposer: Jordi Palet Martínez
> jordi.pa...@theipv6company.com
> 
> 
> 1. Problem Statement
> 
> 
> This proposal suggests multiple (mainly) editorial changes in the IPv6
> Policy.
> The intent is to remove non-necessary text, and simplify the policy.
> 
> Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is
> removed,
> as it is something obvious that operators need to assign some space for
> different
> parts of their own infrastructure.
> 
> Section 5.2.4.3. explicitly states that it was drafted at a time when
> there was no
> experience with IPv6 deployment, which is this is longer the case, it
> does not make
> sense to have NIR/RIR to evaluate each instance where an LIR has an End
> User whose
> end site(s) requires a shorter prefix than a /48.
> 
> Finally, section 10.1.4.1. is reworded, taking advantage of some of the
> editorial
> changes in the precedent sections, so to avoid duplicating text.
> 
> 
> 
> 2. Objective of policy change
> -
> 
> Fulfil the above indicated edits.
> 
> 
> 3. Situation in other regions
> -
> 
> A similar proposal has been submitted to RIPE.
> 
> 
> 4. Proposed policy solution
> ---
> 
> Current Text
> 5.2.4.2. Assignment address space size
> 
> ...
> 
> End-users are assigned an end site assignment from their LIR or ISP. The
> exact size of
> the assignment is a local decision for the LIR or ISP to make, using a
> minimum value of
> a /64 (when only one subnet is anticipated for the end site) up to the
> normal maximum of
> /48, except in cases of extra large end sites where a larger assignment
> can be justified.
> 
> ...
> 
> 
> New Text
> 5.2.4.2. Assignment address space size
> 
> ...
> 
> End Users are assigned an end site assignment from their LIR or ISP. The
> size of the
> assignment is a local decision for the LIR or ISP to make, using a value
> of "n" x /64.
> BCOP RIPE690 Section 4.2, provides guidelines about this.
> 
> ...
> 
> ==
> 
> Current Text
> 5.2.4.3. Assignment of multiple /48s to a single end site
> 
> When a single end site requires an additional /48 address block, it must
> request the
> assignment with documentation or materials that justify the request.
> Requests for multiple
> or add

[sig-policy] editorial clarification on prop-131

[JORDI PALET MARTINEZ]

Hi all,

Following the suggestion in the mic during the today SIG session, in section 
5.2.4.3. the new title is "Assignment of multiple /48s to a single end site", 
however in section 10.1.4.1. Initial assignment, is was using a reference to 
"5.2.4.3. Assignments shorter than a /48 to a single End-Site".

Obviously, this is an editorial mistake, and the reference should be as well to 
the new title:

"5.2.4.3. Assignment of multiple /48s to a single end site"

Thanks!

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] editorial clarification on prop-131

[JORDI PALET MARTINEZ]

Sorry, confusing myself (again).

The right wording in both places of the text is:

5.2.4.3. Assignments shorter than a /48 to a single End Site

The problem was created when editing the text version, my "word" original 
version was ok.

Regards,
Jordi
@jordipalet
 
 

El 12/9/19 12:34, "JORDI PALET MARTINEZ"  escribió:

Hi all,

Following the suggestion in the mic during the today SIG session, in 
section 5.2.4.3. the new title is "Assignment of multiple /48s to a single end 
site", however in section 10.1.4.1. Initial assignment, is was using a 
reference to "5.2.4.3. Assignments shorter than a /48 to a single End-Site".

Obviously, this is an editorial mistake, and the reference should be as 
well to the new title:

"5.2.4.3. Assignment of multiple /48s to a single end site"

Thanks!

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy 
  *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy
**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.






**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Version 4 of prop-126 PDP Update

[JORDI PALET MARTINEZ]

Hi Amrita,

 

Thanks a lot for your inputs!

 

I don’t think the policy can be changed without running thru the PDP. If some 
text is not sufficiently clear, if it is open to different interpretations it 
must be resolved.

 

It is not approriate, for example, to have a discrepancy on anyone reading the 
manual and the staff having a differente read on the same point. Take my 
example in my proposal for sub-assignment clarification. According to the staff 
a DC or an ISP must use an allocation for providing service to customers. 
However, if we consider the equipments connected as part of the infrastructure, 
anyone reading the same text will agree that it is possible to use an 
assignment as well. This is insane. In IPv4 is not a problem, but in IPv6 to 
make it possible you will provide a single IPv6 address to a complete customer 
network, or a single host that runs multiple VMs, which means, in turn, that 
you will need some kind of crazy non-standard NAT “function”.

 

Editorial changes are allowed to policy proposals, even after reaching 
consensus, but not once they become implemented, and consequently, once the 
text is already in the policy manual.

 

Regarding the 4 weeks period. I disagree. The current PDP text allows to have 
it variable, and I think that it must be a very clear and well defined time, so 
it is not possible to be “subjective” or “discriminate” among different policy 
proposal. All them should be treated the same. If a policy proposal in the 
“last-call” period is creating too much conflicting discussion (and specially 
on new aspect not discussed before), it definitively it should be interpreted 
as a sign for the chairs that the consensus is not clear, and probably instead 
of extending that period, should be send back to the list for a complete new 
discussion.

 

Regards,

Jordi

@jordipalet

 

 

 

El 12/9/19 13:03, "Amrita"  escribió:

 

Hi 

 

Had a few comments based on today’s presentation, during the Policy SIG meeting.

 

>From what I understood making information about policy more easily and readily 
>available does not need a policy change . It  just needs to have existing 
>information more readily and easily available .

 

Secondly, as shared by many people who commented, the four week input period is 
normally sufficient for most PDPs, therefore it does not need any change . 
Policy timelines are not set for exceptional situations, but for general 
situations. If a policy discussion takes more that 4 weeks , as clarified, the 
chairs can already extend it. Therefore, no changes need to be paid in the 
policy discussion timeline.

 

However, perhaps the community may want to work on setting up  a mechanism  for 
reviewing  policies that have been implemented. 

 

Regards

 

Amrita 

 

From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
Sent: Tuesday, September 10, 2019 4:57 AM
To: JORDI PALET MARTINEZ
Cc: Policy SIG
Subject: Re: [sig-policy] Version 4 of prop-126 PDP Update

 

I took the liberty of reformatting the message into a consistent font and size.

 




On Sep 9, 2019, at 02:41 , JORDI PALET MARTINEZ  
wrote:

 

Hi Owen,

 

 

El 27/8/19 8:15, "Owen DeLong"  escribió:

 

 





On Aug 26, 2019, at 03:05 , JORDI PALET MARTINEZ  
wrote:

 

Hi Javed,

 

I don’t agree, let me explain why.

 

The current process only talks about the meeting and the chairs have clearly 
indicated that they take in consideration the list and the confer. Anyone from 
the community that dislikes a consensus/non-consensus decision, could create a 
trouble even in courts, because we are accepting consensus from sources not 
documented in the PDP. Rewording it resolves the problem.

 

Furthermore, the current process has not an “in-process” appeal procces. This 
will be ilegal in may legislations (may be only the AU applies, but considering 
that the community is “the entire Internet”, may be this may be declared 
illegal in another country where a member decides to claim for). The only way 
(actually) to appeal, will be going to the courts. We should not aim to that. 
We should have an internal way.

 

While there is no appeal process, there are sufficient iterations of approval 
and ratification in the current process that I am not convinced an appeal 
process is necessary.

 

I don’t agree on that. If today chairs decide that something is out-of-scope, 
nobody has a way to change that decision. There is no way the community will be 
able to discuss the policy proposal as a “policy proposal”, because the chairs 
don’t accept it.

 

Is there any history of the chairs determining that something was out of scope 
erroneously? To the best of my knowledge, this is not the case in the APNIC 
region.

 


In the case of ARIN, there is a kind of appeal process with is the “petition 
process”. Here we don’t have that. And is the only region where we don’t have 
that.

 

Yes,

Re: [sig-policy] editorial clarification on prop-131

[JORDI PALET MARTINEZ]

No issue !

Thanks a lot!

Regards,
Jordi
@jordipalet
 
 

El 18/9/19 1:58, "Srinivas Chendi"  escribió:

Hi Jordi,

Apologies for the error. This is now corrected and published.

Regards
Sunny

On 12/09/2019 3:43 pm, JORDI PALET MARTINEZ wrote:
> Sorry, confusing myself (again).
> 
> The right wording in both places of the text is:
> 
> 5.2.4.3. Assignments shorter than a /48 to a single End Site
> 
> The problem was created when editing the text version, my "word" original 
version was ok.
> 
> Regards,
> Jordi
> @jordipalet
    >   
>   
> 
> El 12/9/19 12:34, "JORDI PALET MARTINEZ" 
 
escribió:
> 
>  Hi all,
>  
>  Following the suggestion in the mic during the today SIG session, in 
section 5.2.4.3. the new title is "Assignment of multiple /48s to a single end 
site", however in section 10.1.4.1. Initial assignment, is was using a 
reference to "5.2.4.3. Assignments shorter than a /48 to a single End-Site".
>  
>  Obviously, this is an editorial mistake, and the reference should be 
as well to the new title:
>  
>  "5.2.4.3. Assignment of multiple /48s to a single end site"
>  
>  Thanks!
>  
>  Regards,
>  Jordi
>  @jordipalet
>   
>   
>  
>  
>  
>  **
>  IPv4 is over
>  Are you ready for the new Internet ?
>  http://www.theipv6company.com
>  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.
>  
>  
>  
>  *  sig-policy:  APNIC SIG on resource management policy  
 *
>  ___
>  sig-policy mailing list
>  sig-policy@lists.apnic.net
>  https://mailman.apnic.net/mailman/listinfo/sig-policy
>  **
>  IPv4 is over
>  Are you ready for the new Internet ?
>  http://www.theipv6company.com
>  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.
>  
>  
>  
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> 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: [sig-policy] Call for Papers: 5th IEEE/IFP International Workshop on Analytics for Network and Service Management (AnNet 2020)

[JORDI PALET MARTINEZ]

I wonder if the policy mailing is appropriate for CfP and if there is an AUP 
that clearly indicate that.

We receive frequent CfP in this list, which doesn't happen in other RIRs and I 
guess the people sending them (which from time to time I recall is the same 
people), should be warned and if they don't stop, get their posting rights ban.

Regards,
Jordi
@jordipalet
 
 

El 26/11/19 3:26, "Sandrine VATON"  escribió:

[Sorry for multiple receptions]

===

5th IEEE/IFP International Workshop on Analytics for Network and Service 
Management (AnNet 2020)

In conjunction with the IEEE/IFP Network Operations and Management 
Symposium (NOMS 2020) in Budapest, Hungary, April 20-24, 2020

https://annet2020.loria.fr/

(Submissions due:  January 5, 2020)
===

The Fifth IEEE/IFIP International Workshop on Analytics for Network and 
Service Management (AnNet 2020) will be held in conjunction with the IEEE/IFIP 
Network Operations and Management Symposium (NOMS 2020) in Budapest, Hungary, 
April 20-24, 2020. 

Following the success of  its previous editions, AnNet aims to present 
research and experience results in the area of data analytics and machine 
learning for network and service management.  Approaches such as statistical 
analysis, data mining, and machine learning are promising mechanisms to harness 
the immense stream of operational data and to improve operations and management 
of IT systems and networks. 

AnNet 2020 will include original full-papers presentations, a keynote, and 
short-paper sessions. The workshop attendees will be stimulated to participate 
in interesting discussions. To this end, short papers describing late-breaking 
advances and work-in-progress reports from ongoing research and experimental 
work are also welcome.

---
Topics of Interest

Authors are invited to submit papers that fall into or are related to one 
or multiple topic areas listed below:

Data Analytics:
- Analysis, modeling and visualization
- Operational analytics and intelligence 
- Event and log analytics Big data analytics
- Network traffic analysis 
- Anomaly detection and prediction 
- Monitoring and measurements for management 
- Predictive and real-time analytics
- Harnessing social data for management

Machine Learning Techniques:
- Supervised, semi-supervised and unsupervised learning 
- Clustering and data mining 
- Reinforcement learning 
- Multi-agent based learning 
- Deep learning 
- Bayesian methods 
- Ensemble methods 
- Cognitive computing 
- Mining spatiotemporal and time series data

Network Management Paradigms:  
- Autonomous and autonomic networks
- Fog/edge computing
- In-network processing

- Bio-inspired networks self-management 
- Cognitive and software defined networks 
- Network function virtualization 
- Security, fault, performance and resource management

Application Domains:
- Computer Networks
- Mobile ad-hoc networks Wireless sensor networks 
- Clouds and data centers 
- Virtualized infrastructures
- Internet of Things 
- Computing and network services 
- IT service management, Storage resource management
---
Paper Submission

Paper submissions must present original, unpublished research or 
experiences. Only original papers that have not been published or
submitted for publication elsewhere can be submitted. Each submission must 
be written in English, accompanied by a 75 to 200 words abstract that clearly 
outlines the scope and contributions of the paper. There is a length limitation 
of 6 pages (including title, abstract, all figures, tables, and references) for 
regular papers, and 4 pages for short papers describing work in progress. 
Submissions must be in IEEE 2-column style. Self-plagiarized papers will be 
rejected without further review.

Authors should submit their papers via JEMS: 
https://jems.sbc.org.br/home.cgi?c=3497

Papers accepted for AnNet 2020 will be included in the conference 
proceedings, IEEE Xplore, IFIP database and EI Index. IFIP and IEEE reserve the 
right to remove any paper from the IFIP database and IEEE Xplore if the paper 
is not presented at the workshop. Awards will be presented to the best paper at 
the workshop.

---
Important Dates

- Paper Registration: December 29, 2019 
- Paper Submission Deadline: January 5, 2020 
- Acceptance Notification: January 26, 2020 
- Camera-Ready Papers: 

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 <mailto: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
> w

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

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I agree that we can improve this adding an explicit reference to the RFC7282, 
and making clear that the policy expires if not updated by the next OPM, so we 
don't depend on exact 6-months period, which not necessary will match from 
meeting to meeting.

So, I think we should make a new version using the following text changes:

Previous version:

Step 2: Consensus Determination
Consensus is defined as “rough consensus” as observed by the Chairs.

Consensus is determined first considering the SIG mailing list, other 
electronic means, and the SIG session, and afterwards at the Member Meeting.

If there is no consensus on a proposal, the authors can decide to
withdraw it.

Otherwise, the proposal will expire in six months, unless a new version
is provided, restarting the discussions with the community.


New version:

Step 2: Consensus Determination
Consensus is defined as “rough consensus” (RFC7282) as observed by the Chairs.

Consensus is determined first considering the SIG mailing list, other 
electronic means, and the SIG session, and afterwards at the Member Meeting.

If there is no consensus on a proposal, the authors can decide to
withdraw it.

Otherwise, the proposal will be considered as expired by the next OPM, unless a 
new version
is provided, restarting the discussions with the community.


Please, update the version number of this proposal with these changes, which I 
guess clears your impact assessment as well.

Regards,
Jordi
@jordipalet
 
 

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

Dear SIG members,

Here is the Secretariat impact assessment for proposal “prop-134-v001: 
PDP Update” and the same is also published at:

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

Staff comments
--

No foreseen change on APNIC Services procedures or systems as a result 
of this policy proposal.

For reference and definition of “Rough Consensus” suggest adding RFC 
7282 to the proposed text.

It is difficult to keep track of proposals “expire in six months” may be 
change to “expire at the next OPM”.


Technical comments
--

No comments.


Legal comments
--

Given that rough consensus is defined under RFC 7282 - no further comments.


Implementation
--

within 3 months.


Regards
Sunny


On 20/01/2020 10:23 am, Bertrand Cherrier wrote:
> Dear SIG members
> 
> The proposal "prop-134-v001: PDP Update" has been sent to the Policy SIG 
> for review.
> 
> (This is a new version of "prop-126" 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-134
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> 
> prop-134-v001: PDP Update
> 
> 
> 
> Proposer: Jordi Palet Martínez
> jordi.pa...@theipv6company.com 
> 
> 
> 1. Problem statement
> 
> The actual PDP doesn’t support the usage of electronic means to 
> “measure” the consensus.
> However, “Confer” is being used. This should be clarified, or otherwise 
> the process is not fair (remote participants don’t know about it reading 
> the PDP) and can be considered a violation of the PDP itself.
> 
> The PDP also don’t have a formal process to withdraw a proposal, and 
> doesn’t force the authors to keep editing it according the community 
> inputs, or otherwise, allow the SIG chairs to declared it as expired.
> 
> Finally, as editorial change, the expression “rough consensus” (RFC7282) 
> is used instead of “general agreement”, so it is consistent with the 
> actual pra

Re: [sig-policy] prop-130-v002: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I understand that your assesment for this proposal is only informational inputs 
and not suggesting any text changes, in the sense that:

1) The M&A from/to other regions will need to be verified by the counter-party 
RIR. I expect that this is part of the operational procedure, and I suggest to 
use the same as you actually have for Inter-RIR transfers, may be requiring 
slight modifications. However, I don't think it is relevant to include that in 
the policy text, and instead should be fully managed by the staff.

2) I fully understand that there are implementation implications, not only in 
APNIC systems, but also in couter-party RIRs, and the "full" implementation 
will depend on all that.

Let me know if otherwise you think "anything" should be added/clarified in the 
policy proposal.

Regards,
Jordi
@jordipalet
 
 

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

Dear SIG members,

Here is the Secretariat impact assessment for proposal “prop-130-v002: 
Modification of transfer policies” and the same is also published at:

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

Staff comments
--

Possible difficulties in verifying mergers, acquisition, reorganization, 
or relocation from out of APNIC region due to unfamiliarity of languages 
and legal systems.

The NRO comparative policy matrix indicates APNIC Members outside of the 
region must have network presence in the Asia Pacific. Additionally, 
some RIRs have an ‘out of region’ policy which restricts where they can 
use their resources.

Members may face difficulties updating their domain objects if there has 
been a partial IPv6 transfer where a larger block has been de-aggregated.


Technical comments
--

APNIC’s current systems are not configured to handle inter-RIR IPv6 
reverse DNS. This will need to be developed.

APNIC cannot predict when other RIRs will support IPv6 reverse DNS 
fragments incoming to their systems.


Legal comments
--

This will affect how APNIC verifies M&A documents. May require cross RIR 
coordination.


Implementation
--

6 months


Regards
Sunny


On 20/01/2020 10:16 am, Bertrand Cherrier wrote:
> Dear SIG members,
> 
> A new version of the proposal "prop-130: Modification of transfer 
policies"
> has been sent to the Policy SIG for review.
> 
> 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-130
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> 
> prop-130-v002: Modification of transfer policies
> 
> 
> 
> Proposer: Jordi Palet Martinez
> jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com>
> 
> 
> 1. Problem statement
> 
> Existing transfer policies for IPv4, IPv6 and ASN resources have some
> differences
> among what is allowed and what not, if in the case of intra-RIR and
> inter-RIR, and
> it is not clear if in case of merger and acquisitions it is referring to
> a complete
> company, part of it, or even if in case of a company reorganization or
> relocation,
> the policy is supportive to that case.
> 
> In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> policy or
> procedure that allows it.
> 
> 
> 2. Objective of policy change
> 
> To ensure that the policy text is clarified, if those cases are
> supported by the
> co

Re: [sig-policy] prop-130-v002: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Adam,

 

I’m not native english speaker either, and probably, because I learnt it by 
myself, have a lot of deficiences.

 

All the policies may have implementation issues. I don’t think this is a 
problem at all, just increase the implementation time, that’s just fine, and 
this was my response to that.

 

The policy doesn’t pretend to be an Inter-RIR IPv6 transfer. The policy 
recognize that if there is an M&A (which are happening every other day),  where 
several type of resources are involved, it should be possible to get a solution 
for all them. It will not make sense to do an M&A for IPv4 only, when we try to 
move to IPv6. It is an incredible innecesary ban to ask a corporation that 
acquired another (or part of it) “renumber”, if for example, they are just 
moving the VMs from one datacenter in Amsterdam to a data center in Brisbane 
(or the other way around). Because with VMs you just need to resync them, and 
once done, get activated in the new location and deactivated in the old one.

 

I can’t believe that anyone suggest that we can tell this organization: we 
allow you to do that for IPv4 but for IPv6, you need to renumber.

 

When I said full implementation I mean that the implementation involving 
several RIRs can be finished, let’s say in 6 months for APNIC, RIPE may take 
just 4, and maybe LACNIC needs 8. It is just an example. Consequently, after 
APNIC finish the implementation, if there in an M&A case APNIC-RIPE, it will be 
possible, but may be a case APNIC-LACNIC needs to wait for 2 additional months 
to be completed (at least using “automation” between the systems of both RIRs).

 

Regards,

Jordi

@jordipalet

 

 

 

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

 

Hi Jordi

Please stop saying you are “clarifying” policy text when you are actually 
changing policy. People with English as a second language may misunderstand 
what is happening.

I’m supportive of more specific language in the M&A policy, but this is 
basically an inter-RIR IPv6 transfer policy.

I do not support this policy proposal because I doubt there are sufficient 
legitimate use cases to justify the significant implementation burden, 
technical issues, and legal work this would create for the Secretariat(s). 

Your response to the assessment provided by Sunny doesn’t address the technical 
implementation issues. When the Secretariat tells you that it is a 6-month 
timeframe it is because it is complex and expensive to do. Simply saying you 
understand the implementation issues for APNIC and other RIRs doesn’t change 
this. It should mean that you have to work hard to demonstrate there is a 
community need for the change. Also, I’m not sure what you mean by “full” 
implementation. You can’t have a half implemented Policy.

In my opinion, you haven’t provided sufficient justification for this change in 
policy and I think it’s a bad idea for a host of reasons.

My recommendation is that the Secretariat editorially “clarify” Sections 8.4, 
11.0, and 13.3 to explicitly say "APNIC will only recognize the intra-RIR 
transfer of…."

Regards,

Adam

 



On 16 Feb 2020, at 11:55 am, JORDI PALET MARTINEZ  
wrote:

 

Hi Sunny, all,

I understand that your assesment for this proposal is only informational inputs 
and not suggesting any text changes, in the sense that:

1) The M&A from/to other regions will need to be verified by the counter-party 
RIR. I expect that this is part of the operational procedure, and I suggest to 
use the same as you actually have for Inter-RIR transfers, may be requiring 
slight modifications. However, I don't think it is relevant to include that in 
the policy text, and instead should be fully managed by the staff.

2) I fully understand that there are implementation implications, not only in 
APNIC systems, but also in couter-party RIRs, and the "full" implementation 
will depend on all that.

Let me know if otherwise you think "anything" should be added/clarified in the 
policy proposal.

Regards,
Jordi
@jordipalet



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

   Dear SIG members,

   Here is the Secretariat impact assessment for proposal “prop-130-v002: 
   Modification of transfer policies” and the same is also published at:

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

   Staff comments
   --

   Possible difficulties in verifying mergers, acquisition, reorganization, 
   or relocation from out of APNIC region due to unfamiliarity of languages 
   and legal systems.

   The NRO comparative policy matrix indicates APNIC Members outside of the 
   region must have network presence in the Asia Pacific. Additionally, 
   some RIRs have an ‘out of region’ policy which restricts where they can 
   use their resources.

   Members may face difficulties updating their domain objects if there has 
   been a partial IPv6 transfer where a larger block has been de-ag

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

[JORDI PALET MARTINEZ]

, each time we make a change (on the justification 
requirements), we will be affecting it. In this concrete proposal, we aren’t, 
as explained before, changed the original intent. The original intent was not 
“give me an exact description of how are you using each of the IPv6 addresses 
in the /48 PI that you will receive”, but instead “this is only for you within 
your network, NOT for sub-assignment to other parties in other networks”.

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"  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 <mailto: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, ARIN, LACNIC and
RIPE.


   4. Proposed policy solution

Actual text:
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user, for specific use within the Internet infrastructure they operate.
Assignments must only be made for specific, documented purposes and may not
be sub-assigned.

Proposed text:
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.


   5. Advantages / Disadvantages

Advantages:
Advantages of the proposal:
Fulfilling the objective above ind

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

[JORDI PALET MARTINEZ]

Hi Adam,

 

By the way, thanks a lot for all the inputs, just sorry that we only get them 
from one person and they are so late. If we can get discussions more time ahead 
the meetings, we can get much better text, for sure!

 

Below, in-line.

 

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

 

Hi Jordi 

My comments are inline

 

 

New version:

Step 2: Consensus Determination
Consensus is defined as “rough consensus” (RFC7282) as observed by the Chairs.

 

You are making a significant change, but presenting it as a “clarification”. 

 

-> Again, for me, in my native language, this is clarifying the situation. I 
don’t think it makes sense to discuss that, otherwise, we turn each proposal 
into a language discussion, which in turn, it will be differently understood by 
every non-native English speaker. The relevant thing here is what we actually 
do in the process and adapt the text to it, otherwise, we aren’t following our 
own PDP (our own rules).

It is okay to consider adoption of IETF definitions of “rough consensus” to use 
in the APNIC Policy Process, but this is not a clarification. To be clear, the 
SIG doesn’t currently use the “rough consensus” model in RFC 7282. It uses the 
consensus model in the APNIC SIG Guidelines. 
https://www.apnic.net/community/participate/sigs/sig-guidelines/#steps

-> The first problem we have here is that those guidelines were developed long 
time ago (2 decades or so), when we had many SIGs, and they were developed by 
the SIG chairs, not the community. The 2nd issue is that the PDP doesn’t 
mention anything about the guidelines. This is not a mere editorial comment, it 
requires the community to accept those guidelines in a modification (thru a 
policy proposal) of the PDP. The third problem is that the PDP talks about 
“general agreement”, while the guidelines talks about “consensus”. It is a 
matter of English wording? I don’t know, but making it clear is good for 
everyone. Otherwise a newcomer will not see in the meeting that we are 
following our own process (because we aren’t!).

-> If I recall correctly, when asked at least one of the co-chairs about what 
they recognize as consensus, and I believe is the way they explain at the 
beginning of each Policy SIG, they use the rough consensus definition and I’m 
almost sure they even mention the IETF RFC.

 

 

The RFC is similar, but fundamentally different. Changing this in the PDP is 
not just a word tweak. It would result in a different approach from the Chairs 
and participants. There is no concept of “Minor” and “Major” objections in RFC 
7282, for example.

-> The RFC doesn’t provide the “operational” details, it is an informational 
document, so nothing precludes the co-chairs for their assessment to still make 
some “classification”, but again,  the guidelines aren’t part of the PDP, 
unless we change it. I think they key here, and again, I believe is the 
understanding of the chairs, if I got it correctly, we aren’t counting hands or 
votes, but instead we declare consensus “when all the issues are addressed, but 
not necessarily accommodated”, which is the “short” description of the RFC.

 

Consensus is determined first considering the SIG mailing list, other 
electronic means, and the SIG session, and afterwards at the Member Meeting.

 

I’m supportive of the spirit of this change.

It’s a bit late in the day to be proposing changes, but I would have written: 

“The Chair(s) assess if the SIG has reached consensus on a proposal by 
considering discussions both on the mailing list and at the Open Policy (Policy 
SIG) Meeting. The Chair(s) may use measurement techniques to take the 
temperature of the room. Consensus must be reached first at the SIG session and 
afterwards at the Member Meeting for the process to continue."

-> I think is not late if we get some other inputs in the list … people 
supporting this one? I’m fine either way. For me the shorter version works 
fine, but again, there may be tiny English language details … What about (also 
reading your next paragraph and assuming that it is the Executive Council 
Chair, but this is easy to change in the final text if we send a new version 
and my recall or the actual situation is wrong):

“The Chair(s) assess if a proposal has reached consensus by considering 
discussions both on the mailing list, other electronics means and at the SIG 
Meeting. Consensus must be afterwards sustained at the Member Meeting for the 
process to continue, as observed by the Executive Council Chair.”

-> Note that my wording allows changing/evolving the (electronic) tools without 
requiring a PDP change (even incorporating several to facilitate the 
participation increase), and then there is no need to explicitly say that the 
tools are used for “measuring”, because that’s part of the consensus process. 
Also use SIG because this PDP seems to apply to policies developed by other 
SIGs, right? (if this is not currently the case).

I think retaining the “pro

Re: [sig-policy] Criteria of resubmission the proposal

[JORDI PALET MARTINEZ]

Hi Sumon, Satoru-San, all,

 

Let me also provide my point of view on this:
If you look at the videos of the previous presentations, there were some people 
in support of those policies. In fact, I used the videos and all the inputs (as 
in the list, unfortunatelly, basically there were only inputs from yourself). 
In fact, for the sub-assigment clarification, the proposal advanced from the 2 
previous APNIC meetings thanks to the inputs from our colleagues from India. 
And again, from the inputs from Aftab, it advanced once more to the actual 
version, highly simplified.
I’ve said this before. The PDP doesn’t state anything about if the chairs can 
“abandon” a policy proposal. In fact, this may be not the right term. I read 
abandon as “I abandon”, not somebody “abandon for me”, which will be “force 
abandon” or something-like. I understand that the chairs are following 
guidelines, that were developed by the existing chairs but not the community, 2 
decades ago, in the scope of many SIGs. The PDP and all related to the PDP is 
developed by the community as a whole, not a subset of. Furthermore, the PDP 
doesn’t have *ANY* link, decided by  the community, to the guidelines. We 
should update this. Just consider how negative/surprising is for anyone 
(specially newcommers), to read the PDP and then see that “something else is 
behind the PDP”.
We have seen this lots of times. A proposal doesn’t reach consensus the 1st 
time. Because there are no inputs in the list, in can’t get improved with the 
community inputs. It doesn’t passes the 2nd time, but it reach consensus the 
3rd time. Another proposal takes 5 rounds. Another proposal reach consensus on 
the 1st round. Another proposal fails during 2 rounds, but then after 1 year of 
pause, it comes back and reach consensus. This is *normal* and it should be 
like that. Different proposals need more or less discussion, more or less 
inputs, if the inputs don’t come in the list, then it takes more cyles. How you 
put the limit in the number of times it can come back before it gets “abandon” 
? You can’t. If the authors are getting the inputs, you should allow them to 
continue. It is a different case, if the authors ignore the inputs from the 
community. If you have 3 inputs *only* (just an example) 2 against – 1 in 
favour, this is not sufficient to say “abandon”. PDP is a slow process because 
it looks for consensus. This is completely normal. If authors don’t follow the 
community inputs and there are newer proposals or more important ones, the 
chairs have the way to de-prioritize them to the last part of the agenda, in 
case there is no sufficient time. Why “abandon” after 3 times, and not 2, or 5? 
It is impossible to decide upfront, each proposal has different complexity and 
may take more or less time. I’ve seen proposals that take 3 years to reach 
consensus (and they reached it), it is just fine! Other proposals didn’t reach 
consensus the first time and it was obvious, even for the authors that there is 
no point to continue. But even if there is a small fraction of the community 
that was supporting a proposal, I don’t see the point to abandon it after “n” 
times.
 

Besides those specific proposals, I think this discussion is very important and 
interesting to have.

 

Regards,

Jordi

@jordipalet

 

 

 

El 18/2/20 11:44, "Sumon Ahmed Sabir"  escribió:

 

Dear Satoru-San and all,

 

Thank you very much for sharing your feedbacks  and raising your concerns.

 

I do agree that the concern is valid and it may repeat similar discussions and 
we will be discussing similar issues.

 

>From SIG Chair Point of view, we have abandoned the earlier proposals as it 
>didn't reached consensus in three consecutive meetings and there were merely 
>any support for the proposal.

 

You are correct that if a proposal is abandoned then there will be no further 
discussions about the proposals.

 

But if proposer feels that it is important for community and needed to be 
discussed again and comes with a new proposal, as Policy Chair, it is our duty 
to accommodate that as long as it falls under PDP guidelines. 

 

And lastly it does not happen very often. So let us see how APNIC Community 
think about the proposal in next three days.

 

best regards,

 

Sumon Ahmed Sabir

Chair, Policy SIG

 

 

 

 

 

 

 

On Mon, Feb 17, 2020 at 3:13 PM Tsurumaki, Satoru  wrote:

Dear SIG Chair and all,

I am Satoru Tsurumaki from Japan Open Policy Forum.

I would like to share key feedback in our community for criteria for
adopting the proposal based on a meeting we organised on 4th Feb.

First of all, it should be pointed out that there is no intention to
limit the proposals where the problem statement or proposal has
changed.

Japanese community concerned that it might repeated similar
discussions if the resubmission of a proposal that was previously
abandoned.

My understanding is that "abandon" is a proposal that chair has
decided that no further discussions 

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

[JORDI PALET MARTINEZ]

Hi Adam,

 

(thanks a lot, very good inputs!)

 

 

El 18/2/20 13:19, "Adam Gosling"  escribió:

 

Hi Jordi

 

Sorry, but I have a very close knowledge of these documents. They are not 
perfect (or even good). Everybody may not always understand them, or apply 
them. That is why I want to make sure people understand what it is they are 
changing from and what they are changing to.

 

-> I see your point, and fully agree. However, I think jugging a policy because 
the title says clarification may bring to wrong assumptions, depending on who 
reads that. I think it is clear that it depends on the perspective. And I can 
ensure that my point was not to convince anyone that this is minor change or 
anything like that, but saying that the guidelines are part of the PDP is also 
wrong, so the PDP doesn’t have a formal definition of “general agreement”.



On 17 Feb 2020, at 1:30 pm, JORDI PALET MARTINEZ  
wrote:

 

Hi Adam,

 

-> The first problem we have here is that those guidelines were developed long 
time ago (2 decades or so), when we had many SIGs, and they were developed by 
the SIG chairs, not the community. The 2nd issue is that the PDP doesn’t 
mention anything about the guidelines.

 

Then propose that we add a reference to the Guidelines into the PDP. We can 
easily reach consensus and move on.

 

-> I don’t think is that easy. Does the community agree that the guidelines are 
valid? It is a much more complicated task than a single reference.

 

This is not a mere editorial comment, it requires the community to accept those 
guidelines in a modification (thru a policy proposal) of the PDP. The third 
problem is that the PDP talks about “general agreement”, while the guidelines 
talks about “consensus”. It is a matter of English wording? I don’t know, but 
making it clear is good for everyone. Otherwise a newcomer will not see in the 
meeting that we are following our own process (because we aren’t!).

-> If I recall correctly, when asked at least one of the co-chairs about what 
they recognize as consensus, and I believe is the way they explain at the 
beginning of each Policy SIG, they use the rough consensus definition and I’m 
almost sure they even mention the IETF RFC.

 

The only reference Google finds to RFC7282 on the www.apnic.net or 
conference.apnic.net site is your presentation 

https://www.google.com.au/search?q=site:www.apnic.net+rfc7282&gbv=1&sei=gTxLXuOENLuX4-EPpp-I8Ac

 

I checked the slides presented at the beginning of APNIC 46 and 47. These 
explain Consensus = ‘general agreement’ and the concept of Minor and Major 
Objections. They also provide the URL for the PDP and SIG Guidelines.

 

Anybody that says APNIC Policy runs on ‘rough consensus’ has made an assumption 
or is using the phrase to make it easier for you to understand to idea of 
'general agreement'.

 

 

 

The RFC is similar, but fundamentally different. Changing this in the PDP is 
not just a word tweak. It would result in a different approach from the Chairs 
and participants. There is no concept of “Minor” and “Major” objections in RFC 
7282, for example.

-> The RFC doesn’t provide the “operational” details, it is an informational 
document, so nothing precludes the co-chairs for their assessment to still make 
some “classification”, but again,  the guidelines aren’t part of the PDP, 
unless we change it. I think they key here, and again, I believe is the 
understanding of the chairs, if I got it correctly, we aren’t counting hands or 
votes, but instead we declare consensus “when all the issues are addressed, but 
not necessarily accommodated”, which is the “short” description of the RFC.

 

My reading of the Guidelines and the practice I have noticed from past Chairs 
is that Minor Objections can be 'addressed but not necessarily accommodated'. 
For Major Objections the guidelines say "When this happens, the Chair should 
encourage the proponent and the community to continue discussion and develop a 
more widely accepted proposal to be presented at the following meeting.” 

 

-> And this is rough consensus. So, there is consensus when there are minor 
objections. If there are major objections, then we need to continue the 
discussion and possibly have a new version: no consensus. I don’t see the 
difference with RFC7282.

 

I’m not saying that it is bad to change. I am just saying that we should be 
aware of what change we are making.

 


If there is no consensus on a proposal, the authors can decide to
withdraw it.

 

This removes discretion from the Chair (and the SIG), to abandon a proposal if 
an Author repeatedly persists with the same unpopular idea. I think that’s 
interesting and worth discussing if that’s what we want.

 

 

-> Which I think is wrong. It is inappropriate (in my opinion) that (and it may 
be again an English understanding) chairs can “abandon” on behalf of the 
authors (I will understand “force with

Re: [sig-policy] prop-130-v002: Secretariat impact assessment

[JORDI PALET MARTINEZ]

ment 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-130
> >
> > Regards
> >
> > Sumon, Bertrand, Ching-Heng
> > APNIC Policy SIG Chairs
> >
> > 
> >
> > prop-130-v002: Modification of transfer policies
> >
> > 
> >
> > Proposer: Jordi Palet Martinez
> > jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com>
> >
> >
> > 1. Problem statement
> >
> > Existing transfer policies for IPv4, IPv6 and ASN resources have some
> > differences
> > among what is allowed and what not, if in the case of intra-RIR and
> > inter-RIR, and
> > it is not clear if in case of merger and acquisitions it is referring to
> > a complete
> > company, part of it, or even if in case of a company reorganization or
> > relocation,
> > the policy is supportive to that case.
> >
> > In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> > policy or
> > procedure that allows it.
> >
> >
> > 2. Objective of policy change
> >
> > To ensure that the policy text is clarified, if those cases are
> > supported by the
> > community. It will also facilitate companies or business units, moving
> > or being established
> > in other regions.
> >
> >
> > 3. Situation in other regions
> >
> > There is a variety of support of all those cases in different regions.
> > The one more open is
> > RIPE, followed by ARIN. Similar policy proposals are being submitted in
> > LACNIC and AFRINIC.
> >
> >
> > 4. Proposed policy solution
> >
> > Actual Text
> > 8.4. Mergers & acquisitions
> >
> > APNIC will process and record the transfer of IPv4 resources as the
> > result of merger or acquisition.
> >
> > 11.0. Transfer of IPv6 resources
> >
> > APNIC will only recognize the transfer or IPv6 addresses as the result
> > of Merger & Acquisition activity.
> > The following conditions and consequences apply.
> >
> > 13.3. Mergers & acquisitions
> >
> > APNIC will recognize the transfer of ASNs as the result of merger or
> > acquisition.
> >
> > Proposed Text
> > 8.4. Mergers, acquisitions and relocations
> >
> > APNIC will process and record the transfer of IPv4 resources as the
> > result of a partial or complete merger,
> > acquisition, reorganization or relocation, in both cases, intra-RIR and
> > inter-RIR.
> >
> > In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> > policy/procedure that allows it.
> >
> > 11.0. Transfer of IPv6 resources
> >
> > APNIC will only recognize the transfer or IPv6 addresses as the result
> > of a partial or complete merger,
> > acquisition, reorganization or relocation activity, in both cases,
> > intra-RIR and inter-RIR. The following
> > conditions and consequences apply.
> >
> > In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> > policy/procedure that allows it.
> >
> > 13.3. Mergers, acquisitions and relocations
> >
> > APNIC will recognize the transfer of ASNs as the result of a partial or
> > complete merger, acquisition,
> > reorganization or relocation activity, in both cases, intra-RIR and
> > inter-RIR.
> >
> > In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> > policy/procedure that allows it.
> >
> >
> > 5.

Re: [sig-policy] New version - prop-133-v002: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi again and responding below ...

 

El 17/2/20 15:24, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum.

I would like to share key feedback in our community for prop-133,
based on a meeting we organised on 4th Feb to discuss these proposals.

Many opposing opinions were expressed about this proposal.

(comment details)
 - In the discuss about previous proposal, prop-124, some opinions
were expressed as to who was in trouble and who needed to change, but
it seems that the proposer did not respond to these opinions in this
proposal.

[Jordi] I've responded to that, please review the videos of the previous SIG. 
We can't put all the discussions in the proposal text. In summary. The actual 
text talks about documented purposes. If an end-user organization asked APNIC 
for an IPv4 (not using NAT, as some universities still do) or IPv6 prefix for 
their own systems (documented purpose), and later on they decide to run a guest 
or employees WiFi, they are not anymore using the assigned space for the 
documented purpose. It is a new purpose in additional for the original 
documented one. I think it is clear that the intend of the original text was 
not to restrict this, but instead to restrict that this assignment is not 
provided to "external third parties". Which this simple clarification, we 
resolve the problem. Instead we have the case for many organizations, that may 
be breaking the rules.

 - IP addresses should be delegated on an as-needed basis, and if this
proposal is passed, there is concern that clarification of the
intended use at the time of acquisition will be lost.

[Jordi] Need basis is, in this case "I need space for my organization". Right 
now, if you strictly follow the policy and you said "I need space for my 
organization systems", you are violating the rules. It is a tiny difference, or 
it looks like that, but we should make sure that we follow the original intend, 
which was not to be so restrictive as "if you didn't over-specified every 
detail, now you're lost".

 - While it may be good to loosen the policy operationally, we oppose
easing the policy itself.

[Jordi] I'm not sure to understand this.

 - This proposal seems not to aim "Clarification" of Sub assignment.

[Jordi] For me it is a clarification if we look at the intend of the policy: it 
was not to be restrictive in "how you use the resources in your organization", 
the idea was "the resources are only for your organization". There is no need 
to "document every tiny detail" if we can just make sure that it is clear that 
"it is for your organization, not for providing to others".

Regards,
Satoru Tsurumaki / JPOPF Steering Team

2020年2月16日(日) 18:31 Bertrand Cherrier :
>
> Dear SIG members
>
> A new version of the proposal "prop-133-v002: Clarification on
> Sub-Assignments" has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-133
>
> You are encouraged to express your views on the proposal:
>
> Do you support or oppose the proposal?
> Is there anything in the proposal that is not clear?
> What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
> 
>
> prop-133-v002: 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, 

Re: [sig-policy] New version - prop-134-v002: PDP Update

[JORDI PALET MARTINEZ]

Hi again ... see below ...

 

El 17/2/20 15:28, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum.

I would like to share key feedback in our community for prop-134,
based on a meeting we organised on 4th Feb to discuss these proposals.

We discussed this proposal dividing into 3 parts below.

1. Wording of "rough consensus"
Many opposing opinions were expressed.
 - Rough consensus seems something that almost attendees agrees, but
the consensus in OPM is a consensus that the chair decides based on
grounds, so the term rough consensus may be different.

[Jordi] If you follow the recent email exchange with Adam, I think it is clear 
that we are talking of the same (minor objections is consensus, major is not).

2. electronic means
Many opposing opinions were expressed about electronic means.
 - I support using the electronic system like a CONFER to gauge
support for a policy proposal, but oppose voting by using current
electronic system because of lack of identification.

[Jordi] We always have said that is not a voting. The proposal is not changing 
that! Never has been identified the people even in the meeting room, neither in 
the list or confer! The proposal is not changing that.

 - The specification is unclear about introducing an electronic
statement of intention.

[Jordi] Today we use confer. It was not used a few years ago. Tomorrow it can 
be a different tool to gauge the support. The PDP must have a language that, as 
much as possible, is self-adaptative to different tools. If we state "confer" 
and tomorrow the secretariat finds a better tool, we need to pass it thru the 
PDP. In fact, user confer today is *against* the PDP, because it is not 
explicitly supported. Even more than that, today following the PDP the few 
inputs in the list (including your emails), can't be formally considered as 
part of the consensus decision by the chairs. It makes sense to include that in 
the PDP.

 - It is necessary to use a means such as a registered name to avoid
the organized vote.

[Jordi] If we decide to use voting, and ask everyone in the meeting room to be 
also identified, they we should change our model. Otherwise, the same done in 
the meeting room should be done here. For example, if the NIRs are talking from 
the inputs provided by their own communities, should also the people 
partiticipating in the NIRs also be identified?


3. Expiring the proposal
Many supporting opinions were expressed about expiring the proposal.
In Japan, the same policy already make a consensus at last Japan Open
policy Meeting.

[Jordi] Just to make sure I got it correctly. You mean that you support this 
specific change as well?

Regards,
Satoru Tsurumaki / JPOPF Steering Team

2020年2月16日(日) 18:32 Bertrand Cherrier :
>
> Dear Chairs,
>
> Here is the draft email for new version of prop-134. Please review/edit
> and post to mailing list soon.
>
> Subject: prop-134-v002: PDP Update
>
> Thanks
> Sunny
>
> 
>
> Dear SIG members
>
> A new version of the proposal "prop-134-v002: PDP Update" has been sent
> to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-134
>
> You are encouraged to express your views on the proposal:
>
> - Do you support or oppose the proposal?
> - Is there anything in the proposal that is not clear?
> - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
> 
>
> prop-134-v002: PDP Update
>
> 
>
> Proposer: Jordi Palet Martínez
> jordi.pa...@theipv6company.com
>
> 1. Problem statement
>
> The actual PDP doesn’t support the usage of electronic means to
> “measure” the consensus.
> However, “Confer” is being used. This should be clarified, or otherwise
> the process is not
> fair (remote participants don’t know about it reading the PDP) and can
> be considered a
> violation of the PDP itself.
>
> The PDP also don’t have a formal process to withdraw a proposal, and
> doesn’t force the authors
> to keep editing it according the community inputs, or otherwise, allow
> the SIG chairs to
> declared it as expired.
>
> Finally, as editorial change, the expression “rough consensus” (RFC7282)
> is used instead of
> “general agreement”, so it is consistent with the actual practice.
>
> 2. Objective of policy change
>
> To resolve the issues above indicate

[sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi all,

As you know, we have decided to continue the discussion of this proposal in the 
mailing list.

I've been thinking in a possible way to keep the "documented purposes" text as 
some indicated in the mike.

So, what do you feel about these two choices:

Option a)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate.

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

My personal preference, and following the staff analysis in v2, will be option 
a, but just in case the community prefers to re-state "and may not be 
sub-assigned to other networks" (I believe, and also according to the staff 
inputs that "exclusive" is already indicating it).

Just as a reminder, the actual proposal (v2) is at:
https://www.apnic.net/wp-content/uploads/2020/02/prop-133-v002.txt

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Thanks Bertrand,

I’m fine as well with this option. Repeating it here:

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

Could the secretariat let us know if they still believe there is any text that 
is "unnecessarily duplicated" or if they could live with that?

Note that it seems that emails using DMARC still get wrong to the mailing list. 
It will be very important that the secretariat resolves that, otherwise, some 
participants are not getting emails from some of us (including me). So, no 
wonder that they don’t respond!

Regards,
Jordi
@jordipalet



El 21/2/20 15:14, "Bertrand Cherrier" 
<mailto:sig-policy-boun...@lists.apnic.net en nombre de 
mailto:b.cherr...@micrologic.nc> escribió:

Hello everyone,
Thank you Jordi for this revised prop.
How about this :

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

It would be nice to have inputs from other members of the Policy SIG, 
especially from those who opposed this proposal.
Regards,
Cordialement,

Bertrand Cherrier
Administration Systèmes - R&D
Micro Logic Systems
mailto:b.cherr...@micrologic.nc
https://www.mls.nc
Tél : +687 24 99 24
VoIP : 65 24 99 24
SAV : +687 36 67 76 (58F/min)

On 21 Feb 2020, at 11:09, JORDI PALET MARTINEZ wrote:
Hi all,

As you know, we have decided to continue the discussion of this proposal in the 
mailing list.

I've been thinking in a possible way to keep the "documented purposes" text as 
some indicated in the mike.

So, what do you feel about these two choices:

Option a)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate.

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

My personal preference, and following the staff analysis in v2, will be option 
a, but just in case the community prefers to re-state "and may not be 
sub-assigned to other networks" (I believe, and also according to the staff 
inputs that "exclusive" is already indicating it).

Just as a reminder, the actual proposal (v2) is at:
https://www.apnic.net/wp-content/uploads/2020/02/prop-133-v002.txt

Regards,
Jordi
@jordipalet





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



* sig-policy: APNIC SIG on resource management policy *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy * 
___ sig-policy mailing list 
sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Owen,

 

APNIC policy allows ISPs to get, in addition to the allocation, an assignment 
for their infrastructure.

 

I don’t think this is needed and I recall it doesn’t longer exist in other 
RIRs. May be is something else to consider and to amend as well.

 

The issue we are having, is that without inputs in the list, there is no way we 
can move on, otherwise, every 6 months, we fail again and again …

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/2/20 10:30, "Owen DeLong"  escribió:

 

Assigned address space isn’t generally delegated to LIRs,… It’s generally 
delegated to end-users. Address space delegated to LIRs may then be reassigned 
by the LIR to itself for internal purposes.

 

Unless there’s a case where an LIR is receiving an assignment instead of an 
allocation, I think we can limit it to space that is delegated to an end-user 
by the RIR.

 

Owen

 



On Feb 20, 2020, at 20:20 , JORDI PALET MARTINEZ  
wrote:

 

Thanks Bertrand,

I’m fine as well with this option. Repeating it here:

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

Could the secretariat let us know if they still believe there is any text that 
is "unnecessarily duplicated" or if they could live with that?

Note that it seems that emails using DMARC still get wrong to the mailing list. 
It will be very important that the secretariat resolves that, otherwise, some 
participants are not getting emails from some of us (including me). So, no 
wonder that they don’t respond!

Regards,
Jordi
@jordipalet



El 21/2/20 15:14, "Bertrand Cherrier" 
<mailto:sig-policy-boun...@lists.apnic.net en nombre de 
mailto:b.cherr...@micrologic.nc> escribió:

Hello everyone,
Thank you Jordi for this revised prop.
How about this :

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

It would be nice to have inputs from other members of the Policy SIG, 
especially from those who opposed this proposal.
Regards,
Cordialement,

Bertrand Cherrier
Administration Systèmes - R&D
Micro Logic Systems
mailto:b.cherr...@micrologic.nc
https://www.mls.nc
Tél : +687 24 99 24
VoIP : 65 24 99 24
SAV : +687 36 67 76 (58F/min)

On 21 Feb 2020, at 11:09, JORDI PALET MARTINEZ wrote:
Hi all,

As you know, we have decided to continue the discussion of this proposal in the 
mailing list.

I've been thinking in a possible way to keep the "documented purposes" text as 
some indicated in the mike.

So, what do you feel about these two choices:

Option a)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate.

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

My personal preference, and following the staff analysis in v2, will be option 
a, but just in case the community prefers to re-state "and may not be 
sub-assigned to other networks" (I believe, and also according to the staff 
inputs that "exclusive" is already indicating it).

Just as a reminder, the actual proposal (v2) is at:
https://www.apnic.net/wp-content/uploads/2020/02/prop-133-v002.txt

Regards,
Jordi
@jordipalet





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



* sig-policy: APNIC SIG on resource management policy *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy * 
___ sig-policy mailing l

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi all,

After my previous response to Owen, I can't find anymore any the text in the 
actual policy (neither guidelines)  about assignments. So, I'm wondering if I 
was wrong, or it has been removed at some point and I don't recall it ... Could 
the secretariat point out to the specific text about that? If it has been 
removed, clearly there is a need to further update section 2.2.3 to remove that 
reference and avoid the mismatch.

One more request for the secretariat. Could you please provide stats on the 
number of ISP (not end-users) assignments, for example in the last 12-15 years, 
in order to understand if this is a real requirement?

Anyone can provide examples of why an ISP could need and assignment instead of 
using their own allocation?

Thanks!

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Of course, no issue, thanks!

 

Safe flights for everyone!

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/2/20 12:21, "Sanjaya Sanjaya"  escribió:

 

Hi Jordi and all,

Will respond on Monday as we're currently recuperating from the APRICOT week :) 
Stay tuned.

Sanjaya 

Sent from my mobile. 

 

From: sig-policy-boun...@lists.apnic.net  
on behalf of JORDI PALET MARTINEZ 
Sent: Saturday, February 22, 2020 1:20:59 PM
To: mailman_SIG-policy 
Subject: Re: [sig-policy] prop-133: Clarification on Sub-Assignments 

 

Hi all,

After my previous response to Owen, I can't find anymore any the text in the 
actual policy (neither guidelines)  about assignments. So, I'm wondering if I 
was wrong, or it has been removed at some point and I don't recall it ... Could 
the secretariat point out to the specific text about that? If it has been 
removed, clearly there is a need to further update section 2.2.3 to remove that 
reference and avoid the mismatch.

One more request for the secretariat. Could you please provide stats on the 
number of ISP (not end-users) assignments, for example in the last 12-15 years, 
in order to understand if this is a real requirement?

Anyone can provide examples of why an ISP could need and assignment instead of 
using their own allocation?

Thanks!

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-134: PDP Update withdrawn by author

[JORDI PALET MARTINEZ]

Hi Bertrand, all,

As indicated in the meeting, the withdraw of this proposal is "temporary", in 
view of the commitment from the EC/secretariat to review the discrepancies in 
the actual PDP and SIG guidelines, assuming that this will be brought back to 
the community, following the bottom-up-approach, but the next meeting (maximum).

I still thing that this should not be a task done only by the EC/secretariat 
but instead a Taks Force should be setup. I hope the EC can still consider 
setting up this TF.

As a result of the EC review or TF review the community should be able to 
decide how to move on, including, if needed, new policy proposals.

Regards,
Jordi
@jordipalet
 
 

El 24/2/20 3:57, "Bertrand Cherrier"  escribió:

Dear colleagues

Version 2 of prop-134: PDP Update, did not reach consensus and was 
withdrawn by the author at the APNIC 49 Open Policy Meeting.

Proposal details, including the full text of the proposal, history, and 
links to previous versions are available at:

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

We'd like to thank the author and everyone for taking the time to 
discuss this proposal.

Regards
Sumon, Bertrand, Ching-Heng
Policy SIG Chairs
*  sig-policy:  APNIC SIG on resource management policy 
  *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Sunny, all,

Let me try to clarify.

2.2.3 mention "address space that is delegated to an LIR" ... "for specific use 
within the Internet infrastructure they operate". Let's put aside, for the 
moment, the end-user case.

If you read 9.2. Initial IPv6 allocations and 10.0. IPv6 assignments, there is 
not any explicit reference to assignments for an LIR.

We could interpret 10.1.4.1. Initial assignment "Organizations are eligible for 
an IPv6 Provider Independent delegation if they are able to demonstrate a valid 
reason that an assignment from their ISP, or LIR, is not suitable.", as if an 
ISP/LIR can't assign part of their own allocation to its own network, but it is 
really weird.

So, I'm wondering if this is valid case anymore, or it is one of those things 
that come from the original IPv6-policy, and was drafted due to lack of 
experience at that time. Do we have a case for that? In other RIRs, this has 
been already removed.

Regards,
Jordi
@jordipalet
 
 

El 24/2/20 4:39, "Srinivas Chendi"  escribió:

Hello Jordi,

On 22/02/2020 2:20 pm, JORDI PALET MARTINEZ wrote:
> Hi all,
> 
> After my previous response to Owen, I can't find anymore any the text in 
the actual policy (neither guidelines)  about assignments. So, I'm wondering if 
I was wrong, or it has been removed at some point and I don't recall it ... 
Could the secretariat point out to the specific text about that? If it has been 
removed, clearly there is a need to further update section 2.2.3 to remove that 
reference and avoid the mismatch.

You mean section 2.2.3 text? It is not removed. You can find it in the 
current policy manual here


https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space


> 
> One more request for the secretariat. Could you please provide stats on 
the number of ISP (not end-users) assignments, for example in the last 12-15 
years, in order to understand if this is a real requirement?

Noted! Secretariat will provide the stats soon.

Regards
Sunny

> 
> Anyone can provide examples of why an ISP could need and assignment 
instead of using their own allocation?
> 
> Thanks!
> 
> Regards,
> Jordi
> @jordipalet
>   
>   
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> 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.
> 
> 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
> 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Sunny,

I'm mainly interested in the assignments to ISP infrastructure, as the others 
are different cases, and clearly are "end-users". The point is to understand if 
there is really a need for ISPs to get additional assignments, why they can't 
do it already from their own allocation. 

Any indication of the tendency for those cases (assignments for ISP 
infrastructure), I mean if this was in an early stage and the is going up or 
going down?

What specific text of the policy or guidelines is "being" used to do that?

Regards,
Jordi
@jordipalet
 
 

El 26/2/20 4:18, "Srinivas Chendi"  escribió:

Hi Jordi,

On 24/02/2020 1:39 pm, Srinivas (Sunny) Chendi wrote:
>>
>> One more request for the secretariat. Could you please provide stats 
>> on the number of ISP (not end-users) assignments, for example in the 
>> last 12-15 years, in order to understand if this is a real requirement?
> 
> Noted! Secretariat will provide the stats soon.
> 
> Regards
> Sunny

To date we have delegated portable assignments to 547 ISPs. Some common 
reasons for this include:

- Assignment to operate IXP
- Historical Resource assignments
- M&A of members who held assignments
- Assignment for ISP infrastructure

Regards
Sunny




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-134: PDP Update withdrawn by author

[JORDI PALET MARTINEZ]

Hi Paul,

Then it seems there is a misunderstanding, at least in the way I interpreted 
what it was said in the meeting.

For me it is not just editorial changes, because there is not a link, in 
between the PDP and the guidelines. It is not a matter of just "adding" that 
link now. It is a matter of having either a guidelines developed following the 
PDP (bottom-up) or updating the PDP itself (by means of the PDP as well), to 
include the points that are needed from the guidelines.

My observation in the meeting was that the guidelines were developed too long 
ago, by the SIG chairs, when we had many SIGs, not developed by the community, 
and not developed on purpose for the policy development. I think there is a 
substantial difference in between SIGs that don't develop policies and the one 
responsible for the policies.

Regards,
Jordi
@jordipalet
 
 

El 26/2/20 6:18, "Paul Wilson"  escribió:

Dear Jordi, and colleagues,

This policy document review is on the Secretariat workplan for 2020, and 
it has been regarded as an editorial task, on an assumption that it will
not affect the substance of any policies.

Of course, any document changes would be subject to the usual editorial 
review process, and progress will be shared with the community in time 
for APNIC 50 where it can be discussed.

There is no plan to create a taskforce, but this could certainly be 
decided at the next meeting, if the community agrees.

All the best

Paul.


Paul Wilson, Director-General, APNICd...@apnic.net
http://www.apnic.net@apnicdg

On 25 Feb 2020, at 10:16, Srinivas Chendi wrote:

> Hi Jordi,
>
> Thanks for your suggestion. Secretariat will consult with the APNIC 
> EC.
>
> Regards
> Sunny
    >
> On 24/02/2020 8:53 pm, JORDI PALET MARTINEZ wrote:
>> Hi Bertrand, all,
>>
>> As indicated in the meeting, the withdraw of this proposal is 
>> "temporary", in view of the commitment from the EC/secretariat to 
>> review the discrepancies in the actual PDP and SIG guidelines, 
>> assuming that this will be brought back to the community, following 
>> the bottom-up-approach, but the next meeting (maximum).
>>
>> I still thing that this should not be a task done only by the 
>> EC/secretariat but instead a Taks Force should be setup. I hope the 
>> EC can still consider setting up this TF.
>>
>> As a result of the EC review or TF review the community should be 
>> able to decide how to move on, including, if needed, new policy 
>> proposals.
>>
>> Regards,
>> Jordi
>> @jordipalet
>>
>>
>>
>> El 24/2/20 3:57, "Bertrand Cherrier" 
>> > b.cherr...@micrologic.nc> escribió:
>>
>>  Dear colleagues
>>
>>  Version 2 of prop-134: PDP Update, did not reach consensus and 
>> was
>>  withdrawn by the author at the APNIC 49 Open Policy Meeting.
>>
>>  Proposal details, including the full text of the proposal, 
>> history, and
>>  links to previous versions are available at:
>>
>>  https://www.apnic.net/community/policy/proposals/prop-134/
>>
>>  We'd like to thank the author and everyone for taking the time 
>> to
>>  discuss this proposal.
>>
>>  Regards
>>  Sumon, Bertrand, Ching-Heng
>>  Policy SIG Chairs
>>  *  sig-policy:  APNIC SIG on resource management 
>> policy   *
>>  ___
>>  sig-policy mailing list
>>  sig-policy@lists.apnic.net
>>  https://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>>
>>
>> **
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> 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 
>> str

[sig-policy] PDP and SIG Guidelines Review Report (Policy SIG earlier today)

[JORDI PALET MARTINEZ]

Hi all,

I just saw the video (not able to attend on-line to all the sessions because a 
very different time zone all the week), of the Policy SIG session today, and 
specially the "PDP and SIG Guidelines Review Report".

I've seen also the diff of both documents.

I feel somehow "guilty" about this topic, as I was the one pushing for several 
policy proposals to update the PDP. I think that the pandemic showed us that, 
without having the crystal ball, I was right in many points!

Despite that, I'm very happy that finally, there are some action to update 
this, however I've doubts about the say to proceed and the proposed changes.

The first big question is that I'm not sure the actual PDP allows "editorial" 
changes to be actually made without the community consensus. Also, the 
associated problem is to agree in what is and what not an editorial change. 
Sunny actually said that in his presentation, confirming that the community 
owns those documents.

In principle, I could agree that if they are really pure editorial inputs, they 
can be changed by the staff, but in any case, this needs to have a pass thru 
the community (as mandated by ICP-2 and consensus/bottom-up approach), and I 
guess this is the appropriate mailing list for that.

So, I will start by commenting in detail the proposed changes. However, for 
that, I need a word or txt version, as I tried to use the html-diff and if I 
try to copy one column to paste as text, it actually copies both columns ...

Can the secretariat provide such doc or txt version already? (doc has the 
advantage to allow track of changes and comments, I think it is preferable). I 
know that it is the plan, but I will like to start now (no reason to delay it), 
as I've some more availability now, that will not necessarily be the case in a 
few days/weeks (I'm strong believer of "never leave till tomorrow what you can 
do today").

Further inputs to the today's session:

1) I agree with some of the inputs from Owen. For example, the voting for 
elections, I've proposed this actually in other regions. I will prefer 6 months 
instead of 60 days. The goal is that only people in the mailing list 6 months 
before the month where the elections happens is allowed to vote in order to 
avoid possible fraud in elections (100 friends of one of the candidates 
registering only for voting).

2) On Gaurab comment, and somehow Aftab. I also think that we will need a PDP 
change to allow having OPM by their own (if it becomes necessary for whatever 
reason, LACNIC PDP already allows it without changes) and as it was in one of 
my policy proposals, because the EC already needs to endorse a proposal, this 
is sufficient and not AGM approval is needed, it is a "repetitive" process.

3) Following another Owen input, SIG guidelines don't necessarily need to be 
the same for all the SIGs, because there is a substantial difference between 
the Policy SIG and the others (the Policy SIG makes policies, not the others). 
So the PDP should be self-contained and not depend on "other" SIG guidelines.

Tks!

Regards,
Jordi
@jordipalet





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] about prop-125 Implementation update

[JORDI PALET MARTINEZ]

Hi George, all,

I just looked at the presentation that you have done earlier today and have 
some inputs about possible ways to improve it.

1. Slides 9-10
1.1. About receiving spam
The abuse mailbox should receive *all* the emails to be able to receive abuse 
reports about spam. If you filter emails that contain headers from spam, then 
you are ruining the purpose of the abuse-c. Clearly this could be improved, as 
an operational decision, by making some kind of automation, but in such way 
that ensures that only real spam is dropped. Note that the other RIRs are also 
using (at some point), validation links via the abuse-c email.

1.2. About clicking links
I provided an example procedure in the policy proposal to avoid this. I've 
copied this below my signature. See points 1-5. If that procedure is followed, 
I think it is obvious that you will avoid this problem. I missed to ensure 
during the previous implementation presentations, that you are following a 
procedure that avoids this problem. Of course, you can even avoid needing to 
send the validation link if you just say in the email with the code "you need 
to go to your MyAPNIC account to use this code" ... Maybe also an alternative 
is to use email certificates from APNIC.

2. Slide 11
2.1. About the validation cycle.
In more recent versions of this policy, in other RIRs, I have included specific 
text so APNIC can accommodate both, the validation periods and the cycle 
validation. The idea is that you can do a slow start (which seems not to be 
needed in the case of APNIC due to the 87% validation success - 
congratulations!), but you can also adjust the timing depending on the staff 
available to escalating the validation, or to move from 6 months to 1 year once 
the "99%" of the contacts are valid, and if needed, for example, the contacts 
get bad, move again to 6 months or even 3 months to get them again on track.

2.2. Deprecating IRT.
The policy proposal included in the ADDITIONAL INFORMATION section:
"a. Since this proposal is implemented, APNIC will publish the IRT also as 
abuse-c, in order to facilitate the search in whois, for the same information, 
regardless if looking for abuse-c or IRT. This is done in order to assimilate 
the IRT to the majority of the RIRs where it is abuse-c."

So clearly, the idea was that we move from the IRT to abuse-c, so to align as 
much as possible all the 5 RIRs (in ARIN is POC, and AFRINIC is also IRT, but 
there is a policy proposal like this one, an in fact there are only a 
ridiculous fraction of IRT objects because is not mandatory right now).

I've one question I've. What is the status of implementation at each NIR?

Now, regarding the points that I've commented above, I will be happy to get 
additional inputs and send a policy proposal in a few days. I don't think we 
should do anything about 1.1. 1.2 and 2.2 should be addressed as part of the 
operational procedure by the staff. We can address 2.1. Something else?

Now, a possible idea to improve this will be move the policy to make mandatory 
the use of XARF "eXtended Abuse Reporting Format" (RFC5965/RFC6692). There is 
already open source (and commercial tools) that allow it. This will resolve the 
problem 1.1 above and provide much better tools to the resource-holders to 
avoid manual monitoring as much as possible, automate the abuse processing, etc.

Can we get some inputs about if this is perceived as interesting by the 
community?

Maybe we can draft the policy proposal in such way that XARF can be optional at 
this stage, and later on, if there is a good adoption %, in 1-2 years, move to 
mandatory?

I will send a policy proposal to update this upon getting some inputs. I guess 
Aftab will be happy to join as well, and happy to get other people on-board!

Regards,
Jordi
@jordipalet
 
 c. Example of the validation procedure.

1) APNIC initiates the validation automatically, sending TWO consecutive emails 
to each of the mailboxes.

2) These emails will be sent containing plain text only.

3) The first email will contain the URL where the validation is to be performed 
("validation.apnic.net") and may contain information about the procedure, a 
brief summary of this policy, etc.

4) The second email will contain a unique alphanumeric validation code.

5) The person in charge of the each of the mailboxes must go to the URL and 
paste the code received in the second email in the form.

6) This URL must be designed in such a way that it prevents the use of an 
automated process (for example, "captcha"). In addition, it must contain a text 
that confirms that the person performing the validation understands the 
procedure and the policy, that they regularly monitor the mailboxes, that 
measures are taken to solve reported cases of abuse, and that the abuse report 
receives a response, with a "checkbox" that must be accepted in order to 
proceed.

7) The alphanumeric code will only be valid for a maximum of fifteen days.

8) If the code is not e

Re: [sig-policy] about prop-125 Implementation update

[JORDI PALET MARTINEZ]

Hi George,

Tks for your response!

I think it is just ok, however I've a minor disagreement.

My idea is to amend the proposal so the validation is done every 6 months and 
the timer for the initial validation is 15 days, BUT state that the secretariat 
is able to adjust both timings according to circumstances, and inform the 
community about the reasons.

This allows to, once almost 99% of the validations are ok, decide if we need to 
make only one validation per year, but if after that validation the quality of 
the contacts is going down, the secretariat can consider making it again every 
6 or 8 months to readjust, etc. This will allow you to manage those timers, 
without amending the proposal. Do you see my point?

(this is what I've done in other regions)

Regards,
Jordi
@jordipalet
 
 

El 16/9/20 9:44, "George Odagi"  escribió:

Hi Jordi,

Thanks for watching the presentation and for your comments.

Based on our recommendations, we are suggesting the following changes:




Example of new validation procedure

1) APNIC initiates the validation automatically ONCE a year, sending ONE 
email to the 'abuse-mailbox' address. 
(We will consider deprecating the 'email' attribute so only one email 
address requires validation)

2) The email will be sent containing plain text only.

3) The email will contain the unique code required for the validation and 
may contain information about the procedure, a brief summary of this policy, 
etc.

4) The person in charge of the mailbox will be instructed to visit the 
APNIC website (eg. www.apnic.net/irt-validation) and paste the code received in 
their email. (MyAPNIC cannot be used since many abuse mailboxes are either 
customers of members or company staff who do not have MyAPNIC access).

5) The IRT validation page on the APNIC website will be designed in a way 
that it prevents the use of an automated process (for example, "CAPTCHA"). In 
addition, it will contain a text that confirms that the person performing the 
validation understands the procedure and the policy, that they regularly 
monitor the mailboxes, that measures are taken to solve reported cases of 
abuse, and that the abuse report receives a response, with a "checkbox" that 
must be accepted in order to proceed.

6) If the code is not entered within 15 days, the system will mark the IRT 
as "Invalid” in the APNIC Whois Database and an automatic reminder will be 
sent. If validation is still not completed after 30 days, MyAPNIC access will 
be restricted and APNIC staff will follow-up with the member using all contact 
methods available.

7) Once the validation has been resolved, the IRT will be marked as "Valid" 
and MyAPNIC access will be reinstated.




From the Secretariat's point of view - the intention is to make minor 
tweaks to the existing process to simplify the validation and reduce burden 
that we are putting on members. Most of the changes can be made as operational 
procedure; however the current policy text specifies that validation occurs 
every 6 months, so we would need an amended proposal to change this timeframe. 
We want to keep this simple by using a fixed timeframe of once yearly as we are 
already starting to reach the goals that we have set out to achieve in this 
policy. 

Regarding the NIRs, they have reported the following statuses:

- CNNIC is almost ready to implement
- IDNIC have implemented but still tweaking
- JPNIC is working with JPOPF on the implementation
- TWNIC and VNNIC will implement by Q1 2021

We are currently in discussion with IRINN and KRNIC about their 
implementation plan.

We would love to hear from the rest of the community about these changes 
and work together in amending this policy.

Any questions or concerns, please let us know.


Regards,

___
George Odagi
Internet Resource Analyst/Policy Support, APNIC
e: god...@apnic.net
p: +61 7 3858 3188
f: +61 7 3858 3199
www.apnic.net
___
Join the conversation:   https://blog.apnic.net/












    On 10/9/20, 5:57 pm, "sig-policy-boun...@lists.apnic.net on behalf of 
JORDI PALET MARTINEZ"  wrote:

Hi George, all,

I just looked at the presentation that you have done earlier today and 
have some inputs about possible ways to improve it.

1. Slides 9-10
1.1. About receiving spam
The abuse mailbox should receive *all* the emails to be able to receive 
abuse reports about spam. If you filter emails that contain headers from spam, 
then you are ruining the purpose of the ab

Re: [sig-policy] SIG Guidelines Review

[JORDI PALET MARTINEZ]

Could a track of changes be provided to simplify the review?

Regards,
Jordi
@jordipalet
 
 

El 16/11/20 2:44, "Bertrand Cherrier"  escribió:

Hello everybody !

Last year at APNIC 48 a discussion started about reviewing the SIG 
Guidelines.
It is important to make documents match the evolution of the current 
practice.

SIG Chairs and co-Chairs along with the big help of APNIC Secretariat 
designed a draft version of the new Guidelines, you will find it with 
this email.

Here is a brief of the major changes :

- Make SIG Guidelines a numbered document
- Move Policy SIG specific content to PDP
- Move SIG elections online and to APNIC standalone conference
- Restructure and renumber the document
- Include reference to Code of Conduct
- Include procedure to change document

If you have any comments or remarks and we hope you do !, please do 
share thoses with the community by Friday 20th

Have a nice week,

Regards,

Bertrand and Ching-Heng
APNIC Policy SIG Chairs
*  sig-policy:  APNIC SIG on resource management policy 
  *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Final editorial comments on draft document

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I've several points in addition to my document comments. I can't use the 
comments platform, which by the way, is absolutely unpractical (not to say 
something really more negative), because a) you need to be on-line, which may 
not be the case, b) you don't create a public discussion on the inputs - which 
is critical for the bottom-up consensus, c) you don't know if the community is 
really following it or not, d) it doesn't follow the PDP itself!. So, I will 
summarize here my more critical inputs.

I've raised those several times, but it seems that it was ignored.

1) The actual PDP doesn't have any binding to the SIG guidelines, so *legally 
speaking* the SIG guidelines aren't applicable. Is like if tomorrow we make 
another document that we call "Policy SIG meeting guidelines" and we try to 
bypass the PDP adopting it as a separate document, not using the PDP, and/or 
there is no PDP modification to bind that document.

2) In your email you indicate that consensus has already been reached. In what 
meeting? If this is not a PDP document (SIG guidelines), is not bound to the 
PDP, etc., how come consensus has been reached? Could you provide a step by 
step consensus process for this document? Again, are we trying to bypass the 
PDP and inventing a different consensus path for *separate documents* ?

3) So clearly, I can only object to this, it is an illegal act against the 
community and every community member to try to bypass our PDP, and if this goes 
on, it will be against ICANN ICP-2 and the rules that established APNIC and we 
will need to appeal that.

4) I fully agree that the PDP needs to be improved, and that's why I've 
submitted policy proposals for that, but *we need to do it in the correct way* 
so only can be done following the PDP.

5) The PDP must be self-inclusive. It looks nice to have a "5 sentences" PDP, 
but it has been demonstrated that it is just an illusion that doesn't work. At 
a minimum, any additional document should be bound to the PDP and follow the 
same process.

6) This is the most important point, which invalidates all the process: 
According to the PDP there is NO authorization for editorial changes. So that 
means that even *editorial changes* need a complete pass thru the PDP. I'm not 
saying this is optimal, and I will prefer that the secretariat can actually do 
editorial review of documents, *however* my wish and your intent aren't part of 
the actual PDP. So, if we want to make editorial changes this way, we need 
*FIRST* to have a policy proposal adopted via the PDP to add that prerogative 
to the secretariat. By the way, how we decide what is editorial and what not? 
This must be clarified to allow that "functionality" (for example, only 
grammar, typos, etc. or also text clarification that doesn't change the 
intended original meaning).

7) Please see also my email on September 9 (2020), which I don't recall has 
been answered (clearly no answer doesn't show ANY consensus): 
https://mailman.apnic.net/mailing-lists/sig-policy/archive/2020/09/msg2.html

Inputs to the document:

1. Introduction
This text is drastically changing the PDP it is not *editorial*. It introduces 
an *artificial link* to the SIG guidelines which, as I already mention above, 
*are not part of the PDP* and can't be, unless that document pass as a policy 
proposal via the PDP itself. Accepting that is like accepting that a government 
change a law (in a democratic country) without nobody know it, and without the 
voting in the parliament, so basically a crime.

The actual PDP only talks about meetings and lists. As I've commented other 
times, we have been using electronic means, which I agree, but changing this in 
the PDP is NOT an editorial comment. It needs to pass via the PDP. In fact, the 
demonstration of why that change is NOT an editorial comment, is that in one of 
my proposals, that change *never reached consensus*, even if the chairs asked 
just for that point (isolated from the rest of the proposal). So how come we 
can now say that it is an editorial comment and bypass the community decision 
*in the PDP* that they don't agree with that change?

Using the expression "anyone with an interest in the management and use of 
Internet number resources ..." is creating a big problem vs the actual wording, 
because the actual wording clearly means that if someone is interested in 
improving the PDP (not and Internet number resource), will not be able to do 
participate, or saying it in another way, again this is not an editorial 
change, because we are using a subterfuge to restrict the PDP to be updated in 
the future, which creates a big trouble!

How come RIR, ICANN and PTI employees can't participate? I've never seen that 
in any RIR. Usually they don't do, or they speak up clearly indicating if they 
are speaking as employees of those organizations or as community members. This 
is completely broken! NOBODY can restrict an employee of a RIR to say "in their 

Re: [sig-policy] prop-130-v003: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I fully understand the difficulties that you mention, but those difficulties, 
to me look like the same as per existing policy.

Any transfer requires checking documents, which may be in different languages. 
Any transfer requires coordination among NIRs or RIRs, etc.

So, I do not see it as different to what it happened with previous transfer 
policies (whatever is the reason). Of course, I also fully understand that the 
implementation time depends on coordination with the other RIRs and their 
systems, but this is also true for existing Inter-RIR policies.

Just want to make sure that I'm not missing anything and your assessment is 
just a reminder about that, not indicating any real and unsolvable issues.

Regards,
Jordi
@jordipalet
 
 

El 17/2/21 7:04, "Srinivas (Sunny) Chendi"  escribió:

Dear all,

Here is the Secretariat impact assessment for proposal "prop-130-v003: 
Modification of transfer policies".

Possible difficulties in verifying mergers, acquisition, reorganization, 
or relocation from out of APNIC region due to unfamiliarity of languages 
and legal systems. May require cross RIR coordination.

Partial IPv6 transfers may result in registration of IPv6 allocations 
that are more specific than /32.

APNIC’s current systems are not configured to handle inter-RIR IPv6 
reverse DNS. This will need to be developed.

APNIC cannot predict when other RIRs will support IPv6 reverse DNS 
fragments incoming to their systems.

Implementation: 3 months, except inter-RIR IPv6 reverse DNS (rDNS).

Regards
Sunny

On 2/02/2021 2:25 pm, chku wrote:
> Dear SIG members,
>
> A new version of the proposal "prop-130: Modification of transfer 
policies"
> has been sent to the Policy SIG for review.
>
> It will be presented during the Open Policy Meeting at APRICOT2021/APNIC 
51
> online-only conference on Wednesday, 03 February 2021.
>
> 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 conference 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:
> 
https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apnic.net%2Fpolicy%2Fproposals%2Fprop-130&data=04%7C01%7C%7C4fa1eb6f23ac419a95e508d8c7329f44%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637478367555653423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CsjZK2dQEUNWNP6Z5zdhzNiiZzC0sXfCesvMgnEbye4%3D&reserved=0
>
> Regards,
> Bertrand and Ching-Heng
> APNIC Policy SIG Chairs
>
>
> ---
>
> prop-130-v003: Modification of transfer policies
>
> ---
>
> Proposer: Jordi Palet Martnez
> jordi.pa...@theipv6company.com
>
>
> 1. Problem statement
> 
>
> Existing transfer policies for IPv4, IPv6 and ASN resources have some
> differences among what is allowed and what not, if in the case of
> intra-RIR and inter-RIR, and it is not clear if in case of merger and
> acquisitions it is referring to a complete company, part of it, or even
> if in case of a company reorganization or relocation, the policy is
> supportive to that case.
>
> In some regions, this may not be a policy, but an administrative
> procedure, but this may change in the future by means of a policy 
proposal.
>
> In the caser of inter-RIR, the counterpart RIR need to have a reciprocal
> policy or procedure that allows it.
>
> Finally, there should not be differences from the APNIC perspective, on
> the considerations of an M&A for different type of resources, because
> there is no reason for allowing, for example, IPv4 resources to be
> transferred, and instead IPv6 ones not. For example, an organization may
> be hosting services in a Data Center, by means of Virtual Machines and
> moving to a different DC in another region. It is ridiculous to allow to
> keep the IPv4 addresses (so not renumber the VMs) and instead ask to
> renumber IPv6. It is a big and unnecessary disruptive complexity.
>
>
> 2. Objective of policy change
> --
> To ensure that the policy text is clarified, if those

Re: [sig-policy] prop-130-v003: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Adam,

I don't have the need to "disguise" any policy proposal. I'm a very honest and 
transparent person, pity that you didn't noticed it, and if I believe that IPv6 
transfers outside of M&A's are required, I will submit that policy in an open 
and transparent manner.

I've you believe that I'm trying to cheat the community, please say so clearly 
and show evidences.

That said, I'm happy to work on IPv6 Inter-RIR transfers at a later stage, but 
this is not the case with this proposal.

The policies not always have cases that *already happened*. The policies should 
be there to prevent those cases being real needs and rejected. In fact, if they 
happened there may several situations:
1) The organizations that need that read the policy manual, understood they 
can't do it, and desisted.
2) They asked the secretariat.
3) They didn't read the policy/DBs update is managed (or not updated al all), 
that nobody noticed it, especially in intra-RIR situations.

So the question here is, do we want to have oredered solutions for real 
business situations, or we prefer to ignore them and even force them to bypass 
the policies and hide the situation?

If we don't have policies up-front problems, then problems became a huge issue, 
delay business, even may create losses. Some folks will just ignore policies 
and go ahead. We all know it. Policies have been done *always* up-front issues 
happening, when those possible issues where discovred, not just after we 
discover the issue. Some times we have policies too late, because nobody 
discovered the issue: that's unavoidable, because we don't have the crystal 
ball.

I can't talk for the secretariat if there have been questions about this 
previously, hopefully they can say. I know it happened in other regions.

By the way, my reading of the RIPE procedures is that they don't distinguish if 
you do an M&A with all the resources or part of it, they may confirm it (I'm 
sure they are in the list), if that's the case, and if already happened or 
there have been questions on that.

Clearly the secretariat, and the same for other RIRs, should work on developing 
whatever the community decides is good to have. And I think it is much better 
to ensure that we have those developments in mind up-front of having real 
problems, specially if they may be complex and require coordination among 
different RIRs, instead of rushing when we have the problems already in our 
back, right?

Regards,
Jordi
@jordipalet
 
 

El 1/3/21 3:31, "sig-policy-boun...@lists.apnic.net en nombre de 
em...@adamgosling.com"  escribió:

Hi all,

I oppose this proposal.

I am not convinced of the need for it. Are there examples of when an M&A 
request was refused that would be permitted by this policy change?

This looks like an IPv6 Inter-RIR transfer proposal in disguise?

I don't think the APNIC Secretariat should be required to do the 
development work to support IPv6 reverse DNS if there is no clear 
indication that other regions will support IPv6 reverse DNS fragments in 
the future.


Adam




On 2021-02-01 22:25, chku wrote:
> Dear SIG members,
> 
> A new version of the proposal "prop-130: Modification of transfer 
> policies"
> has been sent to the Policy SIG for review.
> 
> It will be presented during the Open Policy Meeting at 
> APRICOT2021/APNIC 51
> online-only conference on Wednesday, 03 February 2021.
> 
> 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 conference 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-130
> 
> Regards,
> Bertrand and Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> ---
> 
> prop-130-v003: Modification of transfer policies
> 
> ---
> 
> Proposer: Jordi Palet Martnez
> jordi.pa...@theipv6company.com
> 
> 
> 1. Problem statement
> 
> 
> Existing transfer policies for IPv4, IPv6 and ASN resources have some
> differences among what is allowed and what not, if in the case of
> intra-RIR and inter-RIR, and it is not clear if in case of merger and
> acquisitions it is referring to a complete company, par

Re: [sig-policy] Policy Discussion in bdNOG for APNIC51

[JORDI PALET MARTINEZ]

Hi,

It will be possible to understand what issues the participants have discussed 
about prop-130?

By the way, I think it will be much more efficient if instead of reading a 
policy proposal on behalf the author (and without him knowing it), an 
opportunity to the author to participate is provided. That will allow 
clarifications to be done in real-time.

Regards,
Jordi
@jordipalet
 
 

El 2/3/21 2:46, "bdNOG Secretariat"  escribió:

Greetings from Bangladesh Network Operators Group (bdNOG).

This is the first time we have done a policy discussion in our NOG, based
on the upcoming OPM in APNIC51. The event was done on Feb 24, 2021 04:30
PM (BST) to introduce how APNIC runs the OPM in all the APNIC meetings and
what are the current policies proposed in the upcoming APNIC51 virtual
event. Also we had a raise hand session and open mic session. For better
understanding the whole event was done in Bangla and in English partially.

There are two active policy proposals to be discussed at APNIC 51.
Prop-130: Modification of transfer policies was read-out by Ms. Shaila
Sharmin on behalf of the author and prop-133: Clarification on
Sub-Assignments was read-out by Mr. Abdul Awal.

After the discussion consensus was taken by raising the hand. 

Prop-130, there was no consensus as there were mixed responses from the
audience.
Prop-133, was supported by the majority of the audience and there was no
one opposed to the proposal.

bdNOG will try to organize more Policy Discussion in the upcoming main
events and will try to share more inputs and thoughts from Bangladesh
Community.

With Regards

Secretariat,
Bangladesh Network Operators Group (bdNOG).


-- 

|Bangladesh Network Operators Group (bdNOG)|

A group of people playing with the Internet
puzzle and trying hard to build better Internet
in Bangladesh. www.bdnog.org

*  sig-policy:  APNIC SIG on resource management policy 
  *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] prop-130-v003: Modification of transfer policies

[JORDI PALET MARTINEZ]

ation. Your stated benefit is that 
some resource holder may at some time in the future require this service and 
that at the time the counterpart RIR may have a policy that allows it and may 
have developed the technical ability to fulfil the request.

The cost is estimated by the Secretariat as 3 months development time. 
Perhaps the Secretariat could tell us what project will be cancelled if this 
proposal reaches consensus, because this development time will not be budgeted 
for 2021.

Your point that the RIR's and the community should develop solutions the 
community may want/need in future is quite valid. However, if that’s what you 
are proposing, then make that more transparent in your proposal.

    If the community demonstrates that it accepts this cost / benefit 
trade-off, I’ll happily support the proposal.

Regards,

Adam



> On 1 Mar 2021, at 9:09 pm, JORDI PALET MARTINEZ 
 wrote:
> 
> Hi Adam,
> 
> I don't have the need to "disguise" any policy proposal. I'm a very 
honest and transparent person, pity that you didn't noticed it, and if I 
believe that IPv6 transfers outside of M&A's are required, I will submit that 
policy in an open and transparent manner.
> 
> I've you believe that I'm trying to cheat the community, please say so 
clearly and show evidences.
> 
> That said, I'm happy to work on IPv6 Inter-RIR transfers at a later 
stage, but this is not the case with this proposal.
> 
> The policies not always have cases that *already happened*. The policies 
should be there to prevent those cases being real needs and rejected. In fact, 
if they happened there may several situations:
> 1) The organizations that need that read the policy manual, understood 
they can't do it, and desisted.
> 2) They asked the secretariat.
> 3) They didn't read the policy/DBs update is managed (or not updated al 
all), that nobody noticed it, especially in intra-RIR situations.
> 
> So the question here is, do we want to have oredered solutions for real 
business situations, or we prefer to ignore them and even force them to bypass 
the policies and hide the situation?
> 
> If we don't have policies up-front problems, then problems became a huge 
issue, delay business, even may create losses. Some folks will just ignore 
policies and go ahead. We all know it. Policies have been done *always* 
up-front issues happening, when those possible issues where discovred, not just 
after we discover the issue. Some times we have policies too late, because 
nobody discovered the issue: that's unavoidable, because we don't have the 
crystal ball.
> 
> I can't talk for the secretariat if there have been questions about this 
previously, hopefully they can say. I know it happened in other regions.
> 
> By the way, my reading of the RIPE procedures is that they don't 
distinguish if you do an M&A with all the resources or part of it, they may 
confirm it (I'm sure they are in the list), if that's the case, and if already 
happened or there have been questions on that.
> 
> Clearly the secretariat, and the same for other RIRs, should work on 
developing whatever the community decides is good to have. And I think it is 
much better to ensure that we have those developments in mind up-front of 
having real problems, specially if they may be complex and require coordination 
among different RIRs, instead of rushing when we have the problems already in 
our back, right?
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 1/3/21 3:31, "sig-policy-boun...@lists.apnic.net en nombre de 
em...@adamgosling.com"  escribió:
> 
>Hi all,
> 
>I oppose this proposal.
> 
>I am not convinced of the need for it. Are there examples of when an 
M&A 
>request was refused that would be permitted by this policy change?
> 
>This looks like an IPv6 Inter-RIR transfer proposal in disguise?
> 
>I don't think the APNIC Secretariat should be required to do the 
>development work to support IPv6 reverse DNS if there is no clear 
>indication that other regions will support IPv6 reverse DNS fragments 
in 
>the future.
> 
> 
>Adam
> 
> 
> 
> 
>On 2021-02-01 22:25, chku wrote:
>> Dear SIG members,
>> 
>> A new version of the proposal "prop-130: Modification of transfer 
>> policies"
>> has been sent to the Policy SIG for review.
>> 
>> It will be presented during the Open Policy Meeting at 
>> APRICOT2021/APNIC 51
   

[sig-policy] clarification requested from AFRINIC

[JORDI PALET MARTINEZ]

Hi all,

Today, during the APNIC51 meeting, in the Global Reports session 
(https://2021.apricot.net/program/schedule-conference/#/day/10/apnic-global-reports),
 as usual, there was a presentation from every RIR, including AFRINIC.

In this presentation from AFRINIC, there have been two "imprecisions". I prefer 
to use this wording instead of something stronger, because to me those are very 
severe issues. I've asked in the Q&A to get this publicly clarified and it was 
not done.

AFRINIC MUST publicly acknowledge the mistakes.

1) It was explained that the AFRINIC PDWG co-chairs resigned. You can see it at 
the end of the presentation.
https://www.youtube.com/watch?v=5ODvgxbMErs#t=35m50s


2) It has been said that one of the policy proposals that reached consensus 
hasn't been sent to the Board for ratification, which is not true, as discussed 
in the RPD mailing list. The co-chairs did send the policy to the Board, but 
the Board decided to ignore it, because it looks like they want the chairs to 
follow a format that has never been enforced before and it has not been 
approved by the community, neither the PDP.
See slide 6 at 
https://2021.apricot.net/assets/files/APSr481/afrinic-update-apnic51.pdf


Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [rpd] [Community-Discuss] clarification requested from AFRINIC

[JORDI PALET MARTINEZ]

Hi Madhvi,

 

The correction of my point 1 was done in the Q&A screen, but not in “voice”. As 
a consequence, all the participants that usually have the Q&A windows closed 
(in Zoom), were not able to see it, and they may be still under the impression 
that it was a resignation, not a recall. I understand that was out of the hands 
of AFRINIC, so I’ve copied back the relevant APNIC mailing list, so this 
correction is now clear.

 

Regarding point 2, the co-chairs indicated that they have sent an email. The 
PDP doesn’t state any explicit format or template. The list dicussion shows 
that the staff asked them to follow a format used by previous chairs, but the 
PDP doesn’t ask for it, so it can’t be enforced. The Board deny having got that 
report, but they never denied having received the email. Again: the PDP doesn’t 
enforce any specific format, so we need to see the email to understand if the 
Board is missing something and actually *informed* the co-chairs about WHAT 
they missed.

 

Can the Board *confirm* or *deny* if they GOT SUCH EMAIL? That will clarify the 
issue and if the (ex)co-chairs can forward that email to the list, that will be 
awesome, but meanwhile, even if the co-chairs have been recalled, I don’t have 
any reasons to believe that they lied in sense that they didn’t sent the email.

 

Regards,

Jordi

@jordipalet

 

 

 

El 3/3/21 12:09, "Madhvi Gokool"  escribió:

 

Hello Jordi /PDWG

 

On 03/03/2021 1:52 PM, JORDI PALET MARTINEZ via Community-Discuss wrote:
Hi all,
 
Today, during the APNIC51 meeting, in the Global Reports session 
(https://2021.apricot.net/program/schedule-conference/#/day/10/apnic-global-reports),
 as usual, there was a presentation from every RIR, including AFRINIC.
 
In this presentation from AFRINIC, there have been two "imprecisions". I prefer 
to use this wording instead of something stronger, because to me those are very 
severe issues. I've asked in the Q&A to get this publicly clarified and it was 
not done.
 
AFRINIC MUST publicly acknowledge the mistakes.
 
1) It was explained that the AFRINIC PDWG co-chairs resigned. You can see it at 
the end of the presentation.
https://www.youtube.com/watch?v=5ODvgxbMErs#t=35m50s
The AFRINIC staff corrected the initial statement made in his  presentation and 
mentioned that the Co-chairs were recalled in the Q&A feature.  
 
 
2) It has been said that one of the policy proposals that reached consensus 
hasn't been sent to the Board for ratification, which is not true, as discussed 
in the RPD mailing list. The co-chairs did send the policy to the Board, but 
the Board decided to ignore it, because it looks like they want the chairs to 
follow a format that has never been enforced before and it has not been 
approved by the community, neither the PDP.
See slide 6 at 
https://2021.apricot.net/assets/files/APSr481/afrinic-update-apnic51.pdf
i) The PDWG is under the impression from a previous correspondence of the now 
ex-co chair AbdulKarim that the co-chairs  had already sent the ratification 
reports to the Board.

ii) There were requests on the rpd mailing list to the outgoing co-chairs to 
share the mails that they have sent to the Board with the PDWG  and there were 
no responses.  

iii) The Board Chair informed the community on 14 Feb 2021  that the report for 
ratification was not received. 

https://lists.afrinic.net/pipermail/rpd/2021/012363.html

iv) It is incorrect to mention that the Board wanted the chairs to follow a 
specific format. This is a misinterpretation of the information provided by the 
Policy Liaison to the mailing list  in regard to the report template.  
https://lists.afrinic.net/pipermail/rpd/2021/012374.html

 

Regards

Madhvi

___ RPD mailing list 
r...@afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

[sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

Hi Sunny, all,

Some of the topics that you mention, have been already resolved in other RIRs, 
as there were similar issues. In fact, I authored a few policy proposals about 
some of them.

In a quick review of your presentation, I see that many of them are really easy 
to resolve. They are not "editorial" in the sense of typos or grammar, but 
inconsistencies among different parts of the policy "manual" and, the most 
important thing, I believe they are non-contentious (so "should not" have 
objections which create lack of consensus, lengthy discussions, etc.). 

For example, in a quick look, some of those that I believe aren't contentious:

0) Overall: Improve definitions, ensure they are in a single section?
1) End-Site vs end-user
2) 5.31, 5.32, 5.3.3 unify?
3) 5.6 and 5.6.1 repetitive, delete last one
4) Utilization vs usage rate
5) Agree with transfers in a single place
6) LIR assignment for their own infrastructure doesn't look as a real need in 
IPv6?
7) 5.2.1 assignment window for LIRs Second Opinion Request
9) I don't think we need IPv6 guidelines ... anymore, having policies and 
guidelines is making it more complex
10) No need for experimental IPv4 resources anymore?
11) ASNs 12.4 vs 13.0 - rewording or clarification needed

We shouldn't make this very complex or take a long time to resolve them. I will 
say that by the next on-line meeting, should be sorted out, at least for those 
issues that aren't contentious.

I just started a document with a proposal for all them. I will try to finish it 
this afternoon.

However, I think if we can circulate in the list each topic, we can "see" if 
anyone is objecting to any of the issues, before making a formal proposal. This 
way we can split the issues in those that are "non-contentious" and those that 
"may have some objections". Even if the APNIC PDP is used to ask questions for 
separate parts of a single proposal, we can make it much easier having ONE 
proposal for the "non-contentious", and then individual proposals for each of 
the "contentious" ones.

We can try to determine if any of the issues is "contentious" by circulating in 
the sig-policy list each of the points. This will only work if the people 
decide to *actively* participate, in such way that for example, every week 
(more or less), from now to the next meeting (actually a couple of months 
before it, at least), so we have a clear view of points to "exclude" from the 
"non-contentious proposal".

*Otherwise*, if people are not willing to contribute actively, we don't waste 
anyone time and I just fire a proposal tomorrow.

Now, while I'm happy to take over this task myself, I will prefer doing this 
with other folks. May be people that never participated in policy proposals 
before and want to take advantage of the experience?

So, I will ask once more: Anyone interested to contribute (you can email me in 
private if you prefer so)?

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

Hi Sunny, all,

 

I saw your slides, and in fact, that’s what I followed initially for preparing 
my proposal. However, I saw many other points that need resolution, in my 
opinion, as when you touch some of the text, some other text is related to it, 
etc.

 

So, yes, I understand your slide 17, however, the point is still the same … In 
an ideal world, if you don’t need any more any INR (Internet Number Resource), 
which has been provided by the RIR (APNIC in this case), then you just return 
it, so other community members can take advantage of it. However, we know that 
will not happen, and we will need to go into “persecution & reclaim-mode” 
(excluding M&A cases), and this is what triggered the transfer policies. What 
I’m saying is that the apparent contradiction for the ASNs is there also for 
IPv4 resources. We can tidy up a bit the text, but the contradiction is 
“generic” in the sense that any non-used resource must be reclaimed.

 

Let’s talk about this in the community consultation. It is a terrible timing 
for me (national holiday and 5AM) … but I will try to join anyway.

 

By the way, I forgot to mention in my email that the transfers policies, could 
not just be “editorially moved” to a specific part in the policy manual, but 
also try to make the text shorter, instead of having just all the text “there”. 
I will try to prepare something else about that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 15/3/21 7:55, "Srinivas (Sunny) Chendi"  escribió:

 

Hello Jordi,

Thanks for your email. Please see the responses inline below.

On 15/03/2021 8:05 am, JORDI PALET MARTINEZ wrote:
Hi all,
 
I've got no inputs to this message, so I moved on and edited a draft policy 
proposal, trying to avoid any "contentious" wording ... but will see.
As usual, appreciate for your pro-activeness and support. The Policy SIG Chairs 
have sent an invitation to the community to join a virtual community 
consultation to discuss the Policy documentation review report presented at 
APNIC 51 OPM. This is an opportunity for those who missed the OPM to 
participate in this discussion.

   https://www.apnic.net/community/participate/sigs/community-consultation/

After this virtual consultation, hope interested individuals (or groups) may 
come forward to draft proposal/s.

 
I've one question for the secretariat, actually all, regarding the ASN return 
vs. transfers. The point is that if we "ask" all the LIRs to return the ASNs 
that they don't use, we should also ask them to return the IPv4 addresses that 
they don't use ... so then there is no need to allow the transfers. So, I think 
we should keep the ASN/ASN transfers as is today. Or do you think the wording 
in between IPv4 and ASN is so different that makes a point in rewording the ASN 
12.4?
We could keep the current text but is contradicting with the text in "Section 
13.2.2. Conditions on the source of the transfer" and creating confusion as 
reported at APNIC 51. Please refer to slide #17, here

https://2021.apricot.net/assets/files/APSr481/apnic-policy-document-review-report.pdf

This just requires a simple update to "Section 12.4 Providing ASN to customer", 
point #4, to allow transfer in accordance with ASN Transfers 13.0.

Hope this clarifies.

Regards
Sunny



 
So ... see the attached PDF with the proposal. This is just a draft. As I 
mention in my previous email, the goal is to have some discussions in the list 
and get other folks joining before submitting a proposal ... of course, unless 
there is no discussion in the list and I need to go for the proposal.
 
Regards,
Jordi
@jordipalet
 
 
 
El 3/3/21 13:40, "JORDI PALET MARTINEZ"  escribió:
 
    Hi Sunny, all,
 
    Some of the topics that you mention, have been already resolved in other 
RIRs, as there were similar issues. In fact, I authored a few policy proposals 
about some of them.
 
    In a quick review of your presentation, I see that many of them are really 
easy to resolve. They are not "editorial" in the sense of typos or grammar, but 
inconsistencies among different parts of the policy "manual" and, the most 
important thing, I believe they are non-contentious (so "should not" have 
objections which create lack of consensus, lengthy discussions, etc.). 
 
    For example, in a quick look, some of those that I believe aren't 
contentious:
 
    0) Overall: Improve definitions, ensure they are in a single section?
    1) End-Site vs end-user
    2) 5.31, 5.32, 5.3.3 unify?
    3) 5.6 and 5.6.1 repetitive, delete last one
    4) Utilization vs usage rate
    5) Agree with transfers in a single place
    6) LIR assignment for their own infrastructure doesn't look as a real need 
in IPv6?
    7) 5.2.1 assignment window for LIRs Second Opinion Request
    9) I don't think we need IPv6 guidelines ... anymore, having policies and 
guidelines is making i

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

I meant:

 

in the sense that any non-used resource must be returned “voluntarily” (or 
otherwise reclaimed).

 

Regards,

Jordi

@jordipalet

 

 

 

El 15/3/21 10:17, "JORDI PALET MARTINEZ"  escribió:

 

Hi Sunny, all,

 

I saw your slides, and in fact, that’s what I followed initially for preparing 
my proposal. However, I saw many other points that need resolution, in my 
opinion, as when you touch some of the text, some other text is related to it, 
etc.

 

So, yes, I understand your slide 17, however, the point is still the same … In 
an ideal world, if you don’t need any more any INR (Internet Number Resource), 
which has been provided by the RIR (APNIC in this case), then you just return 
it, so other community members can take advantage of it. However, we know that 
will not happen, and we will need to go into “persecution & reclaim-mode” 
(excluding M&A cases), and this is what triggered the transfer policies. What 
I’m saying is that the apparent contradiction for the ASNs is there also for 
IPv4 resources. We can tidy up a bit the text, but the contradiction is 
“generic” in the sense that any non-used resource must be reclaimed.

 

Let’s talk about this in the community consultation. It is a terrible timing 
for me (national holiday and 5AM) … but I will try to join anyway.

 

By the way, I forgot to mention in my email that the transfers policies, could 
not just be “editorially moved” to a specific part in the policy manual, but 
also try to make the text shorter, instead of having just all the text “there”. 
I will try to prepare something else about that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 15/3/21 7:55, "Srinivas (Sunny) Chendi"  escribió:

 

Hello Jordi,

Thanks for your email. Please see the responses inline below.

On 15/03/2021 8:05 am, JORDI PALET MARTINEZ wrote:
Hi all,
 
I've got no inputs to this message, so I moved on and edited a draft policy 
proposal, trying to avoid any "contentious" wording ... but will see.
As usual, appreciate for your pro-activeness and support. The Policy SIG Chairs 
have sent an invitation to the community to join a virtual community 
consultation to discuss the Policy documentation review report presented at 
APNIC 51 OPM. This is an opportunity for those who missed the OPM to 
participate in this discussion.

   https://www.apnic.net/community/participate/sigs/community-consultation/

After this virtual consultation, hope interested individuals (or groups) may 
come forward to draft proposal/s.


 
I've one question for the secretariat, actually all, regarding the ASN return 
vs. transfers. The point is that if we "ask" all the LIRs to return the ASNs 
that they don't use, we should also ask them to return the IPv4 addresses that 
they don't use ... so then there is no need to allow the transfers. So, I think 
we should keep the ASN/ASN transfers as is today. Or do you think the wording 
in between IPv4 and ASN is so different that makes a point in rewording the ASN 
12.4?
We could keep the current text but is contradicting with the text in "Section 
13.2.2. Conditions on the source of the transfer" and creating confusion as 
reported at APNIC 51. Please refer to slide #17, here

https://2021.apricot.net/assets/files/APSr481/apnic-policy-document-review-report.pdf

This just requires a simple update to "Section 12.4 Providing ASN to customer", 
point #4, to allow transfer in accordance with ASN Transfers 13.0.

Hope this clarifies.

Regards
Sunny




 
So ... see the attached PDF with the proposal. This is just a draft. As I 
mention in my previous email, the goal is to have some discussions in the list 
and get other folks joining before submitting a proposal ... of course, unless 
there is no discussion in the list and I need to go for the proposal.
 
Regards,
Jordi
@jordipalet
 
 
 
El 3/3/21 13:40, "JORDI PALET MARTINEZ"  escribió:
 
Hi Sunny, all,
 
Some of the topics that you mention, have been already resolved in other 
RIRs, as there were similar issues. In fact, I authored a few policy proposals 
about some of them.
 
In a quick review of your presentation, I see that many of them are really 
easy to resolve. They are not "editorial" in the sense of typos or grammar, but 
inconsistencies among different parts of the policy "manual" and, the most 
important thing, I believe they are non-contentious (so "should not" have 
objections which create lack of consensus, lengthy discussions, etc.). 
 
For example, in a quick look, some of those that I believe aren't 
contentious:
 
0) Overall: Improve definitions, ensure they are in a single section?
1) End-Site vs end-user
2) 5.31, 5.32, 5.3.3 unify?
3) 5.6 and 5.6.1 repetitive, delete last one
4) Utilization vs usage rate
5) Agree with transfers in a single place
6) LIR assignment for their own infras

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

Hi Vivek,

 

I was thinking on that, but not all the policies have an explicit mention to 
the “NIR” or related text, and what is more important, my understanding is that 
a NIR member is also an APNIC member by default, or at least, that’s what I 
understand from:

 

https://www.apnic.net/about-apnic/corporate-documents/documents/membership/nir-membership-agreement/

 

(or I got wrong that document?)

 

If the secretariat believes that we should make it more explicit (I think 
redundant text is not always good, but I’m fine with that), then we could use:

 

5. The ASN could be transferred, instead of returned, in cases such as the 
customer using the ASN becomes an APNIC/NIR member.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/3/21 7:59, "Vivek Nigam"  escribió:

 

Hi Jordy,

 

Yes, this will address the cases I explained in my previous email.

 

Since APNIC has NIRs in our region, you may want to include them in your 
proposed point.

 

Thanks

Vivek

 

From: JORDI PALET MARTINEZ 
Date: Tuesday, 16 March 2021 at 7:08 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document 
Review Report"

 

Hi Vivek,

 

I fully understand that case. It makes a lot of sense that a customer which 
initially got the ASN from the upstream, now becomes a member and then it 
should be transferred. Probably also the IPv4 addresses, but that’s a more 
complex issue.

 

I was thinking in a different case.

1)  An upstream is providing an ASN to a customer.

2)  The customer cancels the contract and don’t ask for the transfer.

3)  The upstream has an ASN not being used (let’s assume that it is not 
used for another customer in more than 6 months or so).

4)  The honest thing in this case, is to return it, not to transfer it 
after 12 months (example). Otherwise, it is a stockpiling.

 

Based on that, I’ve updated the document. Do you thing adding this in 12.4 will 
work?

 

5. The ASN could be transferred, instead of returned, in cases such as the 
customer using the ASN becomes an APNIC member.

 

Otherwise, it is a good starting point for a discussion on this specific topic!

 

Regards,

Jordi

@jordipalet

 

 

 

El 16/3/21 3:33, "Vivek Nigam"  escribió:

 

Hi Jordi,

As per points 3 and 4 in policy clause 12.4. Providing ASN to customer

3. If the customer ceases to receive connectivity from the requesting 
organization it must return the ASN. The requesting organization is expected to 
enter into an agreement with the customer to this effect.

4. Any ASNs returned to the requesting organization must then be returned to 
APNIC or the relevant NIR.

We have had cases where a member has received an ASN on behalf of their 
customer. Subsequently that customer became a member of APNIC and requested to 
transfer that ASN into their APNIC account. We have also had cases where 
members have re-assigned their customer ASNs to new customers after their 
original customer ceased to receive connectivity from them. Subsequently the 
new customer became a member of APNIC and requested to transfer that ASN into 
their APNIC account.

When the policy for customer ASNs was written, the ASN transfer policy did not 
exist. Now that we have a policy for ASN transfers, we would like to have some 
clarity around the transfer of customer ASNs.

Thanks

Vivek

 

From:  on behalf of JORDI PALET MARTINEZ 

Date: Monday, 15 March 2021 at 7:20 pm
To: Srinivas Chendi , sig-policy 
Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document 
Review Report"

 

I meant:

 

in the sense that any non-used resource must be returned “voluntarily” (or 
otherwise reclaimed).

 

Regards,

Jordi

@jordipalet

 

 

 

El 15/3/21 10:17, "JORDI PALET MARTINEZ"  escribió:

 

Hi Sunny, all,

 

I saw your slides, and in fact, that’s what I followed initially for preparing 
my proposal. However, I saw many other points that need resolution, in my 
opinion, as when you touch some of the text, some other text is related to it, 
etc.

 

So, yes, I understand your slide 17, however, the point is still the same … In 
an ideal world, if you don’t need any more any INR (Internet Number Resource), 
which has been provided by the RIR (APNIC in this case), then you just return 
it, so other community members can take advantage of it. However, we know that 
will not happen, and we will need to go into “persecution & reclaim-mode” 
(excluding M&A cases), and this is what triggered the transfer policies. What 
I’m saying is that the apparent contradiction for the ASNs is there also for 
IPv4 resources. We can tidy up a bit the text, but the contradiction is 
“generic” in the sense that any non-used resource must be reclaimed.

 

Let’s talk about this in the community consultation. It is a terrible timing 
for me (national holiday and 5AM) … but I will try to join anyway.

 

By the way, I

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

Tks Vivek, I will update the document to v0.3 with that modification.

 

However, I think it is important to clarify if the nir-membership-agreement is 
still valid, because if that’s the case, a further clarification and 
simplification that can be done *across the entire policy manual* is to remove 
many of the references to NIRs, as they are implicit.

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/3/21 9:54, "Vivek Nigam"  escribió:

 

Hi Jordi,

 

Your proposed text is more consistent with the text in bullet point 4 now.

 

4. Any ASNs returned to the requesting organization must then be returned to 
APNIC or the relevant NIR.

 

Thanks

Vivek

 

From: JORDI PALET MARTINEZ 
Date: Wednesday, 17 March 2021 at 6:36 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document 
Review Report"

 

Hi Vivek,

 

I was thinking on that, but not all the policies have an explicit mention to 
the “NIR” or related text, and what is more important, my understanding is that 
a NIR member is also an APNIC member by default, or at least, that’s what I 
understand from:

 

https://www.apnic.net/about-apnic/corporate-documents/documents/membership/nir-membership-agreement/

 

(or I got wrong that document?)

 

If the secretariat believes that we should make it more explicit (I think 
redundant text is not always good, but I’m fine with that), then we could use:

 

5. The ASN could be transferred, instead of returned, in cases such as the 
customer using the ASN becomes an APNIC/NIR member.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/3/21 7:59, "Vivek Nigam"  escribió:

 

Hi Jordy,

 

Yes, this will address the cases I explained in my previous email.

 

Since APNIC has NIRs in our region, you may want to include them in your 
proposed point.

 

Thanks

Vivek

 

From: JORDI PALET MARTINEZ 
Date: Tuesday, 16 March 2021 at 7:08 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document 
Review Report"

 

Hi Vivek,

 

I fully understand that case. It makes a lot of sense that a customer which 
initially got the ASN from the upstream, now becomes a member and then it 
should be transferred. Probably also the IPv4 addresses, but that’s a more 
complex issue.

 

I was thinking in a different case.

1)  An upstream is providing an ASN to a customer.

2)  The customer cancels the contract and don’t ask for the transfer.

3)  The upstream has an ASN not being used (let’s assume that it is not 
used for another customer in more than 6 months or so).

4)  The honest thing in this case, is to return it, not to transfer it 
after 12 months (example). Otherwise, it is a stockpiling.

 

Based on that, I’ve updated the document. Do you thing adding this in 12.4 will 
work?

 

5. The ASN could be transferred, instead of returned, in cases such as the 
customer using the ASN becomes an APNIC member.

 

Otherwise, it is a good starting point for a discussion on this specific topic!

 

Regards,

Jordi

@jordipalet

 

 

 

El 16/3/21 3:33, "Vivek Nigam"  escribió:

 

Hi Jordi,

As per points 3 and 4 in policy clause 12.4. Providing ASN to customer

3. If the customer ceases to receive connectivity from the requesting 
organization it must return the ASN. The requesting organization is expected to 
enter into an agreement with the customer to this effect.

4. Any ASNs returned to the requesting organization must then be returned to 
APNIC or the relevant NIR.

We have had cases where a member has received an ASN on behalf of their 
customer. Subsequently that customer became a member of APNIC and requested to 
transfer that ASN into their APNIC account. We have also had cases where 
members have re-assigned their customer ASNs to new customers after their 
original customer ceased to receive connectivity from them. Subsequently the 
new customer became a member of APNIC and requested to transfer that ASN into 
their APNIC account.

When the policy for customer ASNs was written, the ASN transfer policy did not 
exist. Now that we have a policy for ASN transfers, we would like to have some 
clarity around the transfer of customer ASNs.

Thanks

Vivek

 

From:  on behalf of JORDI PALET MARTINEZ 

Date: Monday, 15 March 2021 at 7:20 pm
To: Srinivas Chendi , sig-policy 
Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document 
Review Report"

 

I meant:

 

in the sense that any non-used resource must be returned “voluntarily” (or 
otherwise reclaimed).

 

Regards,

Jordi

@jordipalet

 

 

 

El 15/3/21 10:17, "JORDI PALET MARTINEZ"  escribió:

 

Hi Sunny, all,

 

I saw your slides, and in fact, that’s what I followed initially for preparing 
my proposal. However, I saw many other points that need resolution, in my 
opinion, as when you touch some of the text, some othe

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

Hi Anupam,

 

Tks for checking this!

 

For you point 1, you mean shortening such as:

 

Actual:

4. Any ASNs returned to the requesting organization must then be returned to 
APNIC or the relevant NIR.

Proposal:

4. The ASN could be transferred, in cases such as the customer using the ASN 
becomes an APCNI/NIR member. Otherwise must be returned to APNIC or the 
relevant NIR.

Let me know if I understood correclty your point.

 

For your point 2, I don’t think such a problem exists, because if 1 customer is 
using the ASN and becomes an APNIC/NIR member, then customer 2 will never use 
that ASN. Now, if you mean:
Customer 1 uses the ASN.
Customer 1 drops the contract or the use of the ASN.
In theory here, if not transferred it should be returned
Now, if is not returned because immediately customer 2 qualify to use the ASN 
(according to 12.0), then it will start using it.
Even if now customer 1 and 2 want to become members at the same time, the one 
“in use” of the ASN will be customer 2 and “naturally” it seems is the one to 
get it. Customer 1 will need to start a new request, no need for a transfer 
because it cesaed in the use of that ASN (probably he changed to another ISP 
and instead of getting the ASN transferred he opted for a new one). Anyway, 
this is something that is, in my opinion, beyond the scope of this policy 
(12.0) and if falls into 13.0 and the decision of the ISP, which is the 
“current” holder of the ASN.
If customer 2 also ceased to use the ASN, then we are in the same situation as 
b, and in consequence, it should have been returned because it was not 
transferred to customer 2. If “immediately” customer 1 joins again the ISP 
network and qualify for the use of the ASN, then we are back in c.
 

So I think there is no need to have additional text to “resolve” that 
situation. I hope my explanation is clear, but if not, le me know, same if I’m 
missing something from your point.

 

For your point 3., I think it is more comprehensive to city 12.0, because “all” 
is criteria about how to apply, conditions for it, how to handle if the 
customer becomes a member, etc.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/3/21 11:47, "Anupam Agrawal"  escribió:

 

Few Pointers:

 

1. In the suggested text “instead of returned” appears an additional text and 
can be removed. The return scenario is anyways handled in 12.4 Point 4. 

 

2. In a hypothetical scenario, where an ASN has been used by say 2 customers 
and all two customers have become APNIC member, then which customer has the 
right to ASN or it is the last using customer or it is the prerogative of the 
requesting organisation or APNIC. 

 

3. In point 1 of 12.4 the reference is to Section 12.0 Objectively can it be 
made to 12.1?

 

Regards

Anupam 

 



On 17-Mar-2021, at 2:24 PM, Vivek Nigam  wrote:

 

Hi Jordi,

 

Your proposed text is more consistent with the text in bullet point 4 now.

 

4. Any ASNs returned to the requesting organization must then be returned to 
APNIC or the relevant NIR.

 

Thanks

Vivek

 

From: JORDI PALET MARTINEZ 
Date: Wednesday, 17 March 2021 at 6:36 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document 
Review Report"

 

Hi Vivek,

 

I was thinking on that, but not all the policies have an explicit mention to 
the “NIR” or related text, and what is more important, my understanding is that 
a NIR member is also an APNIC member by default, or at least, that’s what I 
understand from:

 

https://www.apnic.net/about-apnic/corporate-documents/documents/membership/nir-membership-agreement/

 

(or I got wrong that document?)

 

If the secretariat believes that we should make it more explicit (I think 
redundant text is not always good, but I’m fine with that), then we could use:

 

5. The ASN could be transferred, instead of returned, in cases such as the 
customer using the ASN becomes an APNIC/NIR member.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/3/21 7:59, "Vivek Nigam"  escribió:

 

Hi Jordy,

 

Yes, this will address the cases I explained in my previous email.

 

Since APNIC has NIRs in our region, you may want to include them in your 
proposed point.

 

Thanks

Vivek

 

From: JORDI PALET MARTINEZ 
Date: Tuesday, 16 March 2021 at 7:08 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document 
Review Report"

 

Hi Vivek,

 

I fully understand that case. It makes a lot of sense that a customer which 
initially got the ASN from the upstream, now becomes a member and then it 
should be transferred. Probably also the IPv4 addresses, but that’s a more 
complex issue.

 

I was thinking in a different case.

1)  An upstream is providing an ASN to a customer.

2)  The customer cancels the contract and don’t ask for the transfer.

3)  The upstream has an ASN not being used (let’s

Re: [sig-policy] Abuse Role Object

[JORDI PALET MARTINEZ]

Hi Aftab, all,

 

In my opinion, the policy text + the explanations/presentation provided by the 
authors + the “additional information” section of the policy proposal, was 
providing the information to avoid this type of issues.

 

Of course, the secretariat could take different implementation approaches, but 
the fact that we worked the details in the “additional information” was 
precisely because we foresee some possible issues and we suggested some 
implementation details to avoid them. I recall I’ve already sent a couple of 
emails to respond to some of those issues after a presentation of George, they 
should be archived. Actually, I think one of those emails that I’ve sent was 
not responded. I was asking there if some of the issues require an update of 
the policy via a new proposal. Could the secretariat take a look and tell us?

 

Trying to summarize:

 
IRT was meant to (optionally) disappear at some point, or be an “alias” of 
abuse-c.
Initially it is expected that the “main” abuse-c is created as a duplicate of 
the existing IRT.
Each organization need to define if they want additional abuse-c for different 
set of resources. For example, you may have a different abuse handling team for 
IPv6 and IPv4, or even for different IPv4 blocks; you may want to have a 
customer-assigned block to be handled by the customer abuse team, etc.
I don’t think Country and Phone should be mandatory, but of course, instead of 
bogus data should be empty, if no data is available. Note that I’m also not 
opposed to have them with mandatory Country and Phone, but the full idea of the 
validation process is to have a “working email” so if the working email being 
validated doesn’t work, the policy escalate to other contacts and those 
contacts, should already have the right country and phones, right?
 

So, I don’t think this specific topic requires a policy update, unless I’m 
missing something?

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/5/21 6:19, "Aftab Siddiqui"  escribió:

 

Hi Everyone,

 

As some of you have already seen the discussion [1] on twitter, started by 
Fakrul.

 

Just sharing the problem here. As part of some of the additional 
request/reference in prop-125 (Validation of “abuse-mailbox” and other IRT 
emails) "APNIC will publish the IRT also as abuse-c, in order to facilitate the 
search in whois, for the same information, regardless if looking for abuse-c or 
IRT. This is done in order to assimilate the IRT to the majority of the RIRs 
where it is abuse-c."

 

APNIC Secretariat implemented this by adding "abuse-c" attribute in the inetnum 
(example below) and inet6num. 

 

inetnum:103.162.142.0 - 103.162.143.255
netname:ISAL-SG
descr:  Internet Society Asia Limited
descr:  3 Temasek Avenue Level 21 Centennial Tower
country:SG
org:ORG-ISAL1-AP
admin-c:ISAL1-AP
tech-c: ISAL1-AP
abuse-c:AI706-AP

 

The abuse-c attribute requires NIC-handle but which NIC-handle? There can be 
many NIC-handle within the organisation but one organisation can only have one 
IRT object. So, APNIC generated a new "role object" using the data from the 
IRT-object. 

 

Now, the problem is that role object has some mandatory field as per APNIC 
whois policy defined here [2], which either doesn't exist (country) or are 
optional (phone) in IRT object i.e.

 

role:  [mandatory]  [single] [lookup key]
address:    [mandatory]  [multiple]   [ ]
country:    [mandatory]  [single] [ ]
phone:  [mandatory]  [multiple]   [ ]
irt:    [mandatory]  [single] [primary/lookup key]
address:    [mandatory]  [multiple]   [ ]
phone:  [optional]   [multiple]   [ ]
fax-no: [optional]   [multiple]   [ ]
When APNIC auto generated the data for this new abuse-c NIC-handle, they filled 
it with bogus data.

 

role:   ABUSE ISALSG
address:3 Temasek Avenue Level 21 Centennial Tower, Singapore Singapore 
039190
country:ZZ
phone:  +0

 

The APNIC Secretariat is seeking suggestions to fix this problem as to how to 
fill up the missing information. 

 

IMO, a simple way would be to make Country (ISO-3166) and Phone number 
mandatory in the IRT object (currently they are optional). This can be done 
during the next IRT validation cycle.

Btw, Country Code in the role object is not a mandatory attribute (it doesn't 
exist) as per RFC2622 [3] but it is as per APNIC whois policy. 

 

[1] - https://twitter.com/rapappu/status/1397522066002247686?s=21

[2] - https://www.apnic.net/manage-ip/using-whois/guide/role/

[3] - https://datatracker.ietf.org/doc/html/rfc2622#section-3.3


Regards,

Aftab A. Siddiqui



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to

Re: [sig-policy] Abuse Role Object

[JORDI PALET MARTINEZ]

This is the email I was referring to:

 

https://mailman.apnic.net/mailing-lists/sig-policy/archive/2020/09/msg4.html

 

There are a couple of emails after this one.

 

I think we need to get clear responses from the secretariat if “anything” 
requires a policy update, or it is just implementation details that they can 
adjust without working out a policy proposal.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/5/21 8:31, "JORDI PALET MARTINEZ"  escribió:

 

Hi Aftab, all,

 

In my opinion, the policy text + the explanations/presentation provided by the 
authors + the “additional information” section of the policy proposal, was 
providing the information to avoid this type of issues.

 

Of course, the secretariat could take different implementation approaches, but 
the fact that we worked the details in the “additional information” was 
precisely because we foresee some possible issues and we suggested some 
implementation details to avoid them. I recall I’ve already sent a couple of 
emails to respond to some of those issues after a presentation of George, they 
should be archived. Actually, I think one of those emails that I’ve sent was 
not responded. I was asking there if some of the issues require an update of 
the policy via a new proposal. Could the secretariat take a look and tell us?

 

Trying to summarize:

 

1)  IRT was meant to (optionally) disappear at some point, or be an “alias” 
of abuse-c.

2)  Initially it is expected that the “main” abuse-c is created as a 
duplicate of the existing IRT.

3)  Each organization need to define if they want additional abuse-c for 
different set of resources. For example, you may have a different abuse 
handling team for IPv6 and IPv4, or even for different IPv4 blocks; you may 
want to have a customer-assigned block to be handled by the customer abuse 
team, etc.

4)  I don’t think Country and Phone should be mandatory, but of course, 
instead of bogus data should be empty, if no data is available. Note that I’m 
also not opposed to have them with mandatory Country and Phone, but the full 
idea of the validation process is to have a “working email” so if the working 
email being validated doesn’t work, the policy escalate to other contacts and 
those contacts, should already have the right country and phones, right?

 

So, I don’t think this specific topic requires a policy update, unless I’m 
missing something?

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/5/21 6:19, "Aftab Siddiqui"  escribió:

 

Hi Everyone,

 

As some of you have already seen the discussion [1] on twitter, started by 
Fakrul.

 

Just sharing the problem here. As part of some of the additional 
request/reference in prop-125 (Validation of “abuse-mailbox” and other IRT 
emails) "APNIC will publish the IRT also as abuse-c, in order to facilitate the 
search in whois, for the same information, regardless if looking for abuse-c or 
IRT. This is done in order to assimilate the IRT to the majority of the RIRs 
where it is abuse-c."

 

APNIC Secretariat implemented this by adding "abuse-c" attribute in the inetnum 
(example below) and inet6num. 

 

inetnum:103.162.142.0 - 103.162.143.255
netname:ISAL-SG
descr:  Internet Society Asia Limited
descr:  3 Temasek Avenue Level 21 Centennial Tower
country:SG
org:ORG-ISAL1-AP
admin-c:ISAL1-AP
tech-c: ISAL1-AP
abuse-c:AI706-AP

 

The abuse-c attribute requires NIC-handle but which NIC-handle? There can be 
many NIC-handle within the organisation but one organisation can only have one 
IRT object. So, APNIC generated a new "role object" using the data from the 
IRT-object. 

 

Now, the problem is that role object has some mandatory field as per APNIC 
whois policy defined here [2], which either doesn't exist (country) or are 
optional (phone) in IRT object i.e.

 

role:  [mandatory]  [single] [lookup key]
address:[mandatory]  [multiple]   [ ]
country:[mandatory]  [single] [ ]
phone:  [mandatory]  [multiple]   [ ]
irt:[mandatory]  [single] [primary/lookup key]
address:[mandatory]  [multiple]   [ ]
phone:  [optional]   [multiple]   [ ]
fax-no: [optional]   [multiple]   [ ]
When APNIC auto generated the data for this new abuse-c NIC-handle, they filled 
it with bogus data.

 

role:   ABUSE ISALSG
address:3 Temasek Avenue Level 21 Centennial Tower, Singapore Singapore 
039190
country:ZZ
phone:  +0

 

The APNIC Secretariat is seeking suggestions to fix this problem as to how to 
fill up the missing information. 

 

IMO, a simple way would be to make Country (ISO-3166) and Phone number 
mandatory in the IRT object (currently they are optional). This can be done 
during the next IRT validation cycle.

Btw, Country Code in the role object is not a mandatory attribute 

Re: [sig-policy] New Proposal prop-139-v001: SOR not required

[JORDI PALET MARTINEZ]

Hi Satoru,

 

I’m not sure to understand your comments.

 

If the exising SOR is not being use, it means that removing it will not make a 
significant difference, right? So we’re not making allocations easier, we are 
just trusting that if the SOR is not being used, we should adapt the policy to 
existing reality.

 

In any case, if a LIR come back for more resources, and has been assigning 
addresses to customers without a good justification, they will need to justifiy 
that during the APNIC review.

 

We shall also remember that we have no more IPv4 addresses, so will not make a 
big difference.

 

In the case of IPv6, normally a houshold will not get more than /48. A business 
will probably will get a /48, and if they are smart enough, they will avoid 
renumbering getting a provider independent assigment directly from APNIC, so if 
they instead require a /47, for example, that will be part of the justification 
already.

 

So, in summary, I really think there are not chances to abuse of the policy 
with the proposed change, and instead we have a simplification of procedures 
for both, members and secretariat.

 

Regards,

Jordi

@jordipalet

 

 

 

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.

I would like to share key feedback in our community for prop-139,
based on a meeting we organised on 25th Aug to discuss these proposals.

Many neutral opinions were expressed about this proposal in view of the fact 
that the impact of this proposal should be examined in more depth.

(comment details)
 - Isn't there a possibility that some kind of loophole or allocation 
   against the purpose may occur by making allocation easier?
 - Although disorderly allocation will become possible, the total 
   number of IPv4 owned by each organization will not change, 
   so it should be operated at the discretion of ISPs.


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2021年8月13日(金) 8:58 Bertrand Cherrier :

Dear SIG members,

The proposal "prop-139-v001: SOR not required" has been sent to
the Policy SIG for review.

It will be presented at the Open Policy Meeting (OPM) at APNIC 52
on Thursday, 16 September 2021.

https://conference.apnic.net/52/program/schedule/#/day/4

We invite you to review and comment on the proposal on the mailing
list before the OPM.

The comment period on the mailing list before the OPM is an important
part of the Policy Development Process (PDP). 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 appended below and also available at:

http://www.apnic.net/policy/proposals/prop-139

Regards,
Bertrand and Ching-Heng
APNIC Policy SIG Chairs


---

prop-139-v001: SOR not required

---

Proposer: Jordi Palet Martínez (jordi.pa...@theipv6company.com)


1. Problem statement

Section 5.2.1 enforces a SOR (Second Opinion Request) process, which is 
rarely used.

It was meant for ensuring that resources aren’t wasted being allocated 
unnecessarily, however, this is already the job of the LIRs, and they 
may be audited at any point, even if this policy doesn’t exist.

Further to that, doesn’t make sense that this is being done for 
exhausted IPv4 resources, while it has been already avoided for IPv6.

2. Objective of policy change
-
Avoiding an unnecessary and rarely used process.


3. Situation in other regions
-
Other RIRs don’t have this process or it is optional/not used.


4. Proposed policy solution
---
Actual text:
5.0. Resource Management
...
Also, NIRs must, wherever possible, apply slow start, assignment window, 
and second opinion policies to their own members in a manner consistent 
with the way APNIC applies such policies.
...

5.2.1. Assignment window for LIRs
APNIC and NIRs shall apply an assignment window mechanism to help LIRs 
understand and comply with APNIC policies and the address management goals.
The assignment window indicates the maximum number of addresses an LIR 
may delegate to an end-user without first seeking a "second opinion". If 
an LIR wishes to make a delegation that exceeds its delegation window, 
the LIR must first submit a second opinion request.
LIRs start with a delegation window of zero, meaning all proposed 
delegations must first be approved.
APNIC, or the relevant NIR, will regularly assess the proficiency of LIR 
staff in making delegations and seeking second opinions and will review 
the size of the assignment window accordingly. A

Re: [sig-policy] New Proposal prop-140-v001: Update End-Site Definition

[JORDI PALET MARTINEZ]

Hi again …

 

When I wrote this proposal, I was looking for all the uses of the complete 
policy manual for end-user, end-site, etc. And I was sure that I didn’t miss 
anything. So, could you point to what specific sections in the policy manual 
I’ve missed, so I can see if a new version can fix that?

 

Regarding the other comment, I’ve not used, and is not used in the policy 
manual, any term related to “payment”. On the other way around,  since a few 
years ago, we already included “who has a business or legal relationship (same 
or associated entities)” to ensure that we are covering situations where you 
have “any kind of partner”, be it a business, a “sister organization”, etc., 
without restricting the relationship to a “business paid customer”. So, I think 
that’s was already resolved and this proposal is not changing that.

 

Regards,

Jordi

@jordipalet

 

 

 

ear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-140,
based on a meeting we organised on 25th Aug to discuss these proposals.

In addition to "end site" and “end-user," "customer" is scattered throughout 
the policy document. An opinion was expressed that it is necessary to organize 
the overall consistency.

(comment details)
 - The revisions in the current proposal seems not to be sufficient. 
   There seems to be a mixture of "end user" as a general term and 
   "end user" as defined in 2.10.
 - Isn't the concept of "customer" who "pays" for the numbered resources 
   inappropriate for the policy? Partners who are not customers should 
   also be treated as customers.


Regards,

Satoru Tsurumaki / JPOPF Steering Team  

2021年8月13日(金) 8:59 Bertrand Cherrier :

Dear SIG members,

The proposal "prop-140-v001: Update End-Site Definition" has been
sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting (OPM) at APNIC 52
on Thursday, 16 September 2021.

https://conference.apnic.net/52/program/schedule/#/day/4

We invite you to review and comment on the proposal on the mailing
list before the OPM.

The comment period on the mailing list before the OPM is an important
part of the Policy Development Process (PDP). 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 appended below and also available at:

http://www.apnic.net/policy/proposals/prop-140

Regards,
Bertrand and Ching-Heng
APNIC Policy SIG Chairs


---

prop-140-v001: Update End-Site Definition

---

Proposer: Jordi Palet Martínez (jordi.pa...@theipv6company.com)


1. Problem statement

Section 2.9 was introduced with an IPv4 mind-set and doesn’t fully 
accommodate IPv6 deployments and members that may have multiple sites in 
case of assignments.

Even if this text has evolved in several RIRs, the previous changes were 
imperfect, and thru this evolution in other RIRs, it was obvious that we 
missed some aspects such as “multiple locations” being different than 
“end-sites”.

Further to that, sometimes it becomes confusing the fact that there is 
not a formal definition of end-user.

Finally, 10.1.4.1. is slightly updated, just to make sure that 
assignments are considered per end-site, not member.

Note that those changes are basically editorial clarifications because 
do not imply actual changes on what policies already allow.



2. Objective of policy change
-
Ensuring that both end-site and end-user are defined in a more accurate 
way.


3. Situation in other regions
-
Other RIRs already updated the policies on this regard.


4. Proposed policy solution
---
Actual text:
2.9. End site
An end site is defined as an end-user (subscriber) who has a business 
relationship with a service provider that involves:
• that service provider assigning address space to the end-user
• that service provider providing transit service for the end-user to 
other sites
• that service provider carrying the end-user's traffic
• that service provider advertising an aggregate prefix route that 
contains the end-user's assignment


10.1.4.1. Initial assignment
…
The minimum size of the assignment is a /48. The considerations of 
Section 5.2.4.3 "Assignment of multiple /48s to a single end site" must 
be followed if multiple /48s are requested. "APNIC guidelines for IPv6 
allocation and assignment requests".

Proposed text:
2.9. End-site
An End-Site is defined as the location of an End-User who has a

Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 allocation"

[JORDI PALET MARTINEZ]

Hi all,

See my comments below in-line as [Jordi].

Regards,
Jordi
 

-Mensaje original-
De:  en nombre de Satoru Tsurumaki 

Responder a: 
Fecha: viernes, 8 de septiembre de 2017, 14:34
Para: SIG policy 
Asunto: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"

Dear Colleagues,


I am Satoru Tsurumaki from Policy Working Group in Japan.

I would like to share key feedback in our community for prop-121,
based on a meeting we organised on 5th Sep to discuss these proposals.


Many opposing comments were expressed on the proposal with reasons below.

* Under the current criteria, networks with IPv4 can receive IPv6
easily. However, with adoption of this proposal, this consideration
based on IPv4 network will be removed, and the policy could become
more strict for some applications.

[Jordi]I think is in the other way around. With the proposal, I’m removing 
the requirement for “at least 200 customers” (there may be ISPs that have much 
less number of customers than that) and “be an existing LIR with IPv4 
allocations”. There is not more IPv4 space, is not realistic to have such 
requirement, furthermore, in the short term, I’m sure, there will be IPv6-only 
ISPs, so again not reason for asking them to have IPv4 allocations.

* Would like to confirm how specifically APNIC secretariat will
evaluate requests under this policy. The criteria becomes ambiguous
with this proposal which would make it harder for applications to
prepare for the evaluation.

[Jordi]This has been running with the same text in RIPE region, and has not 
been considered as an issue by the staff, so I guess here we can take the 
advantage of that experience.

* Approach may not be the right one to achieve the objective of IPv6 
promotion

[Jordi]I think in the other way around, it facilitates the IPv6 promotion, 
as it doesn’t require to be a “big” ISP (200 customers) neither to have been an 
IPv4 one before.

* From the current IPv6 allocation criteria, it is unlikely to have
many cases where criteria. d is being the barrier to receive IPv6
space.

[Jordi]Not sure what is criteria d. ? If you mean criteria 4 as in 
https://www.apnic.net/community/policy/resources#Part-3:-IPv6-Policy (9.2.2. 
4), I think I’ve responded to that already with my previous responses?

Best Regards,

Satoru Tsurumaki
Policy Working Group
Japan Open Policy Forum

2017-08-09 15:19 GMT+09:00 chku :
> Dear SIG members
>
> The proposal "prop-121: Updating “Initial IPv6 allocation” policy" has
> been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 44 which will
> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 September
> 2017.
>
> 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-121
>
> Regards
>
> Sumon, Ching-Heng, Bertrand
> APNIC Policy SIG Chairs
>
>
> 
>
> prop-121-v001: Updating “Initial IPv6 allocation” policy
>
> 
>
> Proposer:   Jordi Palet Martinez
> jordi.pa...@consulintel.es
>
> Problem Statement
> -
>
> The actual policy text (9.2.2. Account holders without existing IPv4
> space) is assuming that an LIR will have more than 200 customers over a
> period of 2 years, or it is already an IPv4 LIR.
>
> However, it is a perfectly valid possibility to have small LIRs, which
> may be never will have 200 customers, for example they may have a dozen
> of big enterprise customers, or they may be a new LIR, not having any
> IPv4 addresses (we all know the run-out problem) or may choose to use a
> limited number of IPv4 addresses from their upstream providers, 

Re: [sig-policy] New proposal prop-122-v001: Updating "Subsequent IPv6 allocation " policy

[JORDI PALET MARTINEZ]

So, here the inputs I’ve provided for 121 are exactly the same …

Regards,
Jordi
 

-Mensaje original-
De:  en nombre de Satoru Tsurumaki 

Responder a: 
Fecha: viernes, 8 de septiembre de 2017, 14:34
Para: SIG policy 
Asunto: Re: [sig-policy] New proposal prop-122-v001: Updating "Subsequent IPv6 
allocation " policy

Dear Colleagues,


I am Satoru Tsurumaki from Policy Working Group in Japan.

I would like to share key feedback in our community for prop-122,
based on a meeting we organised on 5th Sep to discuss these proposals.


Many opposing comments were expressed with the same reasons as for prop-121.

* Under the current criteria, networks with IPv4 can receive IPv6
easily. However, with adoption of this proposal, this consideration
based on IPv4 network will be removed, and the policy could become
more strict for some applications.

* Would like to confirm how specifically APNIC secretariat will
evaluate requests under this policy. The criteria becomes ambiguous
with this proposal which would make it harder for applications to
prepare for the evaluation.

* Approach may not be the right one to achieve the objective of IPv6 
promotion

* From the current IPv6 allocation criteria, it is unlikely to have
many cases where criteria. d is being the barrier to receive IPv6
space.


Best Regards,

Satoru Tsurumaki
Policy Working Group
Japan Open Policy Forum

2017-08-09 15:20 GMT+09:00 chku :
> Dear SIG members
>
> The proposal "prop-122-v001: Updating "Subsequent IPv6 allocation"
> policy. " has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 44 which will
> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 September
> 2017.
>
> 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-122
>
> Regards
>
> Sumon, Ching-Heng, Bertrand
> APNIC Policy SIG Chairs
>
>
> 
>
> prop-122-v001: Updating “Subsequent IPv6 allocation” policy
>
> 
>
> Proposer:   Jordi Palet Martinez
> jordi.pa...@consulintel.es
>
> Problem Statement
> -
> If we reach consensus on the Updating "Initial IPv6 allocation"
> policy, it is necessary to align the text of the subsequent allocations,
> in order to be coherent and not discriminate LIRs with existing
> allocations.
>
> If consensus on that policy proposal is not reached, this proposal also
> allows LIRs with existing allocations a better justification of their
> new needs and not limited to a 2 years period.
>
> The actual policy text (9.3.4. Size of subsequent allocation) is
> assuming that an LIR will need just doubling his actual block, and then
> states the possibility of more space providing the relevant
> documentation. However, it is limiting that to a two-years period.
>
>
> Objective of policy change
> --
> To make sure that the subsequent IPv6 allocation policy is synchronized
> with the initial allocation one.
>
>
> Situation in other regions
> --
> Both RIPE and LACNIC have approved equivalent changes.
>
>
> Proposed policy solution
> 
> Change some of the actual text as follows.
>
>
> Actual text:
>
> 9.3.4. Size of subsequent allocation
>
> When an organization has achieved an acceptable utilization for its
> allocated address space, it is immediately eligible to obtain an
> additional allocation that results in a doubling 

Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 allocation"

[JORDI PALET MARTINEZ]

Hi Hiroki,

I just read again all the text of the actual policy, just to make sure I didn’t 
forget anything.

Unless I’m missing something, according to that, the HD-ratio is only checked 
for subsequent allocations, so it has no effect on the initial IPv6 allocations.

Regards,
Jordi
 

-Mensaje original-
De:  en nombre de Hiroki Kawabata 

Responder a: 
Fecha: domingo, 10 de septiembre de 2017, 16:23
Para: sig-policy 
Asunto: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"

Dear Jordi,

We support these proposals(prop-121 and 122) in general but we have one 
comment.

Now, when hostmaster evaluate the request bigger than the minimun 
allocation size,
they detemin the allocated size based on the HD-Ratio.
HD-Ratio is clearly written in the policy document.
In the case of your policy proposal, it seems that it is not clear and
it is difficult for hostmaster to objectively evaluate the allocation size.

Regards,
Hiroki

---
Hiroki Kawabata(kawab...@nic.ad.jp)
Hostmaster, IP Address Department
Japan Network Information Center(JPNIC)


Subject: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"
From: chku 
Date: Wed Aug 09 2017 15:19:00 GMT+0900

> Dear SIG members
> 
> The proposal "prop-121: Updating “Initial IPv6 allocation” policy" has
> been sent to the Policy SIG for review.
> 
> It will be presented at the Open Policy Meeting at APNIC 44 which will
> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 September
> 2017.
> 
> 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-121
> 
> Regards
> 
> Sumon, Ching-Heng, Bertrand
> APNIC Policy SIG Chairs
> 
> 
> 
> 
> prop-121-v001: Updating “Initial IPv6 allocation” policy
> 
> 
> 
> Proposer:   Jordi Palet Martinez
>  jordi.pa...@consulintel.es
> 
> Problem Statement
> -
> 
> The actual policy text (9.2.2. Account holders without existing IPv4
> space) is assuming that an LIR will have more than 200 customers over a
> period of 2 years, or it is already an IPv4 LIR.
> 
> However, it is a perfectly valid possibility to have small LIRs, which
> may be never will have 200 customers, for example they may have a dozen
> of big enterprise customers, or they may be a new LIR, not having any
> IPv4 addresses (we all know the run-out problem) or may choose to use a
> limited number of IPv4 addresses from their upstream providers, because
> they don’t intend to provide IPv4 services.
> 
> It is also possible that the LIR is planning for a longer term than just
> 2 years, for example a government with a national network which may take
> a longer period to deploy, connecting all kind of institutions at
> different levels (ministries, schools, health centres, municipalities,
> other public institutions, etc.).
> 
> 
> Objective of policy change
> --
> 
> To make sure that the policy is aligned with a wider set of possible
> IPv6 deployment cases, including those indicated in the previous section
> and facilitate the justification of the allocation/assignment size if a
> bigger address block (versus the default one) is requested.
> 
> 
> Situation in other regions
> --
> This situation, concretely in the case of big initial IPv6 allocations
> to governments, has already occurred in RIPE, and the policy was updated
> to be able to make those allocations. In some cases, a few governments
> got delayed their deployments sever

Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 allocation"

[JORDI PALET MARTINEZ]

ng we organised on 5th Sep to discuss these 
proposals.
> > >  Many opposing comments were expressed on the proposal 
with reasons below.
> >  * Under the current criteria, networks with IPv4 can receive 
IPv6
>  easily. However, with adoption of this proposal, this consideration
>  based on IPv4 network will be removed, and the policy could become
>  more strict for some applications.
> >  * Would like to confirm how specifically APNIC secretariat will
>  evaluate requests under this policy. The criteria becomes ambiguous
>  with this proposal which would make it harder for applications to
>  prepare for the evaluation.
> >  * Approach may not be the right one to achieve the objective 
of IPv6
>  promotion
> >  * From the current IPv6 allocation criteria, it is unlikely to 
have
>  many cases where criteria. d is being the barrier to receive IPv6
>  space.
> > >  Best Regards,
> >  Satoru Tsurumaki
>  Policy Working Group
>  Japan Open Policy Forum
> >  2017-08-09 15:19 GMT+09:00 chku :
>  > Dear SIG members
>  >
>  > The proposal "prop-121: Updating “Initial IPv6 allocation” policy" 
has
>  > been sent to the Policy SIG for review.
>  >
>  > It will be presented at the Open Policy Meeting at APNIC 44 which 
will
>  > be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 
September
>  > 2017.
>  >
>  > 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-121
>  >
>  > Regards
>  >
    >  > Sumon, Ching-Heng, Bertrand
>  > APNIC Policy SIG Chairs
>  >
>  >
>  > 

>  >
>  > prop-121-v001: Updating “Initial IPv6 allocation” policy
>  >
>  > 

>  >
>  > Proposer:   Jordi Palet Martinez
>  > jordi.pa...@consulintel.es
>  >
>  > Problem Statement
>  > -
>  >
>  > The actual policy text (9.2.2. Account holders without existing 
IPv4
>  > space) is assuming that an LIR will have more than 200 customers 
over a
>  > period of 2 years, or it is already an IPv4 LIR.
>  >
>  > However, it is a perfectly valid possibility to have small LIRs, 
which
>  > may be never will have 200 customers, for example they may have a 
dozen
>  > of big enterprise customers, or they may be a new LIR, not having 
any
>  > IPv4 addresses (we all know the run-out problem) or may choose to 
use a
>  > limited number of IPv4 addresses from their upstream providers, 
because
>  > they don’t intend to provide IPv4 services.
>  >
>  > It is also possible that the LIR is planning for a longer term 
than just
>  > 2 years, for example a government with a national network which 
may take
>  > a longer period to deploy, connecting all kind of institutions at
>  > different levels (ministries, schools, health centres, 
municipalities,
>  > other public institutions, etc.).
>  >
>  >
>  > Objective of policy change
>  > --
>  >
>  > To make sure that the policy is aligned with a wider set of 
p

Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 allocation"

[JORDI PALET MARTINEZ]

Hi Satoru,

To make it short. You said:

“We support the motivation of the proposal. However, there were some
who felt that this policy could make it more difficult as unintended
consequence.

The biggest concern is that for those networks based on IPv4, you are
able to receive an equivalent IPv6 space, based on the size of your
IPv4 holding. If you remove this criteria, there is no assurance to be
able to receive equivalent IPv6.

On this criteria, we can support if the proposal maintains evaluation
based on current IPv4 holding and make it an OR condition for those
who do not want to apply based on IPv4 holding.”

My interpretation of my proposal, is that I’m not changing that. I only change 
the allocation size *in case* you request something bigger. But I’m happy to 
“tune” the text to make it clear if needed.

Regards,
Jordi
 

-Mensaje original-
De: Satoru Tsurumaki 
Responder a: 
Fecha: jueves, 14 de septiembre de 2017, 8:54
Para: 
CC: SIG policy 
Asunto: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"

Hi Jordi,

Thank you for your response.



2017-09-09 12:40 GMT+08:00 JORDI PALET MARTINEZ 
:
> Hi all,
>
> See my comments below in-line as [Jordi].
>
> Regards,
> Jordi
>
>
> -Mensaje original-
> De:  en nombre de Satoru Tsurumaki 

> Responder a: 
> Fecha: viernes, 8 de septiembre de 2017, 14:34
> Para: SIG policy 
> Asunto: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"
>
> Dear Colleagues,
>
>
> I am Satoru Tsurumaki from Policy Working Group in Japan.
>
> I would like to share key feedback in our community for prop-121,
> based on a meeting we organised on 5th Sep to discuss these proposals.
>
>
> Many opposing comments were expressed on the proposal with reasons 
below.
>
> * Under the current criteria, networks with IPv4 can receive IPv6
> easily. However, with adoption of this proposal, this consideration
> based on IPv4 network will be removed, and the policy could become
> more strict for some applications.
>
> [Jordi]I think is in the other way around. With the proposal, I’m 
removing the requirement for “at least 200 customers” (there may be ISPs that 
have much less number of customers than that) and “be an existing LIR with IPv4 
allocations”. There is not more IPv4 space, is not realistic to have such 
requirement, furthermore, in the short term, I’m sure, there will be IPv6-only 
ISPs, so again not reason for asking them to have IPv4 allocations.


We support the motivation of the proposal. However, there were some
who felt that this policy could make it more difficult as unintended
consequence.

The biggest concern is that for those networks based on IPv4, you are
able to receive an equivalent IPv6 space, based on the size of your
IPv4 holding. If you remove this criteria, there is no assurance to be
able to receive equivalent IPv6.

On this criteria, we can support if the proposal maintains evaluation
based on current IPv4 holding and make it an OR condition for those
who do not want to apply based on IPv4 holding.


>
> * Would like to confirm how specifically APNIC secretariat will
> evaluate requests under this policy. The criteria becomes ambiguous
> with this proposal which would make it harder for applications to
> prepare for the evaluation.
>
> [Jordi]This has been running with the same text in RIPE region, and 
has not been considered as an issue by the staff, so I guess here we can take 
the advantage of that experience.
>
> * Approach may not be the right one to achieve the objective of IPv6 
promotion
>
> [Jordi]I think in the other way around, it facilitates the IPv6 
promotion, as it doesn’t require to be a “big” ISP (200 customers) neither to 
have been an IPv4 one before.
>
> * From the current IPv6 allocation criteria, it is unlikely to have
> many cases where criteria. d is being the barrier to receive IPv6
> space.
>
> [Jordi]Not sure what is criteria d. ? If you mean criteria 4 as in 
https://www.apnic.net/community/policy/resources#Part-3:-IPv6-Policy (9.2.2. 
4), I think I’ve responded to that already with my previous responses?
>
> Best Regards,
>
> Satoru Tsurumaki
> Policy Working Group
> Japan Open Policy Forum
>
> 2017-08-09 15:19 GMT+09:00 chku :
> > Dear SIG members
> >
> > The proposal "prop-121: Updating “Initial IPv6 allocation”

Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 allocation"

[JORDI PALET MARTINEZ]

Reading thru the policy again, just in case I’m missing anything.

If you look at 9.1, as I’m not changing that, it looks to me that the case for 
existing IPv4 holders, that need something bigger than /32, either using 
justification 1 or 2, but also if you see my proposal:

“The allocation size, in case an address block bigger than the default
one (as indicated in 9.2.1.) is requested, will be based on the number
of users, the extent of the organisation's infrastructure, the
hierarchical and geographical structuring of the organisation, the
segmentation of infrastructure for security and the planned longevity of
the allocation.”

It means that all the criteria I’m setting there, will be valid to justify your 
needs.

I guest hostmasters can confirm if that’s their interpretation as well?

Regards,
Jordi
 

-Mensaje original-
De:  en nombre de JORDI PALET MARTINEZ 

Responder a: 
Fecha: jueves, 14 de septiembre de 2017, 9:00
Para: SIG policy 
Asunto: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"

Hi Satoru,

To make it short. You said:

“We support the motivation of the proposal. However, there were some
who felt that this policy could make it more difficult as unintended
consequence.

The biggest concern is that for those networks based on IPv4, you are
able to receive an equivalent IPv6 space, based on the size of your
IPv4 holding. If you remove this criteria, there is no assurance to be
able to receive equivalent IPv6.

On this criteria, we can support if the proposal maintains evaluation
based on current IPv4 holding and make it an OR condition for those
who do not want to apply based on IPv4 holding.”

My interpretation of my proposal, is that I’m not changing that. I only 
change the allocation size *in case* you request something bigger. But I’m 
happy to “tune” the text to make it clear if needed.

Regards,
Jordi
 

-Mensaje original-
De: Satoru Tsurumaki 
Responder a: 
Fecha: jueves, 14 de septiembre de 2017, 8:54
Para: 
CC: SIG policy 
Asunto: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"

Hi Jordi,

Thank you for your response.



2017-09-09 12:40 GMT+08:00 JORDI PALET MARTINEZ 
:
> Hi all,
>
> See my comments below in-line as [Jordi].
>
> Regards,
> Jordi
>
>
> -Mensaje original-
> De:  en nombre de Satoru 
Tsurumaki 
> Responder a: 
> Fecha: viernes, 8 de septiembre de 2017, 14:34
> Para: SIG policy 
> Asunto: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"
>
> Dear Colleagues,
>
>
> I am Satoru Tsurumaki from Policy Working Group in Japan.
>
> I would like to share key feedback in our community for prop-121,
> based on a meeting we organised on 5th Sep to discuss these 
proposals.
>
>
> Many opposing comments were expressed on the proposal with 
reasons below.
>
> * Under the current criteria, networks with IPv4 can receive IPv6
> easily. However, with adoption of this proposal, this 
consideration
> based on IPv4 network will be removed, and the policy could become
> more strict for some applications.
>
> [Jordi]I think is in the other way around. With the proposal, I’m 
removing the requirement for “at least 200 customers” (there may be ISPs that 
have much less number of customers than that) and “be an existing LIR with IPv4 
allocations”. There is not more IPv4 space, is not realistic to have such 
requirement, furthermore, in the short term, I’m sure, there will be IPv6-only 
ISPs, so again not reason for asking them to have IPv4 allocations.


We support the motivation of the proposal. However, there were some
who felt that this policy could make it more difficult as unintended
consequence.

The biggest concern is that for those networks based on IPv4, you are
able to receive an equivalent IPv6 space, based on the size of your
IPv4 holding. If you remove this criteria, there is no assurance to be
able to receive equivalent IPv6.

On this criteria, we can support if the proposal maintains evaluation
based on current IPv4 holding and make it an OR condition for those
who do not want to apply based on IPv4 holding.


>
> * Would like to confirm how specifically APNIC secretariat will
> evaluate requests under this p

[sig-policy] Re: Final Comment Period for prop-142: Unify Transfer Policies Text

[JORDI PALET MARTINEZ via sig-policy]

Hi Koki, all,

Let me clarify it.

The actual policy for IPv4 transfers has this text at the end of 8.0:
"APNIC will maintain a public log of all transfers made under this policy."

The rest of the transfers (actual policy), is silent about that, so even if 
APNIC could also include those transfers into the log, it is not "enforced" to 
do that.

Our proposal is taking *exactly the same* text ("APNIC will maintain a public 
log of all transfers.") but into the new combined section 5, which apply to all 
the transfers.

So, the proposal is NOT enforcing the NIRs to do that publication, they could 
voluntarily, but probably, having a single "centralized" web page with the 
publication of all the transfers is easier to maintain. To be honest, it 
probably depends on if already the NIRs have that web page for actual IPv4 
transfers, maybe you can confirm if that's the case?

Tks!
 
 
Regards,
Jordi
@jordipalet
 
 

El 4/3/22 7:54, "Koki Nakagawa"  escribió:

Thank you Ching-Heng,

I want to confirm about prop-142.
This propsal aquire to publish transfer log about all type of it.
In this change, NIRs also need to publish transfer log  as same as APNIC's 
one isn't it?
(Of course, it depends on the status of each NIR's transfer policy 
implementation.)

If I have a misunderstanding, plz indicate it.

Regards,

Koki Nakagawa/JPNIC

On 2022/03/04 10:34, chku wrote:
> Dear colleagues,
> 
> Version 1 of prop-142: Unify Transfer Policies Text, reached consensus at 
the APNIC 53
> Open Policy Meeting and later at the APNIC General Meeting (AGM).
> 
> This proposal will now move to the next step in the APNIC Policy 
Development Process
> and is being returned to the Policy SIG mailing list for the final 
Comment Period.
> 
> - Deadline for comments:  23:59 (UTC +10) Sunday, 03 April 2022.
> 
> Proposal details, including the full text of the proposal, history, and 
links to previous
> versions are available at:
> 
> https://www.apnic.net/community/policy/proposals/prop-142
> 
> Regards,
> Bertrand, Ching-Heng, Shaila
> Policy SIG Chairs
> 
> ___
> sig-policy - sig-policy@lists.apnic.net https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
___
sig-policy - sig-policy@lists.apnic.net https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.



___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Sunny, all,

 

In my opinion because the policy is just a clarification of a fact, it doesn’t 
change the situation for non-LIR/ISP account holders. Further to that, direct 
assignments from APNIC can’t be further sub-assigned, so clearly this disallows 
any type of “business” with addresses for those account holders. Do you think 
that’s sufficiently clear or do you think a small text clarification in the 
proposal is needed?

 

Regarding your 2nd point, there is not already a generic contact email to let 
know APNIC if anything is wrong regarding policy compliance? It will be 
surprising that today anyone discovers some breach and can’t report it, so this 
will also apply the same to this proposal. Again, if you believe a text 
clarification is needed, we can make a new version for that.

 

Finally, regarding your 3rd question, in my understanding the policy manual 
apply to *all the resources* unless we state otherwise. So not only those after 
being implemented are subjected to this proposal. And once more, the proposal 
is only a clarification, not changing what is the current reality. Anyway, we 
are happy to state it more clearly if needed.

 

Tks!

 

Regards,

Jordi

@jordipalet

 

 

El 22/8/22, 2:45, "Srinivas (Sunny) Chendi"  escribió:

 

Hi all, 

This is the secretariat's impact assessment for prop-148-v001, which is also 
available on the proposal page.

http://www.apnic.net/policy/proposals/prop-148

APNIC notes that this proposal suggests explicitly stating in the APNIC 
Internet Number Resources policy document that leasing of IP addresses is 
not permitted in the APNIC region.

Clarifications:

Is this proposal restricted to LIRs/ISPs, or does it apply to all APNIC 
account holders?

The proposal does not specify how an APNIC investigation should be initiated. 
Should there be a form to report this, similar to IRT escalation?

Does this proposal apply to all existing allocations or only those delegated 
after the policy is implemented?

Implementation:

This proposal may require changes to the system.

If this proposal reaches consensus, implementation may be completed within 
3 months.

Regards,
Sunny
APNIC Secretariat

On 11/08/2022 5:01 pm, chku wrote:
Dear SIG members,
 
The proposal "prop-148: Leasing of Resources is not Acceptable" has been 
sent to the Policy SIG for review.
 
It will be presented at the Open Policy Meeting (OPM) at APNIC 54 on 
Thursday, 15 September 2022.
 
    https://conference.apnic.net/54/program/schedule/#/day/8
 
We invite you to review and comment on the proposal on the mailing list 
before the OPM.
 
The comment period on the mailing list before the OPM is an important 
part of the Policy Development Process (PDP). 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 appended below as well as available at:
 
    http://www.apnic.net/policy/proposals/prop-148
 
Regards,
Bertrand, Shaila, and Ching-Heng
APNIC Policy SIG Chairs
 
---
 
prop-148-v001: Leasing of Resources is not Acceptable
 
----
 
Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
  Amrita Choudhury (amritachoudh...@ccaoi.in)
  Fernando Frediani (fhfred...@gmail.com)
 
 
1. Problem statement

RIRs have been conceived to manage, allocate and assign resources according to 
need, in such way that a LIR/ISP has addresses to be able to directly connect 
its customers based on justified need. Addresses are not, therefore, a property 
with which to trade or do business.
 
When the justification of the need disappears or changes, for whatever reasons, 
the expected thing would be to return said addresses to the RIR, otherwise 
according to Section 4.1. (“The original basis of the delegation remains 
valid”) and 4.1.2. (“Made for a specific purpose that no longer exists, or 
based on information that is later found to be false or incomplete”) of the 
policy manual, APNIC is not enforced to renew the license. An alternative is to 
transfer these resources using the appropriate transfer policy.
 
If the leasing of addresses is authorized, contrary to the original spirit of 
the policies and the very existence of the RIRs, the link between connectivity 
and addresses disappears, which also poses security problems, since, in the 
absence of connectivity, the resource holder who has received the license to 
use the addresses does not have immediate physical control to manage/filter 
them, which can cause damag

[sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Mike,

 

 

 

 

 

 

In at least, LACNIC and AFRINIC, it has been made clear by staff, that leasing 
is not a valid justification for getting resources, *THE SAME as in APNIC*, so 
if you use that as a justification, the request is denied. If you change the 
“usage” after the request is passed, then you’re bypassing the original 
justification, which is also *disallowed*.

 

I will let the secretariat to confirm if leasing is allowed or not, actually 
responding to your points on APNIC policies, even if this policy doesn't reach 
consensus. However, in my opinion the policy manual must be clear enough so 
nobody can interpret that something is not allowed when actually is not.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/8/22, 12:17, "Mike Burns"  escribió:

 

There are a number of problems with this policy.

 

First let’s start with Jordi stating the policy is just a clarification of fact.

If so, why is it necessary? Actually it is not a fact as leasing is occurring 
in APNIC and there is nothing in policy preventing it.  So this needs to be 
considered as a change in policy.

 

Second, there are inaccuracies in the verbiage associated with the policy, 
particularly in reference to the status of leasing at other RIRs.  How can you 
make the statement “ In other RIRs, the leasing of addresses is not authorized 
either and since it is not explicit in their policy manuals…”?

 

Are you unilaterally deciding that things which are not mentioned in policy are 
by definition “unauthorized”? I think this is wrong, and it’s better to 
consider things as authorized unless they are forbidden by policy.  However, 
either way there is no language in any RIR regarding leasing and you can’t make 
assumptions based on your own feelings. 

 

You are also wrong in stating that “Nothing is currently mentioned in RIPE 
about this and it is not acceptable as a justification of the need.” In actual 
fact, RIPE will accept leased-out addresses as justification of need in the 
only case where RIPE actually has a needs test, and that is with inter-regional 
transfers sourced in ARIN.  It bears remembering that RIPE simply has no needs 
test for transfers and this has been the policy for many years.  You may wonder 
what the point of a needs-test for transfers is, since the recipients are 
paying for the addresses.

 

ARIN staff has made it known that leasing addresses is not against policy at 
all, but leased-out addresses can’t be used to justify transfers. However a 
policy explicitly allowing leased-out addresses to be used as justification is 
under consideration.

 

Also leases can be used to justify addresses in ARIN if any tiny connectivity 
is created between the lessor and lessee. For example, a small VPN can be 
created, even though it carries no (or nearly no) traffic. If you want to get 
technical, the lessor and the lessee both advertise the block, but the lessor 
advertises a longer and more expensive route than the lessee, who will receive 
all the traffic except for any loose packets that find their way to the lessor, 
who will send them down the tunnel to the lessee.

 

The issue of retention of a needs test should be reconsidered by the APNIC 
community in the face of evidence garnered from the RIPE experiment. RIPE has 
had no needs test and APNIC had also removed the needs-test for transfers but 
only restored it at the behest of ARIN, who at the time was the only source for 
desperate APNIC members faced with APNIC exhaust.  Now there are other sources 
for inter-regional transfers to APNIC, and APNIC can take the path of RIPE in 
performing needs test only for inbound ARIN transfers so that source would not 
be precluded. So why not return to APNIC’s previous position of removing the 
needs test from transfers?

 

Leasing is a natural progression of the IPv4 market that provides benefits to 
both lessee and lessor, and that is why it is inevitable and why it exists 
today.  There are those who hold unused addresses but who don’t want to sell 
for some reason. There are those who need IPv4 but who can’t afford to pay for 
it all at once. There are those with a temporary need. Leasing is the answer 
for the smaller organizations that need IPv4. There are no addresses left in 
the free pool, so it’s either buy or lease. No other options.

 

Today APNIC (and ARIN and RIPE) will allow existing address holders to lease 
their blocks to non-connected customers. This is not a policy violation and 
addresses can’t be revoked for reasons of utilization or non-utilization. I 
believe that contra this policy, leasing should be authorized explicitly and 
that leased out addresses in-use on an operational network should logically be 
accepted as justification, because does it really matter whose network they are 
used on? Isn’t the salient point that they are in use?

 

I am against this policy.

 

Regards,
Mike Burns

 

 

 

 

 

 

From: JORDI PALET MARTINEZ via sig-policy

[sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Sorry the email went thru while I was still preparing it …

 

APNIC confirmed to the authors, that “leasing is not recognized as a valid 
“use” of resources”.

 

Further to that, to receive resources for the purpose of “leasing” them to 
other parties is not recognized under APNIC policies as an acceptable use. 
APNIC resources are delegated based on demonstrated needs. In order to receive 
resources (by allocation from APNIC or through transfer from others), the 
recipient must demonstrate their need for those resources by describing the 
proposed use of the resources in some specific network infrastructure which 
they own or control. Implicitly, the recipient could not receive addresses for 
subsequent reallocation to other purposes, because the actual use of the 
addresses would be unknown and cannot be subjected to the required assessment 
of the need.


APNIC policies also state that if the declared use of allocated resources 
changes fundamentally, then the resources may be subject to reclamation by 
APNIC.

 

Is not that clear enough?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/8/22, 18:40, "JORDI PALET MARTINEZ"  escribió:

 

Hi Mike,

 

 

 

 

 

 

In at least, LACNIC and AFRINIC, it has been made clear by staff, that leasing 
is not a valid justification for getting resources, *THE SAME as in APNIC*, so 
if you use that as a justification, the request is denied. If you change the 
“usage” after the request is passed, then you’re bypassing the original 
justification, which is also *disallowed*.

 

I will let the secretariat to confirm if leasing is allowed or not, actually 
responding to your points on APNIC policies, even if this policy doesn't reach 
consensus. However, in my opinion the policy manual must be clear enough so 
nobody can interpret that something is not allowed when actually is not.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/8/22, 12:17, "Mike Burns"  escribió:

 

There are a number of problems with this policy.

 

First let’s start with Jordi stating the policy is just a clarification of fact.

If so, why is it necessary? Actually it is not a fact as leasing is occurring 
in APNIC and there is nothing in policy preventing it.  So this needs to be 
considered as a change in policy.

 

Second, there are inaccuracies in the verbiage associated with the policy, 
particularly in reference to the status of leasing at other RIRs.  How can you 
make the statement “ In other RIRs, the leasing of addresses is not authorized 
either and since it is not explicit in their policy manuals…”?

 

Are you unilaterally deciding that things which are not mentioned in policy are 
by definition “unauthorized”? I think this is wrong, and it’s better to 
consider things as authorized unless they are forbidden by policy.  However, 
either way there is no language in any RIR regarding leasing and you can’t make 
assumptions based on your own feelings. 

 

You are also wrong in stating that “Nothing is currently mentioned in RIPE 
about this and it is not acceptable as a justification of the need.” In actual 
fact, RIPE will accept leased-out addresses as justification of need in the 
only case where RIPE actually has a needs test, and that is with inter-regional 
transfers sourced in ARIN.  It bears remembering that RIPE simply has no needs 
test for transfers and this has been the policy for many years.  You may wonder 
what the point of a needs-test for transfers is, since the recipients are 
paying for the addresses.

 

ARIN staff has made it known that leasing addresses is not against policy at 
all, but leased-out addresses can’t be used to justify transfers. However a 
policy explicitly allowing leased-out addresses to be used as justification is 
under consideration.

 

Also leases can be used to justify addresses in ARIN if any tiny connectivity 
is created between the lessor and lessee. For example, a small VPN can be 
created, even though it carries no (or nearly no) traffic. If you want to get 
technical, the lessor and the lessee both advertise the block, but the lessor 
advertises a longer and more expensive route than the lessee, who will receive 
all the traffic except for any loose packets that find their way to the lessor, 
who will send them down the tunnel to the lessee.

 

The issue of retention of a needs test should be reconsidered by the APNIC 
community in the face of evidence garnered from the RIPE experiment. RIPE has 
had no needs test and APNIC had also removed the needs-test for transfers but 
only restored it at the behest of ARIN, who at the time was the only source for 
desperate APNIC members faced with APNIC exhaust.  Now there are other sources 
for inter-regional transfers to APNIC, and APNIC can take the path of RIPE in 
performing needs test only for inbound ARIN transfers so that source would not 
be precluded. So why not return to APNIC’s previous position of removing the 
needs test from transfers?

[sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Richard,

 

Maybe it passed without noticing that is not a valid justification use.

 

Morally, the correct thing to do is to return unused resources to the RIR. We 
accepted a way in the middle with transfers. So be it. Transfer the resources 
that you don’t use, but don’t lease them.

 

Resources are not meant to make business but to ensure a global, open, stable 
and secure Internet.

 

Again, let’s wait for the secretariat confirmation on this.

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/8/22, 18:07, "Richard Ham"  escribió:

 

 

Leasing addresses has been common practice for my entire career in the ISP/CSP 
world, back when 28.8kbps was normal. Someone with excess would assist a 
smaller entity while they sorted out AUNIC/APNIC applications (and often 
learned the ropes). Leasing, while not limited to smaller organisations, 
benefits those of us who are small ( and do not have caches of resources to 
help us when a single /24 for 24 months would make an enormous difference to 
the viability of our business).

 

On the topic of smaller resource holders, I believe we need to make life easier 
for them, rather than harder - the fee structure is already biased against 
someone who holds a /22 compared to a /16, they have limited staff to follow 
policy, apply for that otherwise leasable /24 etc.

 

In this day and age the idea that an organisation would voluntarily hand back 
IPv4 so it can be reallocated seems to be overly optimistic. It is considered a 
rare and limited supply business asset and a valuable one at that.

 

Punitive punishments as suggested in the proposal are also about as welcome as 
another wave of covid inspired lock-downs and reinforce my belief that not only 
is this proposed policy unsupportable but actually is attempting to do the 
opposite of what we need to do - that is - change the policy to support and 
encourage leasing where needs justify. As historical cases show, leasing is 
useful.

 

I too am against this policy.

 

Kind Regards,

 

Richard

 

-- Original Message --

From: "Mike Burns" 

To: "'JORDI PALET MARTINEZ'" ; "'Srinivas (Sunny) 
Chendi'" ; sig-policy@lists.apnic.net

Sent: 23/08/2022 3:17:12 AM

Subject: [sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

 

There are a number of problems with this policy.

 

First let’s start with Jordi stating the policy is just a clarification of fact.

If so, why is it necessary? Actually it is not a fact as leasing is occurring 
in APNIC and there is nothing in policy preventing it.  So this needs to be 
considered as a change in policy.

 

Second, there are inaccuracies in the verbiage associated with the policy, 
particularly in reference to the status of leasing at other RIRs.  How can you 
make the statement “ In other RIRs, the leasing of addresses is not authorized 
either and since it is not explicit in their policy manuals…”?

 

Are you unilaterally deciding that things which are not mentioned in policy are 
by definition “unauthorized”? I think this is wrong, and it’s better to 
consider things as authorized unless they are forbidden by policy.  However, 
either way there is no language in any RIR regarding leasing and you can’t make 
assumptions based on your own feelings. 

 

You are also wrong in stating that “Nothing is currently mentioned in RIPE 
about this and it is not acceptable as a justification of the need.” In actual 
fact, RIPE will accept leased-out addresses as justification of need in the 
only case where RIPE actually has a needs test, and that is with inter-regional 
transfers sourced in ARIN.  It bears remembering that RIPE simply has no needs 
test for transfers and this has been the policy for many years.  You may wonder 
what the point of a needs-test for transfers is, since the recipients are 
paying for the addresses.

 

ARIN staff has made it known that leasing addresses is not against policy at 
all, but leased-out addresses can’t be used to justify transfers. However a 
policy explicitly allowing leased-out addresses to be used as justification is 
under consideration.

 

Also leases can be used to justify addresses in ARIN if any tiny connectivity 
is created between the lessor and lessee. For example, a small VPN can be 
created, even though it carries no (or nearly no) traffic. If you want to get 
technical, the lessor and the lessee both advertise the block, but the lessor 
advertises a longer and more expensive route than the lessee, who will receive 
all the traffic except for any loose packets that find their way to the lessor, 
who will send them down the tunnel to the lessee.

 

The issue of retention of a needs test should be reconsidered by the APNIC 
community in the face of evidence garnered from the RIPE experiment. RIPE has 
had no needs test and APNIC had also removed the needs-test for transfers but 
only restored it at the behest of ARIN, who at the time

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Sunny, all,

 

Just summited a new proposal version amending the editorial inputs and also 
adding the following text:

“Furthermore, from 1st January 2023, all historical resources need to be 
maintained in a current APNIC account. In the event of an account closure, the 
historical resource will be placed in a quarantine period and then made 
available for re-delegation similar to current resources.”

 

Also, in order to facilitate the job, I agree that will be safer to move to a 
single option with 12 months, so I’ve deleted the “2 choices” in the new 
version.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/22, 6:51, "Srinivas (Sunny) Chendi"  escribió:

 

Hi all, 

This is the secretariat's impact assessment for prop-147-v001, which is also 
available on the proposal page.

http://www.apnic.net/policy/proposals/prop-147

APNIC understands that this proposal suggests that historical IPv4 resources be 
justified and claimed, or that they be made available to other organizations 
that require them.

APNIC also notes the deletion of Section 4.2.1. Recovery of unused historical 
resources. As reported to the community at APNIC 50, this may no longer be 
applicable once the project is completed, possibly by the end of 2022.

https://conference.apnic.net/50/assets/files/APCS790/Reclaiming-unused-IPv4.pdf

Recommendations:

For consistency of language and to align with the current policy document, the 
reference to "available pool" could be changed to "free pool". Also the 
reference to "original resource holder" and "original custodians" could be 
changed to "custodian/s".

Given the number of uncontactable resource holders, the 12-month option would 
be safer for APNIC to implement, as some historical resource holders may not be 
aware of the changes to the treatment of historical resources until they are 
placed into reserved status on January 1, 2023.

Clarification:

This proposal only addresses historical resources that have not been claimed by 
January 1st, 2023. It does not specify what happens to the historical resources 
that are claimed, but the Member or Non-Member account is not renewed after 
January 1, 2023. These resources will be considered historical and may remain 
in reserve status indefinitely. 

Regards,
Sunny
APNIC Secretariat

On 11/08/2022 4:59 pm, chku wrote:
Dear SIG members,
 
The proposal "prop-147: Historical Resources Management" has been 
sent to the Policy SIG for review.
 
It will be presented at the Open Policy Meeting (OPM) at APNIC 54 on 
Thursday, 15 September 2022.
 
    https://conference.apnic.net/54/program/schedule/#/day/8
 
We invite you to review and comment on the proposal on the mailing list 
before the OPM.
 
The comment period on the mailing list before the OPM is an important 
part of the Policy Development Process (PDP). 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 appended below as well as available at:
 
    http://www.apnic.net/policy/proposals/prop-147
 
Regards,
Bertrand, Shaila, and Ching-Heng
APNIC Policy SIG Chairs
 
 
 
---
 
prop-147-v001: Historical Resources Management
 
--------
 
Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
  Anupam Agrawal (anupamagrawal...@gmail.com)
 
 
1. Problem statement

Section 4.2.1 is outdated and only looking for very old non-routed resources.
 
The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.
 
Given the continued need for IPv4 addresses, it would seem illogical to keep 
these unused historical resources in reserve indefinitely. Alternatively, these 
resources can be used in a way that is sufficiently justified in accordance 
with existing policies, allowing other organizations to benefit from them 
during the IPv6 transition.
 
 
2. Objective of policy change
-
Ensure that historical IPv4 resources are justified and claimed, or that they 
are available for other organizations that require them.
 
If the resources are marked as reserved, the original holders may reclaim them 
with a valid justification, when APNIC failed to conta

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Andrew, all,

 

I see it otherwise.

 

We are providing APNIC one year to resolve the remaining cases. If we don’t 
have this policy on January 1st 2023, all those addresses will be “frozen” into 
reserved status.

 

Please note this:

 

“The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.”

 

Failing to reach consensus on this proposal (suggestions to improve it, of 
course, are welcome, as we can publish new versions in the next few days), 
means that we can’t change the situation up to a new alternative proposal reach 
consensus, which could happen around March 2023, or may be September 2023. Till 
then those resources are “lost” in the wild.

 

Resources in the wild could be more easily hijacked or used for all kind of 
malicious activities. Do you think the community should accept that risk?

 

In the impact analysis of the first version, APNIC indicated that 6 months may 
be too short, and 12 months will be safer, so we opted for keeping the 12 
months option only. Do you have any data that suggest that APNIC will be unable 
to complete the project in the next year?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 26/8/22, 2:56, "Andrew Yager"  escribió:

 

Hi,

 

Thanks for this data vivek.

 

On the basis of this I cannot suggest this proposal can be accepted - the 
impact is too large.

 

Certainly we, as a community, and APNIC as a whole, need to look at what can be 
done to assist these prefixes coming "into the fold" - but with 581 still with 
no response, and 175 "not yet done" - the risk of this proposal having adverse 
consequences on the routing table is too great.

 

Andrew

 

 

On Fri, 26 Aug 2022 at 17:45, Vivek Nigam  wrote:

Hi Andrew,

 

Please see my responses below.

 

> a) the number of legacy resources currently in use (as in, visible in the 
> global table), but not yet claimed through this process

 

We started this project in February this year and identified 3932 historical 
IPv4 prefixes that were not managed under an APNIC account. 885 of these 
prefixes are currently visible in the routing table. Following if the breakdown 
of these 885 prefixes.

 

Retained by custodian: 81

These prefixes have successfully been claimed and are managed under active 
APNIC accounts now.

 

Being claimed by custodian: 175

We are in contact with the potential custodians and they are in the process of 
claiming these prefixes. 

 

No response: 581

We have sent emails to the custodians but have not got a response as yet. We 
are in the process to find alternate contacts by contacting the ASN announcing 
these prefixes. 

 

Yet to contact: 44

No valid contact information available in whois. We are in the process to look 
for alternate contacts via publicly available searches as well as contacting 
the ASN announcing these prefixes.

 

No longer needed: 4

The custodians have informed us they no longer need these prefixes. We are in 
the process to contact the ASN announcing these prefixes to check why they are 
announcing them.

 

> b) the number of legacy resource claims that have been attempted but not 
> successfully justified

 

So far we have not formally rejected any claims. Where a claimant does not 
provide sufficient information to support their claim, we do not reject the 
claim but rather advise them we will need more information in order to properly 
assess it. We have 3 pending cases where we have requested additional 
supporting information and one case where the custodian has refused to setup an 
APNIC account. We will continue to assist them with their claims through the 
year.

 

Thanks

Vivek

 

From: Srinivas (Sunny) Chendi 
Date: Wednesday, 24 August 2022 at 6:02 pm
To: Andrew Yager , JORDI PALET MARTINEZ 

Cc: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management

Dear Andrew,

Thank you for requesting data.
We will do our best to provide it as soon as possible.

Regards,
Sunny
APNIC Secretariat

On 24/08/2022 4:03 pm, Andrew Yager wrote:

Is there any data indicating:

 

a) the number of legacy resources currently in use (as in, visible in the 
global table), but not yet claimed through this process

b) the number of legacy resource claims that have been attempted but not 
successfully justified

 

I am aware that this has remained a topic of concern for a number of APNIC 
members and technical engineers, and many have been working with APNIC to try 
and resolve resource allocations with various degrees of success.

 

Andrew

 

 

On Wed, 24 Aug 2022 at 09:36, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Sunny, all,

 

Jus

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

If I understood correctly the implications of the EC decision, *if* tis policy 
proposal doesn’t go thru they will become reserved anyway.

 

Could the staff confirm that?

 

Instead, with the proposal, there will be additional 12 months, to react before 
that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 26/8/22, 7:59, "Brett O'Hara"  escribió:

 

Hi Jordi and SIG

The implication of your proposal, by 5.1.4, is that by putting them in Reserved 
status, APNIC will assign them RPKI ROA AS0 and deny them routing on the 
Internet.  You will then allow them 12 months grace after you have denied their 
operation to officially claim them.  Your update from 6 to 12 months has not 
allowed APNIC any more time to contact custodians.

 

I agree with Andrew that the current impact is too large and too damaging to 
internet end point users in your proposed time frame.

 

I believe APNIC members should asess the progress of the HRM project in 12 
months time and consider your proposal then, rather than mandating in a policy 
final date in this cycle, despite your afore mentioned risks.

 

Regards,

Brett

 

On Fri, Aug 26, 2022 at 10:19 PM JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Andrew, all,

 

I see it otherwise.

 

We are providing APNIC one year to resolve the remaining cases. If we don’t 
have this policy on January 1st 2023, all those addresses will be “frozen” into 
reserved status.

 

Please note this:

 

“The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.”

 

Failing to reach consensus on this proposal (suggestions to improve it, of 
course, are welcome, as we can publish new versions in the next few days), 
means that we can’t change the situation up to a new alternative proposal reach 
consensus, which could happen around March 2023, or may be September 2023. Till 
then those resources are “lost” in the wild.

 

Resources in the wild could be more easily hijacked or used for all kind of 
malicious activities. Do you think the community should accept that risk?

 

In the impact analysis of the first version, APNIC indicated that 6 months may 
be too short, and 12 months will be safer, so we opted for keeping the 12 
months option only. Do you have any data that suggest that APNIC will be unable 
to complete the project in the next year?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 26/8/22, 2:56, "Andrew Yager"  escribió:

 

Hi,

 

Thanks for this data vivek.

 

On the basis of this I cannot suggest this proposal can be accepted - the 
impact is too large.

 

Certainly we, as a community, and APNIC as a whole, need to look at what can be 
done to assist these prefixes coming "into the fold" - but with 581 still with 
no response, and 175 "not yet done" - the risk of this proposal having adverse 
consequences on the routing table is too great.

 

Andrew

 

 

On Fri, 26 Aug 2022 at 17:45, Vivek Nigam  wrote:

Hi Andrew,

 

Please see my responses below.

 

> a) the number of legacy resources currently in use (as in, visible in the 
> global table), but not yet claimed through this process

 

We started this project in February this year and identified 3932 historical 
IPv4 prefixes that were not managed under an APNIC account. 885 of these 
prefixes are currently visible in the routing table. Following if the breakdown 
of these 885 prefixes.

 

Retained by custodian: 81

These prefixes have successfully been claimed and are managed under active 
APNIC accounts now.

 

Being claimed by custodian: 175

We are in contact with the potential custodians and they are in the process of 
claiming these prefixes. 

 

No response: 581

We have sent emails to the custodians but have not got a response as yet. We 
are in the process to find alternate contacts by contacting the ASN announcing 
these prefixes. 

 

Yet to contact: 44

No valid contact information available in whois. We are in the process to look 
for alternate contacts via publicly available searches as well as contacting 
the ASN announcing these prefixes.

 

No longer needed: 4

The custodians have informed us they no longer need these prefixes. We are in 
the process to contact the ASN announcing these prefixes to check why they are 
announcing them.

 

> b) the number of legacy resource claims that have been attempted but not 
> successfully justified

 

So far we have not formally rejected any claims. Where a claimant does not 
provide sufficient information to support their claim, we do not reject the 
claim but rather advise them we will need more information in order to properly 
assess it. We have 3 pending cases where we