sig-policy January 2019

sig-policy@lists.apnic.net

8 participants
11 discussions

Prop-127 announcement : Change maximum delegation size of 103/8 IPv4 address, pool to a /23
by Bertrand Cherrier 27 Feb '19

27 Feb '19

Dear SIG members, The proposal "prop-127-v001: Change maximum delegation size of 103/8 IPv4 address pool to a /23" 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-127 Regards Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs ---------------------------------------------------------------------- prop-127-v001: Change maximum delegation size of 103/8 IPv4 address pool to a /23 ---------------------------------------------------------------------- Proposers: Ching-Heng Ku, Aftab Siddiqui, Yen-Chieh Wang chku(a)twnic.tw 1. Problem Statement -------------------- This is a proposal to change the maximum size of IPv4 address delegations from the APNIC 103/8 IPv4 address pool [1] to a /23. 2. Objective of policy change ----------------------------- The current final /8 allocation policy[1] requires that the current minimum delegation size for IPv4 is a /24 and each APNIC account holder is only eligible to receive IPv4 address delegations totalling a maximum /22 from the APNIC 103/8 IPv4 address pool. According to the APNIC IPv4 Address Report, https://ipv4.potaroo.net/, remaining addresses in the APNIC 103/8 pool are 42.8%, 33.3%, 23.4% of /8 in the end of 2016, 2017, and 2018, respectively. The remaining number of APNIC 103/8 IPv4 address pool for APNIC account holder is less and less. It is predicted that the 103/8 pool will be exhausted in 2020. Reducing the maximum IPv4 delegation size from APNIC 103/8 IPv4 address pool can prolong the exhaustion time of the 103/8. Newcomers of APNIC account holders will have the benefit in this period of time. New companies can obtain some IPv4 address space in the APNIC service region without the need to trade for address space and can make the preparation for the subsequent IPv6 migration. It is recommended that the number of assigned IPv4 addresses in Final /8 be reduced from a maximum of /22 to /23. It will be estimated to extend the exhaustion time for at least three years or more. 3. Situation in other regions ----------------------------- There is no similar policy in place in other RIR regions. 4. Proposed policy solution --------------------------- It is proposed to modify the 6.1 Minimum and maximum IPv4 delegations of the APNIC Internet Number Resource Policies[1]. This proposal is to change the maximum size of IPv4 address delegations from the APNIC 103/8 IPv4 address pool[1] to a /23. /23 is important because new ISPs can use /24 for internal infrastructure and /24 customer assignments and NAT for IPv6 transition. Current Policy text Each APNIC account holder is only eligible to receive IPv4 address delegations totalling a maximum /22 from the APNIC 103/8 IPv4 address pool. New Policy text Each APNIC account holder without APNIC 103/8 IPv4 address delegations from the APNIC 103/8 IPv4 address pool is only eligible to receive a maximum /23 from the APNIC 103/8 IPv4 address pool. 5. Advantages / Disadvantages ----------------------------- Advantages: - This proposal allows a greater range of networks to access the resources in the final /8. - This proposal extends the maximum possible total number of networks that can benefit from the final /8 pool from around 16,000 to around 18,000 networks, providing small amounts of IPv4 to be available for networks, developing economy, etc., making the transition to IPv6 for many years to come. Disadvantages: - No disadvantages are foreseen. 6. Impact on resource holders ----------------------------- It reduces the maximum size of the delegated address block available to APNIC members during the final /8 phase. This will affect NIR members in the same way as APNIC members. 7. References ------------- [1] Section 6.1. "Minimum and maximum IPv4 delegations" of "Policies for IPv4 address space management in the Asia Pacific region" https://www.apnic.net/community/policy/resources#Part-2-IPv4-Policy

3 2

prop-129-v001: Abolish Waiting list for unmet IPv4 requests
by Bertrand Cherrier 26 Feb '19

26 Feb '19

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.siddiqui(a)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 -------------

3 2

Version 3 - prop-126 PDP Update
by Bertrand Cherrier 26 Feb '19

26 Feb '19

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.palet(a)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 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. Step 2 Actual: 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 Meeting for the process to continue. If there is no consensus on a proposal at either of these forums, the SIG (either on the mailing list or at a future OPM) will discuss whether to amend the proposal or to withdraw it. Proposed: Consensus at the OPM Consensus is defined as “rough consensus” as observed by the Chairs. Consensus is determined in both, the SIG session and the SIG mailing list, in a maximum of two weeks after the OPM. 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, following the discussions with the community. Step 3 Actual: Discussion after the OPM Proposals that have reached consensus at the OPM and the AMM 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. Proposed: Last-Call Proposals that have reached consensus will be circulated on the appropriate SIG mailing during four weeks. The purpose of the “last-call” is to provide the community with a brief and final opportunity to comment on the proposal, especially those who didn’t earlier. Consequently, during this period editorial comments may be submitted and, exceptionally, objections if any aspect is discovered that was not considered in the discussion prior to determining consensus. Any new objections must also be substantiated and must therefore not be based on opinions lacking a technical justification. Step 4 Actual: Confirming consensus Consensus is assumed to continue unless there are substantial objections raised during the “comment period”. When the “comment period” has expired, the appropriate SIG Chair (and Co-chairs) will decide whether the discussions on the mailing list represent continued consensus. If the Chair (and Co-chairs) observe that there are no “substantial objections” to the proposed policy, consensus is confirmed and the process continues as outlined below in Step 5. If it is observed that there have been “substantial objections” raised to the proposed policy, consensus is not confirmed and the proposal will not be implemented. The SIG will then discuss (either on the mailing list or in the SIG) whether to pursue the proposal or withdraw it. Proposed: Confirming consensus In a maximum of one week, after the end of the “last-call”, the Chairs will confirm whether consensus is maintained and the process continues as outlined below in Step 5. If it is observed that there have been “new substantial objections” raised to the proposed policy, consensus is not confirmed and the proposal will not be implemented. The authors can decide to withdraw it, or provide a new version, following the discussions with the community. The proposal will expire in six months, unless a new version is provided. Step 5 Actual: Endorsement from the EC The EC, in their capacity as representatives of the membership, will be asked to endorse the consensus proposals arising from the OPM and the SIG mailing lists for implementation at the next EC meeting. In reviewing the proposals for implementation, the EC may refer proposals back to the SIG for further discussion with clearly stated reasons. As per the APNIC By-laws, the EC may, at its discretion, refer the endorsement to a formal vote of adoption by the APNIC members. Proposed: Endorsement from the EC The EC, in their capacity as representatives of the membership, will be asked to endorse the consensus proposals arising from the OPM and the SIG mailing lists for implementation at the next EC meeting. In reviewing the proposals for implementation, the EC may refer proposals back to the SIG for further discussion with clearly stated reasons. As per the APNIC By-laws, the EC may, at its discretion, refer the endorsement to a formal vote of adoption by the APNIC members. Appeals process In case of disagreement during the process, any member of the community must initially bring the matter to the mailing list for consideration by the Chairs. Alternately, if any member considers that the Chairs have violated the process or erred in their judgement, they may appeal their decision through the EC, which must decide the matter within a period of four weeks. Definition of “Rough Consensus” Achieving “rough 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 al”’ (unanimity). More specifically, RFC7282, explains that “Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.” Consequently, the use of “consensus” in the PDP, must be interpreted as “rough consensus”. 5. Advantages / Disadvantages ----------------------------- Advantages: Fulfilling the objectives above indicated and making sure that there is no discrimination with community members that aren’t able to travel. Disadvantages: None foreseen. 6. Impact on resource holders ----------------------------- None. 7. References ------------- http://www.lacnic.net/679/2/lacnic/policy-development-process https://www.ripe.net/publications/docs/ripe-710

2 1

prop-128-v001: Multihoming not required for ASN
by Bertrand Cherrier 26 Feb '19

26 Feb '19

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.palet(a)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

4 4

Monthly List Reminder
by noreply＠apnic.net 31 Jan '19

31 Jan '19

Dear Subscriber, This is the monthly reminder of subscription information for the sig-policy list, hosted at APNIC. For subscription information including how to un-subscribe go to http://mailman.apnic.net/mailman/listinfo/sig-policy Thank you for participating in this discussion. Kind Regards, List administrator

1 0

Re: [sig-policy] prop-129-v001: Abolish Waiting list for unmet IPv4 requests
by Aftab Siddiqui 24 Jan '19

24 Jan '19

Hi Ernest, > I support this proposal but not all of the view. > Thanks for your partial support, I hope I will be able to transform it in full support :) > The point: > The last APNIC 103/8 block is a brand new came from IANA, unused IPv4 > block, and it is never used by other user on the Internet from other RIR. > This SHOULD be the case but unfortunately, it isn't true. Let me explain it why. As I'm writing this email, there are 43 prefixes from 103/8 block on the global routing table which are not allocated to anyone by APNIC. Yes, 43 Bogons from 103/8. All these prefixes are most likely to be allocated to new members in the future. They are "used" and probably "abused" prefixes by all means. [source: cidr-report.org] > The recovered pool IP block is used by other user from other RIR may be. > Same is the case with 103/8 block > If the recovered pool IP will assign to the new member, would it have some > problem when use it ? > All the recovered blocks have the same issues like 103/8. > Best Regards, > > Ernest Tse > > > On Tue, 22/01/2019 08.15, Bertrand Cherrier <b.cherrier(a)micrologic.nc> > 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.siddiqui(a)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(a)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(a)lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy

1 0

Policy SIG Chair Nominations now open
by George Odagi 23 Jan '19

23 Jan '19

Dear Community Members, The APNIC Secretariat is now seeking volunteers to serve as Chair of the Policy SIG for a two-year term period. If you would like to nominate yourself or somebody else, please do so before the deadline. Nominations will be accepted only by using the online form: https://2019.apricot.net/apnic-sigs/elections/ The deadline for nominations is: ------------------------------------------ 23:59 (UTC +10) Friday, 22 February 2019 The responsibilities are outlined in Section 2.3 of the APNIC SIG Guidelines. https://www.apnic.net/sig-guidelines The election will be the first agenda item of the APNIC Policy SIG meeting on Wednesday, 27 February 2019. Kind regards, George Odagi Internet Resource Analyst/Policy Support, APNIC e: godagi(a)apnic.net p: +61 7 3858 3191 f: +61 7 3858 3199 www.apnic.net _______________________________________________________ Join the conversation: https://blog.apnic.net/ _______________________________________________________

1 0

APNIC EC endorses prop-125 - Validation of abuse-mailbox and other IRT emails
by Srinivas Chendi 16 Jan '19

16 Jan '19

_______________________________________________________________________ APNIC EC endorses policy proposal _______________________________________________________________________ Dear colleagues The APNIC EC (Executive Council) endorsed the proposal "prop-125: Validation of abuse-mailbox and other IRT emails" at its meeting on 5-7 December 2018. Minutes from this meeting will be available after they have been adopted at the next EC meeting. As this proposal is complex, it requires more technical changes to APNIC software and Whois. Therefore, it will be implemented by the APNIC Secretariat during the second quarter of 2019. 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-125/ Regards -- _______________________________________________________________________ Srinivas (Sunny) Chendi Senior Advisor - Policy and Community Development Asia Pacific Network Information Centre (APNIC) | Tel: +61 7 3858 3100 PO Box 3646 South Brisbane, QLD 4101 Australia | Fax: +61 7 3858 3199 6 Cordelia Street, South Brisbane, QLD | http://www.apnic.net _______________________________________________________________________

1 0

prop-124-version 5: Clarification on IPv6 Sub-Assignments
by Bertrand Cherrier 10 Jan '19

10 Jan '19

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.palet(a)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 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 (already reached consensus), LACNIC and ARIN. 4. Proposed policy solution --------------------------- Add a new paragraph after the existing one in 2.2.3. 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 exclusive use within the infrastructure they operate, as well as for interconnection purposes. The address space assignment is only for use by the original holder of said assignment, as well as for third party devices, as long as they are operating within the original holder infrastructure. Sub-assignments are not allowed outside that infrastructure (for example using sub-assignments for ISP customers), neither for providing addressing space to third parties in data-centers (or similar cases). 5. Advantages / Disadvantages ----------------------------- Advantages: Fulfilling the objective above indicated and making sure to match the real situation in the market. Disadvantages: None foreseen. 6. Impact on resource holders ----------------------------- None. 7. References ------------- Links to RIPE policy amended and new policy proposal submitted.

2 1

Use of Confer in APNIC Policy SIG Meeting
by Sumon Ahmed Sabir 10 Jan '19

10 Jan '19

Dear Community Members, We have been using CONFER (https://confer.apnic.net/) in the Policy SIG sessions to gauge consensus primarily from remote participants but also onsite. >From our perspective it is a helpful tool to gauge the “temperature” of the participants in the room as well as those who have joined remotely, if it’s being used rationally. This tool allows participation in the PDP by those who cannot afford or have time to attend the meeting physically. In the past and at the most recent meeting, we received some concerns from few community members about using CONFER as a tool for gauging consensus and we would like to explore this further. As part of the PDP it is always preferred to encourage bottom-up participation from all. At this moment, we don't have another option in place to get opinions from remote participants other than the CONFER tool. We are seeking comments from the community to improve the CONFER tool or suggestions of any other similar tools or other means of gauging consensus from remote participants. Your constructive feedback will really help us to improve the bottom-up policy development process. Sincerely, Sumon, Bertrand, Ching-Heng APNIC Policy SIG Chairs

1 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

sig-policy January 2019