[sig-policy] New Proposal prop-141-v001: Change maximum delegation size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses
Dear SIG members, The proposal "prop-141-v001: Change maximum delegation size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting (OPM) at APNIC 52 on Thursday, 16 September 2021. https://conference.apnic.net/52/program/schedule/#/day/4 We invite you to review and comment on the proposal on the mailing list before the OPM. The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is appended below and also available at: http://www.apnic.net/policy/proposals/prop-141 Regards, Bertrand and Ching-Heng APNIC Policy SIG Chairs --- prop-141-v001: Change maximum delegation size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses --- Proposer: Simon Sohel Baroi (sba...@gmail.com) Aftab Siddiqui (aftab.siddi...@gmail.com) 1. Problem statement According to the APNIC IPv4 Address Report, (https://www.apnic.net/manage-ip/ipv4-exhaustion/ ) the available and reserve pool size is as follows: Available Pool : IP Address 3480064 | 13594 Of /24 Reserved Pool : IP Address 224 | 8750 Of /24 If APNIC continues to delegate IPv4 in size of /23 with the average growth rate of 145 x /23 delegations per month the pool will be exhausted around Aug/Sep 2027. Which means the huge number of IPv4 addresses will be unused for a long time and large community members will still remain behind the NAT box or without Internet Connectivity. 2. Objective of policy change - The current final /8 allocation policy [1] advise that the current minimum delegation size for IPv4 is 256 ( /24 ) addresses and each APNIC account holder is only eligible to receive IPv4 address delegations totalling a maximum 512 ( /23 ) addresses from the APNIC 103/8 IPv4 address pool. (6.1. Minimum and maximum IPv4 delegations ) This is a proposal to change the maximum size of IPv4 address delegations from the available IPv4 address pool to a totalling of 768 (/23+/24) addresses. Increasing the maximum IPv4 delegation size from /23 to /23+/24 IPv4 address pool will allow Newcomers and also Existing APNIC account holders who only received /23 after Thursday, 28 February 2019 to receive 256 (/24) IPv4 addresses. 3. Situation in other regions - There is no similar policy in place in other RIR regions. 4. Proposed policy solution --- It is recommended to increase the IPv4 address delegation size from 512 max (/23) to 768 (/23 + /24). The address space can now be allocated from the available 103/8 last /8 block and/or from non 103/8 recovered address blocks. This policy will continue until the available + reserved comes down to less than 900,000 IPv4 addresses i.e. < 3500x/24, once reaching this threshold the maximum delegation size will revert back to 512 IPv4 addresses (/23) and will continue to do so until the available + reserved block comes down to 256,000 IPv4 addresses i.e 1000x/24 then the delegation size will further reduce to 256 IPv4 addresses i.e. /24 and at this time the /16 reserved for future use (as per APNIC-127 Section 5.1.1) will be added to the available address block. It is proposed to modify the section 6.1 maximum IPv4 delegations of the APNIC Internet Number Resource Policies [1] accordingly. Current Policy text Since Thursday, 28 February 2019, each APNIC account holder is only eligible to receive IPv4 address delegations totalling a maximum /23 from the APNIC 103/8 IPv4 address pool. New Policy text Each APNIC account holder is only eligible to receive IPv4 address delegations totalling a maximum 768 ( /23+/24 ) from the APNIC available IPv4 address pool. Existing APNIC account holders (since Thursday, 28 February 2019 ), who only have /23 can apply for another /24 maintaining the criteria matched with section 7.0. If the available IPv4 Pool size, which consists of available and reserve pool, comes down to 900,000 addresses, delegation size will automatically come down to 512 (/23) IPv4 addresses. If the available IPv4 Pool size, which consists of available and reserve pool, comes down to 256,000 addresses, delegation size will automatically come down to 256 (/24) IPv4 addresses. In this situation APNIC will also add /16 reserved blocks in to the available pool which
[sig-policy] New Proposal prop-139-v001: SOR not required
Dear SIG members, The proposal "prop-139-v001: SOR not required" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting (OPM) at APNIC 52 on Thursday, 16 September 2021. https://conference.apnic.net/52/program/schedule/#/day/4 We invite you to review and comment on the proposal on the mailing list before the OPM. The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is appended below and also available at: http://www.apnic.net/policy/proposals/prop-139 Regards, Bertrand and Ching-Heng APNIC Policy SIG Chairs --- prop-139-v001: SOR not required --- Proposer: Jordi Palet Martínez (jordi.pa...@theipv6company.com) 1. Problem statement Section 5.2.1 enforces a SOR (Second Opinion Request) process, which is rarely used. It was meant for ensuring that resources aren’t wasted being allocated unnecessarily, however, this is already the job of the LIRs, and they may be audited at any point, even if this policy doesn’t exist. Further to that, doesn’t make sense that this is being done for exhausted IPv4 resources, while it has been already avoided for IPv6. 2. Objective of policy change - Avoiding an unnecessary and rarely used process. 3. Situation in other regions - Other RIRs don’t have this process or it is optional/not used. 4. Proposed policy solution --- Actual text: 5.0. Resource Management ... Also, NIRs must, wherever possible, apply slow start, assignment window, and second opinion policies to their own members in a manner consistent with the way APNIC applies such policies. ... 5.2.1. Assignment window for LIRs APNIC and NIRs shall apply an assignment window mechanism to help LIRs understand and comply with APNIC policies and the address management goals. The assignment window indicates the maximum number of addresses an LIR may delegate to an end-user without first seeking a "second opinion". If an LIR wishes to make a delegation that exceeds its delegation window, the LIR must first submit a second opinion request. LIRs start with a delegation window of zero, meaning all proposed delegations must first be approved. APNIC, or the relevant NIR, will regularly assess the proficiency of LIR staff in making delegations and seeking second opinions and will review the size of the assignment window accordingly. As the LIR staff become more proficient, the size of their assignment window may be raised. The maximum IPv4 assignment window given to any LIR will be a /19 (8,192 addresses). If an LIR's staff appears to become less proficient (for example, due to the training of new staff or other relevant circumstances) then that LIR's assignment window may be temporarily reduced. 5.2.3. IPv4 Delegations to downstream IRs … • Delegations are subject to the LIR's assignment window. Requests for delegations, which exceed the LIR's assignment window, must first be referred to APNIC for second opinion approval. … Proposed text: 5.0. Resource Management ... Also, NIRs must, wherever possible, apply slow start policies to their own members in a manner consistent with the way APNIC applies such policies. ... (removed) 5.2.3. IPv4 Delegations to downstream IRs … (removed) … 5. Advantages / Disadvantages - Advantages: Fulfilling the objective above indicated. Disadvantages: None. 6. Impact on resource holders - None. 7. References - None. * 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] New Proposal prop-140-v001: Update End-Site Definition
Dear SIG members, The proposal "prop-140-v001: Update End-Site Definition" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting (OPM) at APNIC 52 on Thursday, 16 September 2021. https://conference.apnic.net/52/program/schedule/#/day/4 We invite you to review and comment on the proposal on the mailing list before the OPM. The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is appended below and also available at: http://www.apnic.net/policy/proposals/prop-140 Regards, Bertrand and Ching-Heng APNIC Policy SIG Chairs --- prop-140-v001: Update End-Site Definition --- Proposer: Jordi Palet Martínez (jordi.pa...@theipv6company.com) 1. Problem statement Section 2.9 was introduced with an IPv4 mind-set and doesn’t fully accommodate IPv6 deployments and members that may have multiple sites in case of assignments. Even if this text has evolved in several RIRs, the previous changes were imperfect, and thru this evolution in other RIRs, it was obvious that we missed some aspects such as “multiple locations” being different than “end-sites”. Further to that, sometimes it becomes confusing the fact that there is not a formal definition of end-user. Finally, 10.1.4.1. is slightly updated, just to make sure that assignments are considered per end-site, not member. Note that those changes are basically editorial clarifications because do not imply actual changes on what policies already allow. 2. Objective of policy change - Ensuring that both end-site and end-user are defined in a more accurate way. 3. Situation in other regions - Other RIRs already updated the policies on this regard. 4. Proposed policy solution --- Actual text: 2.9. End site An end site is defined as an end-user (subscriber) who has a business relationship with a service provider that involves: • that service provider assigning address space to the end-user • that service provider providing transit service for the end-user to other sites • that service provider carrying the end-user's traffic • that service provider advertising an aggregate prefix route that contains the end-user's assignment 10.1.4.1. Initial assignment … The minimum size of the assignment is a /48. The considerations of Section 5.2.4.3 "Assignment of multiple /48s to a single end site" must be followed if multiple /48s are requested. "APNIC guidelines for IPv6 allocation and assignment requests". Proposed text: 2.9. End-site An End-Site is defined as the location of an End-User who has a business or legal relationship (same or associated entities) with a service provider that involves: • that service provider assigning address space to the End-User location • that service provider providing transit service for the End-User location to other sites • that service provider carrying the End-User's location traffic • that service provider advertising an aggregate prefix route that contains the End-User's location assignment 2.10. End-User Service subscriber or customer from an LIR. 10.1.4.1. Initial assignment … The minimum size of the assignment is a /48 per End-Site. The considerations of Section 5.2.4.3 "Assignment of multiple /48s to a single end site" must be followed if multiple /48s are requested. "APNIC guidelines for IPv6 allocation and assignment requests". 5. Advantages / Disadvantages - Advantages: Fulfilling the objective above indicated in terms of clarifying end-user/end-site and that an end-site is a single location, which can obtain, in the case of an IPv6 assignment, a /48. Disadvantages: None, it is already consistent with the actual practices. 6. Impact on resource holders - None. 7. References - AFRINIC (different wording, same meaning): • https://www.afrinic.net/policy/manual#PI-A RIPE (same wording as suggested by this proposal): • https://www.ripe.net/publications/docs/ripe-738 * 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] New Proposal prop-138-v001: Restricting AS-ID in ROA
Dear SIG members, The proposal "prop-138-v001: Restricting AS-ID in ROA" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting (OPM) at APNIC 52 on Thursday, 16 September 2021. https://conference.apnic.net/52/program/schedule/#/day/4 We invite you to review and comment on the proposal on the mailing list before the OPM. The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is appended below and also available at: http://www.apnic.net/policy/proposals/prop-138 Regards, Bertrand and Ching-Heng APNIC Policy SIG Chairs --- prop-138-v001: Restricting AS-ID in ROA --- Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com) 1. Problem statement RFC6482 - A Profile for Route Origin Authorisations (ROAs) defines the content of a ROA and one of the field is called "asID" Autonomous System Identifier. It is defined in the RFC as "The asID field contains the AS number that is authorised to originate routes to the given IP address prefixes." asID is an Integer value and the RFC doesn't restrict the range of numbers which can be placed here but technically only allocated ASNs should only be allowed to be added as "asID" or "Origin AS". APNIC ROA management system allows any number between 0 - 4294967295, which includes many ranges of Private ASNs, Reserved ASNs and unallocated ASNs as well. This may lead to creating ROAs with Origin AS which should not be in the global routing table. 2. Objective of policy change - Restrict APNIC members to create ROAs with private, reserved or unallocated ASN. 3. Situation in other regions - In process of verifying this information. 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 be 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. 5. Advantages / Disadvantages - Advantages: This will help APNIC members avoid mistakenly creating unnecessary Bogon ROAs. Disadvantages: Overhead in implementing Origin AS check. 6. Impact on resource holders - APNIC has to request members to delete existing Bogon ROAs, as of 5th August 2021 there are around 30+ Bogon ROAs of APNIC delegated resources. 7. References - None. * 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] New Proposal prop-137-v001: IPv6 assignment for associate members
Dear SIG members, The proposal "prop-137-v001: IPv6 assignment for associate members" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting (OPM) at APNIC 52 on Thursday, 16 September 2021. https://conference.apnic.net/52/program/schedule/#/day/4 We invite you to review and comment on the proposal on the mailing list before the OPM. The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is appended below and also available at: http://www.apnic.net/policy/proposals/prop-137 Regards, Bertrand and Ching-Heng APNIC Policy SIG Chairs --- prop-137-v001: IPv6 assignment for associate members --- Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com) 1. Problem statement The first tier of membership in APNIC is "Associate". As per APNIC-121 Section 2.1 and 2.2, the Associate members do not receive any address space (IPv4 or IPv6). In order to be eligible for IPv6 assignment APNIC Members that have been delegated an IPv4 address block from APNIC, but have no IPv6 space, instantly qualify for an appropriately sized IPv6 block without any restriction. If you have no IPv4 delegation and only requesting IPv6 assignment then as per APNIC-127 section 10.1.4 "Requests for Provider Independent assignments must include a detailed plan of intended usage of the proposed address block over at least the 12 months following the allocation". The minimum size of the assignment is a /48 and requires annual fees of AUD 1,180 as per HD ratio. In the IPv4 exhaustion world, this policy limits anyone who wants to only use IPv6 provider independent assignment for personal use as it doesn't incentivise IPv6 assignment only. The same fees and justification is applied to receive /24 IPv4 + /48 IPv6 address space. This is perceived as a clear barrier to deploy IPv6. This policy proposal addresses that barrier aims to solve this problem by means of providing a Provider Independent assignment to Associate members. 2. Objective of policy change - Provide an incentive to small enterprises and academia/researchers to receive IPv6 assignment. 3. Situation in other regions - RIPE NCC: IPv6 PI can be sponsored by an LIR (EUR 50/yr) ARIN: As an end-user IPv6 only can be requested following certain criteria AFRINIC: Must not be an LIR LACNIC: Not been an LIR or ISP, submit addressing plans for at least a year https://www.nro.net/wp-content/uploads/RIR-Comparative-Policy-Overview-2021-Q2.pdf Section 3.4.3 - END USERS 4. Proposed policy solution --- Remove APNIC-114 "APNIC guidelines for IPv6 allocation and assignment requests" requirement for initial IPv6 provider independent assignment as per APNIC-127 Section 10.1.4. Use the same "Go IPv6" criteria and enable "Get IPv6 Addresses Now" options for Associate members with the restrictions that the Provider Independent assignment cannot be further assigned to other organisations. The Associate member MUST agree to use and announce the IPv6 provider independent address space within twelve (12) months. After that period, if not announced or APNIC host masters believe that it is not in use then the assigned IPv6 address space should be reclaimed and returned to the free pool. Note: This is outside the scope of the policy proposal, therefore requesting APNIC EC to consider that only Associate membership fees should be applied to initial IPv6 provider independent assignment of /48 only. 5. Advantages / Disadvantages - Advantages: This will give incentive to those small enterprises and academics willing to use their own IPv6 addresses but not in a position to be a very small tier member. Disadvantages: - This might slightly increase over head for host masters. - The possible effect of this proposal is the growth of the global routing table 6. Impact on resource holders - No impact on existing resource holders. 7. References - None. * 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] New Proposal prop-136-v001: Registration Requirements
Dear SIG members, The proposal "prop-136-v001: Registration Requirements" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting (OPM) at APNIC 52 on Thursday, 16 September 2021. https://conference.apnic.net/52/program/schedule/#/day/4 We invite you to review and comment on the proposal on the mailing list before the OPM. The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is appended below and also available at: http://www.apnic.net/policy/proposals/prop-136 Regards, Bertrand and Ching-Heng APNIC Policy SIG Chairs --- prop-136-v001: Registration Requirements --- Proposer: Simon Sohel Baroi (sba...@gmail.com) Amrita Choudhury (amritachoudh...@ccaoi.in) 1. Problem statement The registration requirements under Section 5.3 of APNIC Internet Number Resource Policies document is again broken down into three subsections (section 5.3.1, 5.3.2 and 5.3.3) based on each resource type. 2. Objective of policy change - The objective of the policy change is to make the Section of the policy more simpler, concise and easier for the community to understand and adopt and remove duplication if any. 3. Situation in other regions - In most of the RIRs like Afrinic, LACNIC and Ripe NCC the registration requirements have been listed separately for ipv4, ipv6 and ASN under different clauses. 4. Proposed policy solution --- To avoid repetition of similar requirements for each protocol, the proposed solution is to incorporate the registration requirements for ASN and addresses in Section 5.3.1 and updating registration details in 5.3.2. Presently the Section and the sub-sections are as follows : 5.3. Registration requirements 5.3.1. Requirements for IPv4 addresses IRs are responsible for promptly and accurately registering their address space use with APNIC as follows: - All delegations from APNIC to the IR must be registered. - All delegations to downstream IRs must be registered. - Delegations made to networks greater than a /30 must be registered. - Delegations made to networks of a /30 or less may be registered, at the discretion of the IR and the network administrator. - Delegations to hosts may be registered, at the discretion of the IR and the end-user. IRs can choose whether or not to designate this information "public". Customer registration details that are not designated "public" will not be generally available via the APNIC Whois Database. The database record will instead direct specific whois enquiries to the IR concerned. 5.3.1.1. Updating registration details IRs must update their registration records when any of the registration information changes. This is the responsibility of the IR concerned. However, this responsibility may be formally assigned to the end-user as a condition of the original delegation. 5.3.2. Registration requirements for IPv6 addresses When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /48 networks. When more than a /48 is assigned to an organisation, the assigning organisation is responsible for ensuring that the address space is registered in an RIR/NIR database. RIR/NIRs will use registered data to calculate the HD-Ratio at the time of application for subsequent allocation and to check for changes in assignments over time. IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration. Organisations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available. If the organisation does not indicate a choice, or it chooses to hide its customer assignment registrations, then those records will not be visible in the public whois database. Whois queries on these records will return details of the allocation. 5.3.3. Registration requirements for AS Numbers All ASNs assigned
[sig-policy] New Proposal prop-135-v001: Documentation
Dear SIG members, The proposal "prop-135-v001: Documentation" has been sent to the Policy SIG for review. It will be presented at the Open Policy Meeting (OPM) at APNIC 52 on Thursday, 16 September 2021. https://conference.apnic.net/52/program/schedule/#/day/4 We invite you to review and comment on the proposal on the mailing list before the OPM. The comment period on the mailing list before the OPM is an important part of the Policy Development Process (PDP). We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this proposal is appended below and also available at: http://www.apnic.net/policy/proposals/prop-135 Regards, Bertrand and Ching-Heng APNIC Policy SIG Chairs --- prop-135-v001: Documentation --- Proposer: Amrita Choudhury (amritachoudh...@ccaoi.in) Simon Sohel Baroi (sba...@gmail.com) 1. Problem statement It has been observed that the Sections 5.6 and 5.6.1 are repetitive in the Resource Request Supportive Document. 2. Objective of policy change - The objective of the policy change is to make the policy simple and easier for the community to understand and adopt and remove duplication if any. 3. Situation in other regions - ARIN: Does not seem to have definitive documentation. Reference Link: https://www.arin.net/participate/policy/nrpm/ RIPE NCC: Does not seem to have a consolidated document Reference Link: https://www.ripe.net/publications/docs/ripe-policies?b_start:int=0 LACNIC mentions: 2.3.2.5.Documentation Internet Registries shall use the IPv4 addresses they have been allocated in an efficient manner. To this end, IRs shall document the justification for each IPv4 address assignment. At the request of LACNIC, the corresponding IR shall make this information available. LACNIC shall not make complementary allocations to those Internet Registries that have not properly documented the use of the blocks already allocated. In these cases, existing allocations may also be reviewed. The documentation LACNIC may require includes: • Engineering plans. • Subnetting and aggregation plan. • Description of network topology. • Description of network routing plans. • Receipts documenting investments (equipment). • Other relevant documents Reference Link: https://www.lacnic.net/innovaportal/file/680/1/manual-politicas-en-2-14.pdf AFRINIC: Policy document mentions: 5.2.3 Documentation In order to properly evaluate requests, an RIR must carefully examine all relevant documentation relating to the networks in question. Such documentation may include network engineering plans, sub-netting plans, descriptions of network topology, and descriptions of network routing plans. All documentation should conform to a consistent standard and any estimates and predictions that are documented must be realistic and justifiable. Reference Link: https://afrinic.net/policy/manual 4. Proposed policy solution --- To avoid duplication, the proposal is to remove 5.6.1 and include any additional requirements into 5.6. Currently the two sections are as follows: Section 5.6. General requirements All requests for address space must be supported by documentation describing: ·The network infrastructure of the organization making the request, ·Any address space currently held by that organization (including Historical address space), ·Previous assignments made by that organization (including assignments made from Historical address allocations), and ·The intended use for the address space requested. In addition to this general requirement, more specific documentation may also be requested, as outlined below. Section 5.6.1. Documentation states To properly evaluate requests, IRs must carefully examine all relevant documentation relating to the networks in question. This documentation may include: ·Network engineering plans ·Subnetting plans ·Descriptions of network topology ·Descriptions of network routing plans ·Equipment invoices and purchase orders ·Other relevant documents All documentation should conform to a consistent standard and any estimates and predictions that are documented must be realistic and justifiable. Ref link: https://www.apnic.net/community/policy/resources#5.6.-General-requirements-for-requests What we propose is: 5.6 General Requirements: In order to properly evaluate requests, APNIC must carefully examine all relevant documentation relating to the networks in question. Such
