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 <b.cherr...@micrologic.nc>: > Dear SIG members, > > The proposal "prop-128-v001: Multihoming not required for ASN" has been > sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 47 in > Daejeon, South Korea on Wednesday, 27 February 2019. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, tell > the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > Information about this proposal is available at: > > http://www.apnic.net/policy/proposals/prop-128 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > ------------------------------ > > prop-128-v001: Multihoming not required for ASN > ------------------------------ > > Proposers: Jordi Palet Martínez > jordi.pa...@theipv6company.com > 1. Problem Statement > > When the ASN assignment policy was originally designed, the reliability > of networks was not so good as today. So, at that time, it was making > sense to make sure that and ASN holder is multihomed. > > However, today this is not necessarily a reasonable requirement, and > even in some cases, some networks may require an ASN and not willing > to be multihomed (because the cost, or remote locations that have only > a single upstream, etc.), and their SLA requirements don’t need that > redundancy. > > The deployment of IPv6 also increase the need for organizations which > are not ISPs, to obtain IPv6 PI in order to have stable addresses, > and in that situation, ideally, they should announce their PI space > with their own ASN. In most cases, they don’t have to be multihomed. > 2. Objective of policy change > > To ensure that organizations which have their own routing policy and > the need to interconnect with other organizations, can do it. > > Interconnect is used here with the commonly understood meaning of > establishing a connection between two (administratively) separate > networks. > 3. Situation in other regions > > ARIN and LACNIC don’t require multihoming. RIPE requires it. AfriNIC has > a policy equivalent to APNIC, but I’m submitting a proposal similar to > this one to change it as well as in the case of RIPE. > 4. Proposed policy solution > > Current Policy text > > 12.1. Evaluation of eligibility > > An organization is eligible for an ASN assignment if: > - it is currently multihomed, or > - it holds previously-allocated provider independent address space and > intends to multihome in the future. > > An organization will also be eligible if it can demonstrate that it will > meet the above criteria upon receiving an ASN (or within a reasonably > short time thereafter). > > Requests for ASNs under these criteria will be evaluated using the > guidelines described in RFC1930 'Guidelines for the creation, selection > and registration of an Autonomous System' (AS). > > Proposed text > > 12.1. Evaluation of eligibility > > An organization is eligible for an ASN assignment if: > - it is multihomed or > - has the need to interconnect with other AS. > > An organization will also be eligible if it can demonstrate that it will > meet any > of the above criteria upon receiving an ASN (or within a reasonably > short time thereafter). > > Requests for ASNs under these criteria will be evaluated using the > guidelines described in RFC1930 'Guidelines for the creation, selection > and registration of > an Autonomous System' (AS). > 5. Advantages / Disadvantages > > Advantages: > Fulfilling the objectives above indicated. > > Disadvantages: > None foreseen. > 6. Impact on resource holders > > None. > 7. References > > https://www.arin.net/policy/nrpm.html#five > https://www.lacnic.net/683/2/lacnic/ > https://www.ripe.net/publications/docs/ripe-679 > * sig-policy: APNIC SIG on resource management 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
