Dear SIG members,
Here is the Secretariat impact assessment for prop-143-v001.
APNIC understands this proposal is suggesting additional
terms
under Section 12.4, Providing ASN to customer, to bring the policy
in line with
the current practice (operational concerns), as recommended in the
Secretariat's policy document review report.
Secretariat observations - new trends:
Many non-ISP type (Data centres, Hosting
providers, etc.)
members are requesting multiple customer ASNs from APNIC. This
trend could be
to get free ASNs from APNIC as a value-added service and lease it
to customers
for a nominal fee.
Recommendations:
1. The proposal uses the term "ASN User"
instead
of the term "customer" in the current policy document. To avoid
confusion and to be consistent, we recommend using the term
"customer" in the proposal.
2. The changes proposed to Section 13.0, and
the new added Section
13.4 are not required if the additional terms language in Section
12.4 is
clearly clarified (worded). Secretariat recommends the following
change:
5.
Alternatively, the same ASN could be
registered:
- via transfer to another APNIC member
(upstream provider connecting that customer), or
- directly by the customer in cases when
they become an APNIC/NIR member and receives that ASN via
transfer.
Implementation:
This proposal would not require any changes to the
systems.
If this proposal reaches consensus, implementation can be
completed within 3 months.
Regards,
Sunny and Odagi
Policy Support
On 2/02/2022 1:06 pm, chku wrote:
Dear
SIG members,
The proposal "prop-143-v001: ASN to Customer" has been sent to
the Policy SIG for review.
It will be presented at the Open Policy Meeting (OPM) at APNIC 53
on
Wednesday, 02 March 2022.
https://conference.apnic.net/53/program/schedule-conference/#/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-143
Regards,
Bertrand, Shaila, and Ching-Heng
APNIC Policy SIG Chairs
---------------------------------------------------------------
prop-143-v001: ASN to Customer
---------------------------------------------------------------
Proposer: Jordi Palet Martínez (jordi.palet@theipv6company.com)
Anupam Agrawal (anupamagrawal.in@gmail.com)
1. Problem statement
--------------------
Section 12.4 allows a LIR to provide an ASN to a customer, but
doesn’t allow that ASN to
be used by the customer if ceases to receive connectivity, even if
the customer gets
connectivity from another LIR or becomes a direct APNIC/NIR
customer. It also contradicts
the options for a transfer.
This generates problems in many situations, such as, for example:
• Bankruptcy of the LIR that originally provided the ASN, even if
other upstream providers
where that ASN was being used still provide the connectivity.
• The customer becomes a direct APNIC/NIR member.
• The LIR change providers (including the one that provided the
ASN) but the customer network
is the same.
The ASNs aren’t a resource that it is subjected to exhaustion in
the medium-long term, but it is also
understandable that ASNs not used should be returned.
However, it doesn’t make sense that an ASN that has been assigned
to a customer needs to be returned
if business situations change, but the network using that ASN is
still connected to Internet and willing
to use the same ASN.
It should be noticed that the criteria for obtaining the ASN was
already initially fulfilled by that
customer, not the LIR, so that’s granted.
This is especially relevant when organizations do the transition
to IPv6, as they may have been customers
from several upstream providers and not have IPv4 allocations, but
they need those for IPv6 PI, which will
be directly assigned by APNIC (or the relevant NIR), and
consequently they need to keep an ASN.
This should not be considered a transfer in the sense that the ASN
was already used by that organization,
so there is no actually being transferred from one user to
another.
2. Objective of policy change
-----------------------------
Simplify the process and avoid a ASN change in certain cases,
recognize a new use case for transfer and most
importantly, record the transfer criteria in the policy document.
3. Situation in other regions
-----------------------------
Other RIRs don’t have explicit rules or restrictions on those
cases, at least not clearly stated in policies,
but the transfer of ASN is much simpler, so it fulfills what this
proposal is trying to achieve.
4. Proposed policy solution
---------------------------
Proposed text:
12.4. Providing ASN to customer
Assignments to organizations that will provide the ASN to one of
its customers are subject to the following additional terms:
1. The customer that will actually use the ASN must meet the
criteria in Section 12.0.
2. The requesting organization is responsible for maintaining the
registration described in Section 5.3.3. on behalf of the
customer.
3. If the customer ceases to receive connectivity from the
requesting organization it must return the ASN. The requesting
organization
is expected to enter into an agreement with the customer to this
effect.
4. Any ASNs returned to the requesting organization must then be
returned to APNIC or the relevant NIR.
5. Alternatively, the same ASN could be registered:
• via another upstream provider connecting that customer, or
• directly by the ASN user in cases when it becomes an APNIC/NIR
member.
13.0. ASN Transfers
Autonomous System Numbers may be transferred in accordance with
the following policies. APNIC does not recognize transfers outside
this policy and require organizations holding such transfers to
return them.
APNIC recognizes there will be situations where ASNs may be
transferred between:
• Current APNIC account holders
• Current APNIC account holders and organizations in other RIR
regions
• Organizations through a merger, acquisition, or takeover
• Current ASN User becoming APNIC Member
13.4. ASN User becoming APNIC Member
APNIC will process and record ASN transfer requests from ASN User
having received ASN from an existing APNIC member when ASN user
itself becomes an APNIC member.
5. Advantages / Disadvantages
-----------------------------
Advantages:
Fulfilling the objective above indicated. Avoids the original ASN
user to reconfigure devices and provides “stability” of the stats
for that ASN (the traffic is from the same customer).
Disadvantages:
It may be perceived as a transfer, but actually is not, because
the user of the ASN is the same as the one that was originally
assigned to.
6. Impact on resource holders
-----------------------------
None.
7. References
-------------
Nil.
_______________________________________________
sig-policy mailing list -- sig-policy@lists.apnic.net
To unsubscribe send an email to sig-policy-leave@lists.apnic.net
