[sig-policy] Re: New proposal: prop-158-v001: IPv6 auto-allocation for each IPv4 request
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.. I would like to share key feedback in our community for prop-158,based on a meeting we organised on 31th Jan to discuss these proposals. This feedback is sent on my behalf, but please note that it is a summary of the discussions among the 12 Japanese community members (5 on-site, 7 remote) who attended the meeting. Many oppose opinions were expressed about this proposal. (comment details) - As pointed out in the Secretariat's impact assessment, it is still possible to obtain a /32 IPv6 address with one click after obtaining an IPv4 address now. On the other hand, the proposed policy automatically delegate IPv6 addresses and requires that they advertise it within two years, which may seem unfair to members who are delegated the address under the this policy. - Unfortunately, there are a certain number of applicants who do not need IPv6 addresses today. - Members who are delegated IPv4 addresses of /23 or less will also be delegated IPv6 addresses of /32, whether they want them or not, and finaly their annual membership fee will increase. Under Japanese law, this is extremely likely to violate the Antimonopoly Law as tying sales. Regards, 2024年1月15日(月) 8:39 Bertrand Cherrier via SIG-policy : > > Dear SIG members, > > A new proposal "prop-158-v001: IPv6 auto-allocation for each IPv4 request" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 57 on > Thursday, 29 February 2024. > > https://2024.apricot.net/program/program/#/day/9/ > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-158 > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > -- > > prop-158-v001: IPv6 auto-allocation for each IPv4 request > > --- > > Proposers: David Aditya Yoga Pratama (da...@idnic.net) > M. Andri Setiawan (an...@idnic.net) > > > 1. Problem statement > - > > Based on this > https://www.apnic.net/manage-ip/ipv4-exhaustion/#how-much-apnic-has, > APNIC still has around 2,539,776 available IPv4 addresses and may > claimed another 2,479,360 reserved IPv4 addresses. > > APNIC member still can get /24 of IPv4 addresses based on the current > APNIC policy. > > Most of the new IPv4 requestors are not allocated or requesting IPv6 > even though they are eligible to do so. > > The rates of IPv4 allocation is faster than IPv6 allocation and it may > keep slow the deployment of IPv6. > > APNIC associate member can get IPv6 without additional cost > (proposal-155), so APNIC member should be able to do the same when they > request IPv4 address. > > 2. Objective of policy change > -- > > Allocate IPv6 addresses to each IPv4 addresses requests to speed up the > IPv6 adoption and deployment rates. > > 3. Situation in other regions > > > AFRINIC - No such policy > ARIN - No such policy and it has no available address space to be offered > RIPE NCC - No such policy and it has no available address space to be > offered > LACNIC - IPv6 allocation request is used as “requirements” for any IPv4 > request as mentioned in their policy point 2.3.3.1 - 2.3.3.4 and 2.3.4. > “The applicant must already have at least one IPv6 block assigned by > LACNIC or, if not, must simultaneously request an initial IPv6 block in > accordance with the corresponding applicable policy. (If an applicant > has already been assigned an IPv6 block, they shall submit to LACNIC a > brief document describing their progress in the implementation of IPv6.)” > > 4. Proposed policy solution > > Add this to Section "6.1. Minimum and maximum IPv4 delegations" of the > APNIC Policy document. > > For all new and initial IPv4 delegation requests, APNIC and NI
[sig-policy] Re: New proposal - prop-157-v001: Temporary IPv4 Transfers
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.. I would like to share key feedback in our community for prop-157,based on a meeting we organised on 31th Jan to discuss these proposals. This feedback is sent on my behalf, but please note that it is a summary of the discussions among the 12 Japanese community members (5 on-site, 7 remote) who attended the meeting. While most participants understood the importance of logging the accutural resouce users, many oppose opinions were expressed about this proposal. (comment details) - Section 11.1.4. establishes a number of additional conditions, but these conditions should not be used to clarification about the transfer. - The method and criteria for checking additional conditions specified in Section11.4.1. are not clear. For example, it is not clear whether additional conditions need to be checked once at the time of application or whether it is necessary to continue to check that additional conditions are met on a regular basis. - At the end of the transfer period, the IP address is to be returned to the original organization. Is justification for IP address usage required at this time? - I believe it is important to record actual users like a this policy. Regards, 2023年12月14日(木) 11:55 Bertrand Cherrier : > > Dear SIG members, > > A new proposal "prop-157-v001: Temporary IPv4 Transfers" has been sent to > the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 57 on > Thursday, 29 February 2024. > > https://2024.apricot.net/program/program/#/day/9/ > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-157 > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > --- > > prop-157-v001: Temporary IPv4 Transfers > > > > Proposer: Jordi Palet Martinez (jordi.pa...@theipv6company.com) > > > 1. Problem statement > > When in the community we discuss the need for leasing, understood > broadly in any of its possible modalities, as one of the mechanisms to > facilitate small sets of IPv4 addresses for the transition to IPv6, > specially for new actors, there are mixed feelings about accepting the > leasing or not. However, we are forgetting that there is already a > mechanism, already accepted by the community, that could be slightly > modified to be equivalent to a leasing, and yet have many advantages for > both parties: temporary transfers. > > It is about guaranteeing compliance with the policies with a system > equivalent to leasing, and that makes it easier to avoid security > problems, keeping the control by the RIR/NIR, and the security of the > return of the addresses when the leasing period concludes. > > At the same time, it seeks to cover the need to be flexible without > excessive operational burden for the RIR/NIR, so that the leasing period > can be simply extended, since it is understood that there may be > situations in which the initially agreed period may be insufficient. > > It is important to emphasize that those who need these transfers, as a > “leasing”, tend to be smaller entities or with more moderate initial > investments and consequently are financially weaker. Therefore, given > that the ultimate goal must be the deployment of IPv6, using IPv6-only > and IPv4aaS, the number of IPv4 addresses that may be needed will be > truly reduced. > > Finally, it seeks to prioritize the benefit of the region and therefore > it makes sense that it is only applicable to operations carried out > within the region. Furthermore, this prevents permanent transfers from > losing reciprocity with those regions that require it. > > The EC could establish specific rates for this type of transfers and/or > their extensions. > > > 2. Objective of policy change > - > APNIC current policies only allow permanent IPv4 address transfers. > > This
[sig-policy] Re: New version: prop-156-v002 Assignment of Temporary IP Resources
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.. I would like to share key feedback in our community for prop-156,based on a meeting we organised on 31th Jan to discuss these proposals. This feedback is sent on my behalf, but please note that it is a summary of the discussions among the 12 Japanese community members (5 on-site, 7 remote) who attended the meeting. Many oppose opinions were expressed about this proposal. In particular, great concern was raised about APNIC's determination of whether an application is for commercial purposes or not, and many agreed. (comment details) - Is there a case for temporary use worthy of making this policy? The number of cases that are expected to be remedied by having this policy should be indicated. - If this policy is the consensus, I believe that AMM and APRICOT should also follow this policy, but will the conditions and restrictions set forth in this policy hinder the holding of AMM and APRICOT? - I wonder that ware the size of reserved resesources enough? - As was pointed out in The Secretariat's impact assessment, absolute criteria are needed to determine commercial or non-commercial use. On the other hand, in the APNIC region, which includes many regions with various business practices, it is impossible to establish such a standard criteria, and therefore, APNIC should not be allowed to determine whether it is commercial or not in reality. Regards, 2024年1月31日(水) 10:14 Bertrand Cherrier via SIG-policy : > > Dear SIG members, > > A new version of the proposal "prop-156-v002: Assignment of Temporary IP > Resources" > has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-156 > > 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. > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > --- > > prop-156-v002: Assignment of Temporary IP Resources > > > > Proposer: Christopher Hawker (ch...@thesysadmin.au) > > > 1. Problem statement > - > At the moment, APNIC does not currently have any policies or mechanisms > in place for the temporary assignment of IP resources with the exception > of experimental space, see Section 5.7 of APNIC-127: APNIC Internet > Number Resource Policies. This means that those who require resources > for temporary purposes (such as conferences and exhibitions) must use > existing delegations under other policies, which may not be in line with > justification provided when the resources were initially delegated. > > > 2. Objective of policy change > -- > The objective of this policy change is to allow for the reservation of a > /21 IPv4 prefix as well as a /29 IPv6 prefix and 8 Autonomous System > numbers, and for temporary assignments to be made from this reserved > space for purposes such as conferences and any other purpose where a > long-term assignment would not be feasible and APNIC deems appropriate. > > > 3. Situation in other regions > > RIPE NCC: RIPE-801 allows for space to be assigned on a temporary basis, > such as academic research, conferences, and other purposes as RIPE NCC > deems appropriate for a specified time-frame. > > ARIN: ARIN does not have a policy which permits or prohibits temporary > assignments. > > LACNIC: LACNIC does not have a policy which permits or prohibits > temporary assignments. > > AFRINIC: Under section 9 of their Consolidated Policy Manual titled > "Temporary Resource Allocations & Assignments", they allow for temporary > assignments to be made for conferences, exhibitions, conventions, and > other similar purposes > > > 4. Proposed policy solution > > 5.8 Temporary Assignments Policy > > 5.8.1 Introduction > > Across the Asia-Pacific region, there are a large number of conferences > that take place for the benefit of the wider internet community, such as > Network Operator Group meetings and other operational events. There may > also be requirements where a temporary assignment may be necessary where > a long-term assignment exceeding 6 months may not be feasible. > > 5.8.1.1 Scope and Goal > > This section describes the policies for the temporary assignment of IPv4 > addres
[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.. I would like to share key feedback in our community for prop-154,based on a meeting we organised on 31th Jan to discuss these proposals. This feedback is sent on my behalf, but please note that it is a summary of the discussions among the 12 Japanese community members (5 on-site, 7 remote) who attended the meeting. Many oppose opinions were expressed about this proposal. In particular, many participants share the view that the IPv4 address savings to be gained from this proposal are not worth the effort related to renumbering that many IXP stakeholders will have to bear. (comment details) - The number of IPv4 addresses that are expected to be saved by this proposal should be indicated in detail. - It was pointed out in APNIC 56 that the effort related to renumbering is very burdensome for IXP and IXP's customers, and I oppose this proposal because it is not considered about it at all in this proposal. Regards, 2023年9月9日(土) 8:07 Shaila Sharmin : > > Dear SIG members, > > A new version of the proposal "prop-154: Resizing of IPv4 assignment for > the IXPs" > has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-154 > > 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. > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > > --- > > prop-154-v002: Resizing of IPv4 assignment for the IXPs > > > > Proposer: Simon Sohel Baroi (sba...@gmail.com) >Aftab Siddiqui > > > 1. Problem statement > > According to APNIC Internet Number Resource Policies ( Ref – APNIC-127, > Dated: 22 DEC, 2022 ), an Internet Exchange Point ( IXP ) is eligible to > receive a maximum /23 of IPv4 and /48 of IPv6 resources. Usually APNIC > assign one /24 to start a new IXP. But from analysis through PeeringDB, > we found most of places the resources have been underutilized and new > IXPs are wasting a large amount of valuable IPv4 space. On the other > side there are large IXP, who can’t grow due to lack of IP resources, > where /23 is not enough as the membership size is big. The size of the > minimum and maximum range of IP delegation to new or existing IXPs is > the main problem in the current policy. > > Present IXP Status in APAC region from PeeringDB [5] : > +---+---++---+---+ > | IX Names | Peers | Vs | Peers | IX > Names | > +---+---+ +---+---+ > | BBIX Tokyo| 299 || 17 | > BBIX-Thailand | > +---+---+ +---+---+ > | JPIX TOKYO| 257 || 3 | > MekongIX | > +---+---+ +---+---+ > | Equinix Tokyo | 131 || 2 | Equinix > Mumbai| > +---+---+ +---+---+ > | JPNAP Tokyo | 211 || 13 | npIX > JWL | > +---+---+ +---+---+ > | HKIX | 296 || 3 | Vanuatu Internet > Exchange | > +---+---+ +---+---+ > | Equinix Hong Kong | 216 || 4 | > MyNAP | > +---+---+ +---+---+ > | Equinix Singapore | 422 || 25 | DE-CIX Kuala > Lumpur | > +---+---+ +---+---+ > | IIX-Jakarta | 449 || 13 | > IIX-Lampung | > +---+---+ +---+---+ > | DECIX-Mumbai | 446 || 14 | Decix > Kolkata | > +---+---+ +---+---+ > | MegaIX Sydney | 232 || 46 | EdgeIX - > Melbourne| > +---+---++---+---+ > > > 2. Objective of policy change > - > The objective of this proposal is to modify the default size of IPv4 > assignments for IXPs from up to /23
[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable
Hi Jordi, > 1) > > > > - I agree with the concept of prohibiting leases, but the proposal > > should not affect to the party who has leased the IPv4 from another party. > > If an APNIC or APNIC NIR member is doing something wrong, neither APNIC or > the NIR ca prevent the effects on third parties. This is the same for any > contractual breach, so not modified by this proposal. Is the same if a JPNIC > or APNIC member stops paying the anual fees, the resources will be reclaimed, > and the customers of that LIR/ISP will suffer the consequences and will need > to find an alternative provider, right? Basically, the addresses leased before this policy is consensus should not be subject to this policy. However, since it is not desirable to tolerate existing leases from the standpoint of policy fairness, I feel that it is necessary to operate in a way that facilitates the transfer of leased addresses to users. 2) > > - JPNIC has a text equivalent to prohibiting leasing in its guidelines. > If this proposal becomes a consensus, it is necessary to consider > including similar text in the address policy depending on its content. > > Could your provide a translation of that text, so we can better understand if > something may be adjusted from our side. The following statement is included in the guidelines. - Assigned only to networks connected to IP designated service providers. - The address assigned by the IP Designated Service Provider must be returned to the IP Designated Service Provider when the connection to the IP Designated Service Provider is lost. In principle, the address must be returned within 3 months from the date of loss of connection. * IP designated service providers: Entities that have received allocation of /23 or higher from JPNIC If this proposal reaches consensus, JPNIC and/or JPOPF will discuss whether to add similar text to the policy text as well. Thanks, --- satoru 2023年9月2日(土) 19:16 jordi.palet--- via SIG-policy : > > Hi Satoru, > > Tks for your inputs. However, I’ve some doubts. > > 1) > > > > - I agree with the concept of prohibiting leases, but the proposal > > should not affect to the party who has leased the IPv4 from another party. > > If an APNIC or APNIC NIR member is doing something wrong, neither APNIC or > the NIR ca prevent the effects on third parties. This is the same for any > contractual breach, so not modified by this proposal. Is the same if a JPNIC > or APNIC member stops paying the anual fees, the resources will be reclaimed, > and the customers of that LIR/ISP will suffer the consequences and will need > to find an alternative provider, right? > > > 2) > > > > - JPNIC has a text equivalent to prohibiting leasing in its guidelines. > > If this proposal becomes a consensus, it is necessary to consider > > including similar text in the address policy depending on its content. > > Could your provide a translation of that text, so we can better understand if > something may be adjusted from our side. > > > Regards, > Jordi > > @jordipalet > > > > El 1 sept 2023, a las 4:40, Satoru Tsurumaki escribió: > > > > Dear Colleagues, > > > > I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. > > > > I would like to express my gratitude to Policy-Sig Chair/Co-Chair and > > the APNIC Secretariat. > > In the past, policy proposals were posted to the SIG-Policy ML in > > batches after the proposal > > deadline four weeks before OPM, but now they have posted the proposed > > policies sequentially > > to the SIG-Policy ML without waiting for the deadline. > > This allowed us enough time to translate the proposals and introduce > > them to our community for discussion. > > > > Then I would like to share key feedback in our community for prop-148, > > based on a meeting we organised on 30th Aug to discuss these proposals. > > > > Many neutral opinions were expressed about this proposal. > > > > (comment details) > > - I agree with the concept of prohibiting leases, but the proposal > > should not affect to the party who has leased the IPv4 from another party. > > > > - JPNIC has a text equivalent to prohibiting leasing in its guidelines. > > If this proposal becomes a consensus, it is necessary to consider > > including similar text in the address policy depending on its content. > > > > Regards, > > > > Satoru Tsurumaki / JPOPF Steering Team > > > > 2023年8月5日(土) 2:00 Shaila Sharmin : > >> > >> Dear SIG members, > >> > >> A new version of the proposal "prop-148-v004: Clarification - Leasing of > >
[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share key feedback in our community for prop-154, based on a meeting we organised on 30th Aug to discuss these proposals. Many Negative opinions were expressed about this proposal. (comment details) - Renumbering is very labor intensive. Some users may stop planning to connect to the /26 IXP because they do not want to renumber in the future. - Who will manage the reverse DNS for longer than /24 prefixes ? If it is managed by APNIC or NIR, it would require a major modification such as system change. - It is hard to imagine that so many new IXPs will be established before IPv4 addresses run out, So it is assumed that the IPv4 that can be saved will be limited. The disadvantages may be greater when compared to the effort and cost for APNICs, IXPs, and IXP users to implement this proposal. Regards, Satoru Tsurumaki / JPOPF Steering Team > > Dear SIG members, > > A new proposal "prop-154-v001: Resizing of IPv4 assignment for the IXPs" has > been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on > Thursday, 14 September 2023. > > https://conference.apnic.net/56/program/program/#/day/8/ > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important part of > the Policy Development Process (PDP). > We encourage you to express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-154 > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > --- > > prop-154-v001: Resizing of IPv4 assignment for the IXPs > > > > Proposer: Simon Sohel Baroi (sba...@gmail.com) >Aftab Siddiqui > > > 1. Problem statement > > According to APNIC Internet Number Resource Policies ( Ref – APNIC-127, > Dated: 22 DEC, 2022 ), > an Internet Exchange Point ( IXP ) is eligible to receive a maximum /23 > of IPv4 and /48 of IPv6 > resources. Usually APNIC assign one /24 to start a new IXP. But from > analysis through PeeringDB, > we found most of the places the resources have been under-utilised and new > IXPs are wasting a large > amount of valuable IPv4 spaces. On the other side there are large IXP, > who can’t grow due to > lack of IP resources, where /23 is not enough as the membership number > is big. The size of the > minimum and maximum range of IP delegation to new or existing IXPs is > the main problem in the > current policy. > > Present IXP Status in APAC region from PeeringDB [5] : > > +---+---++---+---+ > | IX Names | Peers | Vs | Peers | IX > Names | > +---+---+ +---+---+ > | BBIX Tokyo| 299 || 17 | > BBIX-Thailand | > +---+---+ +---+---+ > | JPIX TOKYO| 257 || 3 | > MekongIX | > +---+---+ +---+---+ > | Equinix Tokyo | 131 || 2 | Equinix > Mumbai| > +---+---+ +---+---+ > | JPNAP Tokyo | 211 || 13 | npIX > JWL | > +---+---+ +---+---+ > | HKIX | 296 || 3 | Vanuatu Internet > Exchange | > +---+---+ +---+---+ > | Equinix Hong Kong | 216 || 4 | > MyNAP | > +---+---+ +---+---+ > | Equinix Singapore | 422 || 25 | DE-CIX Kuala > Lumpur | > +---+---+ +---+---+ > | IIX-Jakarta | 449 || 13 | > IIX-Lampung | > +---
[sig-policy] Re: prop-153-v001: Proposed changes to PDP
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share key feedback in our community for prop-152, based on a meeting we organised on 30th Aug to discuss these proposals. Almostly support opinions were expressed about this proposal. (comment details) - It is good to define what is not defined in the current policy. Regards, Satoru Tsurumaki / JPOPF Steering Team > > Dear SIG members, > > A new proposal "prop-153-v001: Proposed changes to PDP" has been sent to > the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on > Thursday, 14 September 2023. > > https://conference.apnic.net/56/program/program/#/day/8/ > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-153 > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > --- > > prop-153-v001: Proposed changes to PDP > > > > Proposer: Bertrand Cherrier (b.cherr...@micrologic.nc) > > > 1. Problem statement > > There has been confusion with the deadline for submission of a proposal. > > > 2. Objective of policy change > - > Define the deadline and remove any confusion. > > > 3. Situation in other regions > - > N/A > > > 4. Proposed policy solution > --- > > 4. Proposal process > > A policy proposal must go through the following chronological steps in > order to be adopted by APNIC. The time and date are set by the location > of OPM at the upcoming APNIC conference. > > Step 1 Discussion before the OPM > > A formal proposal must be submitted to the Policy SIG Chairs from > midnight the day following the OPM ends and five(5) weeks before the > next 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 as > mentioned in Section 5.4 of this document. > > Accepted proposals will be sent to the Policy SIG mailing list, by the > Chairs, for discussion at least four(4) weeks before the start of the OPM. > > If the five(5) weeks deadline is not met, proposals may still be > submitted and presented for discussion at the OPM; however, no decision > may be made by the OPM regarding the proposal. The proposal will need to > be resubmitted in time for the following OPM, if the author wishes to > pursue the proposal. > > If a proposal did not reach consensus, it will have to be amended to > address the issues raised before re-submission, and sent to the Policy > SIG Chairs before the five(5) weeks deadline, otherwise it will be > dropped by the Chairs. > > > 5. Advantages / Disadvantages > - > Advantages: > Remove any confusion in the actual text. > > Disadvantages: > None. > > > 6. Impact on APNIC > -- > Minimum (editorial changes). > > > References > -- > https://www.apnic.net/about-apnic/corporate-documents/documents/policy-development/development-process/ > ___ > SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ > To unsubscribe send an email to sig-policy-le...@lists.apnic.net ___ SIG-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an email to sig-policy-le...@lists.apnic.net
[sig-policy] Re: Prop-152-v001: Reduce the IPv4 delegation from /23 to /24
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share key feedback in our community for prop-152, based on a meeting we organised on 30th Aug to discuss these proposals. Almostly neutral opinions were expressed about this proposal. (comment details) - Organizations that assigned only /24 under the current policy should have been able to assign an additional /24, so consideration should be given to such organizations. - Since the current policy is the result of sufficient similar discussions, there is no need to change the policy to postpone the exhaustion. - There are other means of acquiring addresses, such as transfer. Regards, Satoru Tsurumaki / JPOPF Steering Team > > Dear SIG members, > > A new proposal "prop-152: Reduce the IPv4 delegation from /23 to /24" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on > Thursday, 14 September 2023. > > https://conference.apnic.net/56/program/program/#/day/8/ > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-152 > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > --- > > prop-152-v001: Reduce the IPv4 delegation from /23 to /24 > > > > Proposer: Rajesh Chharia (r...@cjnet4u.com) and Vivek Narayan > (ddgds-...@nic.in) > > > 1. Problem statement > > APNIC's available IPv4 addresses in the final 103/8 are down to 0.3%, > and APNIC will soon begin > delegating from the recovered and/or reserved address space. > > Delegated: 887,431,680 (99.5%) > Available: 2,792,192 (0.3%) > Reserved: 1,293,568 (0.1%) > > Note: ‘Reserved’, as defined by APNIC, means the resource has not been > allocated or assigned to > any entity and is not available for allocation or assignment. This may > include reserved space as > defined in the policy document or by the IETF, voluntarily returned > space that is undergoing > quality checks, or reclaimed space awaiting administrative clearance. > > > 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 /23 from the APNIC 103/8 IPv4 address pool. > > As stated above, the available APNIC 103/8 IPv4 address pool for APNIC > account holders is shrinking. > > At the rate of current delegation size, it is expected that this pool > will be depleted in 2024. > > To further accelerate Internet growth in the Asia Pacific region, it is > recommended that some > IPv4 address space be made available in the APNIC service region for new > businesses, startups, > and so on, so that they can prepare for IPv6 migration rather than > purchasing market transfers, > which may be prohibitively expensive for new entrants. > > Account holders who have already received IPv4 addresses will be > motivated to implement IPv6. > > > 3. Situation in other regions > - > There is no similar policy in place in other RIR regions. > > > 4. Proposed policy solution > --- > 1. No change to the current policy[1] to 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 /23 from the APNIC 103/8 IPv4 address pool. APNIC can continue > with this policy until > all of the available 2,792,192 (0.3%) resources are depleted. > > 2. Once the available 2,792,192 (0.3%) resources are depleted, APNIC and > NIR account holders > who already received IPv4 address space cannot receive any further IPv4 > addresses. > > 3. APNIC and NIRs will delegate a maximum of /24 I
[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to express my gratitude to Policy-Sig Chair/Co-Chair and the APNIC Secretariat. In the past, policy proposals were posted to the SIG-Policy ML in batches after the proposal deadline four weeks before OPM, but now they have posted the proposed policies sequentially to the SIG-Policy ML without waiting for the deadline. This allowed us enough time to translate the proposals and introduce them to our community for discussion. Then I would like to share key feedback in our community for prop-148, based on a meeting we organised on 30th Aug to discuss these proposals. Many neutral opinions were expressed about this proposal. (comment details) - I agree with the concept of prohibiting leases, but the proposal should not affect to the party who has leased the IPv4 from another party. - JPNIC has a text equivalent to prohibiting leasing in its guidelines. If this proposal becomes a consensus, it is necessary to consider including similar text in the address policy depending on its content. Regards, Satoru Tsurumaki / JPOPF Steering Team 2023年8月5日(土) 2:00 Shaila Sharmin : > > Dear SIG members, > > A new version of the proposal "prop-148-v004: Clarification - Leasing of > Resources is not Acceptable" has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-148 > > 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. > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > --- > > prop-148-v004: Clarification - Leasing of Resources is not Acceptable > > -- > > Proposer: Jordi Palet Martinez (jordi.pa...@theipv6company.com) >Amrita Choudhury (amritachoudh...@ccaoi.in) >Fernando Frediani (fhfred...@gmail.com) > > > 1. Problem statement > > RIRs have been conceived to manage, allocate and assign resources > according to need, in such way that a LIR/ISP has addresses to be able > to directly connect its customers based on justified need. Addresses are > not, therefore, a property with which to trade or do business. > > When the justification of the need disappears or changes, for whatever > reasons, the expected thing would be to return said addresses to the > RIR, otherwise according to Section 4.1. (“The original basis of the > delegation remains valid”) and 4.1.2. (“Made for a specific purpose that > no longer exists, or based on information that is later found to be > false or incomplete”) of the policy manual, APNIC is not enforced to > renew the license. An alternative is to transfer these resources using > the appropriate transfer policy. > > If the leasing of addresses is authorized, contrary to the original > spirit of the policies and the very existence of the RIRs, the link > between connectivity and addresses disappears, which also poses security > problems, since, in the absence of connectivity, the resource holder who > has received the license to use the addresses does not have immediate > physical control to manage/filter them, which can cause damage to the > entire community. > > Therefore, it should be made explicit in the Policies that the Internet > Resources should not be leased “per se”, but only as part of a > connectivity service, as it was documented with the original need > justification. > > The existing policies of APNIC are not explicit about that, however > current policies do not regard the leasing of addresses as acceptable, > if they are not an integral part of a connectivity service. > Specifically, the justification of the need would not be valid for those > blocks of addresses whose purpose is not to directly connect customers > of an LIR/ISP, and consequently the renewal of the annual license for > the use of the addresses would not be valid either. Sections 3.2.6. > (Address ownership), 3.2.7. (Address stockpiling) and 3.2.8. > (Reservations not supported) of the policy manual, are keys on this > issue, but an explicit clarification is required. > > 2. Objective of policy change > - > Despite the fact that the intention in this regard underlies the entire > Policy Manual text and is thus applied to justify the need for > resources, this proposal makes this aspect exp
[sig-policy] Re: prop-151-v001: Restricting non hierarchical as-set
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.. I would like to share key feedback in our community for prop-151, based on a meeting we organised on 15th Feb to discuss these proposals. Many participants support the intent of this proposal, but do not believe it should be discussed in Policy SIG. (comment details) - I agree with the purpose of the proposal, but I wonder if it is not something that should be discussed in the sig policy. - I think the problem is how to determine which AS number to permit. - I do not oppose this proposal, but I do not think we should have excessive expectations of IRR. - This proposal should be discussed globally by MANRS or others, not by APNIC Policy SIG. Regards, Satoru Tsurumaki / JPOPF Steering Team 2023年1月20日(金) 9:25 Bertrand Cherrier : > > Dear SIG members, > > The proposal "prop-151: Restricting non hierarchical as-set" has been > sent to > the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on > Wednesday, 1 March 2023. > > https://conference.apnic.net/55/program/schedule/#/day/10 > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-151 > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > > > prop-151-v001: Restricting non hierarchical as-set > > > > Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com) > > > 1. Problem statement > > An as-set (RFC 2622 Section 5.1) provides a way to document the > relationship between ASes which can then be publicly verified. RFC2622 > further defines 2 categories for as-set which can be Hierarchical or Non > Hierarchical. A hierarchical set name is a sequence of set names and AS > numbers separated by colons ‘:’ e.g. AS4826:AS-VOCUS > > Non hierarchical as-set pose a security issue where any one can create > an as-set without any authentication or authorisation e.g. any member > can create AS-FACEBOOK (if available) without authorisation from > Facebook. Since many peering filters are based on as-set, creating a > blank as-set or as-set with wrong members can cause automated filters to > apply empty prefix-filters to BGP session. > > > 2. Objective of policy change > - > Restrict APNIC members to create non hierarchical as-set and notify all > members who already have non hierarchical as-set that it is recommended > to move them to hierarchical as-set. > > > 3. Situation in other regions > - > - RIPE NCC has recently implemented restriction of non hierarchical as-set > - LACNIC IRR supports only hierarchical as-set > > > 4. Proposed policy solution > --- > APNIC members are only allowed to create hierarchical as-set. As defined > in the RFC2622 Section 5 "A hierarchical set name is a sequence of set > names and AS numbers separated by colons ":". At least one component of > such a name must be an actual set name (i.e. start with one of the > prefixes above). All the set name components of an hierarchical name > has to be of the same type." > > An as-set object with name AS65536:.. can only be created by the > maintainer of the AS65536. Therefore, this must be the only allowed > structure for hierarchical as-set. > > Any non hierarchical as-set can not be used as a parent to create a > hierarchical as-set e.g. AS-AFTAB (non hierarchical as-set) should not > be allowed to create AS-AFTAB:AS141384 (hierarchical as-set). > > > 5. Advantages / Disadvantages > - > Advantages: > This will protect members from intentional or unintentional creation of > as-set which already exist in other IRR databases creating name collision. > > Disadvantages: > Overhead for APNIC to notify existing non hierarchical as-set > maintainers about the policy update. > > &g
[sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share key feedback in our community for prop-150, based on a meeting we organised on 15th Feb to discuss these proposals. The Various opinions were expressed about this proposal. (comment details) - I support this proposal if it not cause the increasing APNIC's load. - I beleive that ROA and whois should be discussed separately, since what is required for RoA and whois is different in terms of accuracy, etc. - Essentially, APNIC should not allow such strange registrations. Regards, Satoru Tsurumaki / JPOPF Steering Team 2023年1月30日(月) 9:55 Bertrand Cherrier : > > Dear SIG members, > > A new version of the proposal "prop-150: ROA/whois object with Private, > Reserved and Unallocated (reserved/available) Origin ASN" has been sent to > the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on > Wednesday, 1 March 2023. > > https://conference.apnic.net/55/program/schedule/#/day/10 > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-150 > > Regards, > Bertrand, Shaila, and Anupam > Chairing the best SIG of all : The APNIC Policy SIG > > > -- > > > prop-150-v002: ROA/whois object with Private, Reserved and Unallocated > (reserved/available) Origin ASN > > -- > > > Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com) > > > 1. Problem statement > > Prop-138v2 was converted into a guideline with the understanding that it > will help members to understand not to create ROA with Private, Reserved > and unallocated ASN range. Unfortunately, there are still ROAs with > specified ranges. > > Additionally, if a member creates a ROA with someone else's ASN as > Origin and if APNIC reclaims that ASN due to any policy reason > (non-payment, account closure etc) then this leaves a security issue for > the member. > > > 2. Objective of policy change > - > Restrict APNIC members to create ROAs with private, reserved or > unallocated ASN. Also, notify members if the Origin ASN in their ROA has > been unallocated (reserved/available) and don't automatically renew > those ROAs with unallocated (reserved/available) ASN. > > > 3. Situation in other regions > - > ROAs containing Private and Reserved ASN are visible from APNIC, LACNIC > and RIPE NCC region. > > > 4. Proposed policy solution > --- > Route Origin Authorisation (ROA) is an RPKI object signed by a prefix > holder authorising origination of said prefix from an origin AS > specified in said ROA. It verifies whether an AS is authorised to > announce a specific IP prefix or not. ROA contains 3 mandatory fields > Prefix, Origin AS and Maxlength. > > Prefix: The prefix you would like to originate from the specified ASN. > IPv4 and IPv6 Prefixes listed under "Internet Resources" on My APNIC > portal can only be used here. > > Origin AS: The authorised ASN which can originate the "Prefix". The > origin AS can only be from the IANA specified range and MUST not contain > an ASN from: > > - 23456# AS_TRANS RFC6793 > - 64496-64511 # Reserved for use in docs and code RFC5398 > - 64512-65534 # Reserved for Private Use RFC6996 > - 65535# Reserved RFC7300 > - 65536-65551 # Reserved for use in docs and code RFC5398 > - 65552-131071 # Reserved > - 42-4294967294# Reserved for Private Use RFC6996 > - 4294967295 # Reserved RFC7300 > > And any IANA unallocated ASN. Route Management system should inform the > member why these Origin ASNs are not acceptable. AS0 (zero) is also a > Reserved ASN (RFC760
[sig-policy] Re: prop-149-v001: Change of maximum delegation for less than /21 total IPv4 holdings
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share key feedback in our community for prop-149, based on a meeting we organised on 15th Feb to discuss these proposals. Negative opinion were expressed on this proposal. (comment details) - IPv4 addresses do not have to be used up. What is the problem if they are kept dead for 4 years? - Since the last IPv4 delegation was originally intended for transition to IPv6, there would be no need to change the delegation size if that had not changed. - We should go back to the original purpose of ipv4 delegation. It was to encourage players such as newcomers to organize IPv6 network. To do this, they need a certain amount of ipv4 in IPv6 NW. So we should keep ipv4 in pool until we no longer need to use ipv4. Regards, Satoru Tsurumaki / JPOPF Steering Team 2023年1月20日(金) 9:23 Bertrand Cherrier : > > Dear SIG members, > > The proposal "prop-149: Change of maximum delegation for less than /21 > total > IPv4 holdings" has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on > Wednesday, 1 March 2023. > > https://conference.apnic.net/55/program/schedule/#/day/10 > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-149 > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > - > > > prop-149-v001: Change of maximum delegation for less than /21 total IPv4 > holdings > > - > > > Proposer: Shubham Agarwal (shubham8a...@gmail.com) >Gaurav Kansal gaurav.kan...@nic.in > > > 1. Problem statement > > Over the last three years, no more than 8,00,000 IPv4 addresses have > been reassigned in a single year. > > Status of IPv4 Allocation by APNIC in 2022: > > Available Pool: 2,593,792 IPv4 Address | about 5,066 Of /23 > Reserved Pool: 1,702,144 IPv4 Address | about 3,300 Of /23 > > A sizable portion of the IPv4 pool is 'available+reserved' at APNIC. If > APNIC continues to delegate /23 > IPv4 at its current rate of 145 x /23 delegations per month, the pool > will be depleted by the end of 2027. > > This implies that a significant portion of the IPv4 address space will > remain available or unallocated > for an extended period of time, and that a sizable community may > continue to face resource shortages. > > This is a proposal to give APNIC account holders with fewer than /21 > delegated IPv4 resources (i.e. fewer > than 2,048 IPs) access to an additional /23 IPv4 address block. > > > 2. Objective of policy change > - > According to the current IPv4 allocation policy, APNIC account holders > are only qualified to receive IPv4 > address delegations totaling a maximum of 512 (/23) from the APNIC 103/8 > IPv4 address pool. The current > minimum delegation size for IPv4 is 256 (/24) addresses. It is as per > APNIC defined current minimum and > maximum IPv4 delegation policy. > > Thus, this proposal permits account holders to use an additional /23 if > their total number of delegated > IPv4 addresses is fewer than 2,048 (less than /21). > > Due to the increase in the maximum IPv4 delegation size from 512 (/23) > to 1024 (/23 + /23) address pool, > the number of IPv4 address resources will increase for new and existing > APNIC account holders with a > total number of delegated IPv4 addresses less than 2,048 (less than /21). > > > 3. Situation in other regions > - > Other RIR regions do not have a similar policy in place. > > > 4. Proposed policy solution > --- > Current Policy text: > > Since Thursday, 28 February 2019, each APNIC account holder is only > eligible to receive IPv4 address > delegations totaling a maximum /23 from the APNIC 103/8 IPv4
[sig-policy] Re: prop-147-v003: Historical Resources Management
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share key feedback in our community for prop-147, based on a meeting we organised on 15th Feb to discuss these proposals. Almost Japanese community members were expressed in favor of this proposal. (comment details) - I favor with this proposal, including the 12-month claim acceptance period. Regards, Satoru Tsurumaki / JPOPF Steering Team 2023年1月20日(金) 9:21 Bertrand Cherrier : > > Dear SIG members, > > A new version of the proposal "prop-147: Historical Resources Management" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on > Wednesday, 1 March 2023. > > https://conference.apnic.net/55/program/schedule/#/day/10 > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > The comment period on the mailing list before the OPM is an important > part of the Policy Development Process (PDP). We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more effective? > > Information about this proposal is appended below as well as available at: > > http://www.apnic.net/policy/proposals/prop-147 > > Regards, > Bertrand, Shaila, and Anupam > APNIC Policy SIG Chairs > > > --- > > prop-147-v003: Historical Resources Management > > > > Proposer: Jordi Palet Martinez (jordi.pa...@theipv6company.com) > > > 1. Problem statement > > Section 4.2.1 is outdated and only looking for very old non-routed > resources. > > The recent EC resolution (22nd February 2022), imply that historical > resource holders in the APNIC region would need to become Members or > Non-Members by 1st January 2023 in order to continue to receive > registration services. Failing this, historical resource registration > will no longer be published in the APNIC Whois Database and said > resources will be placed into reserved status. > > Per current policies, all current and historical resources that are > marked as reserved are automatically added to the AS0. > > Given the continued need for IPv4 addresses, it would seem illogical to > keep these unused historical resources in reserve indefinitely. > Alternatively, these resources can be used in a way that is sufficiently > justified in accordance with existing policies, allowing other > organizations to benefit from them during the IPv6 transition. > > > 2. Objective of policy change > - > Ensure that historical IPv4 resources are justified and claimed, or that > they are available for other organizations that require them. > > If the resources are marked as reserved, the original holders may > reclaim them with a valid justification, when APNIC failed to contact > them for whatever reason. > > One example of a valid justification is the case where an organization > is actually using them internally and there are valid reasons to instead > use RFC1918 space, however the space is not routed. > > To give the original resource holders more time to reclaim them, and > ensure that APNIC has no challenges in finalizing the work, we propose a > time-frame of 12 months. > > > 3. Situation in other regions > - > In other RIRs legacy resources lose their legacy status when the RSA is > signed (upon receiving other resources), so they become under the > regular monitoring. In other cases, there is nothing specified by policies. > > > 4. Proposed policy solution > --- > REMOVE: > 4.2.1. Recovery of unused historical resources > > To recover these globally un-routed resources and place them back in the > free pool for re-delegation, APNIC will contact networks responsible for > historical address space in the APNIC region that has not been globally > routed since 1 January 1998. To recover un-routed historical AS numbers, > APNIC will contact networks responsible for resources not globally used > for a reasonable period of time. > > ADD: > > 4.3. Historical Resources Management > > a) Historical resources currently marked as reserved. > The custodians can claim historical resources that have been marked as > res
Re: [sig-policy] prop-132-v001 AS0 for Bogons
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-132, based on a meeting we organized on 21th Aug to discuss these proposals. Please note that these discussion is based on the first Proposal, prop-132-0001. Many participants basically support this proposal. But If an incorrect ROA is created due to a miss-operation or unexpected trouble, not only the quality of the network will be degraded, but it may adversely affect the deployment of RPKI in this community. We hope careful deployment such as having a sufficient test period if this proposal reach consensus. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月9日(金) 19:02 Sumon Ahmed Sabir : > > > Dear SIG members, > > The proposal "prop-132-v001: AS0 for Bogons" 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-132 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-132-v001: AS0 for Bogons > > -- > > Proposer: Aftab Siddiqui >aftab.siddi...@gmail.com > > > 1. Problem statement > > 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. See [RFC3330] and [RFC1918]. > > As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global > routing table. 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. Beside all these attempts the > issue > of Bogon Advertisement hasn't be resolved so far. > > > 2. Objective of policy change > - > The purpose of creating AS0 (zero) ROAs for unallocated address space by > APNIC > is to resolve the issue of Bogon announcement. When APNIC issues an AS0 > ROA for > unallocated address space in its bucket then it will be marked as > “Invalid” if > someone tries to advertise the same address space. > > 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 address space > in its bucket > (IPv4 and IPv6). Any resource holder can create AS0 (zero) ROAs for the > resources they > have under their account. > > A ROA is a positive attestation that a prefix holder has authorised an > AS to originate a > route for this prefix whereas, a 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 ROAs for address space not yet > allocated to the members > and only APNIC can issue AS0 (zero) ROAs. Once they ROA is issued and > APNIC wants to allocate &
Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-131, based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a opposing for the proposal with reasons that the policy document should not refer the document(RIPE BCOP) which was made and managed by out of our community and if the document is unintentionally modified or obsolete, we cannot control it. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月9日(金) 18:59 Sumon Ahmed Sabir : > > > Dear SIG members, > > The proposal "prop-131-v001: Editorial changes in IPv6 Policy" has been > sent to > the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > Information about this proposal is available at: > http://www.apnic.net/policy/proposals/prop-131 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-131-v001: Editorial changes in IPv6 Policy > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > This proposal suggests multiple (mainly) editorial changes in the IPv6 > Policy. > The intent is to remove non-necessary text, and simplify the policy. > > Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is > removed, > as it is something obvious that operators need to assign some space for > different > parts of their own infrastructure. > > Section 5.2.4.3. explicitly states that it was drafted at a time when > there was no > experience with IPv6 deployment, which is this is longer the case, it > does not make > sense to have NIR/RIR to evaluate each instance where an LIR has an End > User whose > end site(s) requires a shorter prefix than a /48. > > Finally, section 10.1.4.1. is reworded, taking advantage of some of the > editorial > changes in the precedent sections, so to avoid duplicating text. > > > > 2. Objective of policy change > - > > Fulfil the above indicated edits. > > > 3. Situation in other regions > - > > A similar proposal has been submitted to RIPE. > > > 4. Proposed policy solution > --- > > Current Text > 5.2.4.2. Assignment address space size > > ... > > End-users are assigned an end site assignment from their LIR or ISP. The > exact size of > the assignment is a local decision for the LIR or ISP to make, using a > minimum value of > a /64 (when only one subnet is anticipated for the end site) up to the > normal maximum of > /48, except in cases of extra large end sites where a larger assignment > can be justified. > > ... > > > New Text > 5.2.4.2. Assignment address space size > > ... > > End Users are assigned an end site assignment from their LIR or ISP. The > size of the > assignment is a local decision for the LIR or ISP to make, using a value > of "n" x /64. > BCOP RIPE690 Section 4.2, provides guidelines about this. > > ... > > == > > Current Text > 5.2.4.3. Assignment of multiple /48s to a single end site > > When a single end site requires an additional /48 address block, it must > request the > assignment with documentation or materials that justify the request. > Requests for multiple > or additional /48s will be processed and reviewed (i.e., evaluation of > justification) at > the RIR/NIR level. > > Note: There is no experience at the present time with the assignment of > multiple /48s to > the same end site. Having the RIR review all such assignments is > intended to be a temporary > measure until some experience has been gained and some common policies >
Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of transfer policies
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-130, based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a neutral for the proposal with reasons that they don't imagine the reason why we need to change the policy. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年3月14日(木) 21:59 Sumon Ahmed Sabir : > > > Dear SIG members, > > The proposal "prop-130-v001: Modification of transfer policies" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > Information about this proposal is available at: > > http://www.apnic.net/policy/proposals/prop-130 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > * sig-policy: APNIC SIG on resource management policy > * > ___ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-124,based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a neutral for the proposal with reasons that the problem in the current policy is something vague. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月10日(土) 23:33 Sumon Ahmed Sabir : > > Dear SIG members > > A new version of the proposal "prop-124: Clarification on Sub-Assignments" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-124 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-124-v006: Clarification on Sub-Assignments > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > Note that this proposal is ONLY relevant when end-users obtain direct > assignments > from APNIC, or when a LIR obtains, also from APNIC, and assignment for > exclusive > use within its infrastructure. Consequently this is NOT relevant in case > of LIR > allocations. > > When the policy was drafted, the concept of assignments/sub-assignments > did not > consider a practice very common in IPv4 which is replicated and even > amplified > in IPv6: the use of IP addresses for point-to-point links or VPNs. > > In IPv4, typically, this is not a problem if NAT is being used, because > the assigned > addresses are only for the WAN link, which is part of the infrastructure > or interconnection. > > In the case of IPv6, instead of unique addresses, the use of unique > prefixes > (/64) is increasingly common. > > Likewise, the policy failed to consider the use of IP addresses in > hotspots hotspots > (when is not an ISP, for example, associations or community networks), > or the use of > IP addresses by guests or employees in Bring Your Own Device (BYOD) and > many other > similar cases. > > One more case is when an end-user contracts a third-party to do some > services in their > own network and they need to deploy their own devices, even servers, > network equipment, > etc. For example, security surveillance services may require that the > contractor provides > their own cameras, recording system, even their own firewall and/or > router for a dedicated > VPN, etc. Of course, in many cases, this surveillance system may need to > use the addressing > space of the end-user. > > Finally, the IETF has recently approved the use of a unique /64 prefix > per interface/host > (RFC8273) instead of a unique address. This, for example, allows users > to connect to a hotspot, > receive a /64 such that they are “isolated” from other users (for > reasons of security, > regulatory requirements, etc.) and they can also use multiple virtual > machines on their > devices with a unique address for each one (within the same /64). > > > 2. Objective of policy change > - > > Section 2.2.3. (Definitions/Assigned Address Space), explicitly > prohibits such assignments, > stating that “Assigned ... may not be sub-assigned”. > > It also clarifies that the usage of sub-assignments in ISPs, data > centers and similar cases > is not allowed, according to the existing practices of APNIC. > > > 3. Situation in other regions > - > > This situation, has already been corrected in AFRINIC, ARIN, LACNIC and > RIPE. > > > 4. Proposed policy solution > --- > > Current 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, >
Re: [sig-policy] Version 4 of prop-126 PDP Update
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-126, based on a meeting we organized on 21th Aug to discuss these proposals. Many participants expressed a supporting for the proposal with reasons that discussions in the mailing list will be reflected more than ever, also with the reason that expiring policy of the proposal at Step 4 sound good both author and community. And a few question were expressed as below: - In Step2, it seems difficult to understand the process. Which is correct? 1. Consensus is determined... Firstly SIG mailing list/other electronic means/the SIG session and then Member Meeting 2. Consensus is determined... Firstly SIG mailing list/other electronic means and then SIG Session Afterward Member Meeting - What is "other electronic means" ? Is it CONFER? If it is CONFER, I am concerned that CONFER does not know the exact number of people who voted. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年8月9日(金) 3:14 Sumon Ahmed Sabir : > > > Dear SIG members > > A new version of the proposal "prop-126: PDP Update" has been sent to > the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 48 in > Chiang Mai, Thailand on Thursday, 12 September 2019. > > Information about earlier versions is available from: > https://www.apnic.net/community/policy/proposals/prop-126/ > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > -- > > prop-126-v004: PDP Update > > -- > > Proposer: Jordi Palet Martínez >jordi.pa...@theipv6company.com > > > 1. Problem Statement > > > With its requirement of face-to-face participation at the OPM, the current > PDP might – at least partially – be the cause of the low levels of > community > participation in the process by using the policy mailing list. > > This proposal would allow an increased participation, by explicitly > considering > the comments in the list for the consensus determination. So, > consensus would > be determined balancing the mailing list and the forum, and would therefore > increase community participation. > > Even if this is actually done by the chairs, it is not part of the > actual PDP, > and thus constitutes a very clear and explicit violation of the PDP and > the risk > is that anyone from the community could appeal any decision based on that. > > Finally, it completes the PDP by adding a simple mechanism for solving > disagreements > during an appeals phase and an improved definition of ‘consensus’, as > well as a > complete definition of the “consensus” and “last-call”. > > > 2. Objective of policy change > - > > To allow that consensus is determined formally looking at the opinions > of community > members that are not able to travel to the meetings and facilitating a > simple method > for appeals. > > > 3. Situation in other regions > - > > The PDP is different in the different RIRs. This proposal is similar to > the RIPE PDP, > possibly the region with the broadest participation in its policy > proposal discussions, > although there are certain differences such as the mandatory use of the > mailing list and > the meeting, which is more similar to the PDP at ARIN (another region > with broad community > participation). LACNIC has recently adopted a similar policy proposal > with the same aims. > > > 4. Proposed policy solution > --- > > Current Text > Step 2: Consensus at the OPM > Consensus is defined as “general agreement” as observed by the Chair of > the meeting. > Consensus must be reached first at the SIG session and afterwards at the > Member 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. > > New Text > Step 2: Consensus Determination > Consensus is defined as “rough consensus” as observed by the Chairs. > > Consensus is determined
Re: [sig-policy] prop-129-v001: Abolish Waiting list for unmet IPv4 requests
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-129, based on a meeting we organized on 12th Feb to discuss these proposals. Substantial support expressed for the proposal with the reason that as pointed out by the proposer, the standby list is virtually ineffective. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年1月22日(火) 9:15 Bertrand Cherrier : > 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] prop-128-v001: Multihoming not required for ASN
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-128, based on a meeting we organized on 12th Feb to discuss these proposals. Substantial support expressed, subject to not deleting the "it holds previously-allocated provider independent address space" described in the current policy text. * In this proposal, "it holds previously-allocated provider independent address space" is erased. it should keep it in order to prevent unnecessary application of AS number. * In the case of IPv6, the NAT disappears and the global address is assigned to all device in the organization. If each organization uses a PI address that is not locked in to a upper provider, there is a great merit that there is no need to procure the second transit. *There are areas where have only one transit as pointed out by the proposer. This proposal has the effect that policy conforms to the actual situation as a result. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年1月22日(火) 9:14 Bertrand Cherrier : > Dear SIG members, > > The proposal "prop-128-v001: Multihoming not required for ASN" has been > sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 47 in > Daejeon, South Korea on Wednesday, 27 February 2019. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, tell >the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more >effective? > > Information about this proposal is available at: > > http://www.apnic.net/policy/proposals/prop-128 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > -- > > prop-128-v001: Multihoming not required for ASN > -- > > Proposers: Jordi Palet Martínez > jordi.pa...@theipv6company.com > 1. Problem Statement > > When the ASN assignment policy was originally designed, the reliability > of networks was not so good as today. So, at that time, it was making > sense to make sure that and ASN holder is multihomed. > > However, today this is not necessarily a reasonable requirement, and > even in some cases, some networks may require an ASN and not willing > to be multihomed (because the cost, or remote locations that have only > a single upstream, etc.), and their SLA requirements don’t need that > redundancy. > > The deployment of IPv6 also increase the need for organizations which > are not ISPs, to obtain IPv6 PI in order to have stable addresses, > and in that situation, ideally, they should announce their PI space > with their own ASN. In most cases, they don’t have to be multihomed. > 2. Objective of policy change > > To ensure that organizations which have their own routing policy and > the need to interconnect with other organizations, can do it. > > Interconnect is used here with the commonly understood meaning of > establishing a connection between two (administratively) separate > networks. > 3. Situation in other regions > > ARIN and LACNIC don’t require multihoming. RIPE requires it. AfriNIC has > a policy equivalent to APNIC, but I’m submitting 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 cri
Re: [sig-policy] Prop-127 announcement : Change maximum delegation size of 103/8 IPv4 address, pool to a /23
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-127, based on a meeting we organized on 12th Feb to discuss these proposals. Almost half of participants were oppose the proposal and almost other half ware neutral. Many opposing comments were expressed with the reasons below: * I am worried that the change a allocation size and this discussion will be repeated each time the 103/8 address pool decreases. * It should be /24 in this time if it will be changed it in the future. * I'd like to know the reason why "/23", not "/24" or other prefix size. * /23 seems too small for a newcomer. * A Newcomer can choose a transfer as a alternative if the proposal not reach consensus. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年1月18日(金) 15:17 Bertrand Cherrier : > 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 > c...@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: &
Re: [sig-policy] Version 3 - prop-126 PDP Update
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-126, based on a meeting we organized on 12th Feb to discuss these proposals. Many participants expressed a supporting for the proposal. But a few opposing comments were expressed with concern that losing opportunities for remarks of APNIC members by losing consensus call at AMM. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年1月18日(金) 9:23 Bertrand Cherrier : > Dear SIG members > > A new version of the proposal "prop-126: PDP Update" > has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > https://www.apnic.net/community/policy/proposals/prop-126/ > > You are encouraged to express your views on the proposal: > >- Do you support or oppose the proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more >effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > -- > > prop-126-v003: PDP Update > -- > > Proposer: Jordi Palet Martínez > jordi.pa...@theipv6company.com > 1. Problem Statement > > With its requirement of face-to-face participation at the OPM, the > current PDP might – at least partially – be the cause of the low > levels of community participation in the process by using the > policy mailing list. > > This proposal would allow an increased participation, by explicitly > considering also the comments in the list for the consensus > determination. So, consensus would be determined balancing the > mailing list and the forum, and would therefore increase > community participation. > > Further, policy proposals are meant for the community as a whole, > and not only APNIC members, so this proposal suggest removing > the actual “double” consensus required in both groups. > > Finally, it completes the PDP by adding a simple mechanism for > solving disagreements during an appeals phase and an improved > definition of ‘consensus’, as well as a complete definition of > the “consensus” and “last-call”. > 2. Objective of policy change > > To allow that consensus is determined also looking at the opinions > of community members that are not able to travel to the meetings, > adjust the time required before the relevant SIG to submit the > proposals, not requiring “double” consensus with the APNIC members > and facilitating a simple method for appeals. > 3. Situation in other regions > > The PDP is different in the different RIRs. This proposal is similar > to the RIPE PDP, possibly the region with the broadest participation > in its policy proposal discussions, although there are certain > differences such as the mandatory use of the mailing list and the > meeting, which is more similar to the PDP at ARIN (another region > with broad community participation). LACNIC has recently adopted > a similar policy proposal with the same aims. > 4. Proposed policy solution > > Section 4. Proposal process > > A policy proposal must go through the following chronological steps > in order to be adopted by APNIC. > > Step 1 > > Actual: > > Discussion before the OPM > > A formal proposal paper must be submitted to the SIG mailing list and to > the SIG Chair > four weeks before the start of the OPM. The proposal must be in text > which clearly > expresses the proposal, with explicit mention of any changes being > proposed to existing > policies and the reasons for those changes. The APNIC Secretariat will > recommend a > preferred proposal format. If the four-week deadline is not met, > proposals may still > be submitted and presented for discussion at the meeting; however, no > decision may > be made by the meeting regarding the proposal. The proposal will need to > be resubmitted > in time for the following meeting if the author wishes to pursue the > proposal. > > Proposed: > Discussion before the OPM > > A 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 &
Re: [sig-policy] prop-124-version 5: Clarification on IPv6 Sub-Assignments
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-124, based on a meeting we organized on 12th Feb to discuss these proposals. Many participants expressed a neutral for the proposal with reasons that the problem in the current policy is something vague. And a few opposing comments were expressed with same reason as above. Best Regards, Satoru Tsurumaki JPOPF-ST 2019年1月10日(木) 13:28 Bertrand Cherrier : > Dear SIG members, > > We wish you all the best for this new year ! > > A new version of the proposal "prop-124: Clarification on IPv6 > Sub-Assignments" > has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > https://www.apnic.net/community/policy/proposals/prop-124 > > You are encouraged to express your views on the proposal: > >- Do you support or oppose the proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more >effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > -- > > prop-124-v005: Clarification on IPv6 Sub-Assignments > -- > > Proposer: Jordi Palet Martínez > jordi.pa...@theipv6company.com > 1. Problem Statement > > When the policy was drafted, the concept of assignments/sub-assignments > did not consider a practice very common in IPv4 which is replicated and > even amplified in IPv6: the use of IP addresses for point-to-point links > or VPNs. > > In IPv4, typically, this is not a problem because the usage of NAT. > > In the case of IPv6, instead of unique addresses, the use of unique > prefixes (/64) is increasingly common. > > Likewise, the policy failed to consider the use of IP addresses in > hotspots hotspots (when is not an ISP, for example, associations or > community networks), or the use of IP addresses by guests or employees > in Bring Your Own Device (BYOD) and many other similar cases. > > One more case is when an end-user contracts a third-party to do some > services in their own network and they need to deploy their own devices, > even servers, network equipment, etc. For example, security surveillance > services may require that the contractor provides their own cameras, > recording system, even their own firewall and/or router for a dedicated > VPN, etc. Of course, in many cases, this surveillance system may need > to use the addressing space of the end-user. > > Finally, the IETF has recently approved the use of a unique /64 prefix > per interface/host (RFC8273) instead of a unique address. This, for > example, allows users to connect to a hotspot, receive a /64 such that > they are “isolated” from other users (for reasons of security, regulatory > requirements, etc.) and they can also use multiple virtual machines on > their devices with a unique address for each one (within the same /64). > 2. Objective of policy change > > Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits > such assignments, stating that “Assigned ... may not be sub-assigned”. > > This proposal clarifies this situation in this regard and better define > the concept, particularly considering new uses of IPv6 (RFC8273), by means > of new text. > > It also clarifies that the usage of sub-assignments in ISPs, data centers > and similar cases is not allowed. > 3. Situation in other regions > > This situation, has already been corrected in RIPE, and the policy was > updated in a similar way, even if right now there is a small discrepancy > between the 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 origin
Re: [sig-policy] prop-126-v001 : PDP Update
*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would like to share key feedback in our community for prop-126,based on a meeting we organised on 22nd Aug to discuss these proposals.* *Many supporting opinions were expressed about the point of confirming consensus on ML.A question of doubt and concern was expressed, in that it discontinues AMM consensus and changes the proposal's deadline.(Consensus on ML) - I support to take a consensus confirmation with ML instead of AMM. - I support on the point of view that this proposal will expand the opportunities to the remote participant to discussing about proposal. - For consensus confirmation in ML, only proposal which reached consensus in OPM are eligible and the proposal which not reached consensus are not eligible. it is not good to lose the opportunity to state a opinion at the ML about the proposal which not reach consensus.(Consensus at AMM) - The meaning of taking consensus in AMM is for members to clarify the pros and cons about APNIC’s implementation. This is not a simple substitution from AMM to ML. - In addition to the past, how about added a confirmation of consensus in ML ?(Change of deadline of proposal) - For the purpose of this proposal, it is better to have a longer online discussion period. Why shorten the deadline by proposal? The proposer should clarify the intention of wanting to move the deadline.(Other) - It is better to be able to measure the effect after change* Regards, Satoru Tsurumaki 2018-08-10 12:42 GMT+11:00 Bertrand Cherrier : > Dear SIG members, > > The proposal "prop-126-v001: PDP Update" has been sent to the Policy SIG > for review. > > It will be presented at the Open Policy Meeting at APNIC 46 in > Noumea, New Caledonia on Thursday, 13 September 2018. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > >- Do you support or oppose this proposal? >- Does this proposal solve a problem you are experiencing? If so, tell >the community about your situation. >- Do you see any disadvantages in this proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more >effective? > > Information about this proposal is available at: > > http://www.apnic.net/policy/proposals/prop-126 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > https://www.apnic.net/wp-content/uploads/2018/08/prop-126-v001.txt > -- > > prop-126-v001: PDP Update > -- > > Proposer: Jordi Palet Martínez > jordi.pa...@theipv6company.com > 1. Problem Statement > > With its requirement of face-to-face participation at the OPM, the current > PDP > might – at least partially – be the cause of the low levels of community > participation > in the process by using the policy mailing list. > > This proposal would allow an increased participation, by considering also > the comments > in the list for the consensus determination. So, consensus would be > determined balancing > the mailing list and the forum, and would therefore increase community > participation. > > Further, policy proposals are meant for the community as a whole, and not > only APNIC > members, so this proposal suggest removing the actual “double” consensus > required in > both groups. > > Moreover, requiring 4 weeks in advance to the OPM, seems unnecessary as > the consensus > determination can be done in two stages (SIG meeting and list), so the > proposal looks > for just 1 week in advance to the SIG responsible for that proposal. > > Finally, it completes the PDP by adding a simple mechanism for solving > disagreements > during an appeals phase and an improved definition of ‘consensus’. > 2. Objective of policy change > > To allow that consensus is determined also looking at the opinions of > community > members that are not able to travel to the meetings, adjust the time > required > before the relevant SIG to submit the proposals, not requiring “double” > consensus > with the APNIC members and facilitating a simple method for appeals. > 3. Situation in other regions > > The PDP is different in the different RIRs. This proposal is similar to > the RIPE PDP, > possibly the region with the broadest participation in its policy proposal > discussions, > although there are certain differences such as the mandatory use of the > mailing list > and the meeting, which is more similar to the PDP at ARIN (anothe
Re: [sig-policy] prop-125-v001: Validation of "abuse-mailbox" and other IRT emails
*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would like to share key feedback in our community for prop-125,based on a meeting we organised on 22nd Aug to discuss these proposals.Many supporting opinions were expressed on this proposal. - Agree, you should. - When mail address is posted in whois DB, a lot of SPAM is sent. We should take some measures.* Regards, Satoru Tusrumaki 2018-08-17 14:52 GMT+11:00 Sumon Ahmed Sabir : > Dear SIG members, > > The proposal "prop-125-v001: Validation of "abuse-mailbox" and other IRT > emails" has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 46 in > Noumea, New Caledonia on Thursday, 13 September 2018. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, >tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more >effective? > > Information about this proposal is available at: > >http://www.apnic.net/policy/proposals/prop-125 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt > > -- > > prop-125-v001: Validation of "abuse-mailbox" and other IRT emails > > -- > > Proposer: Jordi Palet Martínez - jordi.pa...@theipv6company.com > Aftab Siddiqui - aftab.siddi...@gmail.com > > > 1. Problem Statement > > APNIC implemented mandatory IRT references on 8 November 2010. This means > it is mandatory to register an Incident Response Team (IRT) object for each > resource record in the APNIC Whois Database. The policy mandates IRT > references for each inetnum, inet6num and aut-num objects, however in many > cases, those contain out-of-date, inaccurate, non-existent or not actively > monitored abuse-mailbox information. > > In practice, this contact becomes ineffective to report abuses and > generally gives rise to security issues and costs for the victims. > > This proposal aims to solve the problem and ensure the existence of a > proper abuse-mailbox contact and the process for its utilization. > > 2. Objective of policy change > - > The Internet community is based on collaboration. In many cases, however, > this is not enough and we all need to be able to contact those LIRs which > may be experiencing a problem in their networks and may not be aware of the > situation. > > This proposal aims to solve this problem by means of a simple, periodic > verification of IRT object emails, and establishes the basic rules for > performing such verification and thus avoids unnecessary costs to third > parties who need to contact the persons responsible for solving the abuses > of a specific network. > > The proposal guarantees that the cost of processing the abuse falls on the > LIR whose client is causing the abuse (and from whom they receive financial > compensation for the service), instead of falling on the victim, as would > be the case if they had to resort to the courts, thus avoiding costs > (lawyers, solicitors, etc.) and saving time for both parties. > > 3. Situation in other regions > - > A similar proposal is being discussed in LACNIC and being prepared for > AfriNIC and RIPE NCC. > > Currently, ARIN conducts an annual POC (point of contact) validation and > RIPE NCC validates the “abuse-mailbox:” attribute annually (ripe-705). > > 4. Proposed policy solution > --- > 1. About the "abuse-mailbox", “email”, “admin-c” and “tech-c” > > Emails sent to "abuse-mailbox", “email”, “admin-c” and “tech-c” must > require manual intervention by the recipient at some time, and may not be > filtered, as in certain cases this might prevent the reception of the abuse > reports, for example a case of spam, as it would include the spam message > itself or URLs or content usually classified as spam. > > The mailboxes may initially send an automatic reply, for example, > assigning a ticket number, applying classification procedures, req
Re: [sig-policy] Prop124 version 4
*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would like to share key feedback in our community for prop-124,based on a meeting we organised on 22nd Aug to discuss these proposals.Many supporting opinions were expressed on this proposal.However, also many concerning comment was expressed to explain the specific examples.For this matter, the same opinion was given also at JPOPM34. - It is better to stop specific examples because they tend to fall into discussion of adding / not applying / not applicable. - I think that specific examples should be stated in the guidelines rather than policies.* Regards, Satoru Tsurumaki 2018-09-09 18:37 GMT+11:00 Bertrand Cherrier : > Dear SIG members > > A new version of the proposal "prop-124: Clarification on IPv6 > Sub-Assignments" > has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > https://www.apnic.net/community/policy/proposals/prop-124 > > You are encouraged to express your views on the proposal: > >- Do you support or oppose the proposal? >- Is there anything in the proposal that is not clear? >- What changes could be made to this proposal to make it more >effective? > > Please find the text of the proposal below. > > Kind Regards, > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > -- > > prop-124-v004: Clarification on IPv6 Sub-Assignments > -- > > Proposer: Jordi Palet Martínez > jordi.pa...@theipv6company.com > 1. Problem Statement > > When the policy was drafted, the concept of assignments/sub-assignments > did not consider a practice very common in IPv4 which is replicated and > even amplified in IPv6: the use of IP addresses for point-to-point links > or VPNs. > > In the case of IPv6, instead of unique addresses, the use of unique > prefixes (/64) is increasingly common. > > Likewise, the policy failed to consider the use of IP addresses in > hotspots, > or the use of IP addresses by guests or employees in Bring Your Own Device > (BYOD) and many other similar cases. > > One more case is when an end-user contracts a third-party to do some > services > in their own network and they need to deploy their own devices, even > servers, > network equipment, etc. For example, security surveillance services may > require > that the contractor provides their own cameras, recording system, even > their > own firewall and/or router for a dedicated VPN, etc. Of course, in many > cases, > this surveillance system may need to use the addressing space of the > end-user. > > Finally, the IETF has recently approved the use of a unique /64 prefix per > interface/host (RFC8273) instead of a unique address. This, for example, > allows users to connect to a hotspot, receive a /64 such that they are > “isolated” from other users (for reasons of security, regulatory > requirements, etc.) and they can also use multiple virtual machines > on their devices with a unique address for each one (within the same /64). > 2. Objective of policy change > > Section 2.2.3. (Definitions/Assigned Address Space), explicitly prohibits > such assignments, stating that “Assigned ... may not be sub-assigned”. > > https://www.apnic.net/community/policy/resources#2.2.3.- > Assigned-address-space > > This proposal clarifies this situation in this regard and better define the > concept, particularly considering new uses of IPv6 (RFC 8273), by means of > a new paragraph. > 3. Situation in other regions > > This situation, has already been corrected in RIPE, and the policy was > updated > in a similar way, even if right now there is a small discrepancy between > the > policy text that reached consensus and the RIPE NCC Impact Analysis. A new > policy proposal has been submitted to amend that, and the text is the same > as presented by this proposal at APNIC. Same text has also been submitted > to AfriNIC, LACNIC and ARIN. > 4. Proposed policy solution > > Add a new paragraph after the existing one in 2.2.3 > https://www.apnic.net/community/policy/resources#2.2.3.- > Assigned-address-space > > Actual text: > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for specific use within the Internet infrastructure they operate. > Assignments must > only be made for specific, documented purposes and may not be sub-assigned. > > New text: > 2.2.3. Assigned address space > Assigned address space is address space that is delegated to an LIR, or > end-user, > for specific use within the Internet infrastructure they operate. > Assignments must > only be made for speci
Re: [sig-policy] A new version of the proposal "prop-118: No need policy in APNIC region"
*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would like to share key feedback in our community for prop-118,based on a meeting we organised on 22nd Aug to discuss these proposals.Many supporting opinions were expressed on this proposal.However, many comments were expressed that proposer should feedback for the discussion which we discussed in past OPM. Below are details of opinions expressed. - Demand for 5 years: It is difficult to clarify a demand of address needs for both APNIC and LIR. - The policy should be looser. it will increase a possibilities of address transfer if time frame are expand from 2 years to 5 years. - The reason why APNIC clarify the request of transfer is for tranferring from ARIN. So inter-APNIC case, it not need originally and there is no reason to make a a clarification strictly.I agree with the purpose of the proposal. - Nevertheless, proposer should respond to the past comments. - I'd like to request to proposer to explain the intention of copying the implementation contents of RIPE NCC as it is. - The content of the previous discussion has not been reflected and it is not refined. Although the position of the proposal is not in an opposite position, the proponent should explain more. Please answer the discussion at APNIC 44.* Regards, Satoru Tsurumaki 2018-08-08 4:44 GMT+11:00 Sumon Ahmed Sabir : > 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
Re: [sig-policy] prop-120-v002: Final /8 pool exhaustion plan
Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team. I would like to share a feedback in our community for prop-120, based on a meeting we organised on 31st Jan to discuss these proposals. Many supporting comment expressed on this proposal. Japanese community support prop-120. Best Regards, Satoru Tsurumaki JPOPF-ST 2018-01-30 6:34 GMT+09:00 Bertrand Cherrier <b.cherr...@micrologic.nc>: > Dear SIG members > > A new version of the proposal "prop-120: Final /8 pool exhaustion plan" > has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > https://www.apnic.net/community/policy/proposals/prop-120/ > > 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-120-v002: Final /8 pool exhaustion plan > > --- > > Proposer: Tomohiro Fujisaki >fujisaki at syce dot net > > > 1. Problem statement > > > APNIC makes IPv4 address delegation from two IPv4 pools. These are the > 103/8 (Final /8) pool and the non-103/8 IPv4 Recovered pool. > > Currently, there are no IPv4 addresses in the non-103/8 IPv4 Recovered > pool and APNIC manages a Recovered Pool Waiting List for approved > requests. And, based on the Geoff's projection (*1), the 103/8 (Final > /8) pool will be exhausted in a few years. > > It will be necessary to make a guidance about how to manage the IPv4 > delegation after both IPv4 pools exhaustion. > > > 2. Objective of policy change > - > > To provide a guidance for 103/8 pool exhaustion. > > > 3. Situation in other regions > - > > None. > > > 4. Proposed policy solution > --- > > Guidance for 103/8 pool exhaustion: > > - The first time an approved request cannot be fulfilled from the 103/8 >pool, a waiting list will be created. That waiting list will be >managed same as recovered pool waiting list. > > - APNIC continue to manage two pools, the recovered pool and the 103/8 > pool. > > 5. Advantages / Disadvantages > - > > Advantages: > > - Possible to avoid confusion at 103/8 address pool exhaustion date > > Disadvantages: > > None. > > > 6. Impact on resource holders > -- > > No impact to resource holders. > > > 7. References > - > 1. IPv4 Address Report > http://www.potaroo.net/tools/ipv4/ > > Cordialement, > ___ > Bertrand Cherrier > Administration Systèmes - R > Micro Logic Systems > b.cherr...@micrologic.nc > https://www.mls.nc > Tél : +687 24 99 24 > VoIP : 65 24 99 24 > SAV : +687 36 67 76 (58F/min) > > > * 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] sig-policy Digest, Vol 164, Issue 10
Dear Alex Thank you for your response. > In my opinion, any entity got the ipv4 blocks in 103/8 before 14 Sep 2017 should have the same right to use or transfer its blocks like others. I also think that their rights should be respected. But, > Not only the "One-time" thing ,but a long term right , thank you very much !!! The recipient entities who are transferred 103/8 after 14 Sep 2017 know prop-116. I believe they have no right to transfer a 103/8 because they understand 5 years limitation and transferred it. So, I think the number of transfer of 103/8 before 14 Sep 2017 should be limited to one. Would you please give us your opinion ? BTW, About 60%+ 103/8 has already allocated. Therefore, the consensus of prop-123 means a substantial abolition of prop-116. We need re-think why prop-116 was consensus. Thanks, Satoru Tsurumaki 2018-01-29 20:09 GMT+09:00 yang...@126.com <yang...@126.com>: > Dear Satoru > > Thank you for your question, and i mean it is really a good > question! > > In my opinion, any entity got the ipv4 blocks in 103/8 before 14 > Sep 2017 should have the same right to use or transfer its blocks like > others. > > Not only the "One-time" thing ,but a long term right , thank you > very much !!! > > -- > Alex Yang > > > *From:* sig-policy-request <sig-policy-requ...@lists.apnic.net> > *Date:* 2018-01-29 18:30 > *To:* sig-policy <sig-policy@lists.apnic.net> > *Subject:* sig-policy Digest, Vol 164, Issue 10 > Send sig-policy mailing list submissions to > sig-policy@lists.apnic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.apnic.net/mailman/listinfo/sig-policy > or, via email, send a message with subject or body 'help' to > sig-policy-requ...@lists.apnic.net > > You can reach the person managing the list at > sig-policy-ow...@lists.apnic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sig-policy digest..." > > > Today's Topics: > >1. Re: prop-123-v001: Modify 103/8 IPv4 transfer policy > (Satoru Tsurumaki) >2. Re: prop-123-v001: Modify 103/8 IPv4 transfer policy (Ajai Kumar) > > > -- > > Message: 1 > Date: Mon, 29 Jan 2018 19:03:38 +0900 > From: Satoru Tsurumaki <satoru.tsurum...@g.softbank.co.jp> > To: SIG policy <sig-pol...@apnic.net> > Subject: Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer > policy > Message-ID: > <cahxx+kqbptnrduvldtzknydhno0aqxhq4sbyxuqp8tmkq-v...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Proposer > > I would like to clarify. > > My understanding is: > Prop-116 will be subject to the 103/8 IPv4 address which allocated before > 14 Sep 2017 and be transferred after this proposal will consensus. > It's mean that these address will be allowed to transfer "ONE-TIME". > > Is it correct ? > > Regards, > > Satoru Tsurumaki > JPOPF Steering Team (former JPNIC Policy Working Group) > > > > > 2018-01-26 12:27 GMT+09:00 Bertrand Cherrier <b.cherr...@micrologic.nc>: > > > Dear SIG members, > > > > The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has > > been sent to the Policy SIG for review. > > > > It will be presented at the Open Policy Meeting at APNIC 45 in > > Kathmandu, Nepal on Tuesday, 27 February 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-123 > > > > Regards > > > > Sumon, Bertrand, Ching-Heng > > APNIC Policy SIG Chairs > > > > https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt > > > > --- > > > > prop-123-v001: Modify 103/8 IPv4 transfer poli
Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
Dear Proposer I would like to clarify. My understanding is: Prop-116 will be subject to the 103/8 IPv4 address which allocated before 14 Sep 2017 and be transferred after this proposal will consensus. It's mean that these address will be allowed to transfer "ONE-TIME". Is it correct ? Regards, Satoru Tsurumaki JPOPF Steering Team (former JPNIC Policy Working Group) 2018-01-26 12:27 GMT+09:00 Bertrand Cherrier <b.cherr...@micrologic.nc>: > Dear SIG members, > > The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has > been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 45 in > Kathmandu, Nepal on Tuesday, 27 February 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-123 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt > > --- > > prop-123-v001: Modify 103/8 IPv4 transfer policy > > --- > > Proposer:Alex Yang > yang...@126.com > > > 1. Problem statement > --- > > Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in > the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep > 2017. Since that APNIC has stopped all the IPv4 transfers from 103/8 > block if the delegation date is less than 5 years. > > However, some of the 103/8 ranges were delegated before 14 Sep 2017. > Those resources should not be subjected to 5 years restriction. The > community was not aware of the restriction when they received those > resources, some of the resources have been transferred or planning to > transfer. If APNIC is not allow those transfers to be registered, > there will be underground transfers. This will cause incorrect APNIC > Whois data. > > > 2. Objective of policy change > --- > > To keep the APNIC Whois data correct. > > > 3. Situation in other regions > --- > > No such situation in other regions. > > > 4. Proposed policy solution > --- > > “Prohibit transfer IPv4 addresses under final /8 address block (103/8) > which have not passed five years after its allocation/assignment” > should only apply to those ranges were delegated from APNIC since 14 > Sep 2017. > > > 5. Advantages / Disadvantages > --- > > Advantages: > > - Allow APNIC to register those 103/8 transfers to keep the APNIC > Whois data correct. > > > Disadvantages: > > None. > > > 6. Impact on resource holders > --- > > Resource holders are allowed to transfer 103/8 ranges if the resources > were delegated before 14 Sep 2017. > > > > 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] New proposal prop-121: Updating "InitialIPv6 allocation"
Hi Jordi, Thank you for your response. 2017-09-09 12:40 GMT+08:00 JORDI PALET MARTINEZ <jordi.pa...@consulintel.es>: > Hi all, > > See my comments below in-line as [Jordi]. > > Regards, > Jordi > > > -Mensaje original- > De: <sig-policy-boun...@lists.apnic.net> en nombre de Satoru Tsurumaki > <satoru.tsurum...@g.softbank.co.jp> > Responder a: <satoru.tsurum...@g.softbank.co.jp> > Fecha: viernes, 8 de septiembre de 2017, 14:34 > Para: SIG policy <sig-pol...@apnic.net> > Asunto: Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 > allocation" > > Dear Colleagues, > > > I am Satoru Tsurumaki from Policy Working Group in Japan. > > I would like to share key feedback in our community for prop-121, > based on a meeting we organised on 5th Sep to discuss these proposals. > > > Many opposing comments were expressed on the proposal with reasons below. > > * Under the current criteria, networks with IPv4 can receive IPv6 > easily. However, with adoption of this proposal, this consideration > based on IPv4 network will be removed, and the policy could become > more strict for some applications. > > [Jordi]I think is in the other way around. With the proposal, I’m > removing the requirement for “at least 200 customers” (there may be ISPs that > have much less number of customers than that) and “be an existing LIR with > IPv4 allocations”. There is not more IPv4 space, is not realistic to have > such requirement, furthermore, in the short term, I’m sure, there will be > IPv6-only ISPs, so again not reason for asking them to have IPv4 allocations. We support the motivation of the proposal. However, there were some who felt that this policy could make it more difficult as unintended consequence. The biggest concern is that for those networks based on IPv4, you are able to receive an equivalent IPv6 space, based on the size of your IPv4 holding. If you remove this criteria, there is no assurance to be able to receive equivalent IPv6. On this criteria, we can support if the proposal maintains evaluation based on current IPv4 holding and make it an OR condition for those who do not want to apply based on IPv4 holding. > > * Would like to confirm how specifically APNIC secretariat will > evaluate requests under this policy. The criteria becomes ambiguous > with this proposal which would make it harder for applications to > prepare for the evaluation. > > [Jordi]This has been running with the same text in RIPE region, and has > not been considered as an issue by the staff, so I guess here we can take the > advantage of that experience. > > * Approach may not be the right one to achieve the objective of IPv6 > promotion > > [Jordi]I think in the other way around, it facilitates the IPv6 > promotion, as it doesn’t require to be a “big” ISP (200 customers) neither to > have been an IPv4 one before. > > * From the current IPv6 allocation criteria, it is unlikely to have > many cases where criteria. d is being the barrier to receive IPv6 > space. > > [Jordi]Not sure what is criteria d. ? If you mean criteria 4 as in > https://www.apnic.net/community/policy/resources#Part-3:-IPv6-Policy (9.2.2. > 4), I think I’ve responded to that already with my previous responses? > > Best Regards, > > Satoru Tsurumaki > Policy Working Group > Japan Open Policy Forum > > 2017-08-09 15:19 GMT+09:00 chku <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 > > e
Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG
Dear David, Thaank you for your comment. The main point of our concern is if proposed with a set with prop-118, it may encourage the IP address to be used for abusive activities, to be able to regularly change IP address in a short time span. Please see my comments inline as clarifications on feedback from the Japanese community. 2017-09-08 17:52 GMT+08:00 David Hilario <d.hila...@laruscloudservice.net>: > Dear Satoru, > > Thank you for conveying the feedback here. > > > On 8 September 2017 at 09:32, Satoru Tsurumaki > <satoru.tsurum...@g.softbank.co.jp> wrote: >> Dear Colleagues, >> >> >> Satoru Tsurumaki, with Policy Working Group hat. >> >> I would like to share key feedback in our community for prop-119, >> based on a meeting we organised on 5th Sep to discuss these proposals. >> >> >> Many comments against this proposal were expressed. On the other hand, >> some expressed support for temporary transfer as a measure to increase >> accuracy in database. >> >> >> Concerns/Opposing comments: >> * Cannot understand the need of leasing, nor use of prefixes where >> leasing is appropriate. Leasing of address space could encourage >> prefixes to be used for abuse. (As it accommodates change of address >> range if black listed) >> > > The space will come from one LIR and returned to the same LIR. > It really isn't the offering LIRs interest to have their space blacklisted. > This is not different than when an LIR issues an IP delegation such as > an Assignment of sub-allocation in the APNIC Database, just the lease > is a bit more "formal: in that it is shown as a transfer of authority > in the Database. > >> * It will be costly to the APNIC region to adopt complex scheme of leasing. >> > > Same procedure as with any regular transfer, with the addition of a > return timer. > That should not be too costly. I wasn't being clear enough here. It will require some changes in APNIC database/WHOIS and add/change the operations of hostmaster to accommodate temporary transfers as well as for NIRs. The comment here was that it is not sure whether there is enough benefit to balance these costs (which is not just direct financial costs). > >> * Leasing should not be allowed to a third party where lease source do >> not provide connectivity, to avoid fragmentation. Leasing should be >> only within the scope where LIRs can take responsibility. >> > > LIRs are currently allowed to issue address space to other > organisation by giving them either Assignments or sub-allocations > depending on their needs of their customers. > > So Policy wise this is already a fact that it is allowed, the > temporary transfers would only formalise the transfer of authority in > the APNIC database, also giving the recipient access to all the > required tools to manage the space via MyAPNIC just like any other > address space they have. The implications of allowing lease to those who have connectivity with LIRs and those who do not are not the same. Under the current policy, LIRs must only delegate address space to networks which they provide connectivity. https://www.apnic.net/community/policy/resources#Part-1:-Policy-Environment 3.1.3. Aggregation Address policies should seek to avoid fragmentation of address ranges. Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by network operators, and to limit the expansion of Internet routing tables. This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing. It is a condition of all delegations made under initial or subsequent LIR delegation criteria, that the address space is aggregated by the LIR within a minimum number of route announcements (preferably one). LIRs must only delegate addresses to customers who will be using those addresses in relation to network connectivity services provided by the LIR. LIRs are expected to enter into agreements with their customers specifying that the end-user will hold the addresses only for so long as the end-user remains a customer of that LIR. Such agreements should also be consistent with the license under which the address space is being used by the LIR. > > >> Supportive comments/Suggestions: >> * It is better to allow temporary transfers and reflect the correct >> user of an address prefix, than a situation where registry database >> can no longer point to correct user of a prefix >> * Period of lease should be specified, such as for two years > > That should
Re: [sig-policy] New proposal prop-122-v001: Updating "Subsequent IPv6 allocation " policy
Dear Colleagues, I am Satoru Tsurumaki from Policy Working Group in Japan. I would like to share key feedback in our community for prop-122, based on a meeting we organised on 5th Sep to discuss these proposals. Many opposing comments were expressed with the same reasons as for prop-121. * Under the current criteria, networks with IPv4 can receive IPv6 easily. However, with adoption of this proposal, this consideration based on IPv4 network will be removed, and the policy could become more strict for some applications. * Would like to confirm how specifically APNIC secretariat will evaluate requests under this policy. The criteria becomes ambiguous with this proposal which would make it harder for applications to prepare for the evaluation. * Approach may not be the right one to achieve the objective of IPv6 promotion * From the current IPv6 allocation criteria, it is unlikely to have many cases where criteria. d is being the barrier to receive IPv6 space. Best Regards, Satoru Tsurumaki Policy Working Group Japan Open Policy Forum 2017-08-09 15:20 GMT+09:00 chku <c...@twnic.net.tw>: > Dear SIG members > > The proposal "prop-122-v001: Updating "Subsequent IPv6 allocation" > policy. " has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 44 which will > be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 September > 2017. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > Information about this proposal is available at: > > http://www.apnic.net/policy/proposals/prop-122 > > Regards > > Sumon, Ching-Heng, Bertrand > APNIC Policy SIG Chairs > > > > > prop-122-v001: Updating “Subsequent IPv6 allocation” policy > > > > Proposer: Jordi Palet Martinez > jordi.pa...@consulintel.es > > Problem Statement > - > If we reach consensus on the Updating "Initial IPv6 allocation" > policy, it is necessary to align the text of the subsequent allocations, > in order to be coherent and not discriminate LIRs with existing > allocations. > > If consensus on that policy proposal is not reached, this proposal also > allows LIRs with existing allocations a better justification of their > new needs and not limited to a 2 years period. > > The actual policy text (9.3.4. Size of subsequent allocation) is > assuming that an LIR will need just doubling his actual block, and then > states the possibility of more space providing the relevant > documentation. However, it is limiting that to a two-years period. > > > Objective of policy change > -- > To make sure that the subsequent IPv6 allocation policy is synchronized > with the initial allocation one. > > > Situation in other regions > -- > Both RIPE and LACNIC have approved equivalent changes. > > > Proposed policy solution > > Change some of the actual text as follows. > > > Actual text: > > 9.3.4. Size of subsequent allocation > > When an organization has achieved an acceptable utilization for its > allocated address space, it is immediately eligible to obtain an > additional allocation that results in a doubling of the address space > allocated to it. Where possible, except where separate disaggregated > ranges are requested for multiple discrete networks, the allocation will > be made from an adjacent address block, meaning that its existing > allocation is extended by one bit to the left. > > If an organization needs more address space, it must provide > documentation justifying its requirements for a two-year period. The > allocation made will be based on this requirement. > > > New text: > > 9.3.4. Size of subsequent allocation > > When an organization has achieved an acceptable utilization for its > allocated address space, it is immediately eligible to obtain an > additional allocation that results in a doubling of the addre
Re: [sig-policy] New proposal prop-121: Updating "InitialIPv6 allocation"
Dear Colleagues, I am Satoru Tsurumaki from Policy Working Group in Japan. I would like to share key feedback in our community for prop-121, based on a meeting we organised on 5th Sep to discuss these proposals. Many opposing comments were expressed on the proposal with reasons below. * Under the current criteria, networks with IPv4 can receive IPv6 easily. However, with adoption of this proposal, this consideration based on IPv4 network will be removed, and the policy could become more strict for some applications. * 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 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
Re: [sig-policy] New proposal prop-120: Final /8 pool exhaustion plan
Dear Colleagues, I am Satoru Tsurumaki from Policy Working Group in Japan. I would like to share key feedback in our community for prop-120, based on a meeting we organised on 5th Sep to discuss these proposals. Many support expressed on clarifying how IPv4 addresses should be distributed after /8 pool exhaustion. Different ideas were shared on details of how to distribute. * It is appropriate to prioritise new comers to a certain extent, as they will be challenged if they cannot receive IPv4 address block * Different comments on the size of distribution post /8 pool exhaustion 1) /21 as the upper limit Maintain the current size 2) /22 as the upper limit Adjust to the limited pool post /8 pool exhaustion 3) Two blocks of /22s as the upper limit Separate blocks for new comers and others. New comers can queue to receive the other block after receiving a block for new comers Other comments: * Care should be taken when adopting this policy, to reflect the waiting list of distribution from the returned pool * Consideration needed on how to handle transfer of 103/8 block if prop-116 is adopted (Prefixes will be mixed after the exhaustion of unallocated final /8 pool) Best Regards, Satoru Tsurumaki Policy Working Group Japan Open Policy Forum 2017-08-09 15:17 GMT+09:00 chku <c...@twnic.net.tw>: > Dear SIG members > > The proposal "prop-120: Final /8 pool exhaustion plan" 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? > - 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-120 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > --- > > prop-120-v001: Final /8 pool exhaustion plan > > --- > > Proposer: Tomohiro Fujisaki > fujis...@syce.net > > > 1. Problem statement > > > APNIC makes IPv4 address delegation from two IPv4 pools. These are the > 103/8 (Final /8) pool and the non-103/8 IPv4 Recovered pool. > > Currently, there are no IPv4 addresses in the non-103/8 IPv4 Recovered > pool and APNIC manages a Recovered Pool Waiting List for approved > requests. And, based on the Geoff's projection (*1), the 103/8 (Final > /8) pool will be exhausted in a few years. > > It will be necessary to make a guidance about how to manage the IPv4 > delegation after both IPv4 pools exhaustion. > > > 2. Objective of policy change > - > > To provide a guidance for 103/8 pool exhaustion. > > > 3. Situation in other regions > - > > None. > > > 4. Proposed policy solution > --- > > 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: > > - Possible to avoid confusion at 103/8 address pool exhaustion date > > Disadvantages: > > None. > > > 6. Impact on resource holders > -- > > No impact to resource holders. > > > 7. References > - > 1. IPv4 Address Report > http://www.potaroo.net/tools/ipv4/ > > > > > > > >
Re: [sig-policy] [Sig-policy] New version of prop-116: Prohibit to transfer IPv4 addresses in the final /8 block
Dear Colleagues, I am Satoru Tsurumaki from Policy Working Group in Japan. I would like to share key feedback in our community for prop-116, based on a meeting we organised on 5th Sep to discuss these proposals. Substantial support expressed for the proposal with reasons below. * Transfer of 103/8 block is against the original intention of the final /8 policy (103/8). * Given the purpose of 103/8 block distribution is to make the minimum IPv4 address block available until transition to IPv6, it may even be unnecessary to set the limit of "two years" to prohibit the transfer. Best Regards, Satoru Tsurumaki Policy Working Group Japan Open Policy Forum 2017-08-09 15:12 GMT+09:00 chku <c...@twnic.net.tw>: > 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. > > 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 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? > - 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, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > > > --- > > prop-116-v004: 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 | > | 2017 |45 |178 | > +--+---++- > > 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 | > | 2017 |70 | 288 | > +--+---+---+ > > 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
Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG
Hi David ,Aftab, Thank you for the reply. (snip) >> I do not believe that spammer would benefit from this policy as they >> would have to register with APNIC as members and provide all the >> needed paperwork such as company registration papers, ID/passports, >> billing address etc... > > > It will definitely support the spammers by all means. You temperorary > transfer resource to Spammer, they do their thing and get black listed > everywhere and then you get the resources back and ask everyone that we are > the new owner of this resource so kindly remove all the listing. REPEAT. agree. This proposal support the spammer and the LIR who support or earn income from the spammer. I'm afraid that those spammer and LIR can transfer the address resources more freely and frequency if both prop-119 and prop-118 will be a consensus. Satoru Tsurumaki > >> >> They are much better off renting a /24 from the black market with no >> traces or documented changes ion the address block. > > > Yup, let them pay black market rates for black market business model. > > And what will be the temporary transfer fees? same as permanent transfer > fees? or free? > > In order to resolve a corner case it will open up opertunities for spammers. > I stronly oppose it. > -- > Best Wishes, > > Aftab A. Siddiqui > > * 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-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG
I oppose this proposal. I would like to know who and why need the "temporary" address. I could not imagine the use case of this proposal except for the spammer who get the temporary address which set very short period, sent huge number of SPAM, return the address and run away. After that, the source organization might be "laundering" the address from SPAM DB, then lease this address to another spammers. I think we should oppose the proposal which might support the spammer. regards, Satoru Tsurumaki 2017-08-09 15:16 GMT+09:00 chku <c...@twnic.net.tw>: > 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-ch
