[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.palet@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.