Orbit

Hi Anupam,

Tks for checking this!

For you point 1, you mean shortening such as:

Actual:

4. Any ASNs returned to the requesting organization must then be returned to APNIC or the relevant NIR.

Proposal:

4. The ASN could be transferred, in cases such as the customer using the ASN becomes an APCNI/NIR member. Otherwise must be returned to APNIC or the relevant NIR.

Let me know if I understood correclty your point.

For your point 2, I don’t think such a problem exists, because if 1 customer is using the ASN and becomes an APNIC/NIR member, then customer 2 will never use that ASN. Now, if you mean: Customer 1 uses the ASN. Customer 1 drops the contract or the use of the ASN. In theory here, if not transferred it should be returned Now, if is not returned because immediately customer 2 qualify to use the ASN (according to 12.0), then it will start using it. Even if now customer 1 and 2 want to become members at the same time, the one “in use” of the ASN will be customer 2 and “naturally” it seems is the one to get it. Customer 1 will need to start a new request, no need for a transfer because it cesaed in the use of that ASN (probably he changed to another ISP and instead of getting the ASN transferred he opted for a new one). Anyway, this is something that is, in my opinion, beyond the scope of this policy (12.0) and if falls into 13.0 and the decision of the ISP, which is the “current” holder of the ASN. If customer 2 also ceased to use the ASN, then we are in the same situation as b, and in consequence, it should have been returned because it was not transferred to customer 2. If “immediately” customer 1 joins again the ISP network and qualify for the use of the ASN, then we are back in c.

So I think there is no need to have additional text to “resolve” that situation. I hope my explanation is clear, but if not, le me know, same if I’m missing something from your point.

For your point 3., I think it is more comprehensive to city 12.0, because “all” is criteria about how to apply, conditions for it, how to handle if the customer becomes a member, etc.

Regards,

Jordi

@jordipalet

El 17/3/21 11:47, "Anupam Agrawal" anupamagrawal.in@gmail.com escribió:

Few Pointers:

1. In the suggested text “instead of returned” appears an additional text and can be removed. The return scenario is anyways handled in 12.4 Point 4.

2. In a hypothetical scenario, where an ASN has been used by say 2 customers and all two customers have become APNIC member, then which customer has the right to ASN or it is the last using customer or it is the prerogative of the requesting organisation or APNIC.

3. In point 1 of 12.4 the reference is to Section 12.0 Objectively can it be made to 12.1?

Regards

Anupam

On 17-Mar-2021, at 2:24 PM, Vivek Nigam vivek@apnic.net wrote:

Hi Jordi,

Your proposed text is more consistent with the text in bullet point 4 now.

4. Any ASNs returned to the requesting organization must then be returned to APNIC or the relevant NIR.

Thanks

Vivek

From: JORDI PALET MARTINEZ jordi.palet@consulintel.es Date: Wednesday, 17 March 2021 at 6:36 pm To: Vivek Nigam vivek@apnic.net, Srinivas Chendi sunny@apnic.net, sig-policy sig-policy@lists.apnic.net Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

Hi Vivek,

I was thinking on that, but not all the policies have an explicit mention to the “NIR” or related text, and what is more important, my understanding is that a NIR member is also an APNIC member by default, or at least, that’s what I understand from:

https://www.apnic.net/about-apnic/corporate-documents/documents/membership/n...

(or I got wrong that document?)

If the secretariat believes that we should make it more explicit (I think redundant text is not always good, but I’m fine with that), then we could use:

5. The ASN could be transferred, instead of returned, in cases such as the customer using the ASN becomes an APNIC/NIR member.

Regards,

Jordi

@jordipalet

El 17/3/21 7:59, "Vivek Nigam" vivek@apnic.net escribió:

Hi Jordy,

Yes, this will address the cases I explained in my previous email.

Since APNIC has NIRs in our region, you may want to include them in your proposed point.

Thanks

Vivek

From: JORDI PALET MARTINEZ jordi.palet@consulintel.es Date: Tuesday, 16 March 2021 at 7:08 pm To: Vivek Nigam vivek@apnic.net, Srinivas Chendi sunny@apnic.net, sig-policy sig-policy@lists.apnic.net Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

Hi Vivek,

I fully understand that case. It makes a lot of sense that a customer which initially got the ASN from the upstream, now becomes a member and then it should be transferred. Probably also the IPv4 addresses, but that’s a more complex issue.

I was thinking in a different case.

1) An upstream is providing an ASN to a customer.

2) The customer cancels the contract and don’t ask for the transfer.

3) The upstream has an ASN not being used (let’s assume that it is not used for another customer in more than 6 months or so).

4) The honest thing in this case, is to return it, not to transfer it after 12 months (example). Otherwise, it is a stockpiling.

Based on that, I’ve updated the document. Do you thing adding this in 12.4 will work?

5. The ASN could be transferred, instead of returned, in cases such as the customer using the ASN becomes an APNIC member.

Otherwise, it is a good starting point for a discussion on this specific topic!

Regards,

Jordi

@jordipalet

El 16/3/21 3:33, "Vivek Nigam" vivek@apnic.net escribió:

Hi Jordi,

As per points 3 and 4 in policy clause 12.4. Providing ASN to 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.

We have had cases where a member has received an ASN on behalf of their customer. Subsequently that customer became a member of APNIC and requested to transfer that ASN into their APNIC account. We have also had cases where members have re-assigned their customer ASNs to new customers after their original customer ceased to receive connectivity from them. Subsequently the new customer became a member of APNIC and requested to transfer that ASN into their APNIC account.

When the policy for customer ASNs was written, the ASN transfer policy did not exist. Now that we have a policy for ASN transfers, we would like to have some clarity around the transfer of customer ASNs.

Thanks

Vivek

From: sig-policy-bounces@lists.apnic.net on behalf of JORDI PALET MARTINEZ jordi.palet@consulintel.es Date: Monday, 15 March 2021 at 7:20 pm To: Srinivas Chendi sunny@apnic.net, sig-policy sig-policy@lists.apnic.net Subject: Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

I meant:

in the sense that any non-used resource must be returned “voluntarily” (or otherwise reclaimed).

Regards,

Jordi

@jordipalet

El 15/3/21 10:17, "JORDI PALET MARTINEZ" <sig-policy-bounces@lists.apnic.net en nombre dejordi.palet@consulintel.es> escribió:

Hi Sunny, all,

I saw your slides, and in fact, that’s what I followed initially for preparing my proposal. However, I saw many other points that need resolution, in my opinion, as when you touch some of the text, some other text is related to it, etc.

So, yes, I understand your slide 17, however, the point is still the same … In an ideal world, if you don’t need any more any INR (Internet Number Resource), which has been provided by the RIR (APNIC in this case), then you just return it, so other community members can take advantage of it. However, we know that will not happen, and we will need to go into “persecution & reclaim-mode” (excluding M&A cases), and this is what triggered the transfer policies. What I’m saying is that the apparent contradiction for the ASNs is there also for IPv4 resources. We can tidy up a bit the text, but the contradiction is “generic” in the sense that any non-used resource must be reclaimed.

Let’s talk about this in the community consultation. It is a terrible timing for me (national holiday and 5AM) … but I will try to join anyway.

By the way, I forgot to mention in my email that the transfers policies, could not just be “editorially moved” to a specific part in the policy manual, but also try to make the text shorter, instead of having just all the text “there”. I will try to prepare something else about that.

Regards,

Jordi

@jordipalet

El 15/3/21 7:55, "Srinivas (Sunny) Chendi" sunny@apnic.net escribió:

Hello Jordi,

Thanks for your email. Please see the responses inline below.

On 15/03/2021 8:05 am, JORDI PALET MARTINEZ wrote: Hi all,

I've got no inputs to this message, so I moved on and edited a draft policy proposal, trying to avoid any "contentious" wording ... but will see. As usual, appreciate for your pro-activeness and support. The Policy SIG Chairs have sent an invitation to the community to join a virtual community consultation to discuss the Policy documentation review report presented at APNIC 51 OPM. This is an opportunity for those who missed the OPM to participate in this discussion.

https://www.apnic.net/community/participate/sigs/community-consultation/

After this virtual consultation, hope interested individuals (or groups) may come forward to draft proposal/s.

I've one question for the secretariat, actually all, regarding the ASN return vs. transfers. The point is that if we "ask" all the LIRs to return the ASNs that they don't use, we should also ask them to return the IPv4 addresses that they don't use ... so then there is no need to allow the transfers. So, I think we should keep the ASN/ASN transfers as is today. Or do you think the wording in between IPv4 and ASN is so different that makes a point in rewording the ASN 12.4? We could keep the current text but is contradicting with the text in "Section 13.2.2. Conditions on the source of the transfer" and creating confusion as reported at APNIC 51. Please refer to slide #17, here

https://2021.apricot.net/assets/files/APSr481/apnic-policy-document-review-r...

This just requires a simple update to "Section 12.4 Providing ASN to customer", point #4, to allow transfer in accordance with ASN Transfers 13.0.

Hope this clarifies.

Regards Sunny

So ... see the attached PDF with the proposal. This is just a draft. As I mention in my previous email, the goal is to have some discussions in the list and get other folks joining before submitting a proposal ... of course, unless there is no discussion in the list and I need to go for the proposal.

Regards, Jordi @jordipalet

El 3/3/21 13:40, "JORDI PALET MARTINEZ" <sig-policy-bounces@lists.apnic.net en nombre de jordi.palet@consulintel.es> escribió:

Hi Sunny, all,

Some of the topics that you mention, have been already resolved in other RIRs, as there were similar issues. In fact, I authored a few policy proposals about some of them.

In a quick review of your presentation, I see that many of them are really easy to resolve. They are not "editorial" in the sense of typos or grammar, but inconsistencies among different parts of the policy "manual" and, the most important thing, I believe they are non-contentious (so "should not" have objections which create lack of consensus, lengthy discussions, etc.).

For example, in a quick look, some of those that I believe aren't contentious:

0) Overall: Improve definitions, ensure they are in a single section? 1) End-Site vs end-user 2) 5.31, 5.32, 5.3.3 unify? 3) 5.6 and 5.6.1 repetitive, delete last one 4) Utilization vs usage rate 5) Agree with transfers in a single place 6) LIR assignment for their own infrastructure doesn't look as a real need in IPv6? 7) 5.2.1 assignment window for LIRs Second Opinion Request 9) I don't think we need IPv6 guidelines ... anymore, having policies and guidelines is making it more complex 10) No need for experimental IPv4 resources anymore? 11) ASNs 12.4 vs 13.0 - rewording or clarification needed

We shouldn't make this very complex or take a long time to resolve them. I will say that by the next on-line meeting, should be sorted out, at least for those issues that aren't contentious.

I just started a document with a proposal for all them. I will try to finish it this afternoon.

However, I think if we can circulate in the list each topic, we can "see" if anyone is objecting to any of the issues, before making a formal proposal. This way we can split the issues in those that are "non-contentious" and those that "may have some objections". Even if the APNIC PDP is used to ask questions for separate parts of a single proposal, we can make it much easier having ONE proposal for the "non-contentious", and then individual proposals for each of the "contentious" ones.

We can try to determine if any of the issues is "contentious" by circulating in the sig-policy list each of the points. This will only work if the people decide to *actively* participate, in such way that for example, every week (more or less), from now to the next meeting (actually a couple of months before it, at least), so we have a clear view of points to "exclude" from the "non-contentious proposal".

*Otherwise*, if people are not willing to contribute actively, we don't waste anyone time and I just fire a proposal tomorrow.

Now, while I'm happy to take over this task myself, I will prefer doing this with other folks. May be people that never participated in policy proposals before and want to take advantage of the experience?

So, I will ask once more: Anyone interested to contribute (you can email me in private if you prefer so)?

Regards, Jordi @jordipalet

********************************************** IPv4 is over Are you ready for the new Internet ? https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theipv6... The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.ap...

********************************************** IPv4 is over Are you ready for the new Internet ? https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theipv6... The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

********************************************** IPv4 is over Are you ready for the new Internet ? https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theipv6... The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

* 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