Re: [sig-policy] New Proposal prop-137-v001: IPv6 assignment for associate members

2021-09-12 Thread Hiroki Kawabata 

Aftab-san,

Our position is neutral. At the point of promoting IPv6 deployment, we support 
this. But,

When "Go IPv6" criteria (it probably means 9.2.1. in policy document) was 
implemented,
we were expecting to use IPv6 in an IPv4 network.
This proposal is different from above assumption, so it feels little strange.

In addition to this, we feel that small assignment tend to obscure the resource 
holder to which prefix is assigned. It is necessary to properly grasp them.

Regards,
Hiroki

On 2021/08/13 8:56, Bertrand Cherrier wrote:

Dear SIG members,

The proposal "prop-137-v001: IPv6 assignment for associate members"
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-137

Regards,
Bertrand and Ching-Heng
APNIC Policy SIG Chairs


---

prop-137-v001: IPv6 assignment for associate members

---

Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)


1. Problem statement

The first tier of membership in APNIC is "Associate". As per APNIC-121 Section 2.1 and 
2.2, the Associate members do not receive any address space (IPv4 or IPv6). In order to be eligible 
for IPv6 assignment APNIC Members that have been delegated an IPv4 address block from APNIC, but 
have no IPv6 space, instantly qualify for an appropriately sized IPv6 block without any 
restriction. If you have no IPv4 delegation and only requesting IPv6 assignment then as per 
APNIC-127 section 10.1.4 "Requests for Provider Independent assignments must include a 
detailed plan of intended usage of the proposed address block over at least the 12 months following 
the allocation". The minimum size of the assignment is a /48 and requires annual fees of AUD 
1,180 as per HD ratio.

In the IPv4 exhaustion world, this policy limits anyone who wants to only use 
IPv6 provider independent assignment for personal use as it doesn't incentivise 
IPv6 assignment only. The same fees and justification is applied to receive /24 
IPv4 + /48 IPv6 address space.

This is perceived as a clear barrier to deploy IPv6. This policy proposal 
addresses that barrier aims to solve this problem by means of providing a 
Provider Independent assignment to Associate members.


2. Objective of policy change
-
Provide an incentive to small enterprises and academia/researchers to receive 
IPv6 assignment.


3. Situation in other regions
-
RIPE NCC: IPv6 PI can be sponsored by an LIR (EUR 50/yr)
ARIN: As an end-user IPv6 only can be requested following certain criteria
AFRINIC: Must not be an LIR
LACNIC: Not been an LIR or ISP, submit addressing plans for at least a year

https://www.nro.net/wp-content/uploads/RIR-Comparative-Policy-Overview-2021-Q2.pdf

Section 3.4.3 - END USERS


4. Proposed policy solution
---
Remove APNIC-114 "APNIC guidelines for IPv6 allocation and assignment requests" 
requirement for initial IPv6 provider independent assignment as per APNIC-127 Section 
10.1.4.

Use the same "Go IPv6" criteria and enable "Get IPv6 Addresses Now" options for 
Associate members with the restrictions that the Provider Independent assignment cannot be further 
assigned to other organisations.

The Associate member MUST agree to use and announce the IPv6 provider 
independent address space within twelve (12) months. After that period, if not 
announced or APNIC host masters believe that it is not in use then the assigned 
IPv6 address space should be reclaimed and returned to the free pool.

Note: This is outside the scope of the policy proposal, therefore requesting 
APNIC EC to consider that only Associate membership fees should be applied to 
initial IPv6 provider independent assignment of /48 only.


5. Advantages / Disadvantages
-
Advantages:
This will give incentive to those small enterprises and academics willing to 
use their own IPv6 addresses but not in a position to be a very small tier 
member.

Disadvantages:
  - This might slightly increase over head for host masters.
  - The

Re: [sig-policy] prop-141-v002: Change maximum delegation, size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses

2021-09-09 Thread Hiroki Kawabata 

I support Owen-san's comment.

If the size change to /22, it will be back to March 2019 and I think that it is 
very simple.
Frequent changes will make confuse this community.

Regards,
Hiroki

On 2021/09/09 4:54, Owen DeLong wrote:

I have no strong opinion positive or negative towards the proposal overall.

I do oppose going from /23 to 0.75 /22. If we’re going to do this, let’s just go
from /23 to /22 and keep things on prefix boundaries.

Owen



On Sep 7, 2021, at 15:02 , Bertrand Cherrier  wrote:

Dear SIG members,

A new version of the proposal "prop-141-v002: Change maximum delegation
size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses" 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 earlier versions is available at:

http://www.apnic.net/policy/proposals/prop-141

Regards,
Bertrand and Ching-Heng
APNIC Policy SIG Chairs


--

prop-141-v002: Change maximum delegation size of IPv4 address from 512 ( /23 ) 
to 768 (/23+/24) addresses.

---

Proposer: Simon Sohel Baroi (sba...@gmail.com)
   Aftab Siddiqui (aftab.siddi...@gmail.com)


1. Problem statement

According to the APNIC IPv4 Address 
Report,(https://www.apnic.net/manage-ip/ipv4-exhaustion/ ) the available
and reserve pool size is as follows:

Available Pool : IP Address 3,782,144 | 14,774 Of /24
Reserved Pool : IP Address 1,831,680 | 7,155 Of /24

If APNIC continues to delegate IPv4 in size of /23 with the average growth rate 
of 145 x /23 delegations per
month the pool will be exhausted around Aug/Sep 2027. Which means the huge 
number of IPv4 addresses will be
unused for a long time and large community members will still remain behind the 
NAT box or without Internet
Connectivity.


2. Objective of policy change
-
The current final /8 allocation policy [1] advise that the current minimum 
delegation size for IPv4 is 256 (/24)
addresses and each APNIC account holder is only eligible to receive IPv4 
address delegations totaling a maximum
512 (/23) addresses from the APNIC 103/8 IPv4 address pool. (6.1. Minimum and 
maximum IPv4 delegations)

This is a proposal to change the maximum size of IPv4 address delegations from 
the available IPv4 address pool to
a totaling of 768 (/23+/24) addresses. This proposal also indicates how APNIC 
will distribute the IPv4 resources
systematically when the available pool size reduces.

Increasing the maximum IPv4 delegation size from /23 to /23+/24 IPv4 address 
pool will allow Newcomers and also
Existing APNIC account holders who only received /23 after Thursday, 28 
February 2019 to receive 256 (/24) IPv4
addresses.


3. Situation in other regions
-
There is no similar policy in place in other RIR regions.


4. Proposed policy solution
---
It is recommended to increase the IPv4 address delegation size from 512 max 
(/23) to 768 (/23 + /24). The address
space can now be allocated from the available 103/8 last /8 block and/or from 
non 103/8 recovered address blocks.
This policy will continue until the available + reserved comes down to less 
than 900,000 IPv4 addresses i.e.
< 3515x/24, once reaching this threshold the maximum delegation size will 
revert back to 512 IPv4 addresses (/23)
and will continue to do so until the available + reserved block comes down to 
256,000 IPv4 addresses i.e 1000x/24
then the delegation size will further reduce to 256 IPv4 addresses i.e. /24. 
The very first time the reserved and
available pool goes below 190,000 IPv4 addresses then the IPv4 reserved pool 
(APNIC-127 Section 5.1.1) for Future
Use of /16 (i.e. 256 x /24s) will be added to the available pool.

Thresholds for IPv4 addresses (Available + Reserved):

- More than 900,000 IPv4 addresses: Delegation /23 + /24
- Less than 900,000 IPv4 addresses AND More than 256,000 IPv4 addresses: 
Delegation /23
- Less than 256,000 IPv4 addresses: Delegation /24
- Less than 190,000 IPv4 addresses - add APNIC-127 5.1.1 Reserved /16 to

Re: [sig-policy] prop-132 new version email draft (003)

2019-09-06 Thread Hiroki Kawabata 

Hi all,

Basically we support this proposal.
But now, if this policy implemented and APNIC create AS0 ROAs,
people who want to hijack the route can identify the unallocated and
unassigned address space easily.(Of course, we understand we can now check 
these prefixes)
We think that careful consideration is necessary for the implementation.

Regards,
Hiroki

---
Hiroki Kawabata
Japan Network Information Center(JPNIC)


Subject: [sig-policy] prop-132 new version email draft (003)
Date: Tue, 03 Sep 2019 11:45:32 +1100
From: Bertrand Cherrier 


Dear SIG members

A new version of the proposal "prop-132: RPKI ROAs for unallocated and
unassigned APNIC address space (was: AS0 for Bogons)" has been sent to
the Policy SIG for review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-132

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-132-v003: RPKI ROAs for unallocated and unassigned APNIC address
space (was: AS0 for Bogons)

-

Proposer: Aftab Siddiqui
   aftab.siddi...@gmail.com


1. Problem statement

Address space managed by APNIC which has is either "Unallocated" or
"Unassigned" is considered "Bogon address space". Bogons are defined in
RFC3871, A "Bogon" (plural: "bogons") is a packet with an IP source
address in an address block not yet allocated by IANA or the Regional
Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and LACNIC) as well
as all addresses reserved for private or special use by RFCs.

As of now, there are XXX IPv4 and YYY IPv6 routes in the global Internet
routing table which cover address space ma naged by APNIC, but which is
not allocated or assigned by APNIC. In the past, several attempts have
been made to filter out such bogons through various methods such as
static filters and updating them occasionally but it is hard to keep an
up to date filters, TeamCymru and CAIDA provides full bogon list in text
format to update such filters. TeamCymru also provides bogon BGP feed
where they send all the bogons via a BGP session which then can be
discarded automatically. Despite these attempts, the issue of
unauthorized advertisements of APNIC's address space hasn't be resolved
so far.


2. Objective of policy change
-
The purpose of creating RPKI ROAs with Origin AS 0 for APNIC's
unallocated and unassigned address space is to restrict the propagation
of BGP announcements covering such bogon space. When APNIC issues a ROA
with AS 0 for unallocated address space under APNIC's administration,
BGP announcements covering this space will be marked as Invalid by
networks doing RPKI based BGP Origin Validation using APNIC's TAL.

Currently, in the absence of any ROA, these bogons are marked as
NotFound. Since many operators have implemented ROV and either planning
or already discarding Invalid, then all the AS0 ROAs which APNIC will
create for unallocated address space will be discarded as well.

3. Situation in other regions
-
No such policy in any region at the moment.


4. Proposed policy solution
---
APNIC will create AS0 (zero) ROAs for all the unallocated and unassigned
address space (IPv4 and IPv6) for which APNIC is the current
administrator. Any resource holder (APNIC member) can create AS0 (zero)
ROAs for the resources they have under their account/administration.

A RPKI ROA is a positive attestation that a prefix holder has authorised
an AS to originate a route for this prefix whereas, a RPKI ROA for the
same prefixes with AS0 (zero) origin shows negative intent from the
resource holder that they don't want to advertise the prefix(es) at this
point but they are the rightful custodian.

Only APNIC has the authority to create RPKI ROAs for address space not
yet allocated to the members and only APNIC can issue AS0 (zero) RPKI
ROAs. Once they RPKI ROA is issued and APNIC wants to allocate the
address space to its member, simply they can revoke the RPKI ROA and
delegate the address space to members. (this proposal doesn't formulate
operational process).

5. Advantages / Disadvantages
-
Advantages:
Network operators who implement RPKI based Origin Validation and discard
BGP announcements with RPKI state "invalid", will automatically discard
BGP announcements covering unallocated & unassigned APNIC address space.
Ensuring unallocated or unassig

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

2019-09-06 Thread Hiroki Kawabata 

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

About inter-RIR, there are not consensus about (M and/or market)transfer IPv6 
address
between RIRs.  First of all, we think we need to discuss about it.

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

Re: [sig-policy] prop-129-v001: Abolish Waiting list for unmet IPv4 requests

2019-02-26 Thread Hiroki Kawabata 

Hi Aftab,

I'm neutral position about this.

After policies prop-127 and prop-129 are implemented, members can be received
only /23 from APNIC per one member. Does every member understand this situation?

For at least prop-129, I think that it is an important change because members 
will
not be able to receive /22 from recoverd pool even if future addresses are 
returned to APNIC.


Regards,
Hiroki

---
Hiroki Kawabata(kawab...@nic.ad.jp)
Hostmaster, IP Address Department
Japan Network Information Center(JPNIC)


On 2019/01/22 9:15, Bertrand Cherrier wrote:

Dear SIG members,

The proposal "prop-129-v001: Abolish Waiting list for unmet IPv4
requests" 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-129

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


--

prop-129-v001: Abolish Waiting list for unmet IPv4 requests

--

Proposers: Aftab Siddiqui
 aftab.siddi...@gmail.com


1. Problem Statement


The current APNIC IPv4 Policy allows each APNIC account holder to receive
up to a /22 from the IPv4 Recovered Pool after they have received a /22
from
the final /8 pool (103/8).  However, the Recovered Pool may not always have
enough resources for delegation, therefore a waiting list was created. The
position of a Member on the waiting list is strictly determined by the date
and time that the Member’s completed request received by APNIC. At the time
of writing, there are 658 members in the waiting list.  In 2018, APNIC
received 10 x /24 and 1 x /23 (equal to 3 x /22) from IANA recovered pool.
In the same year, more than 400 members were added to the waiting list
where the majority were requesting for /22. IANA recovered address
delegations
are shrinking to a level where it is impossible to provide IPv4
resources to
current 658 members in the waiting list.


2. Objective of policy change
-

The objective is to remove the waiting list as the IANA or APNIC
recovered address
space is not enough. All the members in the waiting list already have a
minimum of
/22 address space from last /8 (103/8) address block. Whatever is
recovered by IANA
or by APNIC should be left aside to new members ONLY.

3. Situation in other regions
-

Please correct if otherwise
ARIN - returned and/or recovered address space is added to the ARIN's
free pool
RIPE NCC - returned and/or recovered address space is added to the RIPE
NCC’s free pool
LACNIC - returned and/or recovered address space is added to reserve block
AFRINIC - No Clear

4. Proposed policy solution
---

Abolish the current waiting list and once the APNIC receives IPv4
recovered address
space from IANA or recovered by themselves (through closures or returns
etc) then
it should be treated under the same policy as last /8 (103/8).

A waiting list will be created once APNIC runs out of resources in last
/8 and same
last /8 allocation policy will be applied to the waiting list.

5. Advantages / Disadvantages
-

Advantages:
Removing an unnecessary waiting list and able to utilize the recovered
address pool
as part of available IPv4 resources or last /8.

It will also encourage the waiting list members to implement IPv6.

Disadvantages:
No disadvantages.


6. Impact on resource holders
-

No impact on existing resource holders.


7. References
-


*  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

Re: [sig-policy] A new version of the proposal "prop-118: No need policy in APNIC region"

2018-09-05 Thread Hiroki Kawabata 

Dear proposer,

I remember that there are many discussions at APNIC44 meeting.
APNIC secretariat publish the summary of discussions.
https://www.apnic.net/community/policy/proposals/prop-118/discussion-118/

I understand that you have revised this policy proposal based on these comments.
Would you please share with us the reason why you add only the following 
paragraph
in this version?

==
4. Proposed policy solution
---
(snip)

 - When transferring Internet number resources to another RIR, the APNIC will
   follow the transfer policies that apply within its own service region. The
   APNIC will also comply with the commitments imposed by the receiving RIR in
   order to facilitate the transfer.
==

(Opposing arguments)
・In the past 12 months, only a single transfer was refused by the Secretariat
  because the recipient was unable to demonstrate need.
・More fraudulent transfers might occur if there is less analysis by the 
Secretariat.

Especially about opposing arguments, what do you think about?
Because we are the one of NIRs and we have already implemented the transfer 
policy,
we are interested in the above points.

Regards,
Hiroki

---
Hiroki Kawabata(kawab...@nic.ad.jp)
Hostmaster, IP Address Department
Japan Network Information Center(JPNIC)


Subject: [sig-policy] A new version of the proposal "prop-118: No need policy in 
APNIC region"
From: Sumon Ahmed Sabir 
Date: Wed Aug 08 2018 02:44:39 GMT+0900


Dear SIG members

A new version of the proposal "prop-118: No need policy in APNIC region"
has been sent to the Policy SIG for review.

Information about earlier versions is available from:

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

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-118-v002: No need policy in APNIC region

--

Proposer: Heng Lu
h...@laruscloudservice.net


1. Problem Statement


Whenever a transfer of IPv4 is taking place within the APNIC region, the
recipient needs to demonstrate the "need" for the IPv4 space they intend
to transfer.

Companies transferring IPv4 space to their pool do this in ordcer to
enable further growth in their network, since the space is not coming
from the free public pool, regular policies that are intended to protect
the limited pool of IPv4 space can be removed in transfers.


2. Objective of policy change
-

Simplify transfer of IPv4 space between resource holders.
Ease some administration on APNIC staff, increase database accuracy.


3. Situation in other regions
-

RIPE region has an all around no need policy in IPv4, even for first
allocation, transfers do not require the recipient to demonstrate their
intended use of the resources.

ARIN, need base for both transfers and resources issued by ARIN.

AFRINIC, need based policy on transfers (not active yet) and resource
request from AFRINIC based on needs.

LACNIC, no transfers, need based request.

Out of all these RIR, only ARIN and RIPE NCC have inter-RIR transfer
policies,  ARIN has made clear in the past that the "no need" policy
from the RIPE region would break inter-RIR transfers from ARIN to RIPE
region.


4. Proposed policy solution
---

Simply copy the RIPE policy to solve the ARIN transfer incompatibility:

   - APNIC shall accept all transfers of Internet number resources to its
 service region, provided that they comply with the policies relating
 to transfers within its service region.

   - For transfers from RIR regions that require the receiving region to
 have needs-based policies, recipients must provide a plan to the
 APNIC for the use of at least 50% of the transferred resources within
 5 years.

   - When transferring Internet number resources to another RIR, the APNIC
 will follow the transfer policies that apply within its own service
region.
 The APNIC will also comply with the commitments imposed by the
receiving
 RIR in order to facilitate the transfer.


5. Advantages / Disadvantages
-

Advantages:

   - Harmonisation with RIPE region.
   - Makes transfer simpler and smoother within APNIC and between APNIC
 and RIPE.
   - Maintains a compatibility with ARIN.
   - Removes the uncertainty that a transfer may be rejected based on

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

2018-08-16 Thread Hiroki Kawabata 

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?

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

Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 allocation"

2017-09-12 Thread Hiroki Kawabata 

Hi Anna,


For those requesting larger than the minimum delegation size, hostmasters will 
evaluate information such as detailed addressing plan, number of users, network 
infrastructure/diagram and additional information as required in the proposal.
> We feel the new policy proposal would provide sufficient guidelines for 
hostmasters to evaluate IPv6 requests.


Thanks for sharing your practice.

My understanding is as follows,
 * When applicant want to get IPv6 prefix larger than the minimum delegation 
size, you are counting the number of /56 assignments using the provided 
information from applicant.
 * Only if the above total /56 assignments meet the threshold written in policy 
document, the applicant can be received new IPv6 prefix.

In proposal document,

 > the
 > hierarchical and geographical structuring of the organisation, the
 > segmentation of infrastructure for security and the planned longevity of
 > the allocation.

Of course, I also think it is helpful guidelines. But, about the above points, 
It maybe sometimes difficult for us to evaluate the information provided by 
applicant.

Regards,
Hiroki

---
Hiroki Kawabata(kawab...@nic.ad.jp)
Hostmaster, IP Address Department
Japan Network Information Center(JPNIC)


Subject: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 
allocation"
From: Anna Mulingbayan <a...@apnic.net>
Date: Mon Sep 11 2017 17:57:28 GMT+0900


Hi Satoru

If this proposal were to be implemented, APNIC hostmasters will evaluate IPv6 
resource requests from account holders without existing IPv4 space by verifying 
the following criteria are met:

- be an LIR
- not an end-site
- two years plan to provide v6 connectivity to end-users

For those requesting larger than the minimum delegation size, hostmasters will 
evaluate information such as detailed addressing plan, number of users, network 
infrastructure/diagram and additional information as required in the proposal.
> We feel the new policy proposal would provide sufficient guidelines for 
hostmasters to evaluate IPv6 requests.

Thanks
Anna

  Forwarded Message 
 Subject: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6
 allocation"
 Date: Fri, 8 Sep 2017 15:33:22 +0900
 From: Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp>
 To: SIG policy <sig-pol...@apnic.net>
>  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.
>  * 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 <c...@twnic.net.tw>:
 > 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 abo

Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 allocation"

2017-09-10 Thread Hiroki Kawabata 

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 <c...@twnic.net.tw>
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 several years because the lack of an
appropriate policy covering their case.


Proposed policy solution


Change some of the actual text as follows.

Actual text:

9.2.2. Account holders without existing IPv4 space

To qualify for an initial allocation of IPv6 address space, an
organization must:

1.   Be an LIR
2.   Not be an end site
3.   Plan to provide IPv6 connectivity to organizations to which it
  will make assignments.
4.   Meet one of the two following criteria:

  - Have a plan for making at least 200 assignments to other
organizations within two years, or

  - Be an existing LIR with IPv4 allocations from APNIC or an NIR, which
  will make IPv6 assignments or sub-allocations to other organizations
  and announce the allocation in the inter- domain routing system within
  two years.

Private networks (those not connected to the public Internet) may also
be eligible for an IPv6 address space allocation provided they meet
equivalent criteria to those listed above.


New text:

9.2.2. Account holders without existing IPv4 space

To qualify for an initial allocation of IPv6 address space, an
organization must:

1.   Be an LIR
2.   Not be an end site
3.   Plan, within two years, to provide IPv6 connectivity to other
  organizations/end-users to

Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

2017-09-09 Thread Hiroki Kawabata 

Dear David,

We support this proposal in general but we have one comment.

In your proposal, we cannot see the period of temporary transfer.
We think that it is better to limit the period.
For example, when they are going to back it within 2 years, the applicant can 
use this temporary transfer policy.

Regards,
Hiroki

---
Hiroki Kawabata(kawab...@nic.ad.jp)
Hostmaster, IP Address Department
Japan Network Information Center(JPNIC)


Subject: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 
44 Polic  y SIG
From: chku <c...@twnic.net.tw>
Date: Wed Aug 09 2017 15:16:20 GMT+0900


Dear SIG members

The proposal "prop-119: Temporary transfers" was sent to the Policy SIG
Mailing list in May 2017.

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.

Information about the proposal is available from:

 http://www.apnic.net/policy/proposals/prop-119

You are encouraged to express your views on the proposal:

  - Do you support or oppose the proposal?
  - 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?

Please find the text of the proposal below.

Kind Regards,

Sumon, Ching-Heng, Bertrand
APNIC Policy SIG Chairs




prop-119-v001: Temporary transfers


 
Proposer:   David Hilario

 d.hila...@laruscloudservice.net

1. Problem statement


It is currently not possible for an organisation to receive a temporary
transfer under the current policy framework. Some organisations do not
want to have address space registered as assignments or sub-allocations,
but would rather have the address space registered as "ALLOCATED PA".


2. Objective of policy change


Create a possibility for temporary transfers that would allow
organisations to have resources directly registered under them while
they are the custodians of these resources on the Internet. While also
guaranteeing that the offering party will under the APNIC policy be able
to recover the resources once the “lease” time has expired unless
specifically renewed.


3. Situation in other regions


RIPE region has a concept of temporary transfers in their policies. This
concept is not found in the other RIRs for the moment.


4. Proposed policy solution


Adding to section "8.2.1. Conditions on the space to be transferred" the
following paragraphs: It must be specified if the transfer is a
permanent or temporary transfer.

A temporary transfer must have an end date, upon the end date the
resources will be transferred back to the same origin account or its
successor in the event of merger and acquisitions, unless the transfer
is specifically prolonged and confirmed by both parties.

If the source account does no longer exist and has no successor, the
space will then be returned to the origin RIR for the space. Temporary
transfers cannot be further transferred.


5. Advantages / Disadvantages


Advantages:
Gives a greater flexibility in how LIRs manage and distribute their free
pool. Enables organisation to receive address space in the way they
intend.

Disadvantages:
These transfers would be treated and appear as regular transfers, only
APNIC the offering and receiving party will be aware of their temporary
nature.

Organisations receiving such space, if they further assign it, must make
be ready to renumber/revoke space from their customers and services then
the lease expires, this is no different than a sub-allocation and
implies the same limitations.


6. Impact on resource holders

none


7. References
-
 







___
Sig-policy-chair mailing list
sig-policy-ch...@apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy-chair



*  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

Re: [sig-policy] prop-118-v001: No need policy in APNIC region

2017-02-28 Thread Hiroki Kawabata 

Dear David,

We support this proposal in general but we'd like to confirm about your 
proposal.

Under the current transfer policy, we understand transferred address space are 
to be used
by the recipient of the transfer, and not for re-sale purpose without use by 
the recipient.

Please let me confirm that this remains unchanged under this policy proposal,
i.e., the transfer policy is *not* for re-sale.

Regards,
Hiroki

---
Hiroki Kawabata(kawab...@nic.ad.jp)
Hostmaster, IP Address Department
Japan Network Information Center(JPNIC)


Subject: [sig-policy] prop-118-v001: No need policy in APNIC region
From: Sumon Ahmed Sabir <su...@fiberathome.net>
Date: Tue Jan 31 2017 19:44:58 GMT+0900


Dear SIG members

The proposal "prop-118-v001: No need policy in APNIC region" has been
sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 43 in Ho Chi
Minh City, Viet Nam on Wednesday, 1 March 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-118

Regards

Masato, Sumon
APNIC Policy SIG Chairs


---

prop-118-v001: No need policy in APNIC region

---

Proposer:   David Hilario
d.hila...@laruscloudservice.net


1. Problem statement
---

Whenever a transfer of IPv4 is taking place within the APNIC region, the
recipient needs to demonstrate the "need" for the IPv4 space they intend
to transfer.

Companies transferring IPv4 space to their pool do this in ordcer to
enable further growth in their network, since the space is not coming
from the free public pool, regular policies that are intended to protect
the limited pool of IPv4 space can be removed in transfers.


2. Objective of policy change
---

Simplify transfer of IPv4 space between resource holders.
Ease some administration on APNIC staff.


3. Situation in other regions
---

RIPE region has an all around no need policy in IPv4, even for first
allocation, transfers do not require the recipient to demonstrate their
intended use of the resources .

ARIN, need base for both transfers and resources issued by ARIN.

AFRINIC, need based policy on transfers (not active yet) and resource
request from AFRINIC based on needs.

LACNIC, no transfers, need based request.

Out of all these RIR, only ARIN and RIPE NCC have inter-RIR transfer
policies,  ARIN has made clear in the past that the "no need" policy
from the RIPE region would break inter-RIR transfers from ARIN to RIPE
region.


4. Proposed policy solution
---

Simply copy the RIPE policy to solve the ARIN transfer incompatibility:

 - APNIC shall accept all transfers of Internet number resources to its
   service region, provided that they comply with the policies relating
   to transfers within its service region.

 - For transfers from RIR regions that require the receiving region to
   have needs-based policies, recipients must provide a plan to the
   APNIC for the use of at least 50% of the transferred resources within
   5 years.

source:
https://www.ripe.net/publications/docs/ripe-644


5. Advantages / Disadvantages
---

Advantages:

 - Harmonisation with RIPE region.
 - Makes transfer simpler and smoother within APNIC and between APNIC
   and RIPE.
 - maintains a compatibility with ARIN.
 - Removes the uncertainty that a transfer may be rejected based on
   potentially badly documented needs.
 - Lowers the overall administrative burden on APNIC staff.

Disadvantages:

none.


6. Impact on resource holders
---
None


7. References
---



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

Re: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 addresses in the final /8 block

2017-02-27 Thread Hiroki Kawabata 

Dear Fujisaki-san,

We understand that 103/8 block is special purpose pool to accommodate minimum
IPv4 address block for new members.　ARIN has already implemented the policy
that limits the transfer of IPv4 address block with special purpose.

 Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
 https://www.arin.net/policy/proposals/2016_1.html

We thinks this revised proposal has reflected the discussions at APNIC42
and has become reasonable. We support this proposal.

Regards,
Hiroki

---
Hiroki Kawabata(kawab...@nic.ad.jp)
Hostmaster, IP Address Department
Japan Network Information Center(JPNIC)


Subject: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 
addresses in the final /8 block
From: Sumon Ahmed Sabir <su...@fiberathome.net>
Date: Sun Jan 29 2017 20:39:05 GMT+0900


Dear SIG members

A new version of the proposal "prop-116: Prohibit to transfer IPv4
addresses in the final /8 block" has been sent to the Policy SIG for
review.

Information about earlier versions is available from:

http://www.apnic.net/policy/proposals/prop-116

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,

Masato and Sumon






---

prop-116-v003: Prohibit to transfer IPv4 addresses in the final /8 block

---

Proposer:   Tomohiro Fujisaki
fujis...@syce.net


1. Problem statement


There are a lot of transfers of IPv4 address blocks from 103/8
happening, both within the APNIC region and among RIRs.

Then number of transfer from 103/8 block are about 200, which is
about 12% of the total number of transfers. This looks so high
since APNIC manages about 40/8.

And based on the information provided by APNIC secretariat, number
of transfers from the 103/8 block are increasing year by year.

Updated by APNIC Secretariat on 27 January 2017:

1) M transfers containing 103/8 space

+--+---+---+-
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+-
| 2011 | 3 | 12 |
| 2012 |10 | 46 |
| 2013 |18 | 66 |
| 2014 |   126 |498 |
| 2015 |   147 |573 |
| 2016 |63 |239 |
+--+---++-

2) Market transfers containing 103/8 space

+--+---+---+
|  |   Total   | Number of |
| Year | Transfers |   /24s|
+--+---+---+
| 2011 | 2 | 2 |
| 2012 |21 |68 |
| 2013 |16 |61 |
| 2014 |25 |95 |
| 2015 |67 |   266 |
| 2016 |   103 |   394 |
+--+---+---+

And also, transfers from the 103/8 block include:
  - Take place within 1 year of distribution, or
  - Multiple blocks to a single organization in case of beyond 1 year.

Further, there is a case where a single organization have received 12
blocks transfers from 103 range.

see:  https://www.apnic.net/transfer-resources/transfer-logs

From these figures, it is quite likely that substantial number of 103/8
blocks are being used for transfer purpose.

This conflicts with the concept of distribution of 103/8 block
(prop-062), which is intended to accommodate minimum IPv4 address blocks
for new comers.

°°prop-062: Use of final /8
°°https://www.apnic.net/policy/proposals/prop-062


2. Objective of policy change
-

When stated problem is solved, distribution from 103/8 block will be
consistent with its original purpose, for distribution for new entrants
to the industry. Without the policy change, substantial portion of 103/8
blocks will be consumed for transfer purpose.


3. Situation in other regions
-

None.


4. Proposed policy solution
---

Prohibit transfer IPv4 addresses under /8 address block (103/8) which
have not passed two years after its allocation/assignment.
If the address block allocated to a LIR in two years is not needed any
more, it must return to APNIC to allocate to another organization
using final /8 policy.

In the case of transfers due to M, merged organization can have
up to /22 IPv4 address in the 103/8 block in principle. If there
are technical reasons such as all address is used in separate networks
and announced from multiple ASes, merged organization can keep them.
Otherwise, the 103/8 IPv4 address more than /22 must return to APNIC
to allocate to another organization using final /8 policy.


5. Advantages / Disadvantages
-

Advantages:
  - It makes 103/8 blocks available according to the original purpose,
as dist

Re: [sig-policy] Revised version of Prop-117 (Prop-117-v002)

2017-02-27 Thread Hiroki Kawabata 

Dear Fujisaki-san,


4. Proposed policy solution
---

Handling reurned address:
  - Recovered 103/8 space will be placed in the 103/8 (Final /8) pool.
  - Recovered non-103/8 space will be placed in the IPv4 Recovered pool.


We support these above points of this proposal.


Guidance for 103/8 pool exhaustion:
  - The first time an approved request cannot be fulfilled from the 103/8
pool, Final /8 delegations will end.
  - APNIC will begin to manage only one (Recovered) IPv4 pool containing
any residual 103/8 space and all future returns, including 103/8 returns.
  - Each new account holder can receive up to a /21 from the IPv4
Recovered pool.
  - Existing account holders who have not yet received the maximum /21
from the two pools may continue to apply for space from the Recovered
pool until they have received a maximum /21 from the two pools.
  - A waiting list will be created if approved requests cannot be
fulfilled. Each new account holder will be given priority in the
waiting list.


The above points describe the distribution procedure after 103/8 pool 
exhaustion.
We think that it is better to discuss as an independent proposal,
because the content you want to discuss is different from the above two points.

Regards,
Hiroki

---
Hiroki Kawabata(kawab...@nic.ad.jp)
Hostmaster, IP Address Department
Japan Network Information Center(JPNIC)


Subject: [sig-policy] Revised version of Prop-117 (Prop-117-v002)
From: Sumon Ahmed Sabir <su...@fiberathome.net>
Date: Wed Feb 15 2017 19:41:08 GMT+0900



Dear SIG Members,

Tomohiro Fujisaki has submitted a revised version of Prop-117 ( Prop-117-v002) 
after getting some feedback from the community.

Please review and  share your thoughts if you have any comments, suggestions on 
the proposal. This proposal along with three
other proposals will be discussed in APNIC43 Policy SIG meeting.

Please also find all other proposals for APNIC43 Policy SIG here:

https://www.apnic.net/community/policy/proposals/



Regards,

Masato, Sumon



---

prop-117-v002: Returned IPv4 address management and Final /8 exhaustion

---

Proposer:   Tomohiro Fujisaki
fujis...@syce.net <mailto:fujis...@syce.net>


1. Problem statement


APNIC currently makes delegations from two IPv4 pools. These are the
103/8 (Final /8) pool and the non-103/8 IPv4 Recovered pool.

With current policy, all returned address space, including 103/8 blocks,
will be merged into the IPv4 Recovered pool.

If a 103/8 block is returned, it is placed in the IPv4 Recovered pool
and re-distributed as returned space. Some organisations may receive
duplicate blocks from 103/8: one under the final /8 policy, the other
under the returned pool policy.

Current APNIC Policy requires account holders to receive address space
from the 103/8 (Final /8) pool before they can apply for address space
from the Recovered pool.

APNIC currently manages a Recovered Pool Waiting List for approved
requests that cannot be met from the IPv4 Recovered pool.


2. Objective of policy change
-

To simplify the address pool management and to provide guidance for
103/8 pool exhaustion.


3. Situation in other regions
-

None.


4. Proposed policy solution
---

Handling reurned address:
  - Recovered 103/8 space will be placed in the 103/8 (Final /8) pool.
  - Recovered non-103/8 space will be placed in the IPv4 Recovered pool.

Guidance for 103/8 pool exhaustion:
  - The first time an approved request cannot be fulfilled from the 103/8
pool, Final /8 delegations will end.
  - APNIC will begin to manage only one (Recovered) IPv4 pool containing
any residual 103/8 space and all future returns, including 103/8 returns.
  - Each new account holder can receive up to a /21 from the IPv4
Recovered pool.
  - Existing account holders who have not yet received the maximum /21
from the two pools may continue to apply for space from the Recovered
pool until they have received a maximum /21 from the two pools.
  - A waiting list will be created if approved requests cannot be
fulfilled. Each new account holder will be given priority in the
waiting list.


5. Advantages / Disadvantages
-

Advantages:

  - Simplifying management of remaining IPv4 address pools.

Disadvantages:

None.


6. Impact on resource holders
--

No impact to resource holders.


7. References
-

prop-117-v2.txt
Displaying prop-117-v2.txt.


*  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

Re: [sig-policy] Proposal to revise SIG guidelines

2016-09-30 Thread Hiroki Kawabata 

Yamanishi-san,

Thanks for your comment and revise proposal. Yes, I can support.

Regards,
Hiroki


Subject: Re: [sig-policy] Proposal to revise SIG guidelines
From: Masato Yamanishi <myama...@gmail.com>
Date: Fri Sep 30 2016 04:24:17 GMT+0900


Kawabata-san (and maybe Randy),

So, can you support it if I will revise it as follows?


2. SIG Chair's term of service
 I would like to propose revising SIG Chair's term of service as follows.
 - Elections occur yearly. Chair elections and Co-Chair elections occur in 
alternate years (same as current SIG guideline)
 - If Chair election and Co-Chair election are happen in same year, 
Co-Chair's (or Co-Chairs') term of service should be one year
   as Chair's and Co-Chairs' term of service are staggered
 - If current Chair/Co-Chair resigned or was removed, the succesor's term 
should be remaining term of current Chair/Co-Chair


Any thought?

Regards,
Matt



2016-09-28 15:52 GMT+09:00 Hiroki Kawabata <kawab...@nic.ad.jp 
<mailto:kawab...@nic.ad.jp>>:


2. SIG Chair's term of service
I would like to propose aligning Chair' term with Co-Chair's term, which
means that Chair and all Co-Chair will serve for same two years.
To keep this alighment, I would like to propose limiting the successor's
term to remaining term of current Chair/Co-Chair if current
Chair/Co-Chair resigned or was removed.


If ALL current Chair/Co-Chair resigne or are removed at the same time
and the another successor who don't know or share the background and
situations of this forum become New Chair/Co-Chair, who do care for them?

At the point of the stable/continuous forum management,
I think that there is no need to revise the part of this guideline.

Regards,
Hiroki


Subject: [sig-policy] Proposal to revise SIG guidelines
From: Adam Gosling <a...@apnic.net <mailto:a...@apnic.net>>
Date: Mon Sep 05 2016 19:08:46 GMT+0900



Dear SIG members

A proposal to modify the APNIC SIG Guidelines relating to the election
of SIG Chairs and Co-Chairs has been submitted for consideration at
APNIC 42 im Colombo, Sri Lanka.

   https://www.apnic.net/sig-chair-elections/proposed-revision.txt 
<https://www.apnic.net/sig-chair-elections/proposed-revision.txt>

If agreed. these changes will affect all APNIC SIGs from APNIC 43 in Ho
Chi Minh City, Vietnam.

Discussion and call for consensus will take place in the Policy SIG.

   https://www.apnic.net/mailinglists 
<https://www.apnic.net/mailinglists>

If successful in the Policy SIG, a consensus call will be made at the
APNIC Member Meeting. There will be no final Comment Period.

To ensure those not travelling to APNIC 42 are able to participate in
the discussion, you are invited to comment on the Policy SIG Mailing
List before the conference.

More background to this proposal is available at:

   https://www.apnic.net/community/participate/sigs/chair-elections 
<https://www.apnic.net/community/participate/sigs/chair-elections>

Regards

Adam


---

Revising eligible voters of Chair election and Chair's term

---

Proposer:   Masato Yamanishi
   myama...@gmail.com <mailto:myama...@gmail.com>


1. Problem statement


1. Eligible voters in SIG Chair election
In current SIG guidelines, we have no rule or guideline about eligible
voters in SIG Chair election and we have two issues by the lack of such
rule.

Firstly, we need to have clear guideline whether remote participants
have voting rights for SIG Chair election since current practice is
different in each election.

Secondary, it can be used by fraud, like hijacking the position of Chair
agaist the Community by inviting many persons who never attend the
community discussion.

2. SIG Chair's term of service
While SIG guidelines says "Elections occur yearly. Chair elections and
Co-Chair elections occur in alternate years.", both elections were held
at same meeting in many cases, in particular when a current Co-Chair
stand for the position of Chair. With this current practice having both
elections at same meeting, we are not seeing any significant issues for
long time.

In addition, there is no alternative condition for the successor's term
if current Chair/Co-Chair resigned or was removed though such
alternative condition is necessary to maintain staggered term as
requested by SIG guideline. (a.k.a. the successor's term of servic

Re: [sig-policy] Proposal to revise SIG guidelines

2016-09-28 Thread Hiroki Kawabata 

2. SIG Chair's term of service
I would like to propose aligning Chair' term with Co-Chair's term, which
means that Chair and all Co-Chair will serve for same two years.
To keep this alighment, I would like to propose limiting the successor's
term to remaining term of current Chair/Co-Chair if current
Chair/Co-Chair resigned or was removed.


If ALL current Chair/Co-Chair resigne or are removed at the same time
and the another successor who don't know or share the background and
situations of this forum become New Chair/Co-Chair, who do care for them?

At the point of the stable/continuous forum management,
I think that there is no need to revise the part of this guideline.

Regards,
Hiroki


Subject: [sig-policy] Proposal to revise SIG guidelines
From: Adam Gosling 
Date: Mon Sep 05 2016 19:08:46 GMT+0900


Dear SIG members

A proposal to modify the APNIC SIG Guidelines relating to the election
of SIG Chairs and Co-Chairs has been submitted for consideration at
APNIC 42 im Colombo, Sri Lanka.

   https://www.apnic.net/sig-chair-elections/proposed-revision.txt

If agreed. these changes will affect all APNIC SIGs from APNIC 43 in Ho
Chi Minh City, Vietnam.

Discussion and call for consensus will take place in the Policy SIG.

   https://www.apnic.net/mailinglists

If successful in the Policy SIG, a consensus call will be made at the
APNIC Member Meeting. There will be no final Comment Period.

To ensure those not travelling to APNIC 42 are able to participate in
the discussion, you are invited to comment on the Policy SIG Mailing
List before the conference.

More background to this proposal is available at:

   https://www.apnic.net/community/participate/sigs/chair-elections

Regards

Adam


---

Revising eligible voters of Chair election and Chair's term

---

Proposer:   Masato Yamanishi
   myama...@gmail.com


1. Problem statement


1. Eligible voters in SIG Chair election
In current SIG guidelines, we have no rule or guideline about eligible
voters in SIG Chair election and we have two issues by the lack of such
rule.

Firstly, we need to have clear guideline whether remote participants
have voting rights for SIG Chair election since current practice is
different in each election.

Secondary, it can be used by fraud, like hijacking the position of Chair
agaist the Community by inviting many persons who never attend the
community discussion.

2. SIG Chair's term of service
While SIG guidelines says "Elections occur yearly. Chair elections and
Co-Chair elections occur in alternate years.", both elections were held
at same meeting in many cases, in particular when a current Co-Chair
stand for the position of Chair. With this current practice having both
elections at same meeting, we are not seeing any significant issues for
long time.

In addition, there is no alternative condition for the successor's term
if current Chair/Co-Chair resigned or was removed though such
alternative condition is necessary to maintain staggered term as
requested by SIG guideline. (a.k.a. the successor's term of service is
same as remaining term of resigned or removed Chair)


2. Objective of policy change
-

The objective is preventing confusions related to remote participant as
well as mitigating possible frauds in SIG Chair election by setting
clear rule for eligible voters.

In addition, we can also expect aligning SIG guideline with current
practice as well as resolving unclearness of the successor's term when
current Chair/Co-Chair resigned or was removed by revising SIG Chair's
term of service.


3. Situation in other regions
-

Please refer following page made by Adam Gosling

Comparison of RIR SIG/WG Chair Election Processes
https://www.apnic.net/sig-guidelines/chair-elections/other-rirs


4. Proposed policy solution
---

1. Eligible voters in SIG Chair election
I would like to propose limiting eligible voters of SIG Chair election
to registered participants of APNIC Conference where the election is
held.

In this context, registered participants include remote participants who
register to Confer, or its successor in future.

2. SIG Chair's term of service
I would like to propose aligning Chair' term with Co-Chair's term, which
means that Chair and all Co-Chair will serve for same two years.
To keep this alighment, I would like to propose limiting the successor's
term to remaining term of current Chair/Co-Chair if current
Chair/Co-Chair resigned or was removed.



5. Advantages / Disadvantages
-

Advantages:
By setting clear rule for eligible voters,

 - we can avoid confusion whether remote participant cast vote for SIG
   Chair election or not
 - we can mitigate frauds in SIG Chair election

By revising SIG Chair's term of service
 - we can resolve a