Orbit

Same here …

Regards,

Jordi

@jordipalet

El 25/8/21 12:37, "Jordi Palet Martínez" jordi.palet@theipv6company.com escribió:

Same here …

So, what is the point here, I mean, shall we have an informal presentation of both, so the WG (I guess you mean the Policy SIG?) decides what is the direction to take?

Regards,

Jordi

@jordipalet

El 11/8/21 2:42, "Srinivas (Sunny) Chendi" sunny@apnic.net escribió:

Thanks Bertrand.

Dear WG Chairs,

Please note as below.

Regards, Sunny

On 9/08/2021 6:57 pm, Bertrand Cherrier wrote:

Hello Sunny,

This proposal will go back to the working group, as there is another proposal on the same subject (which will also go back to the WG).

Regards,

Le 06/08/2021 à 11:44, Srinivas (Sunny) Chendi a écrit :

Dear Chair,

Please find below a new proposal submitted for OPM at APNIC 52.

According to the SIG Guidelines, Section 2.3.1, the Chair should:

<quote> - Read or review submitted proposals or presentations - Accept or reject proposals or presentations for discussion at the forthcoming SIG forum (and suggest an alternative forum if the topic is not within SIG charter) <unquote>

The Chair may decide that a proposal is not suitable for discussion at the forthcoming OPM if:

- The proposal is out of scope for the SIG charter - The proposal is insufficiently developed to be the basis for a useful discussion - The agenda has already been filled by topics of greater priority

Please let me know by COB Monday, 09 August 2021, if you accept or reject this proposal?

Thank you, Sunny

-------- Forwarded Message --------

Subject: [APNIC #4726089] New APNIC Policy Proposal - ASN to Customer Date: Fri, 06 Aug 2021 04:21:02 +1000 From: Jordi Palet Martínez via RT policy@apnic.net Reply-To: policy@apnic.net

Ticket URL: https://rt4.apnic.net/Ticket/Display.html?id=4726089

ASN to Customer -------------------------------------------------------

Proposer: Jordi Palet Martínez jordi.palet@theipv6company.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.

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 ------------------------------------------------------- Actual 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.

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.

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 -------------------------------------------------------

_______________________________________________ Sig-policy-chair mailing list Sig-policy-chair@apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy-chair