[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

[Jordi Palet Martinez via SIG-policy]

Hi Sunny, all,

1) The proposal only mentions leasing as an example of what is not valid, and 
we say "any form of leasing”, so we don’t need a definition.

2) Proposals don’t state how the implementation must be done. There are ways to 
automate this verification up to certain extent, such as looking for the AS 
path. Same about the frequency. If automated, it can be done even every week. I 
don’t think we need to state that.

3) The proposal already mention “regardless of when the delegation has been 
issued”, so we believe that’s clear?

4) We don’t change the existing policies about usage by “subsidiaries” or 
anything similar, so whatever is accepted today on this regards, or was part of 
the original justification, continues to be the same which this proposal.

Please, let us know if this resolves the staff questions, so we can tidy up the 
text.

After reviewing all the inputs and the last week webinar, we believe that small 
tweaks and probably shortening the proposal text will make it clear, so working 
on that.

Regards,
Jordi

@jordipalet


> El 22 ago 2023, a las 1:29, Srinivas (Sunny) Chendi  
> escribió:
> 
> ---
> 
> Secretariat Impact Assessment: prop-148-v004
> 
> 
> 
> APNIC notes that this proposal suggests explicitly stating in the 
> APNIC Internet Number Resources policy document that leasing of 
> addresses is not permitted in the APNIC region.
> 
> Questions/Comments:
> ---
> - Can the authors provide a clear definition of what is considered 
> 'leasing'?
> 
> - How do the authors propose APNIC verifies that IP addresses are 
> being leased and how often do they suggest APNIC should be checking?
> 
> - Does this proposal apply to all existing delegations or only those 
> addresses delegated after the proposal is implemented (if it reaches 
> consensus)?
> 
> - How does this proposal apply to account holders who have previously 
> received delegations and use the IP addresses under different entities 
> (for example, subsidiaries using them in different locations)?
> 
> Implementation:
> ---
> This proposal may require changes to APNIC systems. If this proposal 
> reaches consensus, implementation may be completed within three months.
> 
> Regards,
> Sunny
> 
> 
> On 5/08/2023 2:59 am, Shaila Sharmin wrote:
>> Dear SIG members,
>> 
>> A new version of the proposal "prop-148-v004: Clarification - Leasing of 
>> Resources is not Acceptable" has been sent to the Policy SIG for review.
>> 
>> Information about earlier versions is available from:
>> 
>> http://www.apnic.net/policy/proposals/prop-148
>> 
>> You are encouraged to express your views on the proposal:
>> 
>>   - Do you support or oppose the proposal?
>>   - Is there anything in the proposal that is not clear?
>>   - What changes could be made to this proposal to make it more effective?
>> 
>> Please find the text of the proposal below.
>> 
>> Regards,
>> Bertrand, Shaila, and Anupam
>> APNIC Policy SIG Chairs
>> 
>> 
>> ---
>> 
>> prop-148-v004: Clarification - Leasing of Resources is not Acceptable
>> 
>> --
>> 
>> Proposer: Jordi Palet Martinez (jordi.pa...@theipv6company.com 
>> <mailto:jordi.pa...@theipv6company.com>)
>>Amrita Choudhury (amritachoudh...@ccaoi.in 
>> <mailto:amritachoudh...@ccaoi.in>)
>>Fernando Frediani (fhfred...@gmail.com 
>> <mailto:fhfred...@gmail.com>)
>> 
>> 
>> 1. Problem statement
>> 
>> RIRs have been conceived to manage, allocate and assign resources 
>> according to need, in such way that a LIR/ISP has addresses to be able 
>> to directly connect its customers based on justified need. Addresses are 
>> not, therefore, a property with which to trade or do business.
>> 
>> When the justification of the need disappears or changes, for whatever 
>> reasons, the expected thing would be to return said addresses to the 
>> RIR, otherwise according to Section 4.1. (“The original basis of the 
>> delegation remains valid”) and 4.1.2. (“Made for a specific purpose that 
>> no longer exists, or based on information that is later found to be 
>> false or incomplete”) of the policy manual, APNIC is not enforced to 
>> renew the license. An alternative is to transfer these resources using 
>> the appropriate transfer policy.
>

[sig-policy] Re: prop-147-v003: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

If my English is correct, "other" is not = "all", and you can also read the 2nd 
part of the sentence.


Regards, 
Jordi 
@jordipalet 





El 20/1/23, 18:41, "Owen DeLong via sig-policy" mailto:sig-policy@lists.apnic.net>> escribió:


> 
> 3. Situation in other regions
> -
> In other RIRs legacy resources lose their legacy status when the RSA is 
> signed (upon receiving other resources), so they become under the regular 
> monitoring. In other cases, there is nothing specified by policies.


This isn’t an accurate reflection of the situation in the RIPE NCC region.


Owen




___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net 
/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-147-v003: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Aftab,

 

12 months after they are marked as reserved. It is the same period, either they 
are claimed, or they will be placed in the free-pool.

 

To make it clear, may be instead of “After 12 months”, “After the 12 months 
period”?

 

Tks for the inputs!

 

Regards,

Jordi

@jordipalet

 

 

 

El 19/1/23, 21:40, "Aftab Siddiqui"  escribió:

 

Hi Jordi,



4.3. Historical Resources Management

a) Historical resources currently marked as reserved.
The custodians can claim historical resources that have been marked as 
reserved within 12 months of the date they were marked as reserved. 
After 12 months, these resources will be placed in the free pool for 
re-delegation.

 

When will this 12 months period start? 

 

Regards,

Aftab A. Siddiqui

 

 

___ sig-policy - 
https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an 
email to sig-policy-le...@lists.apnic.net



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: NEW version - prop-148-v003: Clarification - Leasing of Resource s is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Exactly. As explained many times in the list and in the meeting today, the 
proposal doesn’t change the situation, just clarify it: leasing *in any form* 
is not allowed.

 

Could you please if IPXO justified the need in APNIC or any other RIRs, 
indicating that the addresses will be used for leasing?

 

Regards,

Jordi

@jordipalet

 

 

 

El 15/9/22, 6:40, "Fernando Frediani"  escribió:

 

This is not a proposal about if Leasing should be allow/disallowed, but to make 
something clear in the policy text about what already exists and is what it is.

Fernando

On 14/09/2022 10:35, Evelina Eidukaitė via sig-policy wrote:

Dear Colleagues,

 

My name is Evelina, I represent IPXO, the largest IP leasing platform and we 
don’t support the proposal "prop-148-v003: Clarification - Leasing of Resources 
is not Acceptable", because it opposes to the concept of free, open, and equal 
Internet. 

 

1.   Growing scarcity of IPv4 addresses. RIRs have exhausted their supply 
of IPv4 and their stated purpose is to assist growth. We believe leasing 
improves this, and opposite, by prohibiting lease and not offering any 
alternative way to receive IPv4 addresses RIR is limiting access to IPv4 
addresses and free, open and equal internet.

2.   By limiting the access for everyone to IPv4 addresses and denying the 
right to lease IPv4 addresses, RIR would create situation of monopoly, because 
bigger and wealthy organizations are able to obtain even more resources, on the 
other hand, smaller organizations can’t get the access. In our opinion it 
should be opposite, and RIR should liberalize the market for IPv4 addresses by 
showing more flexibility. RIR should stand for a good faith position that 
promotes an equitable system of Internet number assignment.

3.   We think that RIR should open and govern the market of lease, 
prohibiting it would lead to the users’ activities where they mask the lease; 
and again, it will lead to cybersecurity issues. RIR should serve as gatekeeper 
and registrar of IPv4 assets and encourage better transparency, not opposite.

4.   If RIR wants to control lease or transfer of LIR’s assets, it creates 
situation, where RIR interferes into the business model or business plan of the 
LIR’s entity. If RIR prohibits LIR to make one or other transaction, it acts 
ultra vires, - beyond the authority of RIR to perform. It is not an audit or 
supervisory institution, and should encourage the community to grow and 
develop, but not control, interfere, or prohibit commercial transactions of LIR 
companies.

5.   Some RIR members that strive to prohibit IP Lease explain this 
initiative as encouragement for organizations to migrate to IPv6, however, it 
is not a road to IPv6 adoption, but merely a roadblock. It should be known that 
bureaucratic and police state methods have never led to the progress or 
development. In this case, if IP lease would be prohibited, it would only 
create artificial problems for smaller entities which need and would like to 
lease IP addresses. So, instead of contributing to internet growth, RIR would 
“audit” LIR’s business activities and discourage trust and collaboration of RIR 
members.

6.   The authors of this proposal overloaded it with biased and misleading 
information. For example, the argument of authors that “IP Leasing is already 
banned in most RIRs and should stay as is” is wrong and misleading. According 
to the official statement of RIPE in the very similar discussion on analogous 
authors’ suggestion in ARIN region, “In the RIPE region the term "leasing" is 
not defined and therefore it does not play a role in the request evaluation.” 
Posting desperate and fabricated authors’ slogans in APNIC and ARIN policy 
suggestion groups do not turn them into the facts. Actually, it is very clear, 
that the authors of this suggestion seek “to encourage faster IPv6 adoption” 
because they are interested parties. However, they suggest achieving IPv6 
adoption by simply banning the access of IPv4, which is completely illogical 
and primitive way.

 

7. The text of the suggestion is full of obscurities. Here are some of them:

“Network connectivity services provided directly to customers” – how it is 
going to be checked if services are provided “directly to customers”? What the 
word “directly” means in this context? Is RIR obliged to have the list of each 
LIR’s customers and check the contractual obligations of LIR and customer?


“any form of IP address leasing” – the term of “leasing” in the 3rd latest 
version is finally added as a “Note”, however, definition raised more questions 
than answers. 

First, it says that leasing is providing resources “for a price or even for 
free” and this is the core of the definition, however, it doesn’t define 
parties of such “transaction”, or who provides resources to whom. 

Second, what kind of “leasing” is defined, if it also can be “for free”?

Third, with this construction, even "transfer" 

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

s 
next Thursday, the next date for the Policy SIG to discuss the proposal may be 
Feb next year.  Even if it does pass, the EC Endorsement phase is not until 
December giving the secretariat very little time to update and publish the new 
policy before proposed implementation.

 

Regards,

   Brett O'Hara

   FJ Networking.

 

 

On Fri, Sep 9, 2022 at 9:28 PM Brett O'Hara  wrote:

Hi Vivek,

 

I 100% understand and, within reason, support the EC resolution 2021-09.  I 
have attended many presentations on this topic and have gone through the 
process to acquire custodianship of my Historical Resources, and as such am not 
personally concerned about my situation.

I just can't see anywhere in the existing APNIC Internet Number Resources 
Policy that the secretariat currently has the power on the 1st of Jan 2023 to 
place Historical Resources advertised on the Internet into Reserved status.  I 
may have misread or misinterpreted, and I'm happy to be proved wrong here.

 

Can you please advise where in the Policy APNIC is currently empowered to take 
this action?

 

Regard,

Brett

 

On Fri, Sep 9, 2022 at 8:35 PM Vivek Nigam  wrote:

Hi Jordi, Aftab,

 

I have summarised the process APNIC uses to add/remove prefixes from APNIC AS0 
ROA. This may help explain why you did not find some of the prefixes in AS0 ROA.

 

Once a prefix is marked as 'reserved' it is added into AS0 ROA after 7 days to 
cause as little disruption as possible and avoid any inadvertent actions. Where 
possible, we also aggregate the prefixes that are added into AS0 ROA. When a 
prefix is delegated to a Member, it is removed from AS0 within 5 minute window.

 

As per our implementation of APNIC EC resolution 2021-09, any historical 
resources that are not maintained under an APNIC account will be removed from 
whois and marked as reserved on 1 January, 2023. 7 days after that, those 
reserved prefixes will be added into AS0 ROA.

 

Thanks

Vivek

 

From: JORDI PALET MARTINEZ via sig-policy 
Date: Wednesday, 7 September 2022 at 6:51 pm
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management

Question for the staff on this. Is the AS0 proposal not sufficient to comply 
with Aftab observation, or it is just something in the backlog of pending 
secretariat activities, or what is the reason for that?

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 30/8/22, 3:48, "Aftab Siddiqui"  escribió:

 

Hi Vivek,

 

On Mon, 29 Aug 2022 at 18:15, Vivek Nigam  wrote:

Hi Aftab,

 

APNIC creates RPKI ROAs with origin AS0 for all undelegated address space 
(marked as “Available” and “Reserved” in the delegated-apnic-extended-latest 
stats file. It may be worth noting that APNIC publishes these AS0 ROAs in a 
different Trust Anchor (AS0 TAL) and recommends its Members use APNIC AS0 TAL 
as a routing information service only.

 

https://www.apnic.net/community/security/resource-certification/apnic-limitations-of-liability-for-rpki-2/

 

 

That is incorrect, there are more than 160 IPv4 prefixes (I haven't checked v6 
yet) which are marked as either "reserved" or "available" in the APNIC 
delegation file and they don't exist in AS-0 ROA. So there must be some policy 
which is in place. 

 

delegate file: 2.3|apnic|20220830|158240||20220829|+1000

AS0 ROA: SigningTime:2022-08-30T01:10:15Z


Regards,

Aftab A. Siddiqui

 

 


**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Andrew,

 

Sorry missed this email before.

 

The disadvantages and the impact on resources holders that you mention are not, 
in my opinion, *because* this proposal but instead because the EC decision. 
Those will happen even if the proposal doesn’t reach consensus.

 

Would you agree with that conclusion?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 22:52, "Andrew Yager"  escribió:

 

Hi All,

 

The policy text states:

 

5. Advantages / Disadvantages
-
Advantages:
Fulfilling the objective above indicated. 

Disadvantages:
None. 6. Impact on resource holders
-
None.

 

 

I would conjecture that based on the discussions in this list:

5. Advantages / Disadvantages

-
Advantages

Returning resources to RIR for reallocation providing a temporary additional 
number of IPv4 resources to be allocated in the future

Disadvantages

Currently routed IP space within the global table will be potentially allocated 
to new resource holders who will be unable to utilise them

Existing valid unsigned routes will be mandated to be added to the AS0 space

Legitimate users of resources space that have not yet justified to APNICs 
satisfaction their historical ownership of resources they utilise will not be 
able continue to use resources

Global internet stability will be affected

 

6. Impact on resource holders



Resource holders who have been unable to satisfy APNIC's tests for historical 
resource ownership will be impacted with their routes. Noting that this is a 
direct consequence of the EC policy regarding historical AUNIC resources.

Internet routes which are valid as at 12/2022 may be hijacked by new assigned 
resource owners in the future

 

--

 

I continue to assert that there are too many issues with this current policy 
proposal and the impact of it is too broad. While the goal of returning 
resources to the APNIC free pool is admirable, I cannot see it realistically 
achieving its stated aims.

 

As a concession, some alternate wording that considered whether a prefix needed 
to be removed from the global table for a period, say 36 months, before 
entering quarantine, and then returning to the free pool may be a compromise - 
but without some specific wording considered I could not comment on whether 
this would address my concerns.


At this point I remain opposed to this policy and do not believe it should be 
granted consensus and proceed.

 

Andrew

 

 

On Wed, 7 Sept 2022 at 22:12, Brett O'Hara  wrote:

Jordi,

 

I'm not sure that everyone here understands.  I don't think that the 
secretariat actually can, under the current Policy, AS0 legacy addresses on the 
proposed date.  Unless a policy like yours or similar is passed, the EC cannot 
actually enact resolution 2021-09.  I find it very concerning for APNIC 
governance and for members that there is no published policy on this topic.

 

What I believe is required before considering the support of your proposition 
is the EC's assurance, considering the slow progress of the HRM project, that 
they still back the proposed date and they take full responsibility for the 
outcomes.  The details of your proposal could then be considered.

 

This would be the appropriate due diligence of the Policy SIG.

 

Regards,

Brett

 

On Wed, Sep 7, 2022 at 8:13 PM Andrew Yager  wrote:

Simply because almost no network implements AS-0 blocking due to the issues 
with it.

 

Andrew

 

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 8:09:06 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management 

 

Considering that the EC decision is going to affect the resources on January 
1st, I think waiting so long as you suggest 3-5 years, is not very sensible. 
Waste of resources, why even waste time for the staff to contact holders 
anymore?

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 11:43, "Andrew Yager"  escribió:

 

The problem remains that regardless of what the decisions of the EC are, these 
resources are still by and large present in the global routing table.

 

A decision to reclaim and reissue is impractical, and also impacts the 
stability of the internet.

 

While the EC made a decision that lists these resources in AS0; it would be far 
more problematic to assume that by users of these resources are in fact 
available to reissue at this time, and I remain unconvinced that 12 months is 
the right timeframe. Perhaps we will be in a better position to evaluate this 
in 12 months time and then set a timeframe.

 

If this policy is to go be approved (which I still don’t agree with) I would at 
it at 36-60 months is more practical.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 7:02:10 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Marco,

 

Small clarification from our side. We actually checked this with the policy 
officer around March-April-May 2022, if I recall correctly.

 

What we got from that email exchange was that "leasing" is not defined, but 
also was not explicitly allowed neither disallowed as a valid justification.

 

The point is that with the waiting list there is just a form and no 
justification is provided, you just confirm your intention to make assignments 
within 2 years and that at least one active network element in the network is 
active in the RIPE NCC service region to qualify for a single /24.

 

The point is if we were to ask for a justification, I don’t see how come I will 
be able to say “I will not make assignments, but lease addresses”, right? 
Otherwise, we should say that it is the wild west, really ugly.

 

Regards,

Jordi

@jordipalet

 

 

 

El 12/9/22, 10:39, "Marco Schmidt"  escribió:

 

Hello Ernest and colleagues,

I would like to provide some clarification for the RIPE region.

The proposal states
--
In other RIRs, the leasing of addresses is not authorized either and since it 
is not explicit in their policy manuals either, this proposal will be presented 
as well.

Nothing is currently mentioned in RIPE about this and it is not acceptable as a 
justification of the need. [...]
--

In the RIPE region the term "leasing" is not defined and therefore it does not 
play a role in the request evaluation. 
Further, the RIPE policies for IPv4 do not require any specific justification 
of the need.

Before providing a statement about the policy status in the RIPE region, I 
kindly suggest that proposers contact first our Policy Officer (p...@ripe.net) 
for input.

Kind regards,
Marco Schmidt
Manager Registration Services & Policy Development
RIPE NCC

On 09/09/2022 18:01, Lu Heng wrote:

Hi Ernest: 

 

RIPE, ARIN,AFRINIC does not have any of the similar policy.

 

Due to language barriers, I am not familiar with LACINIC.

 

 

 

On Fri, 9 Sept 2022 at 17:51, ERNEST TSE  wrote:

Hi All, 

 

Just take a look of this new policy suggested and I know this is still in 
discussion stage.

First at all, my business don't have any IP leasing business in APNIC region. 
And majorly my business is doing hosting business, and now I'm sitting in RIPE 
region (UK) for my business.

 

For my view of this new policy as below:

(1) Is that RIPE really have this kind of policy? Which one? (This policy 
suggested RIPE have this kind of policy?) I cannot see it the same thing in 
RIPE of our membership account.

(2) If leasing is not allowed, is that mean small business (New hosting / ISP) 
won't be able to get the new IPv4 address from leasing market? Or they just can 
buy it at high cost from second market?

(3) The policy suggested that there need to have "direct connection", is that 
mean GRE/VPN is also not included? How about if some customers in mainland 
China, they would like to get virtual Internet address from outside(mainly HK) 
in some case?

(4) Any new solution for new comer to apply IPv4 direct from APNIC? If no, what 
they can do?

 

Hope someone can answer of above questions.

 

Thank you,

Ernest Tse

 

Lu Heng  於 2022年9月9日 週五 下午4:13寫道：

Aftab: 

 

Any of APNIC document can not be outside scope of law.

 

Or you suggesting that clause will except APNIC from rule of law?

 

On Fri, 9 Sept 2022 at 16:01, Aftab Siddiqui  wrote:

Hi Lu,
 

On Fri, 9 Sept 2022 at 16:35, Lu Heng  wrote:

Hi Andrew: 

 

No, I did not say the registrar has no power to enforce its own contract.

 

I am saying the power in such a contract is very limited.

 

And policies being made here can not dump out of legal limitation of a contract.

 

IANAL, but just for your information.

 

Membership Agreement

The Member must:

3.2 (d) Comply with this agreement and all APNIC Documents. 

 

All policies once approved and implemented become part of the APNIC documents 
and that's why they become part of the membership agreement. 

 

Anyways, we were discussing the merit of the policy on technical and 
operational grounds not on political grounds or business interest. 

 

 

Regards,

Aftab A. Siddiqui

 


 

-- 

--
Kind regards.
Lu

___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net


 

-- 

--
Kind regards.
Lu



___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net
___ sig-policy - 
https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an 
email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Richard,

 

We like it or not, the policies are our laws. You don’t like law wording, use 
norms, use mandatory rules, whatever you want, but at the end all has the same 
meaning: rules set by the community to follow that must be enforced by APNIC.

 

And the rules must be written in a clear way, so there are no interpretation 
doubts.

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 23:49, "Richard Ham"  escribió:

 

Hi all,

 

The arguments are circular and do not resolving anything.

 

The continued debate about “law” (it’s not – it’s policy), original 
justification (mine is about the same age as a Cisco 1600 router and simply is 
not useful or relevant in 2022) and square peg in a round hole ways of 
determining if leasing is happening and then punishing the evil perpetrator is 
ample proof that this policy is not reaching consensus.

 

Regards,

 

Richard

 

 

 

From: Fernando Frediani  
Sent: Thursday, 8 September 2022 9:54 PM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable

 

Hello Aftab

Let me address this concern so perhaps it gets better clarified.

If an organization who is for example a CDN provider and asks APNIC for an ASN 
number and IP addresses and have justified will use them to provide hosting and 
CDN services to their customers through the infrastructure they own or contract 
from a provider, then there is nothing wrong if eventually that CDN provider 
asks for their upstream provider who provide them connectivity and colocation 
services, to announce their prefixes with the upstream ASN and not their own.

In this scenario there is no problem that the CDN provider ASN will not appear 
in the as-path because at the end the resources remaing being used for what 
they were originally justified and for the own resource holder to use them to 
provide internet services to their customers.

I personally think that not appearing the resource holder ASN in the as-path 
could be a signal of that resources are being rented but this alone cannot be 
something forbidden.
The important things is that resources get used by the resource holder for what 
they were justified and according to the current policy.

Best regards
Fernando

On 08/09/2022 08:20, Aftab Siddiqui wrote:


skipping the other bits..

 

If there is not a direct link from an LIR to a customer, then is not a direct 
connectivity. So, in that case is not tied to a connectivity service.

 

 

I have a simple question, is this an example of leasing or not? 103.93.157.0/25 
allocated to an entity with 2 ASNs (AS149847 and AS136594) but it is announced 
by AS32787. The original entite ASNs are not in the path at all.

 

103.93.157.0/24* and 103.114.130.0/24*
apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
apnic|AU|asn|149847|1|20220526|allocated|A91A0031
apnic|AU|asn|136594|1|20170523|allocated|A91A0031

N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534 20473 
32787 i
N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534 20473 
32787 i

 

Answer to this question is important because you are mixing business and 
operational practices. 

 
___
sig-policy - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net
___ sig-policy - 
https://mailman.apnic.net/sig-policy@lists.apnic.net/ To unsubscribe send an 
email to sig-policy-le...@lists.apnic.net



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Lu,

 

I fully understand that you want to protect your business in every RIR where 
you have resources, but this is not the point here.

 

Here we must try to keep our personal or business interest at a side. 
Exaggerated views as you expose a about looking for 5000 signatures is plain 
wrong; this is not the way this community works. Everyone in the world, even in 
other planets, if they are using Internet, is part of the community. They are 
free to participate, but when anyone actually participating suggest 
improvements or changes in policies, what it counts is who actually 
participates, not what we must ask for signatures or votes about if a proposal 
is good or bad for your business.

 

The point here is that leasing is already against policies, but *the fact that 
we are having this discussion* shows that is not so clear for everyone, and 
just making it clear and transparent so anyone reading the policy manual get 
it, is the honest thing to do.

 

I’ve never talked about regulatory power or anything like that, so no meaning 
to engage in a discussion about that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 9/9/22, 7:34, "Lu Heng"  escribió:

 

Hi Jordi:

 

No, it's you who confuse the few people in this room with the real community. 
Bragging how many policies you have proposed without real community just future 
shows your ignorance and arrogance.

 

Community by definition, is every internet user, my grandma included(Rob's 
original words while I ask him this question).

 

So how about getting 1% of the community to support you by signing a petition? 
It's about 3-4 billion community members in Asia, so 30 million signatures 
would do.

 

I have reduced that difficulty by assuming all APNIC members can represent 
their end user(which is probably not true), so reduce your workload from 30 
million signatures to about 5000 companies.

 

Can you do it? Do you have any idea what those 3billion community members want, 
how many of them you have talked to?

 

You have never reached the real community and you are trying to use a private 
company's company policy to enforce regulatory power.

 

You believe APNIC has the power to disconnect an entire nation if that telecom 
does not obey APNIC "policy" made in this room.

 

You did not realise the policy here does not have any more legal value than 
dress code in any company.

 

As it is currently set up, APNIC as a small private company, the policy can 
only be "a set of operation principles to best operate in a global coodicated 
registration database, nothing more, nothing less.", It can not carry any 
regulatory power.

 

And your policy involves telling people how to run their business, as a single 
person that has no rights represents any of the 3-4 billion people here, you 
have no rights to impose legislation in all those countries in the region. 
APNIC has no rights in impose regulatory power of any kind to its service 
countries, 

 

Secretariat, correct me if you think you have regulatory power.

 

Unless and until APNIC is represented by people elected government officials, 
and becomes an intergovernmental body, such a policy, and many other your 
policy goes along the same line of "if you don't obey we will put you out of 
business" will simply put APNIC out of business.

 

On Thu, 8 Sept 2022 at 19:04, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Lu,

 

I think your confuse members with community. 100% of members could say no to a 
policy proposal and they not provide valid objections and the proposal reach 
consensus. Membership is a very small subset of the community and the policy 
process is driven by rough consensus, not a voting or anything similar.

 

Consequently, is also wrong that policies need to be made by real members of 
APNIC.

 

I don’t understand your point about my proposals and 10% of support. I will say 
otherwise. In 20 years or so, I participated in over 100 hundred policy 
proposals (approximately, didn’t counted them exactly) among all the 5 RIRs, 
and around 95% (or so) of them succeeded. I guess it shows something.

 

APNIC and all the RIRs are not just a bookkeeper, they are the guardians of the 
Internet Number Resources following the community mandates (policies), NOT the 
members mandate.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 8:48, "Lu Heng"  escribió:

 

Hi

 

Let me ask Secretariat a simple question:

 

There is currently one of largest APNIC members who are leasing IP addresses to 
millions of end users(I won't name who that is but people in business should 
know), if this policy is adopted, how will the secretariat plan to enforce it 
without being sued out of existence?

 

 The problem of this policy development process is, the real community is not 
involved. The real community is the near 1 members and billions of end 
users those members represent.

 

Yes, it could be argued it is their faul

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

No, because in that case my cloud provider is becoming part of my network!

 

We didn’t said that you must “own” the network, because that’s not suggested by 
actual policies.

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 13:32, "Brett O'Hara"  escribió:

 

Hi Jordi,

 

Now you're breaking the Internet and not just leasing.  If a member chooses to 
allow a cloud provider AS advertise their address space and operate the compute 
for their our "Internet Infrastructure", are they now in violation of your 
definition?

 

Regards,

Brett

 

On Thu, Sep 8, 2022 at 9:27 PM JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Andrew,

 

The membership agreement also calls for policy compliance. I guess we agree on 
that.

 

If that’s the case, then we need to double check with the secretariat if their 
understanding of

 

“users of their network services” (2.1.3)

And 

“for exclusive use within the Internet infrastructure they operate” (2.2.3)

 

Is consistent with direct conneciivity or they will accept as a valid 
justification “my customers are not directly connected to my network”, but 
instead belong to other networks but I provide addresses to them.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 13:20, "Andrew Yager"  escribió:

 

But what is direct? You keep coming back to it but are unwilling to define it.

 

Also - I disagree that your interpretation of the membership agreement about 
“direct connectivity” is required. Your proposal now changes the membership 
agreement as direct is not currently contained in the definition.

 

The current resource agreement merely states connectivity.

 

This is why definitions are important. And once again why this proposal over 
reaches, and is not necessary.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Thursday, September 8, 2022 9:11:51 PM
To: sig-policy 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Aftab, Andrew (answering both),

 

I can’t believe that we need to define “direct connectivity” as well. Is not 
your understanding that if you’ve a customer connected via a direct link 
(instead of a tunnel, for example), is direct connectivity?

 

Anyone will accept as “direct” a tunnel by means of another transit?

 

In 2.1.3. say:

“… may assign address space to their own network infrastructure and to users of 
their network services. An LIR’s customers may be other “downstream” ISPs, 
which further assign address space to their own customers.”

 

And in 2.2.3:

“Assigned address space is address space that is delegated to an LIR, or 
end-user, for exclusive use within the Internet infrastructure they operate.”

 

 

If there is not a direct link from an LIR to a customer, then is not a direct 
connectivity. So, in that case is not tied to a connectivity service.

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:53, "Aftab Siddiqui"  escribió:

 

Hi Jordi,

 

On Thu, 8 Sept 2022 at 20:44, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Aftab,

 

It is not a matter of who announces them, but if they are connected to the 
original resource holder, so then the addresses are part of the connectivity 
service.

 

I gave you 3 clear cases where the custodians of resources have no direct 
connection as per the routing entries, there is no "connectivity service" here 
and who will define what is connectivity service?. This is what Andrew and Bret 
have highlighted several times in this discussion which you have failed to 
respond to.

 

Regards,

Aftab A. Siddiqui

 

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 3:22, "Aftab Siddiqui"  escribió:

 

Hey Jordi,

 

On Wed, 7 Sept 2022 at 23:45, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Looking into English dictionaries and trying to make something specific to our 
case. Maybe:

 

Providing Internet Number Resources for a price (paid in any form) or even for 
free, when not tied to a direct connectivity service. 

 

 

So do you want to reclaim the following resources from their respective 
custodians as it is announced by an unrelated entity?

 

103.93.157.0/24* and 103.114.130.0/24*
apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
apnic|AU|asn|149847|1|20220526|allocated|A91A0031
apnic|AU|asn|136594|1|20170523|allocated|A91A0031

N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534 20473 
32787 i
N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534 20473 
32787 i


103.81.228.0/24 *
apnic|SG|ipv4|103.81.228.0|256|20161219|assigned|A91E3136

N*> 103.81.228.0/24  169.254.169.25450  0 64515 65534 20473 
13335 i

1.1.1.0/24 and 1.0.0.0/24 *
apnic|AU|ipv4|1.1.1.0|256|20110811|assigned|A91872ED
apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A91872ED

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Not responding for this specific case, but in general:

 

If the original resource holder is NOT in the path, I can’t see how they are 
offering the addresses as part of a connectivity service.

 

Happy to be enlighted!

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 13:21, "Aftab Siddiqui"  escribió:

 


skipping the other bits..

 

If there is not a direct link from an LIR to a customer, then is not a direct 
connectivity. So, in that case is not tied to a connectivity service.

 

 

I have a simple question, is this an example of leasing or not? 103.93.157.0/25 
allocated to an entity with 2 ASNs (AS149847 and AS136594) but it is announced 
by AS32787. The original entite ASNs are not in the path at all.

 

103.93.157.0/24* and 103.114.130.0/24*
apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
apnic|AU|asn|149847|1|20220526|allocated|A91A0031
apnic|AU|asn|136594|1|20170523|allocated|A91A0031

N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534 20473 
32787 i
N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534 20473 
32787 i

 

Answer to this question is important because you are mixing business and 
operational practices. 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Well, the staff can respond to that.

 

In other RIRs, lack of investigation steps in case of policy non-compliance, 
lack of enforcement measures is not an issue, but in case of APNIC they always 
indicate in the analysis impact, that they need an explicit wording out.

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 13:23, "Andrew Yager"  escribió:

 

Again - you assert that there is a problem without any proof that there is. You 
assert that the agreement is somehow not enforceable without this policy. This 
is completely incorrect. You assert that APNIC is presently powerless, but 
provide no proof that this is the case.

 

I can see this is getting nowhere at this point so I’ll leave it here.

 

Andrew 

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Thursday, September 8, 2022 9:15:36 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Yes, that always happen. There are good and bad people in the world. Some 
people, as we have seen in other RIRs, has obtained resources with bad faith 
far beyond bending the rules. Some people have obtained resources with a 
justification of the need that was only a lie, or if was not a lie, failed the 
business model and changed the use of the resources, which is not allowed.

 

Nothing to be surprised again, and the RIRs must have the means to resolve that 
and make the membership agreement enforceable, which some times, may require 
policy clarifications as we are suggesting here.

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:59, "Andrew Yager"  escribió:

 

I fail to see the logic in this argument. You are suggesting the membership 
agreement has no value and Is unenforceable.  This is not the case.

 

You are also suggesting that people are obtaining resources using fraudulent 
methods. At least in Australia, this is illegal. But I have seen no evidence 
that this is the case.

 

You are saying we need this policy because the existing framework is inadequate 
- but as of yet there is no evidence provided to support this assertion.

 

In the event that a need can be demonstrated, then we are still faced with all 
the other issues outlined.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Thursday, September 8, 2022 8:53:38 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

And by the way, and this key with any lack of policy compliance. All the RIRs 
will always attempt to recover the situation in case of lack-of-compliance.

 

So, the address holders can always say, sorry, didn’t knew that this was my bad 
interpretation of the policy text. I will correct the situation immediately.

 

Then the RIR doesn't need to recover the resources.

 

An exception to that, in my opinion, is false documentation, which shows a 
clear bad faith when requesting resources. There have been some cases in RIPE 
of falsified passports, or other documents. No excuses for that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:50, "JORDI PALET MARTINEZ via sig-policy" 
 escribió:

 

Hi Matthew,

 

The starting point here is that leasing is not allowed and this proposal is not 
changing it, just making sure that’s clearly understood by everyone.

 

If anyone is breaking “law” even if that has been happening for several years, 
do you believe the right thing is to continue ignoring that?

 

I feel that it is much better to amend the law text to ensure that everybody 
has the same understanding. And this is what we are doing.

 

The alternative is to change the law and declare and amnesty of those that 
bypassed the law for years. Do you think this is fair? You don’t think this is 
giving the sign that oh well we should ignore policies because they are not 
clear (even if we know that we are doing wrong), because an amnesty will come?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 3:54, "Matthew Shearing"  escribió:

 

Just wanted to chime in here and follow up on Mike's point (and those of 
several others).

 

What APNIC has done by its previous conduct is create a scarce asset collected 
in the hands of a number of large providers, with increasingly less being 
issued to small providers. As with any scarce asset in human history, this 
necessarily creates all the prerequisites for a fee market.

 

Just like real estate, vehicles and other commodities, leasing is a natural 
evolution of scarcity in an asset class with direct utility. Right now, IPv4 
blocks are like houses - some own them, but some don't have the capital 
resources to outright own the amount they need. Simply looking at the prices 
which IPv4 blocks are going for on the open market will make it clear that many 
smaller businesses are priced out.

 

Leasing represents

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Andrew,

 

The membership agreement also calls for policy compliance. I guess we agree on 
that.

 

If that’s the case, then we need to double check with the secretariat if their 
understanding of

 

“users of their network services” (2.1.3)

And 

“for exclusive use within the Internet infrastructure they operate” (2.2.3)

 

Is consistent with direct conneciivity or they will accept as a valid 
justification “my customers are not directly connected to my network”, but 
instead belong to other networks but I provide addresses to them.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 13:20, "Andrew Yager"  escribió:

 

But what is direct? You keep coming back to it but are unwilling to define it.

 

Also - I disagree that your interpretation of the membership agreement about 
“direct connectivity” is required. Your proposal now changes the membership 
agreement as direct is not currently contained in the definition.

 

The current resource agreement merely states connectivity.

 

This is why definitions are important. And once again why this proposal over 
reaches, and is not necessary.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Thursday, September 8, 2022 9:11:51 PM
To: sig-policy 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Aftab, Andrew (answering both),

 

I can’t believe that we need to define “direct connectivity” as well. Is not 
your understanding that if you’ve a customer connected via a direct link 
(instead of a tunnel, for example), is direct connectivity?

 

Anyone will accept as “direct” a tunnel by means of another transit?

 

In 2.1.3. say:

“… may assign address space to their own network infrastructure and to users of 
their network services. An LIR’s customers may be other “downstream” ISPs, 
which further assign address space to their own customers.”

 

And in 2.2.3:

“Assigned address space is address space that is delegated to an LIR, or 
end-user, for exclusive use within the Internet infrastructure they operate.”

 

 

If there is not a direct link from an LIR to a customer, then is not a direct 
connectivity. So, in that case is not tied to a connectivity service.

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:53, "Aftab Siddiqui"  escribió:

 

Hi Jordi,

 

On Thu, 8 Sept 2022 at 20:44, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Aftab,

 

It is not a matter of who announces them, but if they are connected to the 
original resource holder, so then the addresses are part of the connectivity 
service.

 

I gave you 3 clear cases where the custodians of resources have no direct 
connection as per the routing entries, there is no "connectivity service" here 
and who will define what is connectivity service?. This is what Andrew and Bret 
have highlighted several times in this discussion which you have failed to 
respond to.

 

Regards,

Aftab A. Siddiqui

 

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 3:22, "Aftab Siddiqui"  escribió:

 

Hey Jordi,

 

On Wed, 7 Sept 2022 at 23:45, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Looking into English dictionaries and trying to make something specific to our 
case. Maybe:

 

Providing Internet Number Resources for a price (paid in any form) or even for 
free, when not tied to a direct connectivity service. 

 

 

So do you want to reclaim the following resources from their respective 
custodians as it is announced by an unrelated entity?

 

103.93.157.0/24* and 103.114.130.0/24*
apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
apnic|AU|asn|149847|1|20220526|allocated|A91A0031
apnic|AU|asn|136594|1|20170523|allocated|A91A0031

N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534 20473 
32787 i
N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534 20473 
32787 i


103.81.228.0/24 *
apnic|SG|ipv4|103.81.228.0|256|20161219|assigned|A91E3136

N*> 103.81.228.0/24  169.254.169.25450  0 64515 65534 20473 
13335 i

1.1.1.0/24 and 1.0.0.0/24 *
apnic|AU|ipv4|1.1.1.0|256|20110811|assigned|A91872ED
apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A91872ED
apnic|AU|asn|9838|1|20100203|allocated|A91872ED
apnic|AU|asn|24021|1|20080326|allocated|A91872ED
apnic|JP|asn|38610|1|20070716|allocated|A91872ED
apnic|AU|asn|131072|1|20070117|allocated|A91872ED
apnic|AU|asn|131074|1|20070115|allocated|A91872ED

V*  1.1.1.0/24   103.126.52.155 0 141384 4826 13335 
i

 

*APNIC delegate file

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 15:35, "Mike Burns"  escribió:

 

Hello,

 

If we don't have a definition of Leasing we can't fully consider the issues of 
enforcement, among other items.

 

As with many things the devil is in the details.

 

Regards,

 

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

I will be nice to have a clear answer on those points from the secretariat!

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 14:13, "Brett O'Hara"  escribió:

 

Jordi,

 

I'm not sure that everyone here understands.  I don't think that the 
secretariat actually can, under the current Policy, AS0 legacy addresses on the 
proposed date.  Unless a policy like yours or similar is passed, the EC cannot 
actually enact resolution 2021-09.  I find it very concerning for APNIC 
governance and for members that there is no published policy on this topic.

 

What I believe is required before considering the support of your proposition 
is the EC's assurance, considering the slow progress of the HRM project, that 
they still back the proposed date and they take full responsibility for the 
outcomes.  The details of your proposal could then be considered.

 

This would be the appropriate due diligence of the Policy SIG.

 

Regards,

Brett

 

On Wed, Sep 7, 2022 at 8:13 PM Andrew Yager  wrote:

Simply because almost no network implements AS-0 blocking due to the issues 
with it.

 

Andrew

 

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 8:09:06 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management 

 

Considering that the EC decision is going to affect the resources on January 
1st, I think waiting so long as you suggest 3-5 years, is not very sensible. 
Waste of resources, why even waste time for the staff to contact holders 
anymore?

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 11:43, "Andrew Yager"  escribió:

 

The problem remains that regardless of what the decisions of the EC are, these 
resources are still by and large present in the global routing table.

 

A decision to reclaim and reissue is impractical, and also impacts the 
stability of the internet.

 

While the EC made a decision that lists these resources in AS0; it would be far 
more problematic to assume that by users of these resources are in fact 
available to reissue at this time, and I remain unconvinced that 12 months is 
the right timeframe. Perhaps we will be in a better position to evaluate this 
in 12 months time and then set a timeframe.

 

If this policy is to go be approved (which I still don’t agree with) I would at 
it at 36-60 months is more practical.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 7:02:10 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management 

 

I fail to understand why taking already the decision of what to do, like in 
option 2, should be delayed, if we already agree that 12 months is a good 
timing.

 

The PDP allows us to amend the policy text if we need to extend this timing or 
do something else, but I always believe that acting now is better than late, 
and having a strict deadline for not just January 1st, but also one year later, 
will help to enforce the custodians to react, and ensure that APNIC also 
request more resrouces (if needed) to finalize the job.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 10:51, "Andrew Yager"  escribió:

 

Hi,

 

For now, so believe that option 1 you indicated is better. I think we may be in 
a better place to decide option 2 is better in 12 months.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 6:43:22 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management 

 

Hi Aftab,

 

Would you agree extending the 12 months into 18 months?

 

Or maybe an alternative text to the proposal offering a different solution, may 
be 2 different stages in the process, I don’t know, just thinking loud.

 

The point here is:

1.   We do nothing: all those resources are in reserved state (no 
services), instead of some of them being able to be reused by members/newcomers.

2.   We act now: Slowly, some resources will be back to the community in 
the next 12 months, or original custodians will become “visible”.

 

I really think option 2 is better. I fail to understand why you don’t think so. 
If the problem is the timing let’s talk about a longer period instead of 12 
months. Or let’s consider other alternatives. We know that the community will 
not discuss this anymore for the next 6 months, until the next meeting is 
closer. Why we don’t try to fix it now?

 

I can’t believe that we get stuck into option 1, enforced by the EC.

 

To be honest, I disagree with the EC decision on this. It would have been much 
better to have a community decision *before* an enforced EC decision. I 
actually summited a proposal about that whay ahead the EC decision, but the 
chairs decided not to accept it. I think the chairs erred with that. The 
community is on top o

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Satoru,

Tks a lot and well understood from my side.


Regards,
Jordi
@jordipalet
 
 

El 8/9/22, 3:23, "Tsurumaki, Satoru"  escribió:

Hi Jordi,

There was no discussion whether the term should be 6 or 12 months in
the past meeting.
As you can see from my earlier email, the majority of the Japanese
community is in favor of the proposal itself.

It’s a significant change to have historical holders become
members/non-members of APNIC.
Therefore, we believe that we should clearly communicate to current
APNIC members what HRM activities we have been involved in and the
reasons that would compel us to take such a mandatory step.

Regards,
Satoru

2022年9月7日(水) 17:54 JORDI PALET MARTINEZ via sig-policy
:
>
> Hi Satoru,
>
> Tks for your inputs. It will be good if you can comment on the emails 
that I just responded.
>
> Key question is if we don't believe that 12 months is sufficient, would 
you agree with 18-months, or do you suggest any additional improvements to the 
proposal?
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 2/9/22, 7:13, "Tsurumaki, Satoru"  escribió:
>
> Dear Colleagues,
>
> I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..
>
> I would like to share key feedback in our community for prop-145,
> based on a meeting we organised on 29th Aug to discuss these 
proposals.
>
> Many support opinions were expressed about this proposal.
>
> And in response to a comment that HRM activities in Japan might be
> helpful, JPNIC staff reported on their activities in Japan.
>  - Start Dec.2014
>  - Contact resource holders by any means possible, email, phone, mail,
>referral from an acquaintance, etc.
>  - Finish 19th Mar 2019 with the signing of the contract with all
>resource Holders.
>
> (comment details)
>  - There are many unresponses to contacts from APNIC, which may have
> 　 a significant impact when it comes to consensus.
>  - It would be better to explain HRM's past activities for new members
>for more understanding.
>  - I support this proposal, but it will be necessary to response 
carefully
>to the resource holders
>
>
> Regards,
>
> Satoru Tsurumaki / JPOPF Steering Team
>
> 2022年8月11日(木) 16:00 chku :
> >
> > Dear SIG members,
> >
> > The proposal "prop-147: Historical Resources Management" has been
> > sent to the Policy SIG for review.
> >
> > It will be presented at the Open Policy Meeting (OPM) at APNIC 54 on
> > Thursday, 15 September 2022.
> >
> > https://conference.apnic.net/54/program/schedule/#/day/8
> >
> > 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-147
> >
> > Regards,
> > Bertrand, Shaila, and Ching-Heng
> > APNIC Policy SIG Chairs
> >
> >
> >
> > ---
> >
> > prop-147-v001: Historical Resources Management
> >
> > 
> >
> > Proposer: Jordi Palet Martinez 
(jordi.palet@theipv6company.comAnupam)
> >   Anupam Agrawal (anupamagrawal...@gmail.com)
> >
> >
> > 1. Problem statement
> > 
> > Section 4.2.1 is outd

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Yes, that always happen. There are good and bad people in the world. Some 
people, as we have seen in other RIRs, has obtained resources with bad faith 
far beyond bending the rules. Some people have obtained resources with a 
justification of the need that was only a lie, or if was not a lie, failed the 
business model and changed the use of the resources, which is not allowed.

 

Nothing to be surprised again, and the RIRs must have the means to resolve that 
and make the membership agreement enforceable, which some times, may require 
policy clarifications as we are suggesting here.

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:59, "Andrew Yager"  escribió:

 

I fail to see the logic in this argument. You are suggesting the membership 
agreement has no value and Is unenforceable.  This is not the case.

 

You are also suggesting that people are obtaining resources using fraudulent 
methods. At least in Australia, this is illegal. But I have seen no evidence 
that this is the case.

 

You are saying we need this policy because the existing framework is inadequate 
- but as of yet there is no evidence provided to support this assertion.

 

In the event that a need can be demonstrated, then we are still faced with all 
the other issues outlined.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Thursday, September 8, 2022 8:53:38 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

And by the way, and this key with any lack of policy compliance. All the RIRs 
will always attempt to recover the situation in case of lack-of-compliance.

 

So, the address holders can always say, sorry, didn’t knew that this was my bad 
interpretation of the policy text. I will correct the situation immediately.

 

Then the RIR doesn't need to recover the resources.

 

An exception to that, in my opinion, is false documentation, which shows a 
clear bad faith when requesting resources. There have been some cases in RIPE 
of falsified passports, or other documents. No excuses for that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:50, "JORDI PALET MARTINEZ via sig-policy" 
 escribió:

 

Hi Matthew,

 

The starting point here is that leasing is not allowed and this proposal is not 
changing it, just making sure that’s clearly understood by everyone.

 

If anyone is breaking “law” even if that has been happening for several years, 
do you believe the right thing is to continue ignoring that?

 

I feel that it is much better to amend the law text to ensure that everybody 
has the same understanding. And this is what we are doing.

 

The alternative is to change the law and declare and amnesty of those that 
bypassed the law for years. Do you think this is fair? You don’t think this is 
giving the sign that oh well we should ignore policies because they are not 
clear (even if we know that we are doing wrong), because an amnesty will come?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 3:54, "Matthew Shearing"  escribió:

 

Just wanted to chime in here and follow up on Mike's point (and those of 
several others).

 

What APNIC has done by its previous conduct is create a scarce asset collected 
in the hands of a number of large providers, with increasingly less being 
issued to small providers. As with any scarce asset in human history, this 
necessarily creates all the prerequisites for a fee market.

 

Just like real estate, vehicles and other commodities, leasing is a natural 
evolution of scarcity in an asset class with direct utility. Right now, IPv4 
blocks are like houses - some own them, but some don't have the capital 
resources to outright own the amount they need. Simply looking at the prices 
which IPv4 blocks are going for on the open market will make it clear that many 
smaller businesses are priced out.

 

Leasing represents a viable option for companies to access the blocks they need 
and pay manageable, monthly or yearly payments for the use of those blocks. 
Many businesses are reliant on these currently.

 

Saying that APNIC will outright ban leasing and that this will somehow benefit 
businesses is abjectly false. Not only will it disrupt many current business 
operations, but there is no guarantee that a market with more perverse 
incentives won't emerge afterwards. 

 

In our view, APNIC has already demonstrated by its statements and conduct with 
this policy that they have little grasp on how (and why) asset markets evolve. 
They've also done nothing to dissuade us that the new 'status quo' after this 
policy change won't be worse than the current one - which operates relatively 
fine.

 

Practically, for APNIC to say there will be no meaningful damage to current 
users and businesses (who are APNIC members in their own right) it must answer 
the following questions:

 

· What alternative doe

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Aftab, Andrew (answering both),

 

I can’t believe that we need to define “direct connectivity” as well. Is not 
your understanding that if you’ve a customer connected via a direct link 
(instead of a tunnel, for example), is direct connectivity?

 

Anyone will accept as “direct” a tunnel by means of another transit?

 

In 2.1.3. say:

“… may assign address space to their own network infrastructure and to users of 
their network services. An LIR’s customers may be other “downstream” ISPs, 
which further assign address space to their own customers.”

 

And in 2.2.3:

“Assigned address space is address space that is delegated to an LIR, or 
end-user, for exclusive use within the Internet infrastructure they operate.”

 

 

If there is not a direct link from an LIR to a customer, then is not a direct 
connectivity. So, in that case is not tied to a connectivity service.

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:53, "Aftab Siddiqui"  escribió:

 

Hi Jordi,

 

On Thu, 8 Sept 2022 at 20:44, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Aftab,

 

It is not a matter of who announces them, but if they are connected to the 
original resource holder, so then the addresses are part of the connectivity 
service.

 

I gave you 3 clear cases where the custodians of resources have no direct 
connection as per the routing entries, there is no "connectivity service" here 
and who will define what is connectivity service?. This is what Andrew and Bret 
have highlighted several times in this discussion which you have failed to 
respond to.

 

Regards,

Aftab A. Siddiqui

 

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 3:22, "Aftab Siddiqui"  escribió:

 

Hey Jordi,

 

On Wed, 7 Sept 2022 at 23:45, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Looking into English dictionaries and trying to make something specific to our 
case. Maybe:

 

Providing Internet Number Resources for a price (paid in any form) or even for 
free, when not tied to a direct connectivity service. 

 

 

So do you want to reclaim the following resources from their respective 
custodians as it is announced by an unrelated entity?

 

103.93.157.0/24* and 103.114.130.0/24*
apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
apnic|AU|asn|149847|1|20220526|allocated|A91A0031
apnic|AU|asn|136594|1|20170523|allocated|A91A0031

N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534 20473 
32787 i
N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534 20473 
32787 i


103.81.228.0/24 *
apnic|SG|ipv4|103.81.228.0|256|20161219|assigned|A91E3136

N*> 103.81.228.0/24  169.254.169.25450  0 64515 65534 20473 
13335 i

1.1.1.0/24 and 1.0.0.0/24 *
apnic|AU|ipv4|1.1.1.0|256|20110811|assigned|A91872ED
apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A91872ED
apnic|AU|asn|9838|1|20100203|allocated|A91872ED
apnic|AU|asn|24021|1|20080326|allocated|A91872ED
apnic|JP|asn|38610|1|20070716|allocated|A91872ED
apnic|AU|asn|131072|1|20070117|allocated|A91872ED
apnic|AU|asn|131074|1|20070115|allocated|A91872ED

V*  1.1.1.0/24   103.126.52.155 0 141384 4826 13335 
i

 

*APNIC delegate file

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 15:35, "Mike Burns"  escribió:

 

Hello,

 

If we don't have a definition of Leasing we can't fully consider the issues of 
enforcement, among other items.

 

As with many things the devil is in the details.

 

Regards,

 

Mike

 

 

 

 

 

 

Sent from my T-Mobile 4G LTE Device

 

 

---- Original message 

From: JORDI PALET MARTINEZ via sig-policy  

Date: 9/7/22 8:54 AM (GMT-05:00) 

To: sig-policy  

Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Brett,

 

I’m not saying that I reject a definition, what I’m saying is that I don’t 
think is needed, despite that I’m happy to include it if we agree on that, as 
can’t be other way, as this is the way we write proposals: understanding what 
the community want (not just the authors).

 

I’ve not been able to see the video of the discussion. Is it available? Maybe 
the staff can provide it, so I can better understand all the points?

 

Could you suggest a wording of leasing according to you view, to see if we can 
make it happen?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 14:41, "Brett O'Hara"  escribió:

 

Hi Jordi,

 

You have stated that you do need a definition because "any form of leasing is 
unacceptable", and yet I was verbally assured at the APNIC 54 Policy Proposals 
Webinar on the 25th of August, that several examples of leasing were 
acceptable, but not documented in the proposal.  My request for a definition in 
the proposal was positively received by the SIG and we left the issue to the 
authors.  If the respon

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Disagree partially. Education is important, but laws (policies for us), should 
be sufficiently explicit so no different interpretations are possible.

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:42, "Andrew Yager"  escribió:

 

No. That’s not the role of policy.

 

That’s the role of education.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Thursday, September 8, 2022 8:32:35 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Andrew,

 

I will say otherwise. As it has been clearly stated by the secretariat that 
leasing is not allowed, and some people believe it should be allowed, the 
proposal just clarify it.

 

If we, as a community believe leasing should be allowed, then, a proposal to 
change that *in the current policy manual* is needed. Otherwise, this proposal 
is precisely helping to ensure that the current policy text is well understood.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 22:00, "Andrew Yager"  escribió:

 

Wow. This response shows the absurdity of this proposal in the scheme of the 
internet community today and also the issues attached to the poor definitive 
and understanding of terms.

 

This proposal is bad policy, poorly worded and should not be accepted.

 

We thoroughly oppose its adoption in its current form.

 

The existing provisions are more than ample, and this proposal does nothing to 
improve the internet community.

 

In practice, the proposal has still not actually justified it’s need for 
existence and why it should exist.

 

Both Jordi and Fernando have stated multiple times their intention is to see 
unused space returned to the registrar.

 

If that is the intention of this, then make a new proposal to justify that. But 
where will that stop? Will you require operators to issue contiguous 
allocations? Will you require space consolidation? Will you redefine the many 
ways that providers interconnect across exchanges, over long haul services? 
Will you decide that connectivity will be via a physical cable, removing VXCs? 
There is a very narrow view presented here and it is clear that there is an end 
goal in mind from this policy - but this is not the mechanism to achieve it.

 

Again, the existing member agreement provisions are already sufficient and this 
policy adds no value. If the intention is a different outcome (return of unused 
resources to RIR) make a proposal to do that.

 

Andrew 

 

Get Outlook for iOS

From: Fernando Frediani 
Sent: Thursday, September 8, 2022 1:27 am
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hello Andrew

GRE tunnel is not a form of direct connectivity. In order to use a GRE tunnel 
it is already necessary to have a direct connectivity with a Internet Service 
Provider and Upstream who provide internet services.

Can you justify why you are against it if you recognize this is already 
prohibited under the membership agreement ? If something is already forbidden 
so what is the login of not willing to have in clear in the policy text in 
order to avoid any possible doubts ?

Again, this proposal is not changing the current status, so even without it the 
current status can already be circumvented and even if that happens eventually 
it does not invalidate the need to have something clear in the text to make it 
easier for members to understand and avoid that as also to help the RIR to 
stand for these points should a dispute gets to the courts.

Fernando

 

On 07/09/2022 07:48, Andrew Yager wrote:

I mean… to be devils advocate… a gre tunnel is pretty cheap to set up.

 

This type of policy is easily circumvented, and in my opinion unenforceable.

 

Additionally, this activity is already prohibited under the membership 
agreement and I still don’t see any value in adding this.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 8:30:23 PM
To: sig-policy 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Satoru, all,

We haven't defined leasing, because it is common English term, not something 
specific to "addresses".  I can understand that in other languages, it may not 
be the same, but because the policies are bound to the English language, we 
didn't feel the need to define it.

In fact, we had a similar discussion about that in LACNIC 6 months ago, and we 
decided to make a new version, which is the same as we published in APNIC. The 
point was to stress that "any form of leasing" is unacceptable. If you read 
that in the context of the policy, it starts, as you already mention "own 
infrastructure or directly connected customers". So, anything beyond that will 

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

argument that smaller business cannot afford the full 
upfront payment but can afford monthly lease payments?

 

Please address that simple argument by telling me how the small business 
benefits by not having the lease option, but only having the purchase option.

 

Regards,
Mike

 

 

From: Fernando Frediani  
Sent: Wednesday, September 7, 2022 1:01 PM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable

 

IP Leasing is already banned in most RIRs and should stay as is.

But yes it does help as it doesn't push even further up IPv4 pricing and makes 
it easier for these small companies to get IPv4 via the proper and allowed way 
which are transfers. Other then diverting totally the propose o IPv4 
Allocation, Leasing market contributes significantly to price increasing 
fueling the market with more demand for that type of very wrong thing.

RIPE is normally not a good example for certain policies which don't seem to 
have receptivity in discussions on all other RIRs. 

There are still mechanisms that allow companies to get IP addressing either 
directly from the RIR, via Transfers which is a pretty common way or from the 
Upstream providers. People may not have got used yet to learn to live with less 
address and they may believe they need a bunch of address.

IP Leasing will never help small companies. The ones who really benefit from it 
are the IP broker companies who profit from them and also the resource holders 
which don't justify anymore to keep those addresses and are also profiting from 
something that should have been re-assigned directly to those who really need 
and justify for them in order to build Internet Infrastructure and Connectivity 
and instead are leasing a asset they don't own.

Fernando

On 07/09/2022 12:39, Mike Burns wrote:

Hi Fernando,

 

So your argument is that banning leasing actually helps smaller companies in 
their quest for IPv4?

 

Are you aware that RIPE has allowed leasing for many years but is still a 
functioning RIR whose IPv4 sale prices are not more expensive despite the 
history of leasing there?

 

Can you reconcile that with your argument that leasing will raise prices for 
both leasing and transfers?

 

Are you aware that it’s not always possible to get IPv4 blocks from the company 
that is providing you with connectivity?

 

Regards,
Mike

 

 

 

From: Fernando Frediani  
Sent: Wednesday, September 7, 2022 11:27 AM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable

 

This is exactly the opposite.

Allowing IP leasing to happen more than just tottaly divert the propose of IP 
assignments by RIRs it make it bad specially for smaller companies as it 
increases the cost for both leasing and transfers in long term. The cost of 
leasing is based on the transfer and if leasing is allowed then transfer prices 
will  always go up which makes it even harder for smaller companies to go into 
the market.

Any form of IP leasing without a direct connection relationship to provide a 
connectivity service makes it more expensive for smaller companies to get IP 
addresses to operate.

Fernando

On 07/09/2022 11:15, Mike Burns wrote:

Hi Jordi,

 

It’s plain you feel that we should do all possible to raise the price of IPv4 
and make it unattainable for small business in the vain hope that this will 
drive IPv6 adoption.

 

I don’t think making IPv4 more difficult to acquire is the job of the RIR 
system.

 

You have not addressed the inability of smaller companies to acquire necessary 
IPv4 blocks if you ban leasing.

Is that something you are comfortable with, in pursuit of the IPv6 grail?

It’s okay with you that this policy prevents small companies from growing?

 

Regards,
Mike

 

 

From: JORDI PALET MARTINEZ via sig-policy  
Sent: Wednesday, September 7, 2022 10:11 AM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable

 

Actually, I must disagree …

 

If organizations having unused resources, they need to transfer them or return 
them to the RIR. If prices keep going high, that could encourage faster IPv6 
adoption, then transfer prices will go down, up to “no value”. It takes time, 
but it is just market.

 

Those that have more money, have more facilities to do a faster transition and 
not bother about IPv4.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 16:05, "Mike Burns"  escribió:

 

Hello,

 

Per Gaurav’s statement that “only those with millions of dollars can think of 
getting ips”, this community should oppose this policy.

 

Because the only way small companies can afford to get ips today is by leasing 
them.  The same way the small company can’t afford to purchase a big office 
building but instead rents an office. Leasing is the only way to finance IPv4 
acquisitions 

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

And by the way, and this key with any lack of policy compliance. All the RIRs 
will always attempt to recover the situation in case of lack-of-compliance.

 

So, the address holders can always say, sorry, didn’t knew that this was my bad 
interpretation of the policy text. I will correct the situation immediately.

 

Then the RIR doesn't need to recover the resources.

 

An exception to that, in my opinion, is false documentation, which shows a 
clear bad faith when requesting resources. There have been some cases in RIPE 
of falsified passports, or other documents. No excuses for that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 12:50, "JORDI PALET MARTINEZ via sig-policy" 
 escribió:

 

Hi Matthew,

 

The starting point here is that leasing is not allowed and this proposal is not 
changing it, just making sure that’s clearly understood by everyone.

 

If anyone is breaking “law” even if that has been happening for several years, 
do you believe the right thing is to continue ignoring that?

 

I feel that it is much better to amend the law text to ensure that everybody 
has the same understanding. And this is what we are doing.

 

The alternative is to change the law and declare and amnesty of those that 
bypassed the law for years. Do you think this is fair? You don’t think this is 
giving the sign that oh well we should ignore policies because they are not 
clear (even if we know that we are doing wrong), because an amnesty will come?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 3:54, "Matthew Shearing"  escribió:

 

Just wanted to chime in here and follow up on Mike's point (and those of 
several others).

 

What APNIC has done by its previous conduct is create a scarce asset collected 
in the hands of a number of large providers, with increasingly less being 
issued to small providers. As with any scarce asset in human history, this 
necessarily creates all the prerequisites for a fee market.

 

Just like real estate, vehicles and other commodities, leasing is a natural 
evolution of scarcity in an asset class with direct utility. Right now, IPv4 
blocks are like houses - some own them, but some don't have the capital 
resources to outright own the amount they need. Simply looking at the prices 
which IPv4 blocks are going for on the open market will make it clear that many 
smaller businesses are priced out.

 

Leasing represents a viable option for companies to access the blocks they need 
and pay manageable, monthly or yearly payments for the use of those blocks. 
Many businesses are reliant on these currently.

 

Saying that APNIC will outright ban leasing and that this will somehow benefit 
businesses is abjectly false. Not only will it disrupt many current business 
operations, but there is no guarantee that a market with more perverse 
incentives won't emerge afterwards. 

 

In our view, APNIC has already demonstrated by its statements and conduct with 
this policy that they have little grasp on how (and why) asset markets evolve. 
They've also done nothing to dissuade us that the new 'status quo' after this 
policy change won't be worse than the current one - which operates relatively 
fine.

 

Practically, for APNIC to say there will be no meaningful damage to current 
users and businesses (who are APNIC members in their own right) it must answer 
the following questions:

 

· What alternative does APNIC propose to the current IPv4 market and 
particularly, leasing options available to smaller companies and new entrants?

· How will terminating leases currently on foot result in a better 
outcome for the businesses currently relying on them?

· How will new IPv4 addresses be allocated, what timeframes and costs 
will be involved in this allocation?

· Can APNIC give guarantees to current lessees who are reliant on IPv4 
address leases that they can continue to access those addresses or will have 
replacements of similar value, at less cost, instantly after the change is made?

· Is APNIC prepared to be held liable in lawsuits or a class action for 
the damages incurred by this policy change? Has it considered this risk and 
informed members accordingly?

 

It appears that those that will not be affected by this policy or those who 
already have large IPv4 blocks are some of the largest proponents of it - which 
makes sense. It is easy to vote for a change if it's only others that will be 
affected. 

 

However, there are a large number of SME businesses out there who rely on these 
leases to run their operations. For them, this isn't just some merely 
intellectual exercise. Rather, it's a question of hundreds of thousands, or 
even millions, of dollars. 

 

It's their ability to remain operational. It's their employees' livelihoods and 
those of their families. It's a core part of how they operate and for many, the 
foundation which they've built their business on.

 

This policy ch

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

 than just tottaly divert the propose of IP 
assignments by RIRs it make it bad specially for smaller companies as it 
increases the cost for both leasing and transfers in long term. The cost of 
leasing is based on the transfer and if leasing is allowed then transfer prices 
will  always go up which makes it even harder for smaller companies to go into 
the market.

Any form of IP leasing without a direct connection relationship to provide a 
connectivity service makes it more expensive for smaller companies to get IP 
addresses to operate.

Fernando

On 07/09/2022 11:15, Mike Burns wrote:

Hi Jordi,

 

It’s plain you feel that we should do all possible to raise the price of IPv4 
and make it unattainable for small business in the vain hope that this will 
drive IPv6 adoption.

 

I don’t think making IPv4 more difficult to acquire is the job of the RIR 
system.

 

You have not addressed the inability of smaller companies to acquire necessary 
IPv4 blocks if you ban leasing.

Is that something you are comfortable with, in pursuit of the IPv6 grail?

It’s okay with you that this policy prevents small companies from growing?

 

Regards,
Mike

 

 

From: JORDI PALET MARTINEZ via sig-policy  
Sent: Wednesday, September 7, 2022 10:11 AM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable

 

Actually, I must disagree …

 

If organizations having unused resources, they need to transfer them or return 
them to the RIR. If prices keep going high, that could encourage faster IPv6 
adoption, then transfer prices will go down, up to “no value”. It takes time, 
but it is just market.

 

Those that have more money, have more facilities to do a faster transition and 
not bother about IPv4.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 16:05, "Mike Burns"  escribió:

 

Hello,

 

Per Gaurav’s statement that “only those with millions of dollars can think of 
getting ips”, this community should oppose this policy.

 

Because the only way small companies can afford to get ips today is by leasing 
them.  The same way the small company can’t afford to purchase a big office 
building but instead rents an office. Leasing is the only way to finance IPv4 
acquisitions today. No bank or other entity that I am aware of will do it. 
Purchasing addresses requires full upfront payment, but leasing allow for much 
smaller monthly payments.

 

If this community wants to ensure only the largest and richest companies can 
acquire new addresses, ban leasing.

 

But if the community tries to ban something with such a large business 
motivation behind it, it will find itself struggling against a powerful foe.

 

And for what purpose do we punish the small businesses?  Leasing puts addresses 
in the hands of those who need them to build and operate networks. Isn’t that 
the primary goal of the RIR system?  

 

Regards,

Mike

 

 

El 2/9/22, 9:23, "Gaurav Kansal"  escribió:

 

Hello everyone,

 

In my opinion, even Trading of IPs (leave apart the lease for making dollars) 
in the name of transfers must be stopped.

If organisation doesn’t need IPs , then those must be returned back so that 
smaller organisations can get it from the RIR.

 

Currently, only the one which have millions of dollars can think of getting 
IPs. In today’s scenario, no one can start the Data Centre, ISP business 
without investing millions in IPs. Even education and research org doesn’t have 
an option to get IPs from RIR.

 

This is like horse trading and isn’t a good practice for the community as a 
whole.

 

Regards,

Gaurav Kansal

 

 

On 02-Sep-2022, at 12:20, raj...@smartlinkindia.com wrote:

 

Dear Team,

 

As Mr. Satoru, mentioned there are changes, but if carefully implemented in 
phased manner, unauthorised leasing can be stopped.

 

For example in first phase, leasing among countries can be stopped, if the 
owner company doesn't provide any services beyond its home country. For example 
if a company in India doesn't have any operation in Singapore or Japan , can't 
lease resources to those companies in Singapore or Japan. This can be verified 
by taking business registration documents of both lease and lessor. 

Once this is done same may be granularized at RIR level, where in country like 
India, leasing can be restricted to the licensed service area for service 
provider within their designated service area. 

This may stop majority of issues, barring few exceptions. 

Some more brainstorming is required for better understanding and precise 
implementation.

 

Regards,

 

Rajesh Panwala

For Smartlink Solutions Pvt Ltd

+91-9227886001

+91-9426110781

 

On Fri, Sep 2, 2022, 10:44 AM Tsurumaki, Satoru  wrote:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-148,
based on a meeting we organised on 29th Aug to discuss these

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Aftab,

 

It is not a matter of who announces them, but if they are connected to the 
original resource holder, so then the addresses are part of the connectivity 
service.

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 8/9/22, 3:22, "Aftab Siddiqui"  escribió:

 

Hey Jordi,

 

On Wed, 7 Sept 2022 at 23:45, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Looking into English dictionaries and trying to make something specific to our 
case. Maybe:

 

Providing Internet Number Resources for a price (paid in any form) or even for 
free, when not tied to a direct connectivity service. 

 

 

So do you want to reclaim the following resources from their respective 
custodians as it is announced by an unrelated entity?

 

103.93.157.0/24* and 103.114.130.0/24*
apnic|AU|ipv4|103.93.156.0|512|20170523|allocated|A91A0031
apnic|AU|ipv4|103.114.130.0|512|20180427|assigned|A91A0031
apnic|AU|asn|149847|1|20220526|allocated|A91A0031
apnic|AU|asn|136594|1|20170523|allocated|A91A0031

N*> 103.93.157.0/24  169.254.169.25450  0 64515 65534 20473 
32787 i
N*> 103.114.130.0/24 169.254.169.25450  0 64515 65534 20473 
32787 i


103.81.228.0/24 *
apnic|SG|ipv4|103.81.228.0|256|20161219|assigned|A91E3136

N*> 103.81.228.0/24  169.254.169.25450  0 64515 65534 20473 
13335 i

1.1.1.0/24 and 1.0.0.0/24 *
apnic|AU|ipv4|1.1.1.0|256|20110811|assigned|A91872ED
apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A91872ED
apnic|AU|asn|9838|1|20100203|allocated|A91872ED
apnic|AU|asn|24021|1|20080326|allocated|A91872ED
apnic|JP|asn|38610|1|20070716|allocated|A91872ED
apnic|AU|asn|131072|1|20070117|allocated|A91872ED
apnic|AU|asn|131074|1|20070115|allocated|A91872ED

V*  1.1.1.0/24   103.126.52.155 0 141384 4826 13335 
i

 

*APNIC delegate file

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 15:35, "Mike Burns"  escribió:

 

Hello,

 

If we don't have a definition of Leasing we can't fully consider the issues of 
enforcement, among other items.

 

As with many things the devil is in the details.

 

Regards,

 

Mike

 

 

 

 

 

 

Sent from my T-Mobile 4G LTE Device

 

 

 Original message ----

From: JORDI PALET MARTINEZ via sig-policy  

Date: 9/7/22 8:54 AM (GMT-05:00) 

To: sig-policy  

Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Brett,

 

I’m not saying that I reject a definition, what I’m saying is that I don’t 
think is needed, despite that I’m happy to include it if we agree on that, as 
can’t be other way, as this is the way we write proposals: understanding what 
the community want (not just the authors).

 

I’ve not been able to see the video of the discussion. Is it available? Maybe 
the staff can provide it, so I can better understand all the points?

 

Could you suggest a wording of leasing according to you view, to see if we can 
make it happen?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 14:41, "Brett O'Hara"  escribió:

 

Hi Jordi,

 

You have stated that you do need a definition because "any form of leasing is 
unacceptable", and yet I was verbally assured at the APNIC 54 Policy Proposals 
Webinar on the 25th of August, that several examples of leasing were 
acceptable, but not documented in the proposal.  My request for a definition in 
the proposal was positively received by the SIG and we left the issue to the 
authors.  If the response from the authors is that the definition is not 
necessary, I can't see how we can endorse the proposal.

 

Regards,

    Brett

 

On Wed, Sep 7, 2022 at 8:30 PM JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Satoru, all,

We haven't defined leasing, because it is common English term, not something 
specific to "addresses".  I can understand that in other languages, it may not 
be the same, but because the policies are bound to the English language, we 
didn't feel the need to define it.

In fact, we had a similar discussion about that in LACNIC 6 months ago, and we 
decided to make a new version, which is the same as we published in APNIC. The 
point was to stress that "any form of leasing" is unacceptable. If you read 
that in the context of the policy, it starts, as you already mention "own 
infrastructure or directly connected customers". So, anything beyond that will 
be a form of leasing (never mind if you pay a fee for the addresses or they are 
free of charge, or you pay before you use them or afterwards, etc., basically 
"anything not linked to connectivity").

I don't think the implementation is a problem. We know that many proposals come 
with some challenges, however, the community, anyone, can and should help on 
that. Anyone knowing or getting a leasing offer should communicate about that. 
And by the way, I think will not be so dificult to create an automated way of

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

tain policies which don't seem to 
have receptivity in discussions on all other RIRs. 

There are still mechanisms that allow companies to get IP addressing either 
directly from the RIR, via Transfers which is a pretty common way or from the 
Upstream providers. People may not have got used yet to learn to live with less 
address and they may believe they need a bunch of address.

IP Leasing will never help small companies. The ones who really benefit from it 
are the IP broker companies who profit from them and also the resource holders 
which don't justify anymore to keep those addresses and are also profiting from 
something that should have been re-assigned directly to those who really need 
and justify for them in order to build Internet Infrastructure and Connectivity 
and instead are leasing a asset they don't own.

Fernando

On 07/09/2022 12:39, Mike Burns wrote:

Hi Fernando,

 

So your argument is that banning leasing actually helps smaller companies in 
their quest for IPv4?

 

Are you aware that RIPE has allowed leasing for many years but is still a 
functioning RIR whose IPv4 sale prices are not more expensive despite the 
history of leasing there?

 

Can you reconcile that with your argument that leasing will raise prices for 
both leasing and transfers?

 

Are you aware that it’s not always possible to get IPv4 blocks from the company 
that is providing you with connectivity?

 

Regards,
Mike

 

 

 

From: Fernando Frediani  
Sent: Wednesday, September 7, 2022 11:27 AM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable

 

This is exactly the opposite.

Allowing IP leasing to happen more than just tottaly divert the propose of IP 
assignments by RIRs it make it bad specially for smaller companies as it 
increases the cost for both leasing and transfers in long term. The cost of 
leasing is based on the transfer and if leasing is allowed then transfer prices 
will  always go up which makes it even harder for smaller companies to go into 
the market.

Any form of IP leasing without a direct connection relationship to provide a 
connectivity service makes it more expensive for smaller companies to get IP 
addresses to operate.

Fernando

On 07/09/2022 11:15, Mike Burns wrote:

Hi Jordi,

 

It’s plain you feel that we should do all possible to raise the price of IPv4 
and make it unattainable for small business in the vain hope that this will 
drive IPv6 adoption.

 

I don’t think making IPv4 more difficult to acquire is the job of the RIR 
system.

 

You have not addressed the inability of smaller companies to acquire necessary 
IPv4 blocks if you ban leasing.

Is that something you are comfortable with, in pursuit of the IPv6 grail?

It’s okay with you that this policy prevents small companies from growing?

 

Regards,
Mike

 

 

From: JORDI PALET MARTINEZ via sig-policy  
Sent: Wednesday, September 7, 2022 10:11 AM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable

 

Actually, I must disagree …

 

If organizations having unused resources, they need to transfer them or return 
them to the RIR. If prices keep going high, that could encourage faster IPv6 
adoption, then transfer prices will go down, up to “no value”. It takes time, 
but it is just market.

 

Those that have more money, have more facilities to do a faster transition and 
not bother about IPv4.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 16:05, "Mike Burns"  escribió:

 

Hello,

 

Per Gaurav’s statement that “only those with millions of dollars can think of 
getting ips”, this community should oppose this policy.

 

Because the only way small companies can afford to get ips today is by leasing 
them.  The same way the small company can’t afford to purchase a big office 
building but instead rents an office. Leasing is the only way to finance IPv4 
acquisitions today. No bank or other entity that I am aware of will do it. 
Purchasing addresses requires full upfront payment, but leasing allow for much 
smaller monthly payments.

 

If this community wants to ensure only the largest and richest companies can 
acquire new addresses, ban leasing.

 

But if the community tries to ban something with such a large business 
motivation behind it, it will find itself struggling against a powerful foe.

 

And for what purpose do we punish the small businesses?  Leasing puts addresses 
in the hands of those who need them to build and operate networks. Isn’t that 
the primary goal of the RIR system?  

 

Regards,

Mike

 

 

El 2/9/22, 9:23, "Gaurav Kansal"  escribió:

 

Hello everyone,

 

In my opinion, even Trading of IPs (leave apart the lease for making dollars) 
in the name of transfers must be stopped.

If organisation doesn’t need IPs , then those must be returned back so that 
smaller organisations can get it fr

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Andrew,

 

I will say otherwise. As it has been clearly stated by the secretariat that 
leasing is not allowed, and some people believe it should be allowed, the 
proposal just clarify it.

 

If we, as a community believe leasing should be allowed, then, a proposal to 
change that *in the current policy manual* is needed. Otherwise, this proposal 
is precisely helping to ensure that the current policy text is well understood.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 22:00, "Andrew Yager"  escribió:

 

Wow. This response shows the absurdity of this proposal in the scheme of the 
internet community today and also the issues attached to the poor definitive 
and understanding of terms.

 

This proposal is bad policy, poorly worded and should not be accepted.

 

We thoroughly oppose its adoption in its current form.

 

The existing provisions are more than ample, and this proposal does nothing to 
improve the internet community.

 

In practice, the proposal has still not actually justified it’s need for 
existence and why it should exist.

 

Both Jordi and Fernando have stated multiple times their intention is to see 
unused space returned to the registrar.

 

If that is the intention of this, then make a new proposal to justify that. But 
where will that stop? Will you require operators to issue contiguous 
allocations? Will you require space consolidation? Will you redefine the many 
ways that providers interconnect across exchanges, over long haul services? 
Will you decide that connectivity will be via a physical cable, removing VXCs? 
There is a very narrow view presented here and it is clear that there is an end 
goal in mind from this policy - but this is not the mechanism to achieve it.



Again, the existing member agreement provisions are already sufficient and this 
policy adds no value. If the intention is a different outcome (return of unused 
resources to RIR) make a proposal to do that.



Andrew 

 

Get Outlook for iOS

From: Fernando Frediani 
Sent: Thursday, September 8, 2022 1:27 am
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hello Andrew

GRE tunnel is not a form of direct connectivity. In order to use a GRE tunnel 
it is already necessary to have a direct connectivity with a Internet Service 
Provider and Upstream who provide internet services.

Can you justify why you are against it if you recognize this is already 
prohibited under the membership agreement ? If something is already forbidden 
so what is the login of not willing to have in clear in the policy text in 
order to avoid any possible doubts ?

Again, this proposal is not changing the current status, so even without it the 
current status can already be circumvented and even if that happens eventually 
it does not invalidate the need to have something clear in the text to make it 
easier for members to understand and avoid that as also to help the RIR to 
stand for these points should a dispute gets to the courts.

Fernando

 

On 07/09/2022 07:48, Andrew Yager wrote:

I mean… to be devils advocate… a gre tunnel is pretty cheap to set up.

 

This type of policy is easily circumvented, and in my opinion unenforceable.

 

Additionally, this activity is already prohibited under the membership 
agreement and I still don’t see any value in adding this.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 8:30:23 PM
To: sig-policy 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Satoru, all,

We haven't defined leasing, because it is common English term, not something 
specific to "addresses".  I can understand that in other languages, it may not 
be the same, but because the policies are bound to the English language, we 
didn't feel the need to define it.

In fact, we had a similar discussion about that in LACNIC 6 months ago, and we 
decided to make a new version, which is the same as we published in APNIC. The 
point was to stress that "any form of leasing" is unacceptable. If you read 
that in the context of the policy, it starts, as you already mention "own 
infrastructure or directly connected customers". So, anything beyond that will 
be a form of leasing (never mind if you pay a fee for the addresses or they are 
free of charge, or you pay before you use them or afterwards, etc., basically 
"anything not linked to connectivity").

I don't think the implementation is a problem. We know that many proposals come 
with some challenges, however, the community, anyone, can and should help on 
that. Anyone knowing or getting a leasing offer should communicate about that. 
And by the way, I think will not be so dificult to create an automated way of 
detecting it, just by ensuring that the users of any APNIC block is directly 
con

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

No, I’m not thinking that anyone should increase the price. I consider that the 
right thing to do is that if anyone that has unused recourses, should be honest 
enough with the community to return them to the RIR, unfortunately the world is 
not so nice.

 

Smaller ISPs are the ones that have an easier and cheaper transition to IPv6 is 
they start doing so now, as latest, more expensive. We have seen this already 
since long time ago. It is their decision. Not doing the transition is already 
meaning they are risking their own business.

 

Leasing is against the actual policy. We don’t change that. If you really think 
it should be changed, the way is not working against this proposal, but making 
one that change the actual status quo.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 16:15, "Mike Burns"  escribió:

 

Hi Jordi,

 

It’s plain you feel that we should do all possible to raise the price of IPv4 
and make it unattainable for small business in the vain hope that this will 
drive IPv6 adoption.

 

I don’t think making IPv4 more difficult to acquire is the job of the RIR 
system.

 

You have not addressed the inability of smaller companies to acquire necessary 
IPv4 blocks if you ban leasing.

Is that something you are comfortable with, in pursuit of the IPv6 grail?

It’s okay with you that this policy prevents small companies from growing?

 

Regards,
Mike

 

 

From: JORDI PALET MARTINEZ via sig-policy  
Sent: Wednesday, September 7, 2022 10:11 AM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable

 

Actually, I must disagree …

 

If organizations having unused resources, they need to transfer them or return 
them to the RIR. If prices keep going high, that could encourage faster IPv6 
adoption, then transfer prices will go down, up to “no value”. It takes time, 
but it is just market.

 

Those that have more money, have more facilities to do a faster transition and 
not bother about IPv4.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 16:05, "Mike Burns"  escribió:

 

Hello,

 

Per Gaurav’s statement that “only those with millions of dollars can think of 
getting ips”, this community should oppose this policy.

 

Because the only way small companies can afford to get ips today is by leasing 
them.  The same way the small company can’t afford to purchase a big office 
building but instead rents an office. Leasing is the only way to finance IPv4 
acquisitions today. No bank or other entity that I am aware of will do it. 
Purchasing addresses requires full upfront payment, but leasing allow for much 
smaller monthly payments.

 

If this community wants to ensure only the largest and richest companies can 
acquire new addresses, ban leasing.

 

But if the community tries to ban something with such a large business 
motivation behind it, it will find itself struggling against a powerful foe.

 

And for what purpose do we punish the small businesses?  Leasing puts addresses 
in the hands of those who need them to build and operate networks. Isn’t that 
the primary goal of the RIR system?  

 

Regards,

Mike

 

 

El 2/9/22, 9:23, "Gaurav Kansal"  escribió:

 

Hello everyone,

 

In my opinion, even Trading of IPs (leave apart the lease for making dollars) 
in the name of transfers must be stopped.

If organisation doesn’t need IPs , then those must be returned back so that 
smaller organisations can get it from the RIR.

 

Currently, only the one which have millions of dollars can think of getting 
IPs. In today’s scenario, no one can start the Data Centre, ISP business 
without investing millions in IPs. Even education and research org doesn’t have 
an option to get IPs from RIR.

 

This is like horse trading and isn’t a good practice for the community as a 
whole.

 

Regards,

Gaurav Kansal

 

 

On 02-Sep-2022, at 12:20, raj...@smartlinkindia.com wrote:

 

Dear Team,

 

As Mr. Satoru, mentioned there are changes, but if carefully implemented in 
phased manner, unauthorised leasing can be stopped.

 

For example in first phase, leasing among countries can be stopped, if the 
owner company doesn't provide any services beyond its home country. For example 
if a company in India doesn't have any operation in Singapore or Japan , can't 
lease resources to those companies in Singapore or Japan. This can be verified 
by taking business registration documents of both lease and lessor. 

Once this is done same may be granularized at RIR level, where in country like 
India, leasing can be restricted to the licensed service area for service 
provider within their designated service area. 

This may stop majority of issues, barring few exceptions. 

Some more brainstorming is required for better understanding and precise 
implementation.

 

Regards,

 

Rajesh Panwala

For Smartlink Solutions Pvt Ltd

+91-9227886001

+91-9426110781

 

On Fri, Sep 2, 20

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

IG Chairs
>
>
> --
> prop-148-v002: Clarification - Leasing of Resources is not Acceptable
> --
>
> Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
>Amrita Choudhury (amritachoudh...@ccaoi.in)
>Fernando Frediani (fhfred...@gmail.com)
>
>
> 1. Problem statement
> 
> RIRs have been conceived to manage, allocate and assign resources
> according to need, in such a way that a LIR/ISP has addresses to be able
> to directly connect its customers based on justified need. Addresses are
> not, therefore, a property with which to trade or do business.
>
> When the justification of the need disappears or changes, for whatever
> reasons, the expected thing would be to return said addresses to the
> RIR, otherwise according to Section 4.1. (“The original basis of the
> delegation remains valid”) and 4.1.2. (“Made for a specific purpose that
> no longer exists, or based on information that is later found to be
> false or incomplete”) of the policy manual, APNIC is not enforced to
> renew the license. An alternative is to transfer these resources using
> the appropriate transfer policy.
>
> If the leasing of addresses is authorized, contrary to the original
> spirit of the policies and the very existence of the RIRs, the link
> between connectivity and addresses disappears, which also poses security
> problems, since, in the absence of connectivity, the resource holder who
> has received the license to use the addresses does not have immediate
> physical control to manage/filter them, which can cause damage to the
> entire community.
>
> Therefore, it should be made explicit in the Policies that the Internet
> Resources should not be leased “per se”, but only as part of a direct
> connectivity service.
>
> The existing policies of APNIC are not explicit about that, however
> current policies do not regard the leasing of addresses as acceptable,
> if they are not an integral part of a connectivity service.
> Specifically, the justification of the need would not be valid for those
> blocks of addresses whose purpose is not to directly connect customers
> of an LIR/ISP, and consequently the renewal of the annual license for
> the use of the addresses would not be valid either. Sections 3.2.6.
> (Address ownership), 3.2.7. (Address stockpiling) and 3.2.8.
> (Reservations not supported) of the policy manual, are keys on this
> issue, but an explicit clarification is required.
>
>
> 2. Objective of policy change
> -
> Despite the fact that the intention in this regard underlies the entire
> Policy Manual text and is thus applied to justify the need for
> resources, this proposal makes this aspect explicit by adding the
> appropriate clarifying text.
>
>
> 3. Situation in other regions
> -
> In other RIRs, the leasing of addresses is not authorized either and
> since it is not explicit in their policy manuals either, this proposal
> will be presented as well.
>
> Nothing is currently mentioned in RIPE about this and it is not
> acceptable as a justification of the need. In AFRINIC and LACNIC, the
> staff has confirmed that address leasing is not considered as valid for
> the justification. In ARIN it is not considered valid as justification
> of need.
>
> A similar proposal is under discussion in LACNIC and ARIN.
>
>
> 4. Proposed policy solution
> ---
> 5.8. Leasing of Internet Number Resources
>
> In the case of Internet number resources delegated by APNIC or an NIR,
> the justification of the need implies the need to use on their own
> infrastructure and/or network connectivity services provided directly to
> customers. As a result, any form of IP address leasing is unacceptable,
> nor does it justify the need, if it is not part of a set of services
> based, at the very least, on direct connectivity. Even for networks that
> are not connected to the Internet, leasing of IP addresses is not
> permitted, because such sites can request direct assignments from APNIC
> or the relevant NIR and, in the case of IPv4, use private addresses or
> arrange market transfers.
>
> APNIC may proactively investigate those cases and also initiate the
> investigation in case of reports by means of a form, email address or
> other means developed by APNIC.
>
> If any form of leasing, regardless of when the delegation has been
> issued, is confirmed by an APNIC investigation, it will be considered a
> policy violation and revocation may apply against any account holders
> who

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Looking into English dictionaries and trying to make something specific to our 
case. Maybe:

 

Providing Internet Number Resources for a price (paid in any form) or even for 
free, when not tied to a direct connectivity service. 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 15:35, "Mike Burns"  escribió:

 

Hello,

 

If we don't have a definition of Leasing we can't fully consider the issues of 
enforcement, among other items.

 

As with many things the devil is in the details.

 

Regards,

 

Mike

 

 

 

 

 

 

Sent from my T-Mobile 4G LTE Device

 

 

 Original message ----

From: JORDI PALET MARTINEZ via sig-policy  

Date: 9/7/22 8:54 AM (GMT-05:00) 

To: sig-policy  

Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Brett,

 

I’m not saying that I reject a definition, what I’m saying is that I don’t 
think is needed, despite that I’m happy to include it if we agree on that, as 
can’t be other way, as this is the way we write proposals: understanding what 
the community want (not just the authors).

 

I’ve not been able to see the video of the discussion. Is it available? Maybe 
the staff can provide it, so I can better understand all the points?

 

Could you suggest a wording of leasing according to you view, to see if we can 
make it happen?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 14:41, "Brett O'Hara"  escribió:

 

Hi Jordi,

 

You have stated that you do need a definition because "any form of leasing is 
unacceptable", and yet I was verbally assured at the APNIC 54 Policy Proposals 
Webinar on the 25th of August, that several examples of leasing were 
acceptable, but not documented in the proposal.  My request for a definition in 
the proposal was positively received by the SIG and we left the issue to the 
authors.  If the response from the authors is that the definition is not 
necessary, I can't see how we can endorse the proposal.

 

Regards,

Brett

 

On Wed, Sep 7, 2022 at 8:30 PM JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Satoru, all,

We haven't defined leasing, because it is common English term, not something 
specific to "addresses".  I can understand that in other languages, it may not 
be the same, but because the policies are bound to the English language, we 
didn't feel the need to define it.

In fact, we had a similar discussion about that in LACNIC 6 months ago, and we 
decided to make a new version, which is the same as we published in APNIC. The 
point was to stress that "any form of leasing" is unacceptable. If you read 
that in the context of the policy, it starts, as you already mention "own 
infrastructure or directly connected customers". So, anything beyond that will 
be a form of leasing (never mind if you pay a fee for the addresses or they are 
free of charge, or you pay before you use them or afterwards, etc., basically 
"anything not linked to connectivity").

I don't think the implementation is a problem. We know that many proposals come 
with some challenges, however, the community, anyone, can and should help on 
that. Anyone knowing or getting a leasing offer should communicate about that. 
And by the way, I think will not be so dificult to create an automated way of 
detecting it, just by ensuring that the users of any APNIC block is directly 
connected to the AS of the resource holder.

Regards,
Jordi
@jordipalet



El 2/9/22, 7:15, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-148,
based on a meeting we organised on 29th Aug to discuss these proposals.

Many participants support the intent of the proposal but felt that
implementation would be challenging.

(comment details)
- It is undisputed that the current policy allows for the distribution
  of IP addresses according to the actual demand of one's own
  organization or directly connected customers, and does not allow for
  the leasing of IP addresses.
- I think this proposal would be useful if the concept of leasing is
　 accurately defined.
- Leasing IP addresses that damage the accuracy of whois information
  should not be allowed, but I find it difficult to implement.


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2022年8月26日(金) 17:27 Shaila Sharmin :
>
> Dear SIG members,
>
> A new version of the proposal "prop-148-v002: Clarification - Leasing of
> Resources is not Acceptable" has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-148
>
> You are encouraged to express your views on the proposal:
>

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Brett,

 

I’m not saying that I reject a definition, what I’m saying is that I don’t 
think is needed, despite that I’m happy to include it if we agree on that, as 
can’t be other way, as this is the way we write proposals: understanding what 
the community want (not just the authors).

 

I’ve not been able to see the video of the discussion. Is it available? Maybe 
the staff can provide it, so I can better understand all the points?

 

Could you suggest a wording of leasing according to you view, to see if we can 
make it happen?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 14:41, "Brett O'Hara"  escribió:

 

Hi Jordi,

 

You have stated that you do need a definition because "any form of leasing is 
unacceptable", and yet I was verbally assured at the APNIC 54 Policy Proposals 
Webinar on the 25th of August, that several examples of leasing were 
acceptable, but not documented in the proposal.  My request for a definition in 
the proposal was positively received by the SIG and we left the issue to the 
authors.  If the response from the authors is that the definition is not 
necessary, I can't see how we can endorse the proposal.

 

Regards,

Brett

 

On Wed, Sep 7, 2022 at 8:30 PM JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Satoru, all,

We haven't defined leasing, because it is common English term, not something 
specific to "addresses".  I can understand that in other languages, it may not 
be the same, but because the policies are bound to the English language, we 
didn't feel the need to define it.

In fact, we had a similar discussion about that in LACNIC 6 months ago, and we 
decided to make a new version, which is the same as we published in APNIC. The 
point was to stress that "any form of leasing" is unacceptable. If you read 
that in the context of the policy, it starts, as you already mention "own 
infrastructure or directly connected customers". So, anything beyond that will 
be a form of leasing (never mind if you pay a fee for the addresses or they are 
free of charge, or you pay before you use them or afterwards, etc., basically 
"anything not linked to connectivity").

I don't think the implementation is a problem. We know that many proposals come 
with some challenges, however, the community, anyone, can and should help on 
that. Anyone knowing or getting a leasing offer should communicate about that. 
And by the way, I think will not be so dificult to create an automated way of 
detecting it, just by ensuring that the users of any APNIC block is directly 
connected to the AS of the resource holder.

Regards,
Jordi
@jordipalet



El 2/9/22, 7:15, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-148,
based on a meeting we organised on 29th Aug to discuss these proposals.

Many participants support the intent of the proposal but felt that
implementation would be challenging.

(comment details)
- It is undisputed that the current policy allows for the distribution
  of IP addresses according to the actual demand of one's own
  organization or directly connected customers, and does not allow for
  the leasing of IP addresses.
- I think this proposal would be useful if the concept of leasing is
　 accurately defined.
- Leasing IP addresses that damage the accuracy of whois information
  should not be allowed, but I find it difficult to implement.


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2022年8月26日(金) 17:27 Shaila Sharmin :
>
> Dear SIG members,
>
> A new version of the proposal "prop-148-v002: Clarification - Leasing of
> Resources is not Acceptable" has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-148
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Regards,
> Bertrand, Shaila, and Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
> prop-148-v002: Clarification - Leasing of Resources is not Acceptable
> --
>
> Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
>Amrita Choudhury (amritachoudh...@ccaoi.in)
>Fernando Frediani (fhfred...@gmail.com)
&g

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Aftab,

 

No, didn’t, however I don’t need to do that in order to understand that the 
same as in other regions, the text in APNIC is not sufficiently clear and we 
should improve it, regardless of what amount of leasing is happening.

 

If you have the data, would be nice if you can share it, but I don’t think that 
will change our view that the policy text should be clear.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 12:53, "Aftab Siddiqui"  escribió:

 

Hi Jordi,

 

Have you done any analysis to check how big a problem it is in the APNIC 
service region? for example check all (or may be a subset of) the allocations 
and assignments by the APNIC along with their allocated ASN(s) and see if those 
resources are originating from these ASN(s). 


Regards,

Aftab A. Siddiqui

 

 

On Wed, 7 Sept 2022 at 20:37, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Yes, I definitively agree with that: The most honorable thing will be to return 
resources that you don’t use for your directly connected customers.

 

However, not allowing that when the community accepted it long time ago, would 
have been a failure, because many organizations just look for their own 
interest instead of the global community one.

 

In the case of leasing is already not covered by policies, we just want to make 
sure that it is sufficiently clear.

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/9/22, 9:23, "Gaurav Kansal"  escribió:

 

Hello everyone,

 

In my opinion, even Trading of IPs (leave apart the lease for making dollars) 
in the name of transfers must be stopped.

If organisation doesn’t need IPs , then those must be returned back so that 
smaller organisations can get it from the RIR.

 

Currently, only the one which have millions of dollars can think of getting 
IPs. In today’s scenario, no one can start the Data Centre, ISP business 
without investing millions in IPs. Even education and research org doesn’t have 
an option to get IPs from RIR.

 

This is like horse trading and isn’t a good practice for the community as a 
whole.

 

Regards,

Gaurav Kansal

 

 

On 02-Sep-2022, at 12:20, raj...@smartlinkindia.com wrote:

 

Dear Team,

 

As Mr. Satoru, mentioned there are changes, but if carefully implemented in 
phased manner, unauthorised leasing can be stopped.

 

For example in first phase, leasing among countries can be stopped, if the 
owner company doesn't provide any services beyond its home country. For example 
if a company in India doesn't have any operation in Singapore or Japan , can't 
lease resources to those companies in Singapore or Japan. This can be verified 
by taking business registration documents of both lease and lessor. 

Once this is done same may be granularized at RIR level, where in country like 
India, leasing can be restricted to the licensed service area for service 
provider within their designated service area. 

This may stop majority of issues, barring few exceptions. 

Some more brainstorming is required for better understanding and precise 
implementation.

 

Regards,

 

Rajesh Panwala

For Smartlink Solutions Pvt Ltd

+91-9227886001

+91-9426110781

 

On Fri, Sep 2, 2022, 10:44 AM Tsurumaki, Satoru  wrote:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-148,
based on a meeting we organised on 29th Aug to discuss these proposals.

Many participants support the intent of the proposal but felt that
implementation would be challenging.

(comment details)
- It is undisputed that the current policy allows for the distribution
  of IP addresses according to the actual demand of one's own
  organization or directly connected customers, and does not allow for
  the leasing of IP addresses.
- I think this proposal would be useful if the concept of leasing is
　 accurately defined.
- Leasing IP addresses that damage the accuracy of whois information
  should not be allowed, but I find it difficult to implement.


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2022年8月26日(金) 17:27 Shaila Sharmin :
>
> Dear SIG members,
>
> A new version of the proposal "prop-148-v002: Clarification - Leasing of
> Resources is not Acceptable" has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-148
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Regards,
> Bertrand, Shaila, and Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
> prop-148-v002: Clarification - Leasing of Resource

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Yes, but also having an email warning APNIC about a leasing quote received by 
anyone is also easy.

 

Many aspects in policies are easy to circumvent, but this doesn’t preclude that 
we do the right thing and policies are clear to avoid missinterpretations.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 12:48, "Andrew Yager"  escribió:

 

I mean… to be devils advocate… a gre tunnel is pretty cheap to set up.

 

This type of policy is easily circumvented, and in my opinion unenforceable.

 

Additionally, this activity is already prohibited under the membership 
agreement and I still don’t see any value in adding this.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 8:30:23 PM
To: sig-policy 
Subject: [sig-policy] Re: New version - prop-148: Clarification - Leasing of 
Resources is not Acceptable 

 

Hi Satoru, all,

We haven't defined leasing, because it is common English term, not something 
specific to "addresses".  I can understand that in other languages, it may not 
be the same, but because the policies are bound to the English language, we 
didn't feel the need to define it.

In fact, we had a similar discussion about that in LACNIC 6 months ago, and we 
decided to make a new version, which is the same as we published in APNIC. The 
point was to stress that "any form of leasing" is unacceptable. If you read 
that in the context of the policy, it starts, as you already mention "own 
infrastructure or directly connected customers". So, anything beyond that will 
be a form of leasing (never mind if you pay a fee for the addresses or they are 
free of charge, or you pay before you use them or afterwards, etc., basically 
"anything not linked to connectivity").

I don't think the implementation is a problem. We know that many proposals come 
with some challenges, however, the community, anyone, can and should help on 
that. Anyone knowing or getting a leasing offer should communicate about that. 
And by the way, I think will not be so dificult to create an automated way of 
detecting it, just by ensuring that the users of any APNIC block is directly 
connected to the AS of the resource holder.
 
Regards,
Jordi
@jordipalet
 
 

El 2/9/22, 7:15, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-148,
based on a meeting we organised on 29th Aug to discuss these proposals.

Many participants support the intent of the proposal but felt that
implementation would be challenging.

(comment details)
- It is undisputed that the current policy allows for the distribution
  of IP addresses according to the actual demand of one's own
  organization or directly connected customers, and does not allow for
  the leasing of IP addresses.
- I think this proposal would be useful if the concept of leasing is
　 accurately defined.
- Leasing IP addresses that damage the accuracy of whois information
  should not be allowed, but I find it difficult to implement.


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2022年8月26日(金) 17:27 Shaila Sharmin :
>
> Dear SIG members,
>
> A new version of the proposal "prop-148-v002: Clarification - Leasing of
> Resources is not Acceptable" has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-148
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Regards,
> Bertrand, Shaila, and Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
> prop-148-v002: Clarification - Leasing of Resources is not Acceptable
> --
>
> Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
>Amrita Choudhury (amritachoudh...@ccaoi.in)
>Fernando Frediani (fhfred...@gmail.com)
>
>
> 1. Problem statement
> 
> RIRs have been conceived to manage, allocate and assign resources
> according to need, in such a way that a LIR/ISP has addresses to be able
> to directly connect its customers based on justified need. Addresses are
> not, therefore, a property with which to trade or do business.

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Yes, I definitively agree with that: The most honorable thing will be to return 
resources that you don’t use for your directly connected customers.

 

However, not allowing that when the community accepted it long time ago, would 
have been a failure, because many organizations just look for their own 
interest instead of the global community one.

 

In the case of leasing is already not covered by policies, we just want to make 
sure that it is sufficiently clear.

 

Regards,

Jordi

@jordipalet

 

 

 

El 2/9/22, 9:23, "Gaurav Kansal"  escribió:

 

Hello everyone,

 

In my opinion, even Trading of IPs (leave apart the lease for making dollars) 
in the name of transfers must be stopped.

If organisation doesn’t need IPs , then those must be returned back so that 
smaller organisations can get it from the RIR.

 

Currently, only the one which have millions of dollars can think of getting 
IPs. In today’s scenario, no one can start the Data Centre, ISP business 
without investing millions in IPs. Even education and research org doesn’t have 
an option to get IPs from RIR.

 

This is like horse trading and isn’t a good practice for the community as a 
whole.

 

Regards,

Gaurav Kansal

 



On 02-Sep-2022, at 12:20, raj...@smartlinkindia.com wrote:

 

Dear Team,

 

As Mr. Satoru, mentioned there are changes, but if carefully implemented in 
phased manner, unauthorised leasing can be stopped.

 

For example in first phase, leasing among countries can be stopped, if the 
owner company doesn't provide any services beyond its home country. For example 
if a company in India doesn't have any operation in Singapore or Japan , can't 
lease resources to those companies in Singapore or Japan. This can be verified 
by taking business registration documents of both lease and lessor. 

Once this is done same may be granularized at RIR level, where in country like 
India, leasing can be restricted to the licensed service area for service 
provider within their designated service area. 

This may stop majority of issues, barring few exceptions. 

Some more brainstorming is required for better understanding and precise 
implementation.

 

Regards,

 

Rajesh Panwala

For Smartlink Solutions Pvt Ltd

+91-9227886001

+91-9426110781

 

On Fri, Sep 2, 2022, 10:44 AM Tsurumaki, Satoru  wrote:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-148,
based on a meeting we organised on 29th Aug to discuss these proposals.

Many participants support the intent of the proposal but felt that
implementation would be challenging.

(comment details)
- It is undisputed that the current policy allows for the distribution
  of IP addresses according to the actual demand of one's own
  organization or directly connected customers, and does not allow for
  the leasing of IP addresses.
- I think this proposal would be useful if the concept of leasing is
　 accurately defined.
- Leasing IP addresses that damage the accuracy of whois information
  should not be allowed, but I find it difficult to implement.


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2022年8月26日(金) 17:27 Shaila Sharmin :
>
> Dear SIG members,
>
> A new version of the proposal "prop-148-v002: Clarification - Leasing of
> Resources is not Acceptable" has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-148
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Regards,
> Bertrand, Shaila, and Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
> prop-148-v002: Clarification - Leasing of Resources is not Acceptable
> ------
>
> Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
>Amrita Choudhury (amritachoudh...@ccaoi.in)
>Fernando Frediani (fhfred...@gmail.com)
>
>
> 1. Problem statement
> 
> RIRs have been conceived to manage, allocate and assign resources
> according to need, in such a way that a LIR/ISP has addresses to be able
> to directly connect its customers based on justified need. Addresses are
> not, therefore, a property with which to trade or do business.
>
> When the justification of the need disappears or changes, for whatever
> reasons, the expected thing would be to return said addresses to the
> RIR, otherwise according to Section 4.1. (“The original basis of the
> delegation rema

[sig-policy] Re: New version - prop-148: Clarification - Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Satoru, all,

We haven't defined leasing, because it is common English term, not something 
specific to "addresses".  I can understand that in other languages, it may not 
be the same, but because the policies are bound to the English language, we 
didn't feel the need to define it.

In fact, we had a similar discussion about that in LACNIC 6 months ago, and we 
decided to make a new version, which is the same as we published in APNIC. The 
point was to stress that "any form of leasing" is unacceptable. If you read 
that in the context of the policy, it starts, as you already mention "own 
infrastructure or directly connected customers". So, anything beyond that will 
be a form of leasing (never mind if you pay a fee for the addresses or they are 
free of charge, or you pay before you use them or afterwards, etc., basically 
"anything not linked to connectivity").

I don't think the implementation is a problem. We know that many proposals come 
with some challenges, however, the community, anyone, can and should help on 
that. Anyone knowing or getting a leasing offer should communicate about that. 
And by the way, I think will not be so dificult to create an automated way of 
detecting it, just by ensuring that the users of any APNIC block is directly 
connected to the AS of the resource holder.
 
Regards,
Jordi
@jordipalet
 
 

El 2/9/22, 7:15, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-148,
based on a meeting we organised on 29th Aug to discuss these proposals.

Many participants support the intent of the proposal but felt that
implementation would be challenging.

(comment details)
- It is undisputed that the current policy allows for the distribution
  of IP addresses according to the actual demand of one's own
  organization or directly connected customers, and does not allow for
  the leasing of IP addresses.
- I think this proposal would be useful if the concept of leasing is
　 accurately defined.
- Leasing IP addresses that damage the accuracy of whois information
  should not be allowed, but I find it difficult to implement.


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2022年8月26日(金) 17:27 Shaila Sharmin :
>
> Dear SIG members,
>
> A new version of the proposal "prop-148-v002: Clarification - Leasing of
> Resources is not Acceptable" has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-148
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Regards,
> Bertrand, Shaila, and Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
> prop-148-v002: Clarification - Leasing of Resources is not Acceptable
> --
>
> Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
>Amrita Choudhury (amritachoudh...@ccaoi.in)
>Fernando Frediani (fhfred...@gmail.com)
>
>
> 1. Problem statement
> 
> RIRs have been conceived to manage, allocate and assign resources
> according to need, in such a way that a LIR/ISP has addresses to be able
> to directly connect its customers based on justified need. Addresses are
> not, therefore, a property with which to trade or do business.
>
> When the justification of the need disappears or changes, for whatever
> reasons, the expected thing would be to return said addresses to the
> RIR, otherwise according to Section 4.1. (“The original basis of the
> delegation remains valid”) and 4.1.2. (“Made for a specific purpose that
> no longer exists, or based on information that is later found to be
> false or incomplete”) of the policy manual, APNIC is not enforced to
> renew the license. An alternative is to transfer these resources using
> the appropriate transfer policy.
>
> If the leasing of addresses is authorized, contrary to the original
> spirit of the policies and the very existence of the RIRs, the link
> between connectivity and addresses disappears, which also poses security
> problems, since, in the absence

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Considering that the EC decision is going to affect the resources on January 
1st, I think waiting so long as you suggest 3-5 years, is not very sensible. 
Waste of resources, why even waste time for the staff to contact holders 
anymore?

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 11:43, "Andrew Yager"  escribió:

 

The problem remains that regardless of what the decisions of the EC are, these 
resources are still by and large present in the global routing table.

 

A decision to reclaim and reissue is impractical, and also impacts the 
stability of the internet.

 

While the EC made a decision that lists these resources in AS0; it would be far 
more problematic to assume that by users of these resources are in fact 
available to reissue at this time, and I remain unconvinced that 12 months is 
the right timeframe. Perhaps we will be in a better position to evaluate this 
in 12 months time and then set a timeframe.

 

If this policy is to go be approved (which I still don’t agree with) I would at 
it at 36-60 months is more practical.

 

Andrew



Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 7:02:10 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management 

 

I fail to understand why taking already the decision of what to do, like in 
option 2, should be delayed, if we already agree that 12 months is a good 
timing.

 

The PDP allows us to amend the policy text if we need to extend this timing or 
do something else, but I always believe that acting now is better than late, 
and having a strict deadline for not just January 1st, but also one year later, 
will help to enforce the custodians to react, and ensure that APNIC also 
request more resrouces (if needed) to finalize the job.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 10:51, "Andrew Yager"  escribió:

 

Hi,

 

For now, so believe that option 1 you indicated is better. I think we may be in 
a better place to decide option 2 is better in 12 months.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 6:43:22 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management 

 

Hi Aftab,

 

Would you agree extending the 12 months into 18 months?

 

Or maybe an alternative text to the proposal offering a different solution, may 
be 2 different stages in the process, I don’t know, just thinking loud.

 

The point here is:

1.   We do nothing: all those resources are in reserved state (no 
services), instead of some of them being able to be reused by members/newcomers.

2.   We act now: Slowly, some resources will be back to the community in 
the next 12 months, or original custodians will become “visible”.

 

I really think option 2 is better. I fail to understand why you don’t think so. 
If the problem is the timing let’s talk about a longer period instead of 12 
months. Or let’s consider other alternatives. We know that the community will 
not discuss this anymore for the next 6 months, until the next meeting is 
closer. Why we don’t try to fix it now?

 

I can’t believe that we get stuck into option 1, enforced by the EC.

 

To be honest, I disagree with the EC decision on this. It would have been much 
better to have a community decision *before* an enforced EC decision. I 
actually summited a proposal about that whay ahead the EC decision, but the 
chairs decided not to accept it. I think the chairs erred with that. The 
community is on top of the EC decisions and knowing that the EC was already 
working on that, was not an excuse for anyone to avoid the community acting.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/8/22, 6:31, "Aftab Siddiqui"  escribió:

 

Hi Jordi,

I absolutely concur with Brett and Andrew, they have already mentioned the 
reasoning very clearly. I don't support this policy right now and maybe we can 
review the status in 12 months and have another constructive discussion. 

 

Also, it would be a right time to have a clear policy from APNIC to clarify 
what and when any (available + reserved) resource goes into AS0 TAL.


Regards,

Aftab A. Siddiqui

 

 

On Sat, 27 Aug 2022 at 14:21, Brett O'Hara  wrote:

Hi Jordi and SIG

The implication of your proposal, by 5.1.4, is that by putting them in Reserved 
status, APNIC will assign them RPKI ROA AS0 and deny them routing on the 
Internet.  You will then allow them 12 months grace after you have denied their 
operation to officially claim them.  Your update from 6 to 12 months has not 
allowed APNIC any more time to contact custodians.

 

I agree with Andrew that the current impact is too large and too damaging to 
internet end point users in your proposed time frame.

 

I believe APNIC members should asess the progress of the HRM project in 12 
months time and consider your propos

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

I fail to understand why taking already the decision of what to do, like in 
option 2, should be delayed, if we already agree that 12 months is a good 
timing.

 

The PDP allows us to amend the policy text if we need to extend this timing or 
do something else, but I always believe that acting now is better than late, 
and having a strict deadline for not just January 1st, but also one year later, 
will help to enforce the custodians to react, and ensure that APNIC also 
request more resrouces (if needed) to finalize the job.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/9/22, 10:51, "Andrew Yager"  escribió:

 

Hi,

 

For now, so believe that option 1 you indicated is better. I think we may be in 
a better place to decide option 2 is better in 12 months.

 

Andrew

 

Get Outlook for iOS

From: JORDI PALET MARTINEZ via sig-policy 
Sent: Wednesday, September 7, 2022 6:43:22 PM
To: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management 

 

Hi Aftab,

 

Would you agree extending the 12 months into 18 months?

 

Or maybe an alternative text to the proposal offering a different solution, may 
be 2 different stages in the process, I don’t know, just thinking loud.

 

The point here is:

1.   We do nothing: all those resources are in reserved state (no 
services), instead of some of them being able to be reused by members/newcomers.

2.   We act now: Slowly, some resources will be back to the community in 
the next 12 months, or original custodians will become “visible”.

 

I really think option 2 is better. I fail to understand why you don’t think so. 
If the problem is the timing let’s talk about a longer period instead of 12 
months. Or let’s consider other alternatives. We know that the community will 
not discuss this anymore for the next 6 months, until the next meeting is 
closer. Why we don’t try to fix it now?

 

I can’t believe that we get stuck into option 1, enforced by the EC.

 

To be honest, I disagree with the EC decision on this. It would have been much 
better to have a community decision *before* an enforced EC decision. I 
actually summited a proposal about that whay ahead the EC decision, but the 
chairs decided not to accept it. I think the chairs erred with that. The 
community is on top of the EC decisions and knowing that the EC was already 
working on that, was not an excuse for anyone to avoid the community acting.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/8/22, 6:31, "Aftab Siddiqui"  escribió:

 

Hi Jordi,

I absolutely concur with Brett and Andrew, they have already mentioned the 
reasoning very clearly. I don't support this policy right now and maybe we can 
review the status in 12 months and have another constructive discussion. 

 

Also, it would be a right time to have a clear policy from APNIC to clarify 
what and when any (available + reserved) resource goes into AS0 TAL.


Regards,

Aftab A. Siddiqui

 

 

On Sat, 27 Aug 2022 at 14:21, Brett O'Hara  wrote:

Hi Jordi and SIG

The implication of your proposal, by 5.1.4, is that by putting them in Reserved 
status, APNIC will assign them RPKI ROA AS0 and deny them routing on the 
Internet.  You will then allow them 12 months grace after you have denied their 
operation to officially claim them.  Your update from 6 to 12 months has not 
allowed APNIC any more time to contact custodians.

 

I agree with Andrew that the current impact is too large and too damaging to 
internet end point users in your proposed time frame.

 

I believe APNIC members should asess the progress of the HRM project in 12 
months time and consider your proposal then, rather than mandating in a policy 
final date in this cycle, despite your afore mentioned risks.

 

Regards,

Brett

 

On Fri, Aug 26, 2022 at 10:19 PM JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Andrew, all,

 

I see it otherwise.

 

We are providing APNIC one year to resolve the remaining cases. If we don’t 
have this policy on January 1st 2023, all those addresses will be “frozen” into 
reserved status.

 

Please note this:

 

“The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.”

 

Failing to reach consensus on this proposal (suggestions to improve it, of 
course, are welcome, as we can publish new versions in the next few days), 
means that we can’t change the situation up to a new alternative proposal reach 
consensus, which could happen around March 2023, or may be September 2023. Till 
then those resources are “lost” in the wild.

 

Resources in the wild could be more easily hijacked or used for all kind of 
malicious activities. Do you think the com

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Satoru,

Tks for your inputs. It will be good if you can comment on the emails that I 
just responded.

Key question is if we don't believe that 12 months is sufficient, would you 
agree with 18-months, or do you suggest any additional improvements to the 
proposal?
 
Regards,
Jordi
@jordipalet
 
 

El 2/9/22, 7:13, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-145,
based on a meeting we organised on 29th Aug to discuss these proposals.

Many support opinions were expressed about this proposal.

And in response to a comment that HRM activities in Japan might be
helpful, JPNIC staff reported on their activities in Japan.
 - Start Dec.2014
 - Contact resource holders by any means possible, email, phone, mail,
   referral from an acquaintance, etc.
 - Finish 19th Mar 2019 with the signing of the contract with all
   resource Holders.

(comment details)
 - There are many unresponses to contacts from APNIC, which may have
 　a significant impact when it comes to consensus.
 - It would be better to explain HRM's past activities for new members
   for more understanding.
 - I support this proposal, but it will be necessary to response carefully
   to the resource holders


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2022年8月11日(木) 16:00 chku :
>
> Dear SIG members,
>
> The proposal "prop-147: Historical Resources Management" has been
> sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting (OPM) at APNIC 54 on
> Thursday, 15 September 2022.
>
> https://conference.apnic.net/54/program/schedule/#/day/8
>
> 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-147
>
> Regards,
> Bertrand, Shaila, and Ching-Heng
> APNIC Policy SIG Chairs
>
>
>
> ---
>
> prop-147-v001: Historical Resources Management
>
> 
>
> Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
>   Anupam Agrawal (anupamagrawal...@gmail.com)
>
>
> 1. Problem statement
> 
> Section 4.2.1 is outdated and only looking for very old non-routed 
resources.
>
> The recent EC resolution (22nd February 2022), imply that historical 
resource holders in the APNIC region would need to become Members or 
Non-Members by 1st January 2023 in order to receive registration services. 
Failing this, historical resource registration will no longer be published in 
the APNIC Whois Database and said resources will be placed into reserved status.
>
> Given the continued need for IPv4 addresses, it would seem illogical to 
keep these unused historical resources in reserve indefinitely. Alternatively, 
these resources can be used in a way that is sufficiently justified in 
accordance with existing policies, allowing other organizations to benefit from 
them during the IPv6 transition.
>
>
> 2. Objective of policy change
> -
> Ensure that historical IPv4 resources are justified and claimed, or that 
they are available for other organizations that require them.
>
> If the resources are marked as reserved, the original holders may reclaim 
them with a valid justification, when APNIC failed to contact them for whatever 
reason.
>
> One example of a valid justification is the case where an organization is 
actually using them internally and there are valid reasons to instead use 
RFC1918 space, however the space is not routed.
>
> To give the original resource holders more time to reclaim them, we 
propose two time-frames for the community discussion and consideration: 6 
months and 12 

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Question for the staff on this. Is the AS0 proposal not sufficient to comply 
with Aftab observation, or it is just something in the backlog of pending 
secretariat activities, or what is the reason for that?

 

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 30/8/22, 3:48, "Aftab Siddiqui"  escribió:

 

Hi Vivek,

 

On Mon, 29 Aug 2022 at 18:15, Vivek Nigam  wrote:

Hi Aftab,

 

APNIC creates RPKI ROAs with origin AS0 for all undelegated address space 
(marked as “Available” and “Reserved” in the delegated-apnic-extended-latest 
stats file. It may be worth noting that APNIC publishes these AS0 ROAs in a 
different Trust Anchor (AS0 TAL) and recommends its Members use APNIC AS0 TAL 
as a routing information service only.

 

https://www.apnic.net/community/security/resource-certification/apnic-limitations-of-liability-for-rpki-2/

 

 

That is incorrect, there are more than 160 IPv4 prefixes (I haven't checked v6 
yet) which are marked as either "reserved" or "available" in the APNIC 
delegation file and they don't exist in AS-0 ROA. So there must be some policy 
which is in place. 

 

delegate file: 2.3|apnic|20220830|158240||20220829|+1000

AS0 ROA: SigningTime:2022-08-30T01:10:15Z


Regards,

Aftab A. Siddiqui

 

 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Brett,

 

Somehow, I actually responded to your last point before reading it in my 
previous email.

 

I think is really bad that the EC takes decisions that belong to the community, 
unless the community is being called for considering a proposal. I don’t think 
it happened, and actually instead, when I submitted a proposal, it was 
rejected. The EC, the chairs and the community should learn a lesson from this.

 

And yes, the EC decision is binding for the staff, unless we make a policy 
proposal to disallow the EC decision(s) or even change the bylaws. Too late 
anyway for this meeting.

 

And to be clear, I’ve not talked to the EC about this proposal, neither the one 
I submmited about a year ago. I was already considering this as a result of the 
staff presentation on several issues with policies.

 

Regards,

Jordi

@jordipalet

 

 

 

El 29/8/22, 13:17, "Brett O'Hara"  escribió:

 

Thanks for your clarification Vivek.

 

Text of the Resolution is as follows;

 

Resolution 2021-09: The EC resolved that all historical resource holders will 
need to become, or remain, a Member or Non-member of APNIC on and from [1 
January 2023], in order to continue to receive registry services from APNIC.

 

Interpretation from the secretariat via Vivek is that this implies all 
unclaimed historical records will be placed in reserved status, regardless of 
being advertised or not, and subject to ROA AS0 under 5.1.4 on the 1st of 
January 2023.

 

I see prop-147 is an interpretation of EC resolution 2021-09 and attempts to 
clarify this within the Policy.

 

My first question is procedural and governance related.  Can or should the 
secretariat implement the EC resolution without the Policy being updated?

 

If the EC could be considered an effective co-sponsor of this proposal, my 
previous comments now have a broader audience.

 

Does the EC still believe the date they set on EC Resolution 2021-09 is still 
reasonable given the progress of the HRM process and the current impact to the 
potential 193k+ ((175 in progress + 581 no response)* 256 minimum size) active 
Internet endpoints and how does the Policy SIG address the EC for their 
response on this consideration?

 

Regards,

   Brett

 

On Mon, Aug 29, 2022 at 6:15 PM Vivek Nigam  wrote:

Hi Aftab,

 

APNIC creates RPKI ROAs with origin AS0 for all undelegated address space 
(marked as “Available” and “Reserved” in the delegated-apnic-extended-latest 
stats file. It may be worth noting that APNIC publishes these AS0 ROAs in a 
different Trust Anchor (AS0 TAL) and recommends its Members use APNIC AS0 TAL 
as a routing information service only.

 

https://www.apnic.net/community/security/resource-certification/apnic-limitations-of-liability-for-rpki-2/

 

Hi Jordi,

 

> If I understood correctly the implications of the EC decision, *if* tis 
> policy proposal doesn’t go thru they will become reserved anyway.

>  

> Could the staff confirm that?

 

Yes, as per the EC resolution 2021-09, all historical resource holders will 
need to become, or remain, a member or non-member of APNIC on and from 1 
January 2023, in order to continue to receive registry services from APNIC. Any 
historical resources that are not managed under an APNIC account from 1 January 
2023 will be removed from whois and placed into “Reserved” status.  

 

Our understanding is that your proposal is to address the actions that need to 
be taken 12 months after these resources have been placed into reserved status.

 

Thanks

Vivek

 

From: Aftab Siddiqui 
Date: Saturday, 27 August 2022 at 2:30 pm
To: JORDI PALET MARTINEZ 
Cc: sig-policy@lists.apnic.net , Brett O'Hara 

Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management

Hi Jordi,

I absolutely concur with Brett and Andrew, they have already mentioned the 
reasoning very clearly. I don't support this policy right now and maybe we can 
review the status in 12 months and have another constructive discussion. 

 

Also, it would be a right time to have a clear policy from APNIC to clarify 
what and when any (available + reserved) resource goes into AS0 TAL.


Regards,

Aftab A. Siddiqui

 

 

On Sat, 27 Aug 2022 at 14:21, Brett O'Hara  wrote:

Hi Jordi and SIG

The implication of your proposal, by 5.1.4, is that by putting them in Reserved 
status, APNIC will assign them RPKI ROA AS0 and deny them routing on the 
Internet.  You will then allow them 12 months grace after you have denied their 
operation to officially claim them.  Your update from 6 to 12 months has not 
allowed APNIC any more time to contact custodians.

 

I agree with Andrew that the current impact is too large and too damaging to 
internet end point users in your proposed time frame.

 

I believe APNIC members should asess the progress of the HRM project in 12 
months time and consider your proposal then, rather than mandating in a policy 
final date in this cycle, despite your afore mentioned risks.

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Aftab,

 

Would you agree extending the 12 months into 18 months?

 

Or maybe an alternative text to the proposal offering a different solution, may 
be 2 different stages in the process, I don’t know, just thinking loud.

 

The point here is:
We do nothing: all those resources are in reserved state (no services), instead 
of some of them being able to be reused by members/newcomers.
We act now: Slowly, some resources will be back to the community in the next 12 
months, or original custodians will become “visible”.
 

I really think option 2 is better. I fail to understand why you don’t think so. 
If the problem is the timing let’s talk about a longer period instead of 12 
months. Or let’s consider other alternatives. We know that the community will 
not discuss this anymore for the next 6 months, until the next meeting is 
closer. Why we don’t try to fix it now?

 

I can’t believe that we get stuck into option 1, enforced by the EC.

 

To be honest, I disagree with the EC decision on this. It would have been much 
better to have a community decision *before* an enforced EC decision. I 
actually summited a proposal about that whay ahead the EC decision, but the 
chairs decided not to accept it. I think the chairs erred with that. The 
community is on top of the EC decisions and knowing that the EC was already 
working on that, was not an excuse for anyone to avoid the community acting.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/8/22, 6:31, "Aftab Siddiqui"  escribió:

 

Hi Jordi,

I absolutely concur with Brett and Andrew, they have already mentioned the 
reasoning very clearly. I don't support this policy right now and maybe we can 
review the status in 12 months and have another constructive discussion. 

 

Also, it would be a right time to have a clear policy from APNIC to clarify 
what and when any (available + reserved) resource goes into AS0 TAL.


Regards,

Aftab A. Siddiqui

 

 

On Sat, 27 Aug 2022 at 14:21, Brett O'Hara  wrote:

Hi Jordi and SIG

The implication of your proposal, by 5.1.4, is that by putting them in Reserved 
status, APNIC will assign them RPKI ROA AS0 and deny them routing on the 
Internet.  You will then allow them 12 months grace after you have denied their 
operation to officially claim them.  Your update from 6 to 12 months has not 
allowed APNIC any more time to contact custodians.

 

I agree with Andrew that the current impact is too large and too damaging to 
internet end point users in your proposed time frame.

 

I believe APNIC members should asess the progress of the HRM project in 12 
months time and consider your proposal then, rather than mandating in a policy 
final date in this cycle, despite your afore mentioned risks.

 

Regards,

Brett

 

On Fri, Aug 26, 2022 at 10:19 PM JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Andrew, all,

 

I see it otherwise.

 

We are providing APNIC one year to resolve the remaining cases. If we don’t 
have this policy on January 1st 2023, all those addresses will be “frozen” into 
reserved status.

 

Please note this:

 

“The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.”

 

Failing to reach consensus on this proposal (suggestions to improve it, of 
course, are welcome, as we can publish new versions in the next few days), 
means that we can’t change the situation up to a new alternative proposal reach 
consensus, which could happen around March 2023, or may be September 2023. Till 
then those resources are “lost” in the wild.

 

Resources in the wild could be more easily hijacked or used for all kind of 
malicious activities. Do you think the community should accept that risk?

 

In the impact analysis of the first version, APNIC indicated that 6 months may 
be too short, and 12 months will be safer, so we opted for keeping the 12 
months option only. Do you have any data that suggest that APNIC will be unable 
to complete the project in the next year?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 26/8/22, 2:56, "Andrew Yager"  escribió:

 

Hi,

 

Thanks for this data vivek.

 

On the basis of this I cannot suggest this proposal can be accepted - the 
impact is too large.

 

Certainly we, as a community, and APNIC as a whole, need to look at what can be 
done to assist these prefixes coming "into the fold" - but with 581 still with 
no response, and 175 "not yet done" - the risk of this proposal having adverse 
consequences on the routing table is too great.

 

Andrew

 

 

On Fri, 26 Aug 2022 at 17:45, Vivek Nigam  wrote:

Hi Andrew,

 

Please see my responses below.

 

> a) the number of legacy resources currently in

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Tim,

The difference is that they have RPKI and whois support. Not after January 1st.

I fully agree that the important point is to continue the IPv6 deployment, but 
having those resources back into APNIC pool, will help some members or 
newcomers to use some of those addresses for an ordered transition. Even for 
IPv6-ony + IPv4aaS you need *some* IPv4 pools. More and more organizations 
(enterprises), will come on board with direct APNIC assignments due to IPv6, 
and the best way to do that, technically speaking, is having also a small IPv4 
subnet.

 
 
Regards,
Jordi
@jordipalet
 
 

El 27/8/22, 2:25, "Tim Warnock"  escribió:

I'd like evidence to support "Resources in the wild could be more easily 
hijacked or used for all kind of malicious activities.", after all - these 
prefixes have already existed for a significant time already.

I also concur that we should leave these to reserved if unclaimed and 
instead of continuing to keep expending effort on IPv4 that we focus on IPv6 
deployments.

-Original Message-----
    From: JORDI PALET MARTINEZ via sig-policy  
Sent: Friday, 26 August 2022 10:19 PM
To: sig-policy@lists.apnic.net
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management

Hi Andrew, all,



I see it otherwise.



We are providing APNIC one year to resolve the remaining cases. If we don’t 
have this policy on January 1st 2023, all those addresses will be “frozen” into 
reserved status.



Please note this:



“The recent EC resolution (22nd February 2022), imply that historical 
resource holders in the APNIC region would need to become Members or 
Non-Members by 1st January 2023 in order to receive registration services. 
Failing this, historical resource registration will no longer be published in 
the APNIC Whois Database and said resources will be placed into reserved 
status.”



Failing to reach consensus on this proposal (suggestions to improve it, of 
course, are welcome, as we can publish new versions in the next few days), 
means that we can’t change the situation up to a new alternative proposal reach 
consensus, which could happen around March 2023, or may be September 2023. Till 
then those resources are “lost” in the wild.



Resources in the wild could be more easily hijacked or used for all kind of 
malicious activities. Do you think the community should accept that risk?



In the impact analysis of the first version, APNIC indicated that 6 months 
may be too short, and 12 months will be safer, so we opted for keeping the 12 
months option only. Do you have any data that suggest that APNIC will be unable 
to complete the project in the next year?





Regards,

Jordi

@jordipalet







El 26/8/22, 2:56, "Andrew Yager" mailto:and...@rwts.com.au> > escribió:



Hi,



Thanks for this data vivek.



On the basis of this I cannot suggest this proposal can be accepted - the 
impact is too large.



Certainly we, as a community, and APNIC as a whole, need to look at what 
can be done to assist these prefixes coming "into the fold" - but with 581 
still with no response, and 175 "not yet done" - the risk of this proposal 
having adverse consequences on the routing table is too great.



Andrew





On Fri, 26 Aug 2022 at 17:45, Vivek Nigam mailto:vi...@apnic.net> > wrote:

Hi Andrew,



Please see my responses below.



> a) the number of legacy resources currently in use (as in, visible in 
the global table), but not yet claimed through this process



We started this project in February this year and identified 3932 
historical IPv4 prefixes that were not managed under an APNIC account. 885 of 
these prefixes are currently visible in the routing table. Following if the 
breakdown of these 885 prefixes.



Retained by custodian: 81

These prefixes have successfully been claimed and are managed under 
active APNIC accounts now.



Being claimed by custodian: 175

We are in contact with the potential custodians and they are in the 
process of claiming these prefixes. 



No response: 581

We have sent emails to the custodians but have not got a response as 
yet. We are in the process to find alternate contacts by contacting the ASN 
announcing these prefixes. 



Yet to contact: 44

No valid contact information available in whois. We are in the process 
to look for alternate contacts via publicly available searches as well as 
contacting the ASN announcing these prefixes.



No longer needed: 4

The custodians have informed us they no longer need these prefixes. We 
are in the process to contact the ASN announcing these prefixes to check why 
they are announcing them.



> b) the number of legacy resource claims that have been attempted but 
not successfully justifi

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Andrew,

 

The EC decision is clear. If there is no policy, they will frozen on January 
1st. There is no possible secretariat discretion to change that or do anything 
different.

 

Those resources will be placed in reserved status, no RPKI, no whois, no 
services, etc. For me this is worst in terms of chances to be misused, 
hijacked, etc, than today’s situation.

 

This proposal allows that deadline to be extended further 12 months.

 

I don’t agree that they exist in the routing table. Some may be there, some 
not. That's the reason why some of them can’t be contacted.

 

If you (the community) believe that the time frame of 12 months is short, I’ve 
no problem to increase it to 18 months, but something needs to be done.

 

Regards,

Jordi

@jordipalet

 

 

 

El 26/8/22, 15:11, "Andrew Yager"  escribió:

 

Hi Jordi,

 

On Fri, 26 Aug 2022 at 22:19, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Andrew, all,

 

I see it otherwise.

 

We are providing APNIC one year to resolve the remaining cases. If we don’t 
have this policy on January 1st 2023, all those addresses will be “frozen” into 
reserved status. 

 

Please note this:

 

“The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.”

 

In February 2022, APNIC made a decision that to RPKI validation and 
registration services would only be provided to resource holders who were 
members of APNIC, and that all historical resources would be required to be 
registered with APNIC. This is a sensible decision.

 

They gave 12 months for this process to happen. The evidence would suggest that 
in that period of time, APNIC has not successfully achieved the goal of 
bringing these resources into membership status. There may be any number of 
reasons for this, but the statistics indicate that to date, APNIC has only been 
partially successful. With 4 months to go, it would appear that to date this 
process is not likely to yield a high degree of success at present given the 
high number of prefixes present in the internet table that have not yet made 
contact with APNIC.

 

This policy proposal binds APNIC to taking a particular course of action when 
the 12 months are up. Without this policy, it would appear to me that there is 
no specific statement by APNIC on what will or will not happen to these 
resources. From what I can see, it will be up to the Secretariat's discretion 
to work out what to do; and in lack of specific policies APNIC has historically 
leaned towards a functional internet.

 

Failing to reach consensus on this proposal (suggestions to improve it, of 
course, are welcome, as we can publish new versions in the next few days), 
means that we can’t change the situation up to a new alternative proposal reach 
consensus, which could happen around March 2023, or may be September 2023. Till 
then those resources are “lost” in the wild.

 

It could be argued that effectively they are now.

 

But, they exist in the global routing table. Someone is originating them.

 

Absolutely, it's worth having a discussion about what should happen with these 
resources. But, the current proposal is not a good option, and I do not see a 
path to modify this proposal in such a way that addresses what should be very 
real concerns for all internet operators.

 

The only upside that I can see from this policy is that the resources can 
ultimately be reclaimed and reallocated to members as part of the reclaimed 
IPv4 space policies. But even then, until the prefixes are no longer 
originated, this is not viable.

 

 Resources in the wild could be more easily hijacked or used for all kind of 
malicious activities. Do you think the community should accept that risk?

 

As a MANRS member, and an organisation who implements ROA and RPKI, I 
wholeheartedly agree that as much of the internet should implement RPKI and ROA 
as is possible, and resources should be signed.

 

But, this policy is not tto require all resources to be signed, this policy is 
to force APNIC to take a certain level of action that will cause these prefixes 
to become unreachable on the internet for many providers, which seems to fly in 
the face of providing a stable internet policy.

 

 

In the impact analysis of the first version, APNIC indicated that 6 months may 
be too short, and 12 months will be safer, so we opted for keeping the 12 
months option only. Do you have any data that suggest that APNIC will be unable 
to complete the project in the next year?

 

 

I think the statistics speak for themselves.

 

It would be interesting to know, of the 81 who have successfully been brought 
across, how many organisations are r

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

If I understood correctly the implications of the EC decision, *if* tis policy 
proposal doesn’t go thru they will become reserved anyway.

 

Could the staff confirm that?

 

Instead, with the proposal, there will be additional 12 months, to react before 
that.

 

Regards,

Jordi

@jordipalet

 

 

 

El 26/8/22, 7:59, "Brett O'Hara"  escribió:

 

Hi Jordi and SIG

The implication of your proposal, by 5.1.4, is that by putting them in Reserved 
status, APNIC will assign them RPKI ROA AS0 and deny them routing on the 
Internet.  You will then allow them 12 months grace after you have denied their 
operation to officially claim them.  Your update from 6 to 12 months has not 
allowed APNIC any more time to contact custodians.

 

I agree with Andrew that the current impact is too large and too damaging to 
internet end point users in your proposed time frame.

 

I believe APNIC members should asess the progress of the HRM project in 12 
months time and consider your proposal then, rather than mandating in a policy 
final date in this cycle, despite your afore mentioned risks.

 

Regards,

Brett

 

On Fri, Aug 26, 2022 at 10:19 PM JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Andrew, all,

 

I see it otherwise.

 

We are providing APNIC one year to resolve the remaining cases. If we don’t 
have this policy on January 1st 2023, all those addresses will be “frozen” into 
reserved status.

 

Please note this:

 

“The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.”

 

Failing to reach consensus on this proposal (suggestions to improve it, of 
course, are welcome, as we can publish new versions in the next few days), 
means that we can’t change the situation up to a new alternative proposal reach 
consensus, which could happen around March 2023, or may be September 2023. Till 
then those resources are “lost” in the wild.

 

Resources in the wild could be more easily hijacked or used for all kind of 
malicious activities. Do you think the community should accept that risk?

 

In the impact analysis of the first version, APNIC indicated that 6 months may 
be too short, and 12 months will be safer, so we opted for keeping the 12 
months option only. Do you have any data that suggest that APNIC will be unable 
to complete the project in the next year?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 26/8/22, 2:56, "Andrew Yager"  escribió:

 

Hi,

 

Thanks for this data vivek.

 

On the basis of this I cannot suggest this proposal can be accepted - the 
impact is too large.

 

Certainly we, as a community, and APNIC as a whole, need to look at what can be 
done to assist these prefixes coming "into the fold" - but with 581 still with 
no response, and 175 "not yet done" - the risk of this proposal having adverse 
consequences on the routing table is too great.

 

Andrew

 

 

On Fri, 26 Aug 2022 at 17:45, Vivek Nigam  wrote:

Hi Andrew,

 

Please see my responses below.

 

> a) the number of legacy resources currently in use (as in, visible in the 
> global table), but not yet claimed through this process

 

We started this project in February this year and identified 3932 historical 
IPv4 prefixes that were not managed under an APNIC account. 885 of these 
prefixes are currently visible in the routing table. Following if the breakdown 
of these 885 prefixes.

 

Retained by custodian: 81

These prefixes have successfully been claimed and are managed under active 
APNIC accounts now.

 

Being claimed by custodian: 175

We are in contact with the potential custodians and they are in the process of 
claiming these prefixes. 

 

No response: 581

We have sent emails to the custodians but have not got a response as yet. We 
are in the process to find alternate contacts by contacting the ASN announcing 
these prefixes. 

 

Yet to contact: 44

No valid contact information available in whois. We are in the process to look 
for alternate contacts via publicly available searches as well as contacting 
the ASN announcing these prefixes.

 

No longer needed: 4

The custodians have informed us they no longer need these prefixes. We are in 
the process to contact the ASN announcing these prefixes to check why they are 
announcing them.

 

> b) the number of legacy resource claims that have been attempted but not 
> successfully justified

 

So far we have not formally rejected any claims. Where a claimant does not 
provide sufficient information to support their claim, we do not reject the 
claim but rather advise them we will need more information in order to properly 
assess it. We have 3 pending cases where we have 

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Andrew, all,

 

I see it otherwise.

 

We are providing APNIC one year to resolve the remaining cases. If we don’t 
have this policy on January 1st 2023, all those addresses will be “frozen” into 
reserved status.

 

Please note this:

 

“The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.”

 

Failing to reach consensus on this proposal (suggestions to improve it, of 
course, are welcome, as we can publish new versions in the next few days), 
means that we can’t change the situation up to a new alternative proposal reach 
consensus, which could happen around March 2023, or may be September 2023. Till 
then those resources are “lost” in the wild.

 

Resources in the wild could be more easily hijacked or used for all kind of 
malicious activities. Do you think the community should accept that risk?

 

In the impact analysis of the first version, APNIC indicated that 6 months may 
be too short, and 12 months will be safer, so we opted for keeping the 12 
months option only. Do you have any data that suggest that APNIC will be unable 
to complete the project in the next year?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 26/8/22, 2:56, "Andrew Yager"  escribió:

 

Hi,

 

Thanks for this data vivek.

 

On the basis of this I cannot suggest this proposal can be accepted - the 
impact is too large.

 

Certainly we, as a community, and APNIC as a whole, need to look at what can be 
done to assist these prefixes coming "into the fold" - but with 581 still with 
no response, and 175 "not yet done" - the risk of this proposal having adverse 
consequences on the routing table is too great.

 

Andrew

 

 

On Fri, 26 Aug 2022 at 17:45, Vivek Nigam  wrote:

Hi Andrew,

 

Please see my responses below.

 

> a) the number of legacy resources currently in use (as in, visible in the 
> global table), but not yet claimed through this process

 

We started this project in February this year and identified 3932 historical 
IPv4 prefixes that were not managed under an APNIC account. 885 of these 
prefixes are currently visible in the routing table. Following if the breakdown 
of these 885 prefixes.

 

Retained by custodian: 81

These prefixes have successfully been claimed and are managed under active 
APNIC accounts now.

 

Being claimed by custodian: 175

We are in contact with the potential custodians and they are in the process of 
claiming these prefixes. 

 

No response: 581

We have sent emails to the custodians but have not got a response as yet. We 
are in the process to find alternate contacts by contacting the ASN announcing 
these prefixes. 

 

Yet to contact: 44

No valid contact information available in whois. We are in the process to look 
for alternate contacts via publicly available searches as well as contacting 
the ASN announcing these prefixes.

 

No longer needed: 4

The custodians have informed us they no longer need these prefixes. We are in 
the process to contact the ASN announcing these prefixes to check why they are 
announcing them.

 

> b) the number of legacy resource claims that have been attempted but not 
> successfully justified

 

So far we have not formally rejected any claims. Where a claimant does not 
provide sufficient information to support their claim, we do not reject the 
claim but rather advise them we will need more information in order to properly 
assess it. We have 3 pending cases where we have requested additional 
supporting information and one case where the custodian has refused to setup an 
APNIC account. We will continue to assist them with their claims through the 
year.

 

Thanks

Vivek

 

From: Srinivas (Sunny) Chendi 
Date: Wednesday, 24 August 2022 at 6:02 pm
To: Andrew Yager , JORDI PALET MARTINEZ 

Cc: sig-policy@lists.apnic.net 
Subject: [sig-policy] Re: prop-147-v001: Historical Resources Management

Dear Andrew,

Thank you for requesting data.
We will do our best to provide it as soon as possible.

Regards,
Sunny
APNIC Secretariat

On 24/08/2022 4:03 pm, Andrew Yager wrote:

Is there any data indicating:

 

a) the number of legacy resources currently in use (as in, visible in the 
global table), but not yet claimed through this process

b) the number of legacy resource claims that have been attempted but not 
successfully justified

 

I am aware that this has remained a topic of concern for a number of APNIC 
members and technical engineers, and many have been working with APNIC to try 
and resolve resource allocations with various degrees of success.

 

Andrew

 

 

On Wed, 24 Aug 2022 at 09:36, JORDI PALET MARTINEZ via sig-policy 
 wrote:

Hi Sunny, all,

 

Jus

[sig-policy] Re: prop-147-v001: Historical Resources Management

[JORDI PALET MARTINEZ via sig-policy]

Hi Sunny, all,

 

Just summited a new proposal version amending the editorial inputs and also 
adding the following text:

“Furthermore, from 1st January 2023, all historical resources need to be 
maintained in a current APNIC account. In the event of an account closure, the 
historical resource will be placed in a quarantine period and then made 
available for re-delegation similar to current resources.”

 

Also, in order to facilitate the job, I agree that will be safer to move to a 
single option with 12 months, so I’ve deleted the “2 choices” in the new 
version.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/22, 6:51, "Srinivas (Sunny) Chendi"  escribió:

 

Hi all, 

This is the secretariat's impact assessment for prop-147-v001, which is also 
available on the proposal page.

http://www.apnic.net/policy/proposals/prop-147

APNIC understands that this proposal suggests that historical IPv4 resources be 
justified and claimed, or that they be made available to other organizations 
that require them.

APNIC also notes the deletion of Section 4.2.1. Recovery of unused historical 
resources. As reported to the community at APNIC 50, this may no longer be 
applicable once the project is completed, possibly by the end of 2022.

https://conference.apnic.net/50/assets/files/APCS790/Reclaiming-unused-IPv4.pdf

Recommendations:

For consistency of language and to align with the current policy document, the 
reference to "available pool" could be changed to "free pool". Also the 
reference to "original resource holder" and "original custodians" could be 
changed to "custodian/s".

Given the number of uncontactable resource holders, the 12-month option would 
be safer for APNIC to implement, as some historical resource holders may not be 
aware of the changes to the treatment of historical resources until they are 
placed into reserved status on January 1, 2023.

Clarification:

This proposal only addresses historical resources that have not been claimed by 
January 1st, 2023. It does not specify what happens to the historical resources 
that are claimed, but the Member or Non-Member account is not renewed after 
January 1, 2023. These resources will be considered historical and may remain 
in reserve status indefinitely. 

Regards,
Sunny
APNIC Secretariat

On 11/08/2022 4:59 pm, chku wrote:
Dear SIG members,
 
The proposal "prop-147: Historical Resources Management" has been 
sent to the Policy SIG for review.
 
It will be presented at the Open Policy Meeting (OPM) at APNIC 54 on 
Thursday, 15 September 2022.
 
    https://conference.apnic.net/54/program/schedule/#/day/8
 
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-147
 
Regards,
Bertrand, Shaila, and Ching-Heng
APNIC Policy SIG Chairs
 
 
 
---
 
prop-147-v001: Historical Resources Management
 
--------
 
Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
  Anupam Agrawal (anupamagrawal...@gmail.com)
 
 
1. Problem statement

Section 4.2.1 is outdated and only looking for very old non-routed resources.
 
The recent EC resolution (22nd February 2022), imply that historical resource 
holders in the APNIC region would need to become Members or Non-Members by 1st 
January 2023 in order to receive registration services. Failing this, 
historical resource registration will no longer be published in the APNIC Whois 
Database and said resources will be placed into reserved status.
 
Given the continued need for IPv4 addresses, it would seem illogical to keep 
these unused historical resources in reserve indefinitely. Alternatively, these 
resources can be used in a way that is sufficiently justified in accordance 
with existing policies, allowing other organizations to benefit from them 
during the IPv6 transition.
 
 
2. Objective of policy change
-
Ensure that historical IPv4 resources are justified and claimed, or that they 
are available for other organizations that require them.
 
If the resources are marked as reserved, the original holders may reclaim them 
with a valid justification, when APNIC failed to con

[sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Richard,

 

Maybe it passed without noticing that is not a valid justification use.

 

Morally, the correct thing to do is to return unused resources to the RIR. We 
accepted a way in the middle with transfers. So be it. Transfer the resources 
that you don’t use, but don’t lease them.

 

Resources are not meant to make business but to ensure a global, open, stable 
and secure Internet.

 

Again, let’s wait for the secretariat confirmation on this.

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/8/22, 18:07, "Richard Ham"  escribió:

 

 

Leasing addresses has been common practice for my entire career in the ISP/CSP 
world, back when 28.8kbps was normal. Someone with excess would assist a 
smaller entity while they sorted out AUNIC/APNIC applications (and often 
learned the ropes). Leasing, while not limited to smaller organisations, 
benefits those of us who are small ( and do not have caches of resources to 
help us when a single /24 for 24 months would make an enormous difference to 
the viability of our business).

 

On the topic of smaller resource holders, I believe we need to make life easier 
for them, rather than harder - the fee structure is already biased against 
someone who holds a /22 compared to a /16, they have limited staff to follow 
policy, apply for that otherwise leasable /24 etc.

 

In this day and age the idea that an organisation would voluntarily hand back 
IPv4 so it can be reallocated seems to be overly optimistic. It is considered a 
rare and limited supply business asset and a valuable one at that.

 

Punitive punishments as suggested in the proposal are also about as welcome as 
another wave of covid inspired lock-downs and reinforce my belief that not only 
is this proposed policy unsupportable but actually is attempting to do the 
opposite of what we need to do - that is - change the policy to support and 
encourage leasing where needs justify. As historical cases show, leasing is 
useful.

 

I too am against this policy.

 

Kind Regards,

 

Richard

 

-- Original Message --

From: "Mike Burns" 

To: "'JORDI PALET MARTINEZ'" ; "'Srinivas (Sunny) 
Chendi'" ; sig-policy@lists.apnic.net

Sent: 23/08/2022 3:17:12 AM

Subject: [sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

 

There are a number of problems with this policy.

 

First let’s start with Jordi stating the policy is just a clarification of fact.

If so, why is it necessary? Actually it is not a fact as leasing is occurring 
in APNIC and there is nothing in policy preventing it.  So this needs to be 
considered as a change in policy.

 

Second, there are inaccuracies in the verbiage associated with the policy, 
particularly in reference to the status of leasing at other RIRs.  How can you 
make the statement “ In other RIRs, the leasing of addresses is not authorized 
either and since it is not explicit in their policy manuals…”?

 

Are you unilaterally deciding that things which are not mentioned in policy are 
by definition “unauthorized”? I think this is wrong, and it’s better to 
consider things as authorized unless they are forbidden by policy.  However, 
either way there is no language in any RIR regarding leasing and you can’t make 
assumptions based on your own feelings. 

 

You are also wrong in stating that “Nothing is currently mentioned in RIPE 
about this and it is not acceptable as a justification of the need.” In actual 
fact, RIPE will accept leased-out addresses as justification of need in the 
only case where RIPE actually has a needs test, and that is with inter-regional 
transfers sourced in ARIN.  It bears remembering that RIPE simply has no needs 
test for transfers and this has been the policy for many years.  You may wonder 
what the point of a needs-test for transfers is, since the recipients are 
paying for the addresses.

 

ARIN staff has made it known that leasing addresses is not against policy at 
all, but leased-out addresses can’t be used to justify transfers. However a 
policy explicitly allowing leased-out addresses to be used as justification is 
under consideration.

 

Also leases can be used to justify addresses in ARIN if any tiny connectivity 
is created between the lessor and lessee. For example, a small VPN can be 
created, even though it carries no (or nearly no) traffic. If you want to get 
technical, the lessor and the lessee both advertise the block, but the lessor 
advertises a longer and more expensive route than the lessee, who will receive 
all the traffic except for any loose packets that find their way to the lessor, 
who will send them down the tunnel to the lessee.

 

The issue of retention of a needs test should be reconsidered by the APNIC 
community in the face of evidence garnered from the RIPE experiment. RIPE has 
had no needs test and APNIC had also removed the needs-test for transfers but 
only restored it at the behest of ARIN, who at the time was the only s

[sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Sorry the email went thru while I was still preparing it …

 

APNIC confirmed to the authors, that “leasing is not recognized as a valid 
“use” of resources”.

 

Further to that, to receive resources for the purpose of “leasing” them to 
other parties is not recognized under APNIC policies as an acceptable use. 
APNIC resources are delegated based on demonstrated needs. In order to receive 
resources (by allocation from APNIC or through transfer from others), the 
recipient must demonstrate their need for those resources by describing the 
proposed use of the resources in some specific network infrastructure which 
they own or control. Implicitly, the recipient could not receive addresses for 
subsequent reallocation to other purposes, because the actual use of the 
addresses would be unknown and cannot be subjected to the required assessment 
of the need.


APNIC policies also state that if the declared use of allocated resources 
changes fundamentally, then the resources may be subject to reclamation by 
APNIC.

 

Is not that clear enough?

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/8/22, 18:40, "JORDI PALET MARTINEZ"  escribió:

 

Hi Mike,

 

 

 

 

 

 

In at least, LACNIC and AFRINIC, it has been made clear by staff, that leasing 
is not a valid justification for getting resources, *THE SAME as in APNIC*, so 
if you use that as a justification, the request is denied. If you change the 
“usage” after the request is passed, then you’re bypassing the original 
justification, which is also *disallowed*.

 

I will let the secretariat to confirm if leasing is allowed or not, actually 
responding to your points on APNIC policies, even if this policy doesn't reach 
consensus. However, in my opinion the policy manual must be clear enough so 
nobody can interpret that something is not allowed when actually is not.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/8/22, 12:17, "Mike Burns"  escribió:

 

There are a number of problems with this policy.

 

First let’s start with Jordi stating the policy is just a clarification of fact.

If so, why is it necessary? Actually it is not a fact as leasing is occurring 
in APNIC and there is nothing in policy preventing it.  So this needs to be 
considered as a change in policy.

 

Second, there are inaccuracies in the verbiage associated with the policy, 
particularly in reference to the status of leasing at other RIRs.  How can you 
make the statement “ In other RIRs, the leasing of addresses is not authorized 
either and since it is not explicit in their policy manuals…”?

 

Are you unilaterally deciding that things which are not mentioned in policy are 
by definition “unauthorized”? I think this is wrong, and it’s better to 
consider things as authorized unless they are forbidden by policy.  However, 
either way there is no language in any RIR regarding leasing and you can’t make 
assumptions based on your own feelings. 

 

You are also wrong in stating that “Nothing is currently mentioned in RIPE 
about this and it is not acceptable as a justification of the need.” In actual 
fact, RIPE will accept leased-out addresses as justification of need in the 
only case where RIPE actually has a needs test, and that is with inter-regional 
transfers sourced in ARIN.  It bears remembering that RIPE simply has no needs 
test for transfers and this has been the policy for many years.  You may wonder 
what the point of a needs-test for transfers is, since the recipients are 
paying for the addresses.

 

ARIN staff has made it known that leasing addresses is not against policy at 
all, but leased-out addresses can’t be used to justify transfers. However a 
policy explicitly allowing leased-out addresses to be used as justification is 
under consideration.

 

Also leases can be used to justify addresses in ARIN if any tiny connectivity 
is created between the lessor and lessee. For example, a small VPN can be 
created, even though it carries no (or nearly no) traffic. If you want to get 
technical, the lessor and the lessee both advertise the block, but the lessor 
advertises a longer and more expensive route than the lessee, who will receive 
all the traffic except for any loose packets that find their way to the lessor, 
who will send them down the tunnel to the lessee.

 

The issue of retention of a needs test should be reconsidered by the APNIC 
community in the face of evidence garnered from the RIPE experiment. RIPE has 
had no needs test and APNIC had also removed the needs-test for transfers but 
only restored it at the behest of ARIN, who at the time was the only source for 
desperate APNIC members faced with APNIC exhaust.  Now there are other sources 
for inter-regional transfers to APNIC, and APNIC can take the path of RIPE in 
performing needs test only for inbound ARIN transfers so that source would not 
be precluded. So why not return to APNIC’s previous position of removing the 
needs test from transfers?

 

[sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Mike,

 

 

 

 

 

 

In at least, LACNIC and AFRINIC, it has been made clear by staff, that leasing 
is not a valid justification for getting resources, *THE SAME as in APNIC*, so 
if you use that as a justification, the request is denied. If you change the 
“usage” after the request is passed, then you’re bypassing the original 
justification, which is also *disallowed*.

 

I will let the secretariat to confirm if leasing is allowed or not, actually 
responding to your points on APNIC policies, even if this policy doesn't reach 
consensus. However, in my opinion the policy manual must be clear enough so 
nobody can interpret that something is not allowed when actually is not.

 

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/8/22, 12:17, "Mike Burns"  escribió:

 

There are a number of problems with this policy.

 

First let’s start with Jordi stating the policy is just a clarification of fact.

If so, why is it necessary? Actually it is not a fact as leasing is occurring 
in APNIC and there is nothing in policy preventing it.  So this needs to be 
considered as a change in policy.

 

Second, there are inaccuracies in the verbiage associated with the policy, 
particularly in reference to the status of leasing at other RIRs.  How can you 
make the statement “ In other RIRs, the leasing of addresses is not authorized 
either and since it is not explicit in their policy manuals…”?

 

Are you unilaterally deciding that things which are not mentioned in policy are 
by definition “unauthorized”? I think this is wrong, and it’s better to 
consider things as authorized unless they are forbidden by policy.  However, 
either way there is no language in any RIR regarding leasing and you can’t make 
assumptions based on your own feelings. 

 

You are also wrong in stating that “Nothing is currently mentioned in RIPE 
about this and it is not acceptable as a justification of the need.” In actual 
fact, RIPE will accept leased-out addresses as justification of need in the 
only case where RIPE actually has a needs test, and that is with inter-regional 
transfers sourced in ARIN.  It bears remembering that RIPE simply has no needs 
test for transfers and this has been the policy for many years.  You may wonder 
what the point of a needs-test for transfers is, since the recipients are 
paying for the addresses.

 

ARIN staff has made it known that leasing addresses is not against policy at 
all, but leased-out addresses can’t be used to justify transfers. However a 
policy explicitly allowing leased-out addresses to be used as justification is 
under consideration.

 

Also leases can be used to justify addresses in ARIN if any tiny connectivity 
is created between the lessor and lessee. For example, a small VPN can be 
created, even though it carries no (or nearly no) traffic. If you want to get 
technical, the lessor and the lessee both advertise the block, but the lessor 
advertises a longer and more expensive route than the lessee, who will receive 
all the traffic except for any loose packets that find their way to the lessor, 
who will send them down the tunnel to the lessee.

 

The issue of retention of a needs test should be reconsidered by the APNIC 
community in the face of evidence garnered from the RIPE experiment. RIPE has 
had no needs test and APNIC had also removed the needs-test for transfers but 
only restored it at the behest of ARIN, who at the time was the only source for 
desperate APNIC members faced with APNIC exhaust.  Now there are other sources 
for inter-regional transfers to APNIC, and APNIC can take the path of RIPE in 
performing needs test only for inbound ARIN transfers so that source would not 
be precluded. So why not return to APNIC’s previous position of removing the 
needs test from transfers?

 

Leasing is a natural progression of the IPv4 market that provides benefits to 
both lessee and lessor, and that is why it is inevitable and why it exists 
today.  There are those who hold unused addresses but who don’t want to sell 
for some reason. There are those who need IPv4 but who can’t afford to pay for 
it all at once. There are those with a temporary need. Leasing is the answer 
for the smaller organizations that need IPv4. There are no addresses left in 
the free pool, so it’s either buy or lease. No other options.

 

Today APNIC (and ARIN and RIPE) will allow existing address holders to lease 
their blocks to non-connected customers. This is not a policy violation and 
addresses can’t be revoked for reasons of utilization or non-utilization. I 
believe that contra this policy, leasing should be authorized explicitly and 
that leased out addresses in-use on an operational network should logically be 
accepted as justification, because does it really matter whose network they are 
used on? Isn’t the salient point that they are in use?

 

I am against this policy.

 

Regards,
Mike Burns

 

 

 

 

 

 

From: JORDI PALET MARTINEZ via sig-policy  
Se

[sig-policy] Re: prop-148-v001: Leasing of Resources is not Acceptable

[JORDI PALET MARTINEZ via sig-policy]

Hi Sunny, all,

 

In my opinion because the policy is just a clarification of a fact, it doesn’t 
change the situation for non-LIR/ISP account holders. Further to that, direct 
assignments from APNIC can’t be further sub-assigned, so clearly this disallows 
any type of “business” with addresses for those account holders. Do you think 
that’s sufficiently clear or do you think a small text clarification in the 
proposal is needed?

 

Regarding your 2nd point, there is not already a generic contact email to let 
know APNIC if anything is wrong regarding policy compliance? It will be 
surprising that today anyone discovers some breach and can’t report it, so this 
will also apply the same to this proposal. Again, if you believe a text 
clarification is needed, we can make a new version for that.

 

Finally, regarding your 3rd question, in my understanding the policy manual 
apply to *all the resources* unless we state otherwise. So not only those after 
being implemented are subjected to this proposal. And once more, the proposal 
is only a clarification, not changing what is the current reality. Anyway, we 
are happy to state it more clearly if needed.

 

Tks!

 

Regards,

Jordi

@jordipalet

 

 

El 22/8/22, 2:45, "Srinivas (Sunny) Chendi"  escribió:

 

Hi all, 

This is the secretariat's impact assessment for prop-148-v001, which is also 
available on the proposal page.

http://www.apnic.net/policy/proposals/prop-148

APNIC notes that this proposal suggests explicitly stating in the APNIC 
Internet Number Resources policy document that leasing of IP addresses is 
not permitted in the APNIC region.

Clarifications:

Is this proposal restricted to LIRs/ISPs, or does it apply to all APNIC 
account holders?

The proposal does not specify how an APNIC investigation should be initiated. 
Should there be a form to report this, similar to IRT escalation?

Does this proposal apply to all existing allocations or only those delegated 
after the policy is implemented?

Implementation:

This proposal may require changes to the system.

If this proposal reaches consensus, implementation may be completed within 
3 months.

Regards,
Sunny
APNIC Secretariat

On 11/08/2022 5:01 pm, chku wrote:
Dear SIG members,
 
The proposal "prop-148: Leasing of Resources is not Acceptable" has been 
sent to the Policy SIG for review.
 
It will be presented at the Open Policy Meeting (OPM) at APNIC 54 on 
Thursday, 15 September 2022.
 
    https://conference.apnic.net/54/program/schedule/#/day/8
 
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-148
 
Regards,
Bertrand, Shaila, and Ching-Heng
APNIC Policy SIG Chairs
 
---
 
prop-148-v001: Leasing of Resources is not Acceptable
 
----
 
Proposer: Jordi Palet Martinez (jordi.palet@theipv6company.comAnupam)
  Amrita Choudhury (amritachoudh...@ccaoi.in)
  Fernando Frediani (fhfred...@gmail.com)
 
 
1. Problem statement

RIRs have been conceived to manage, allocate and assign resources according to 
need, in such way that a LIR/ISP has addresses to be able to directly connect 
its customers based on justified need. Addresses are not, therefore, a property 
with which to trade or do business.
 
When the justification of the need disappears or changes, for whatever reasons, 
the expected thing would be to return said addresses to the RIR, otherwise 
according to Section 4.1. (“The original basis of the delegation remains 
valid”) and 4.1.2. (“Made for a specific purpose that no longer exists, or 
based on information that is later found to be false or incomplete”) of the 
policy manual, APNIC is not enforced to renew the license. An alternative is to 
transfer these resources using the appropriate transfer policy.
 
If the leasing of addresses is authorized, contrary to the original spirit of 
the policies and the very existence of the RIRs, the link between connectivity 
and addresses disappears, which also poses security problems, since, in the 
absence of connectivity, the resource holder who has received the license to 
use the addresses does not have immediate physical control to manage/filter 
them, which can cause damage to 

[sig-policy] Re: Final Comment Period for prop-142: Unify Transfer Policies Text

[JORDI PALET MARTINEZ via sig-policy]

Hi Koki, all,

Let me clarify it.

The actual policy for IPv4 transfers has this text at the end of 8.0:
"APNIC will maintain a public log of all transfers made under this policy."

The rest of the transfers (actual policy), is silent about that, so even if 
APNIC could also include those transfers into the log, it is not "enforced" to 
do that.

Our proposal is taking *exactly the same* text ("APNIC will maintain a public 
log of all transfers.") but into the new combined section 5, which apply to all 
the transfers.

So, the proposal is NOT enforcing the NIRs to do that publication, they could 
voluntarily, but probably, having a single "centralized" web page with the 
publication of all the transfers is easier to maintain. To be honest, it 
probably depends on if already the NIRs have that web page for actual IPv4 
transfers, maybe you can confirm if that's the case?

Tks!
 
 
Regards,
Jordi
@jordipalet
 
 

El 4/3/22 7:54, "Koki Nakagawa"  escribió:

Thank you Ching-Heng,

I want to confirm about prop-142.
This propsal aquire to publish transfer log about all type of it.
In this change, NIRs also need to publish transfer log  as same as APNIC's 
one isn't it?
(Of course, it depends on the status of each NIR's transfer policy 
implementation.)

If I have a misunderstanding, plz indicate it.

Regards,

Koki Nakagawa/JPNIC

On 2022/03/04 10:34, chku wrote:
> Dear colleagues,
> 
> Version 1 of prop-142: Unify Transfer Policies Text, reached consensus at 
the APNIC 53
> Open Policy Meeting and later at the APNIC General Meeting (AGM).
> 
> This proposal will now move to the next step in the APNIC Policy 
Development Process
> and is being returned to the Policy SIG mailing list for the final 
Comment Period.
> 
> - Deadline for comments:  23:59 (UTC +10) Sunday, 03 April 2022.
> 
> Proposal details, including the full text of the proposal, history, and 
links to previous
> versions are available at:
> 
> https://www.apnic.net/community/policy/proposals/prop-142
> 
> Regards,
> Bertrand, Ching-Heng, Shaila
> Policy SIG Chairs
> 
> ___
> sig-policy - sig-policy@lists.apnic.net https://mailman.apnic.net/sig-policy@lists.apnic.net/
> To unsubscribe send an email to sig-policy-le...@lists.apnic.net
___
sig-policy - sig-policy@lists.apnic.net https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 - https://mailman.apnic.net/sig-policy@lists.apnic.net/
To unsubscribe send an email to sig-policy-le...@lists.apnic.net

Re: [sig-policy] New Proposal prop-140-v001: Update End-Site Definition

[JORDI PALET MARTINEZ]

Hi again …

 

When I wrote this proposal, I was looking for all the uses of the complete 
policy manual for end-user, end-site, etc. And I was sure that I didn’t miss 
anything. So, could you point to what specific sections in the policy manual 
I’ve missed, so I can see if a new version can fix that?

 

Regarding the other comment, I’ve not used, and is not used in the policy 
manual, any term related to “payment”. On the other way around,  since a few 
years ago, we already included “who has a business or legal relationship (same 
or associated entities)” to ensure that we are covering situations where you 
have “any kind of partner”, be it a business, a “sister organization”, etc., 
without restricting the relationship to a “business paid customer”. So, I think 
that’s was already resolved and this proposal is not changing that.

 

Regards,

Jordi

@jordipalet

 

 

 

ear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team..

I would like to share key feedback in our community for prop-140,
based on a meeting we organised on 25th Aug to discuss these proposals.

In addition to "end site" and “end-user," "customer" is scattered throughout 
the policy document. An opinion was expressed that it is necessary to organize 
the overall consistency.

(comment details)
 - The revisions in the current proposal seems not to be sufficient. 
   There seems to be a mixture of "end user" as a general term and 
   "end user" as defined in 2.10.
 - Isn't the concept of "customer" who "pays" for the numbered resources 
   inappropriate for the policy? Partners who are not customers should 
   also be treated as customers.


Regards,

Satoru Tsurumaki / JPOPF Steering Team  

2021年8月13日(金) 8:59 Bertrand Cherrier :

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 

Re: [sig-policy] New Proposal prop-139-v001: SOR not required

[JORDI PALET MARTINEZ]

Hi Satoru,

 

I’m not sure to understand your comments.

 

If the exising SOR is not being use, it means that removing it will not make a 
significant difference, right? So we’re not making allocations easier, we are 
just trusting that if the SOR is not being used, we should adapt the policy to 
existing reality.

 

In any case, if a LIR come back for more resources, and has been assigning 
addresses to customers without a good justification, they will need to justifiy 
that during the APNIC review.

 

We shall also remember that we have no more IPv4 addresses, so will not make a 
big difference.

 

In the case of IPv6, normally a houshold will not get more than /48. A business 
will probably will get a /48, and if they are smart enough, they will avoid 
renumbering getting a provider independent assigment directly from APNIC, so if 
they instead require a /47, for example, that will be part of the justification 
already.

 

So, in summary, I really think there are not chances to abuse of the policy 
with the proposed change, and instead we have a simplification of procedures 
for both, members and secretariat.

 

Regards,

Jordi

@jordipalet

 

 

 

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.

I would like to share key feedback in our community for prop-139,
based on a meeting we organised on 25th Aug to discuss these proposals.

Many neutral opinions were expressed about this proposal in view of the fact 
that the impact of this proposal should be examined in more depth.

(comment details)
 - Isn't there a possibility that some kind of loophole or allocation 
   against the purpose may occur by making allocation easier?
 - Although disorderly allocation will become possible, the total 
   number of IPv4 owned by each organization will not change, 
   so it should be operated at the discretion of ISPs.


Regards,

Satoru Tsurumaki / JPOPF Steering Team

2021年8月13日(金) 8:58 Bertrand Cherrier :

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. 

Re: [sig-policy] Abuse Role Object

[JORDI PALET MARTINEZ]

This is the email I was referring to:

 

https://mailman.apnic.net/mailing-lists/sig-policy/archive/2020/09/msg4.html

 

There are a couple of emails after this one.

 

I think we need to get clear responses from the secretariat if “anything” 
requires a policy update, or it is just implementation details that they can 
adjust without working out a policy proposal.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/5/21 8:31, "JORDI PALET MARTINEZ"  escribió:

 

Hi Aftab, all,

 

In my opinion, the policy text + the explanations/presentation provided by the 
authors + the “additional information” section of the policy proposal, was 
providing the information to avoid this type of issues.

 

Of course, the secretariat could take different implementation approaches, but 
the fact that we worked the details in the “additional information” was 
precisely because we foresee some possible issues and we suggested some 
implementation details to avoid them. I recall I’ve already sent a couple of 
emails to respond to some of those issues after a presentation of George, they 
should be archived. Actually, I think one of those emails that I’ve sent was 
not responded. I was asking there if some of the issues require an update of 
the policy via a new proposal. Could the secretariat take a look and tell us?

 

Trying to summarize:

 

1)  IRT was meant to (optionally) disappear at some point, or be an “alias” 
of abuse-c.

2)  Initially it is expected that the “main” abuse-c is created as a 
duplicate of the existing IRT.

3)  Each organization need to define if they want additional abuse-c for 
different set of resources. For example, you may have a different abuse 
handling team for IPv6 and IPv4, or even for different IPv4 blocks; you may 
want to have a customer-assigned block to be handled by the customer abuse 
team, etc.

4)  I don’t think Country and Phone should be mandatory, but of course, 
instead of bogus data should be empty, if no data is available. Note that I’m 
also not opposed to have them with mandatory Country and Phone, but the full 
idea of the validation process is to have a “working email” so if the working 
email being validated doesn’t work, the policy escalate to other contacts and 
those contacts, should already have the right country and phones, right?

 

So, I don’t think this specific topic requires a policy update, unless I’m 
missing something?

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/5/21 6:19, "Aftab Siddiqui"  escribió:

 

Hi Everyone,

 

As some of you have already seen the discussion [1] on twitter, started by 
Fakrul.

 

Just sharing the problem here. As part of some of the additional 
request/reference in prop-125 (Validation of “abuse-mailbox” and other IRT 
emails) "APNIC will publish the IRT also as abuse-c, in order to facilitate the 
search in whois, for the same information, regardless if looking for abuse-c or 
IRT. This is done in order to assimilate the IRT to the majority of the RIRs 
where it is abuse-c."

 

APNIC Secretariat implemented this by adding "abuse-c" attribute in the inetnum 
(example below) and inet6num. 

 

inetnum:103.162.142.0 - 103.162.143.255
netname:ISAL-SG
descr:  Internet Society Asia Limited
descr:  3 Temasek Avenue Level 21 Centennial Tower
country:SG
org:ORG-ISAL1-AP
admin-c:ISAL1-AP
tech-c: ISAL1-AP
abuse-c:AI706-AP

 

The abuse-c attribute requires NIC-handle but which NIC-handle? There can be 
many NIC-handle within the organisation but one organisation can only have one 
IRT object. So, APNIC generated a new "role object" using the data from the 
IRT-object. 

 

Now, the problem is that role object has some mandatory field as per APNIC 
whois policy defined here [2], which either doesn't exist (country) or are 
optional (phone) in IRT object i.e.

 

role:  [mandatory]  [single] [lookup key]
address:[mandatory]  [multiple]   [ ]
country:[mandatory]  [single] [ ]
phone:  [mandatory]  [multiple]   [ ]
irt:[mandatory]  [single] [primary/lookup key]
address:[mandatory]  [multiple]   [ ]
phone:  [optional]   [multiple]   [ ]
fax-no: [optional]   [multiple]   [ ]
When APNIC auto generated the data for this new abuse-c NIC-handle, they filled 
it with bogus data.

 

role:   ABUSE ISALSG
address:3 Temasek Avenue Level 21 Centennial Tower, Singapore Singapore 
039190
country:ZZ
phone:  +0

 

The APNIC Secretariat is seeking suggestions to fix this problem as to how to 
fill up the missing information. 

 

IMO, a simple way would be to make Country (ISO-3166) and Phone number 
mandatory in the IRT object (currently they are optional). This can be done 
during the next IRT validation cycle.

Btw, Country Code in the role object is not a mandatory attribute (it d

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

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"  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  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 
Date: Wednesday, 17 March 2021 at 6:36 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
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/nir-membership-agreement/

 

(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"  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 
Date: Tuesday, 16 March 2021 at 7:08 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
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

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

Tks Vivek, I will update the document to v0.3 with that modification.

 

However, I think it is important to clarify if the nir-membership-agreement is 
still valid, because if that’s the case, a further clarification and 
simplification that can be done *across the entire policy manual* is to remove 
many of the references to NIRs, as they are implicit.

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/3/21 9:54, "Vivek Nigam"  escribió:

 

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 
Date: Wednesday, 17 March 2021 at 6:36 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
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/nir-membership-agreement/

 

(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"  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 
Date: Tuesday, 16 March 2021 at 7:08 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
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"  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:  on behalf of JORDI PALET MARTINEZ 

Date: Monday, 15 March 2021 at 7:20 pm
To: Srinivas Chendi , sig-policy 
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"  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 othe

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

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/nir-membership-agreement/

 

(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"  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 
Date: Tuesday, 16 March 2021 at 7:08 pm
To: Vivek Nigam , Srinivas Chendi , 
sig-policy 
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"  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:  on behalf of JORDI PALET MARTINEZ 

Date: Monday, 15 March 2021 at 7:20 pm
To: Srinivas Chendi , sig-policy 
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"  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 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 for

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

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"  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 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"  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-report.pdf

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

Re: [sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

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 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"  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-report.pdf

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

[sig-policy] proposals to resolve the "APNIC Policy Document Review Report"

[JORDI PALET MARTINEZ]

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 ?
http://www.theipv6company.com
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

Re: [sig-policy] [rpd] [Community-Discuss] clarification requested from AFRINIC

[JORDI PALET MARTINEZ]

Hi Madhvi,

 

The correction of my point 1 was done in the Q screen, but not in “voice”. As 
a consequence, all the participants that usually have the Q windows closed 
(in Zoom), were not able to see it, and they may be still under the impression 
that it was a resignation, not a recall. I understand that was out of the hands 
of AFRINIC, so I’ve copied back the relevant APNIC mailing list, so this 
correction is now clear.

 

Regarding point 2, the co-chairs indicated that they have sent an email. The 
PDP doesn’t state any explicit format or template. The list dicussion shows 
that the staff asked them to follow a format used by previous chairs, but the 
PDP doesn’t ask for it, so it can’t be enforced. The Board deny having got that 
report, but they never denied having received the email. Again: the PDP doesn’t 
enforce any specific format, so we need to see the email to understand if the 
Board is missing something and actually *informed* the co-chairs about WHAT 
they missed.

 

Can the Board *confirm* or *deny* if they GOT SUCH EMAIL? That will clarify the 
issue and if the (ex)co-chairs can forward that email to the list, that will be 
awesome, but meanwhile, even if the co-chairs have been recalled, I don’t have 
any reasons to believe that they lied in sense that they didn’t sent the email.

 

Regards,

Jordi

@jordipalet

 

 

 

El 3/3/21 12:09, "Madhvi Gokool"  escribió:

 

Hello Jordi /PDWG

 

On 03/03/2021 1:52 PM, JORDI PALET MARTINEZ via Community-Discuss wrote:
Hi all,
 
Today, during the APNIC51 meeting, in the Global Reports session 
(https://2021.apricot.net/program/schedule-conference/#/day/10/apnic-global-reports),
 as usual, there was a presentation from every RIR, including AFRINIC.
 
In this presentation from AFRINIC, there have been two "imprecisions". I prefer 
to use this wording instead of something stronger, because to me those are very 
severe issues. I've asked in the Q to get this publicly clarified and it was 
not done.
 
AFRINIC MUST publicly acknowledge the mistakes.
 
1) It was explained that the AFRINIC PDWG co-chairs resigned. You can see it at 
the end of the presentation.
https://www.youtube.com/watch?v=5ODvgxbMErs#t=35m50s
The AFRINIC staff corrected the initial statement made in his  presentation and 
mentioned that the Co-chairs were recalled in the Q feature.  
 
 
2) It has been said that one of the policy proposals that reached consensus 
hasn't been sent to the Board for ratification, which is not true, as discussed 
in the RPD mailing list. The co-chairs did send the policy to the Board, but 
the Board decided to ignore it, because it looks like they want the chairs to 
follow a format that has never been enforced before and it has not been 
approved by the community, neither the PDP.
See slide 6 at 
https://2021.apricot.net/assets/files/APSr481/afrinic-update-apnic51.pdf
i) The PDWG is under the impression from a previous correspondence of the now 
ex-co chair AbdulKarim that the co-chairs  had already sent the ratification 
reports to the Board.

ii) There were requests on the rpd mailing list to the outgoing co-chairs to 
share the mails that they have sent to the Board with the PDWG  and there were 
no responses.  

iii) The Board Chair informed the community on 14 Feb 2021  that the report for 
ratification was not received. 

https://lists.afrinic.net/pipermail/rpd/2021/012363.html

iv) It is incorrect to mention that the Board wanted the chairs to follow a 
specific format. This is a misinterpretation of the information provided by the 
Policy Liaison to the mailing list  in regard to the report template.  
https://lists.afrinic.net/pipermail/rpd/2021/012374.html

 

Regards

Madhvi

___ RPD mailing list 
r...@afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

[sig-policy] clarification requested from AFRINIC

[JORDI PALET MARTINEZ]

Hi all,

Today, during the APNIC51 meeting, in the Global Reports session 
(https://2021.apricot.net/program/schedule-conference/#/day/10/apnic-global-reports),
 as usual, there was a presentation from every RIR, including AFRINIC.

In this presentation from AFRINIC, there have been two "imprecisions". I prefer 
to use this wording instead of something stronger, because to me those are very 
severe issues. I've asked in the Q to get this publicly clarified and it was 
not done.

AFRINIC MUST publicly acknowledge the mistakes.

1) It was explained that the AFRINIC PDWG co-chairs resigned. You can see it at 
the end of the presentation.
https://www.youtube.com/watch?v=5ODvgxbMErs#t=35m50s


2) It has been said that one of the policy proposals that reached consensus 
hasn't been sent to the Board for ratification, which is not true, as discussed 
in the RPD mailing list. The co-chairs did send the policy to the Board, but 
the Board decided to ignore it, because it looks like they want the chairs to 
follow a format that has never been enforced before and it has not been 
approved by the community, neither the PDP.
See slide 6 at 
https://2021.apricot.net/assets/files/APSr481/afrinic-update-apnic51.pdf


Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-130-v003: Modification of transfer policies

[JORDI PALET MARTINEZ]

 future require this service and 
that at the time the counterpart RIR may have a policy that allows it and may 
have developed the technical ability to fulfil the request.

The cost is estimated by the Secretariat as 3 months development time. 
Perhaps the Secretariat could tell us what project will be cancelled if this 
proposal reaches consensus, because this development time will not be budgeted 
for 2021.

Your point that the RIR's and the community should develop solutions the 
community may want/need in future is quite valid. However, if that’s what you 
are proposing, then make that more transparent in your proposal.

If the community demonstrates that it accepts this cost / benefit 
trade-off, I’ll happily support the proposal.

Regards,

Adam



> On 1 Mar 2021, at 9:09 pm, JORDI PALET MARTINEZ 
 wrote:
> 
> Hi Adam,
> 
> I don't have the need to "disguise" any policy proposal. I'm a very 
honest and transparent person, pity that you didn't noticed it, and if I 
believe that IPv6 transfers outside of M's are required, I will submit that 
policy in an open and transparent manner.
> 
> I've you believe that I'm trying to cheat the community, please say so 
clearly and show evidences.
> 
> That said, I'm happy to work on IPv6 Inter-RIR transfers at a later 
stage, but this is not the case with this proposal.
> 
> The policies not always have cases that *already happened*. The policies 
should be there to prevent those cases being real needs and rejected. In fact, 
if they happened there may several situations:
> 1) The organizations that need that read the policy manual, understood 
they can't do it, and desisted.
> 2) They asked the secretariat.
> 3) They didn't read the policy/DBs update is managed (or not updated al 
all), that nobody noticed it, especially in intra-RIR situations.
> 
> So the question here is, do we want to have oredered solutions for real 
business situations, or we prefer to ignore them and even force them to bypass 
the policies and hide the situation?
> 
> If we don't have policies up-front problems, then problems became a huge 
issue, delay business, even may create losses. Some folks will just ignore 
policies and go ahead. We all know it. Policies have been done *always* 
up-front issues happening, when those possible issues where discovred, not just 
after we discover the issue. Some times we have policies too late, because 
nobody discovered the issue: that's unavoidable, because we don't have the 
crystal ball.
> 
> I can't talk for the secretariat if there have been questions about this 
previously, hopefully they can say. I know it happened in other regions.
> 
> By the way, my reading of the RIPE procedures is that they don't 
distinguish if you do an M with all the resources or part of it, they may 
confirm it (I'm sure they are in the list), if that's the case, and if already 
happened or there have been questions on that.
> 
> Clearly the secretariat, and the same for other RIRs, should work on 
developing whatever the community decides is good to have. And I think it is 
much better to ensure that we have those developments in mind up-front of 
having real problems, specially if they may be complex and require coordination 
among different RIRs, instead of rushing when we have the problems already in 
our back, right?
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 1/3/21 3:31, "sig-policy-boun...@lists.apnic.net en nombre de 
em...@adamgosling.com"  escribió:
> 
>Hi all,
> 
>I oppose this proposal.
> 
>I am not convinced of the need for it. Are there examples of when an 
M 
>request was refused that would be permitted by this policy change?
> 
>This looks like an IPv6 Inter-RIR transfer proposal in disguise?
> 
>I don't think the APNIC Secretariat should be required to do the 
>development work to support IPv6 reverse DNS if there is no clear 
>indication that other regions will support IPv6 reverse DNS fragments 
in 
>the future.
> 
> 
>Adam
> 
> 
> 
> 
>On 2021-02-01 22:25, chku wrote:
>> Dear SIG members,
>> 
>> A new version of the proposal "prop-130: Modification of transfer 
>> policies"
>> has been sent to the Policy SIG for review.
>> 
>> It will be presented during the Open Policy Meeting at 
>> APRICOT2021/APNIC 51
>> online-only conference on Wednesday, 03 February 2021.
>> 
>> We invite you to review and comment on the proposal on the mailing list
>> before the meeting.

Re: [sig-policy] Policy Discussion in bdNOG for APNIC51

[JORDI PALET MARTINEZ]

Hi,

It will be possible to understand what issues the participants have discussed 
about prop-130?

By the way, I think it will be much more efficient if instead of reading a 
policy proposal on behalf the author (and without him knowing it), an 
opportunity to the author to participate is provided. That will allow 
clarifications to be done in real-time.

Regards,
Jordi
@jordipalet
 
 

El 2/3/21 2:46, "bdNOG Secretariat"  escribió:

Greetings from Bangladesh Network Operators Group (bdNOG).

This is the first time we have done a policy discussion in our NOG, based
on the upcoming OPM in APNIC51. The event was done on Feb 24, 2021 04:30
PM (BST) to introduce how APNIC runs the OPM in all the APNIC meetings and
what are the current policies proposed in the upcoming APNIC51 virtual
event. Also we had a raise hand session and open mic session. For better
understanding the whole event was done in Bangla and in English partially.

There are two active policy proposals to be discussed at APNIC 51.
Prop-130: Modification of transfer policies was read-out by Ms. Shaila
Sharmin on behalf of the author and prop-133: Clarification on
Sub-Assignments was read-out by Mr. Abdul Awal.

After the discussion consensus was taken by raising the hand. 

Prop-130, there was no consensus as there were mixed responses from the
audience.
Prop-133, was supported by the majority of the audience and there was no
one opposed to the proposal.

bdNOG will try to organize more Policy Discussion in the upcoming main
events and will try to share more inputs and thoughts from Bangladesh
Community.

With Regards

Secretariat,
Bangladesh Network Operators Group (bdNOG).


-- 

|Bangladesh Network Operators Group (bdNOG)|

A group of people playing with the Internet
puzzle and trying hard to build better Internet
in Bangladesh. www.bdnog.org

*  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



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-130-v003: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Adam,

I don't have the need to "disguise" any policy proposal. I'm a very honest and 
transparent person, pity that you didn't noticed it, and if I believe that IPv6 
transfers outside of M's are required, I will submit that policy in an open 
and transparent manner.

I've you believe that I'm trying to cheat the community, please say so clearly 
and show evidences.

That said, I'm happy to work on IPv6 Inter-RIR transfers at a later stage, but 
this is not the case with this proposal.

The policies not always have cases that *already happened*. The policies should 
be there to prevent those cases being real needs and rejected. In fact, if they 
happened there may several situations:
1) The organizations that need that read the policy manual, understood they 
can't do it, and desisted.
2) They asked the secretariat.
3) They didn't read the policy/DBs update is managed (or not updated al all), 
that nobody noticed it, especially in intra-RIR situations.

So the question here is, do we want to have oredered solutions for real 
business situations, or we prefer to ignore them and even force them to bypass 
the policies and hide the situation?

If we don't have policies up-front problems, then problems became a huge issue, 
delay business, even may create losses. Some folks will just ignore policies 
and go ahead. We all know it. Policies have been done *always* up-front issues 
happening, when those possible issues where discovred, not just after we 
discover the issue. Some times we have policies too late, because nobody 
discovered the issue: that's unavoidable, because we don't have the crystal 
ball.

I can't talk for the secretariat if there have been questions about this 
previously, hopefully they can say. I know it happened in other regions.

By the way, my reading of the RIPE procedures is that they don't distinguish if 
you do an M with all the resources or part of it, they may confirm it (I'm 
sure they are in the list), if that's the case, and if already happened or 
there have been questions on that.

Clearly the secretariat, and the same for other RIRs, should work on developing 
whatever the community decides is good to have. And I think it is much better 
to ensure that we have those developments in mind up-front of having real 
problems, specially if they may be complex and require coordination among 
different RIRs, instead of rushing when we have the problems already in our 
back, right?

Regards,
Jordi
@jordipalet
 
 

El 1/3/21 3:31, "sig-policy-boun...@lists.apnic.net en nombre de 
em...@adamgosling.com"  escribió:

Hi all,

I oppose this proposal.

I am not convinced of the need for it. Are there examples of when an M 
request was refused that would be permitted by this policy change?

This looks like an IPv6 Inter-RIR transfer proposal in disguise?

I don't think the APNIC Secretariat should be required to do the 
development work to support IPv6 reverse DNS if there is no clear 
indication that other regions will support IPv6 reverse DNS fragments in 
the future.


Adam




On 2021-02-01 22:25, chku wrote:
> Dear SIG members,
> 
> A new version of the proposal "prop-130: Modification of transfer 
> policies"
> has been sent to the Policy SIG for review.
> 
> It will be presented during the Open Policy Meeting at 
> APRICOT2021/APNIC 51
> online-only conference on Wednesday, 03 February 2021.
> 
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
> 
> The comment period on the mailing list before an APNIC conference is an
> important part of the policy development process. 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 available at:
> http://www.apnic.net/policy/proposals/prop-130
> 
> Regards,
> Bertrand and Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> ---
> 
> prop-130-v003: Modification of transfer policies
> 
> ---
> 
> Proposer: Jordi Palet Martnez
> jordi.pa...@theipv6company.com
> 
> 
> 1. Problem statement
> 
> 
> Existing transfer policies for IPv4, IPv6 and ASN resources have some
> differences among what is allowed and what not, if in the case of
> intra-RIR and inter-RIR, and it is not clear if in case of merger and
> acquisitions it is referring to a complete company, part of 

Re: [sig-policy] prop-130-v003: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I fully understand the difficulties that you mention, but those difficulties, 
to me look like the same as per existing policy.

Any transfer requires checking documents, which may be in different languages. 
Any transfer requires coordination among NIRs or RIRs, etc.

So, I do not see it as different to what it happened with previous transfer 
policies (whatever is the reason). Of course, I also fully understand that the 
implementation time depends on coordination with the other RIRs and their 
systems, but this is also true for existing Inter-RIR policies.

Just want to make sure that I'm not missing anything and your assessment is 
just a reminder about that, not indicating any real and unsolvable issues.

Regards,
Jordi
@jordipalet
 
 

El 17/2/21 7:04, "Srinivas (Sunny) Chendi"  escribió:

Dear all,

Here is the Secretariat impact assessment for proposal "prop-130-v003: 
Modification of transfer policies".

Possible difficulties in verifying mergers, acquisition, reorganization, 
or relocation from out of APNIC region due to unfamiliarity of languages 
and legal systems. May require cross RIR coordination.

Partial IPv6 transfers may result in registration of IPv6 allocations 
that are more specific than /32.

APNIC’s current systems are not configured to handle inter-RIR IPv6 
reverse DNS. This will need to be developed.

APNIC cannot predict when other RIRs will support IPv6 reverse DNS 
fragments incoming to their systems.

Implementation: 3 months, except inter-RIR IPv6 reverse DNS (rDNS).

Regards
Sunny

On 2/02/2021 2:25 pm, chku wrote:
> Dear SIG members,
>
> A new version of the proposal "prop-130: Modification of transfer 
policies"
> has been sent to the Policy SIG for review.
>
> It will be presented during the Open Policy Meeting at APRICOT2021/APNIC 
51
> online-only conference on Wednesday, 03 February 2021.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC conference is an
> important part of the policy development process. 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 available at:
> 
https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apnic.net%2Fpolicy%2Fproposals%2Fprop-130data=04%7C01%7C%7C4fa1eb6f23ac419a95e508d8c7329f44%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C637478367555653423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=CsjZK2dQEUNWNP6Z5zdhzNiiZzC0sXfCesvMgnEbye4%3Dreserved=0
>
> Regards,
> Bertrand and Ching-Heng
> APNIC Policy SIG Chairs
>
>
> ---
>
> prop-130-v003: Modification of transfer policies
>
> ---
>
> Proposer: Jordi Palet Martnez
> jordi.pa...@theipv6company.com
>
>
> 1. Problem statement
> 
>
> Existing transfer policies for IPv4, IPv6 and ASN resources have some
> differences among what is allowed and what not, if in the case of
> intra-RIR and inter-RIR, and it is not clear if in case of merger and
> acquisitions it is referring to a complete company, part of it, or even
> if in case of a company reorganization or relocation, the policy is
> supportive to that case.
>
> In some regions, this may not be a policy, but an administrative
> procedure, but this may change in the future by means of a policy 
proposal.
>
> In the caser of inter-RIR, the counterpart RIR need to have a reciprocal
> policy or procedure that allows it.
>
> Finally, there should not be differences from the APNIC perspective, on
> the considerations of an M for different type of resources, because
> there is no reason for allowing, for example, IPv4 resources to be
> transferred, and instead IPv6 ones not. For example, an organization may
> be hosting services in a Data Center, by means of Virtual Machines and
> moving to a different DC in another region. It is ridiculous to allow to
> keep the IPv4 addresses (so not renumber the VMs) and instead ask to
> renumber IPv6. It is a big and unnecessary disruptive complexity.
>
>
> 2. Objective of policy change
> --
> To ensure that the policy text is clarified, if those 

Re: [sig-policy] Final editorial comments on draft document

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I've several points in addition to my document comments. I can't use the 
comments platform, which by the way, is absolutely unpractical (not to say 
something really more negative), because a) you need to be on-line, which may 
not be the case, b) you don't create a public discussion on the inputs - which 
is critical for the bottom-up consensus, c) you don't know if the community is 
really following it or not, d) it doesn't follow the PDP itself!. So, I will 
summarize here my more critical inputs.

I've raised those several times, but it seems that it was ignored.

1) The actual PDP doesn't have any binding to the SIG guidelines, so *legally 
speaking* the SIG guidelines aren't applicable. Is like if tomorrow we make 
another document that we call "Policy SIG meeting guidelines" and we try to 
bypass the PDP adopting it as a separate document, not using the PDP, and/or 
there is no PDP modification to bind that document.

2) In your email you indicate that consensus has already been reached. In what 
meeting? If this is not a PDP document (SIG guidelines), is not bound to the 
PDP, etc., how come consensus has been reached? Could you provide a step by 
step consensus process for this document? Again, are we trying to bypass the 
PDP and inventing a different consensus path for *separate documents* ?

3) So clearly, I can only object to this, it is an illegal act against the 
community and every community member to try to bypass our PDP, and if this goes 
on, it will be against ICANN ICP-2 and the rules that established APNIC and we 
will need to appeal that.

4) I fully agree that the PDP needs to be improved, and that's why I've 
submitted policy proposals for that, but *we need to do it in the correct way* 
so only can be done following the PDP.

5) The PDP must be self-inclusive. It looks nice to have a "5 sentences" PDP, 
but it has been demonstrated that it is just an illusion that doesn't work. At 
a minimum, any additional document should be bound to the PDP and follow the 
same process.

6) This is the most important point, which invalidates all the process: 
According to the PDP there is NO authorization for editorial changes. So that 
means that even *editorial changes* need a complete pass thru the PDP. I'm not 
saying this is optimal, and I will prefer that the secretariat can actually do 
editorial review of documents, *however* my wish and your intent aren't part of 
the actual PDP. So, if we want to make editorial changes this way, we need 
*FIRST* to have a policy proposal adopted via the PDP to add that prerogative 
to the secretariat. By the way, how we decide what is editorial and what not? 
This must be clarified to allow that "functionality" (for example, only 
grammar, typos, etc. or also text clarification that doesn't change the 
intended original meaning).

7) Please see also my email on September 9 (2020), which I don't recall has 
been answered (clearly no answer doesn't show ANY consensus): 
https://mailman.apnic.net/mailing-lists/sig-policy/archive/2020/09/msg2.html

Inputs to the document:

1. Introduction
This text is drastically changing the PDP it is not *editorial*. It introduces 
an *artificial link* to the SIG guidelines which, as I already mention above, 
*are not part of the PDP* and can't be, unless that document pass as a policy 
proposal via the PDP itself. Accepting that is like accepting that a government 
change a law (in a democratic country) without nobody know it, and without the 
voting in the parliament, so basically a crime.

The actual PDP only talks about meetings and lists. As I've commented other 
times, we have been using electronic means, which I agree, but changing this in 
the PDP is NOT an editorial comment. It needs to pass via the PDP. In fact, the 
demonstration of why that change is NOT an editorial comment, is that in one of 
my proposals, that change *never reached consensus*, even if the chairs asked 
just for that point (isolated from the rest of the proposal). So how come we 
can now say that it is an editorial comment and bypass the community decision 
*in the PDP* that they don't agree with that change?

Using the expression "anyone with an interest in the management and use of 
Internet number resources ..." is creating a big problem vs the actual wording, 
because the actual wording clearly means that if someone is interested in 
improving the PDP (not and Internet number resource), will not be able to do 
participate, or saying it in another way, again this is not an editorial 
change, because we are using a subterfuge to restrict the PDP to be updated in 
the future, which creates a big trouble!

How come RIR, ICANN and PTI employees can't participate? I've never seen that 
in any RIR. Usually they don't do, or they speak up clearly indicating if they 
are speaking as employees of those organizations or as community members. This 
is completely broken! NOBODY can restrict an employee of a RIR to say "in their 

Re: [sig-policy] SIG Guidelines Review

[JORDI PALET MARTINEZ]

Could a track of changes be provided to simplify the review?

Regards,
Jordi
@jordipalet
 
 

El 16/11/20 2:44, "Bertrand Cherrier"  escribió:

Hello everybody !

Last year at APNIC 48 a discussion started about reviewing the SIG 
Guidelines.
It is important to make documents match the evolution of the current 
practice.

SIG Chairs and co-Chairs along with the big help of APNIC Secretariat 
designed a draft version of the new Guidelines, you will find it with 
this email.

Here is a brief of the major changes :

- Make SIG Guidelines a numbered document
- Move Policy SIG specific content to PDP
- Move SIG elections online and to APNIC standalone conference
- Restructure and renumber the document
- Include reference to Code of Conduct
- Include procedure to change document

If you have any comments or remarks and we hope you do !, please do 
share thoses with the community by Friday 20th

Have a nice week,

Regards,

Bertrand and Ching-Heng
APNIC Policy SIG Chairs
*  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



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] about prop-125 Implementation update

[JORDI PALET MARTINEZ]

Hi George,

Tks for your response!

I think it is just ok, however I've a minor disagreement.

My idea is to amend the proposal so the validation is done every 6 months and 
the timer for the initial validation is 15 days, BUT state that the secretariat 
is able to adjust both timings according to circumstances, and inform the 
community about the reasons.

This allows to, once almost 99% of the validations are ok, decide if we need to 
make only one validation per year, but if after that validation the quality of 
the contacts is going down, the secretariat can consider making it again every 
6 or 8 months to readjust, etc. This will allow you to manage those timers, 
without amending the proposal. Do you see my point?

(this is what I've done in other regions)

Regards,
Jordi
@jordipalet
 
 

El 16/9/20 9:44, "George Odagi"  escribió:

Hi Jordi,

Thanks for watching the presentation and for your comments.

Based on our recommendations, we are suggesting the following changes:




Example of new validation procedure

1) APNIC initiates the validation automatically ONCE a year, sending ONE 
email to the 'abuse-mailbox' address. 
(We will consider deprecating the 'email' attribute so only one email 
address requires validation)

2) The email will be sent containing plain text only.

3) The email will contain the unique code required for the validation and 
may contain information about the procedure, a brief summary of this policy, 
etc.

4) The person in charge of the mailbox will be instructed to visit the 
APNIC website (eg. www.apnic.net/irt-validation) and paste the code received in 
their email. (MyAPNIC cannot be used since many abuse mailboxes are either 
customers of members or company staff who do not have MyAPNIC access).

5) The IRT validation page on the APNIC website will be designed in a way 
that it prevents the use of an automated process (for example, "CAPTCHA"). In 
addition, it will contain a text that confirms that the person performing the 
validation understands the procedure and the policy, that they regularly 
monitor the mailboxes, that measures are taken to solve reported cases of 
abuse, and that the abuse report receives a response, with a "checkbox" that 
must be accepted in order to proceed.

6) If the code is not entered within 15 days, the system will mark the IRT 
as "Invalid” in the APNIC Whois Database and an automatic reminder will be 
sent. If validation is still not completed after 30 days, MyAPNIC access will 
be restricted and APNIC staff will follow-up with the member using all contact 
methods available.

7) Once the validation has been resolved, the IRT will be marked as "Valid" 
and MyAPNIC access will be reinstated.




From the Secretariat's point of view - the intention is to make minor 
tweaks to the existing process to simplify the validation and reduce burden 
that we are putting on members. Most of the changes can be made as operational 
procedure; however the current policy text specifies that validation occurs 
every 6 months, so we would need an amended proposal to change this timeframe. 
We want to keep this simple by using a fixed timeframe of once yearly as we are 
already starting to reach the goals that we have set out to achieve in this 
policy. 

Regarding the NIRs, they have reported the following statuses:

- CNNIC is almost ready to implement
- IDNIC have implemented but still tweaking
- JPNIC is working with JPOPF on the implementation
- TWNIC and VNNIC will implement by Q1 2021

We are currently in discussion with IRINN and KRNIC about their 
implementation plan.

We would love to hear from the rest of the community about these changes 
and work together in amending this policy.

Any questions or concerns, please let us know.


Regards,

___
George Odagi
Internet Resource Analyst/Policy Support, APNIC
e: god...@apnic.net
p: +61 7 3858 3188
f: +61 7 3858 3199
www.apnic.net
___
Join the conversation:   https://blog.apnic.net/












On 10/9/20, 5:57 pm, "sig-policy-boun...@lists.apnic.net on behalf of 
JORDI PALET MARTINEZ"  wrote:

Hi George, all,

I just looked at the presentation that you have done earlier today and 
have some inputs about possible ways to improve it.

1. Slides 9-10
1.1. About receiving spam
The abuse mailbox should receive *all* the emails to be able to receive 
abuse reports about spam. If you filter emails that contain headers from spam, 
then you are ruining the purpose of the abuse-c. Clearly this could be 
im

[sig-policy] about prop-125 Implementation update

[JORDI PALET MARTINEZ]

Hi George, all,

I just looked at the presentation that you have done earlier today and have 
some inputs about possible ways to improve it.

1. Slides 9-10
1.1. About receiving spam
The abuse mailbox should receive *all* the emails to be able to receive abuse 
reports about spam. If you filter emails that contain headers from spam, then 
you are ruining the purpose of the abuse-c. Clearly this could be improved, as 
an operational decision, by making some kind of automation, but in such way 
that ensures that only real spam is dropped. Note that the other RIRs are also 
using (at some point), validation links via the abuse-c email.

1.2. About clicking links
I provided an example procedure in the policy proposal to avoid this. I've 
copied this below my signature. See points 1-5. If that procedure is followed, 
I think it is obvious that you will avoid this problem. I missed to ensure 
during the previous implementation presentations, that you are following a 
procedure that avoids this problem. Of course, you can even avoid needing to 
send the validation link if you just say in the email with the code "you need 
to go to your MyAPNIC account to use this code" ... Maybe also an alternative 
is to use email certificates from APNIC.

2. Slide 11
2.1. About the validation cycle.
In more recent versions of this policy, in other RIRs, I have included specific 
text so APNIC can accommodate both, the validation periods and the cycle 
validation. The idea is that you can do a slow start (which seems not to be 
needed in the case of APNIC due to the 87% validation success - 
congratulations!), but you can also adjust the timing depending on the staff 
available to escalating the validation, or to move from 6 months to 1 year once 
the "99%" of the contacts are valid, and if needed, for example, the contacts 
get bad, move again to 6 months or even 3 months to get them again on track.

2.2. Deprecating IRT.
The policy proposal included in the ADDITIONAL INFORMATION section:
"a. Since this proposal is implemented, APNIC will publish the IRT also as 
abuse-c, in order to facilitate the search in whois, for the same information, 
regardless if looking for abuse-c or IRT. This is done in order to assimilate 
the IRT to the majority of the RIRs where it is abuse-c."

So clearly, the idea was that we move from the IRT to abuse-c, so to align as 
much as possible all the 5 RIRs (in ARIN is POC, and AFRINIC is also IRT, but 
there is a policy proposal like this one, an in fact there are only a 
ridiculous fraction of IRT objects because is not mandatory right now).

I've one question I've. What is the status of implementation at each NIR?

Now, regarding the points that I've commented above, I will be happy to get 
additional inputs and send a policy proposal in a few days. I don't think we 
should do anything about 1.1. 1.2 and 2.2 should be addressed as part of the 
operational procedure by the staff. We can address 2.1. Something else?

Now, a possible idea to improve this will be move the policy to make mandatory 
the use of XARF "eXtended Abuse Reporting Format" (RFC5965/RFC6692). There is 
already open source (and commercial tools) that allow it. This will resolve the 
problem 1.1 above and provide much better tools to the resource-holders to 
avoid manual monitoring as much as possible, automate the abuse processing, etc.

Can we get some inputs about if this is perceived as interesting by the 
community?

Maybe we can draft the policy proposal in such way that XARF can be optional at 
this stage, and later on, if there is a good adoption %, in 1-2 years, move to 
mandatory?

I will send a policy proposal to update this upon getting some inputs. I guess 
Aftab will be happy to join as well, and happy to get other people on-board!

Regards,
Jordi
@jordipalet
 
 c. Example of the validation procedure.

1) APNIC initiates the validation automatically, sending TWO consecutive emails 
to each of the mailboxes.

2) These emails will be sent containing plain text only.

3) The first email will contain the URL where the validation is to be performed 
("validation.apnic.net") and may contain information about the procedure, a 
brief summary of this policy, etc.

4) The second email will contain a unique alphanumeric validation code.

5) The person in charge of the each of the mailboxes must go to the URL and 
paste the code received in the second email in the form.

6) This URL must be designed in such a way that it prevents the use of an 
automated process (for example, "captcha"). In addition, it must contain a text 
that confirms that the person performing the validation understands the 
procedure and the policy, that they regularly monitor the mailboxes, that 
measures are taken to solve reported cases of abuse, and that the abuse report 
receives a response, with a "checkbox" that must be accepted in order to 
proceed.

7) The alphanumeric code will only be valid for a maximum of fifteen days.

8) If the code is not 

[sig-policy] PDP and SIG Guidelines Review Report (Policy SIG earlier today)

[JORDI PALET MARTINEZ]

Hi all,

I just saw the video (not able to attend on-line to all the sessions because a 
very different time zone all the week), of the Policy SIG session today, and 
specially the "PDP and SIG Guidelines Review Report".

I've seen also the diff of both documents.

I feel somehow "guilty" about this topic, as I was the one pushing for several 
policy proposals to update the PDP. I think that the pandemic showed us that, 
without having the crystal ball, I was right in many points!

Despite that, I'm very happy that finally, there are some action to update 
this, however I've doubts about the say to proceed and the proposed changes.

The first big question is that I'm not sure the actual PDP allows "editorial" 
changes to be actually made without the community consensus. Also, the 
associated problem is to agree in what is and what not an editorial change. 
Sunny actually said that in his presentation, confirming that the community 
owns those documents.

In principle, I could agree that if they are really pure editorial inputs, they 
can be changed by the staff, but in any case, this needs to have a pass thru 
the community (as mandated by ICP-2 and consensus/bottom-up approach), and I 
guess this is the appropriate mailing list for that.

So, I will start by commenting in detail the proposed changes. However, for 
that, I need a word or txt version, as I tried to use the html-diff and if I 
try to copy one column to paste as text, it actually copies both columns ...

Can the secretariat provide such doc or txt version already? (doc has the 
advantage to allow track of changes and comments, I think it is preferable). I 
know that it is the plan, but I will like to start now (no reason to delay it), 
as I've some more availability now, that will not necessarily be the case in a 
few days/weeks (I'm strong believer of "never leave till tomorrow what you can 
do today").

Further inputs to the today's session:

1) I agree with some of the inputs from Owen. For example, the voting for 
elections, I've proposed this actually in other regions. I will prefer 6 months 
instead of 60 days. The goal is that only people in the mailing list 6 months 
before the month where the elections happens is allowed to vote in order to 
avoid possible fraud in elections (100 friends of one of the candidates 
registering only for voting).

2) On Gaurab comment, and somehow Aftab. I also think that we will need a PDP 
change to allow having OPM by their own (if it becomes necessary for whatever 
reason, LACNIC PDP already allows it without changes) and as it was in one of 
my policy proposals, because the EC already needs to endorse a proposal, this 
is sufficient and not AGM approval is needed, it is a "repetitive" process.

3) Following another Owen input, SIG guidelines don't necessarily need to be 
the same for all the SIGs, because there is a substantial difference between 
the Policy SIG and the others (the Policy SIG makes policies, not the others). 
So the PDP should be self-contained and not depend on "other" SIG guidelines.

Tks!

Regards,
Jordi
@jordipalet





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-134: PDP Update withdrawn by author

[JORDI PALET MARTINEZ]

Hi Paul,

Then it seems there is a misunderstanding, at least in the way I interpreted 
what it was said in the meeting.

For me it is not just editorial changes, because there is not a link, in 
between the PDP and the guidelines. It is not a matter of just "adding" that 
link now. It is a matter of having either a guidelines developed following the 
PDP (bottom-up) or updating the PDP itself (by means of the PDP as well), to 
include the points that are needed from the guidelines.

My observation in the meeting was that the guidelines were developed too long 
ago, by the SIG chairs, when we had many SIGs, not developed by the community, 
and not developed on purpose for the policy development. I think there is a 
substantial difference in between SIGs that don't develop policies and the one 
responsible for the policies.

Regards,
Jordi
@jordipalet
 
 

El 26/2/20 6:18, "Paul Wilson"  escribió:

Dear Jordi, and colleagues,

This policy document review is on the Secretariat workplan for 2020, and 
it has been regarded as an editorial task, on an assumption that it will
not affect the substance of any policies.

Of course, any document changes would be subject to the usual editorial 
review process, and progress will be shared with the community in time 
for APNIC 50 where it can be discussed.

There is no plan to create a taskforce, but this could certainly be 
decided at the next meeting, if the community agrees.

All the best

Paul.


Paul Wilson, Director-General, APNICd...@apnic.net
http://www.apnic.net@apnicdg

On 25 Feb 2020, at 10:16, Srinivas Chendi wrote:

> Hi Jordi,
>
> Thanks for your suggestion. Secretariat will consult with the APNIC 
> EC.
>
> Regards
> Sunny
>
> On 24/02/2020 8:53 pm, JORDI PALET MARTINEZ wrote:
>> Hi Bertrand, all,
>>
>> As indicated in the meeting, the withdraw of this proposal is 
>> "temporary", in view of the commitment from the EC/secretariat to 
>> review the discrepancies in the actual PDP and SIG guidelines, 
>> assuming that this will be brought back to the community, following 
>> the bottom-up-approach, but the next meeting (maximum).
>>
>> I still thing that this should not be a task done only by the 
>> EC/secretariat but instead a Taks Force should be setup. I hope the 
>> EC can still consider setting up this TF.
>>
>> As a result of the EC review or TF review the community should be 
>> able to decide how to move on, including, if needed, new policy 
>> proposals.
>>
>> Regards,
>> Jordi
>> @jordipalet
>>
>>
>>
>> El 24/2/20 3:57, "Bertrand Cherrier" 
>> > b.cherr...@micrologic.nc> escribió:
>>
>>  Dear colleagues
>>
>>  Version 2 of prop-134: PDP Update, did not reach consensus and 
>> was
>>  withdrawn by the author at the APNIC 49 Open Policy Meeting.
>>
>>  Proposal details, including the full text of the proposal, 
>> history, and
>>  links to previous versions are available at:
>>
>>  https://www.apnic.net/community/policy/proposals/prop-134/
>>
>>  We'd like to thank the author and everyone for taking the time 
>> to
>>  discuss this proposal.
>>
>>  Regards
>>  Sumon, Bertrand, Ching-Heng
>>  Policy SIG Chairs
>>  *  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
>>
>>
>>
>>
>> **
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> 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 proh

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Sunny,

I'm mainly interested in the assignments to ISP infrastructure, as the others 
are different cases, and clearly are "end-users". The point is to understand if 
there is really a need for ISPs to get additional assignments, why they can't 
do it already from their own allocation. 

Any indication of the tendency for those cases (assignments for ISP 
infrastructure), I mean if this was in an early stage and the is going up or 
going down?

What specific text of the policy or guidelines is "being" used to do that?

Regards,
Jordi
@jordipalet
 
 

El 26/2/20 4:18, "Srinivas Chendi"  escribió:

Hi Jordi,

On 24/02/2020 1:39 pm, Srinivas (Sunny) Chendi wrote:
>>
>> One more request for the secretariat. Could you please provide stats 
>> on the number of ISP (not end-users) assignments, for example in the 
>> last 12-15 years, in order to understand if this is a real requirement?
> 
> Noted! Secretariat will provide the stats soon.
> 
> Regards
> Sunny

To date we have delegated portable assignments to 547 ISPs. Some common 
reasons for this include:

- Assignment to operate IXP
- Historical Resource assignments
- M of members who held assignments
- Assignment for ISP infrastructure

Regards
Sunny




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Sunny, all,

Let me try to clarify.

2.2.3 mention "address space that is delegated to an LIR" ... "for specific use 
within the Internet infrastructure they operate". Let's put aside, for the 
moment, the end-user case.

If you read 9.2. Initial IPv6 allocations and 10.0. IPv6 assignments, there is 
not any explicit reference to assignments for an LIR.

We could interpret 10.1.4.1. Initial assignment "Organizations are eligible for 
an IPv6 Provider Independent delegation if they are able to demonstrate a valid 
reason that an assignment from their ISP, or LIR, is not suitable.", as if an 
ISP/LIR can't assign part of their own allocation to its own network, but it is 
really weird.

So, I'm wondering if this is valid case anymore, or it is one of those things 
that come from the original IPv6-policy, and was drafted due to lack of 
experience at that time. Do we have a case for that? In other RIRs, this has 
been already removed.

Regards,
Jordi
@jordipalet
 
 

El 24/2/20 4:39, "Srinivas Chendi"  escribió:

Hello Jordi,
    
On 22/02/2020 2:20 pm, JORDI PALET MARTINEZ wrote:
> Hi all,
> 
> After my previous response to Owen, I can't find anymore any the text in 
the actual policy (neither guidelines)  about assignments. So, I'm wondering if 
I was wrong, or it has been removed at some point and I don't recall it ... 
Could the secretariat point out to the specific text about that? If it has been 
removed, clearly there is a need to further update section 2.2.3 to remove that 
reference and avoid the mismatch.

You mean section 2.2.3 text? It is not removed. You can find it in the 
current policy manual here


https://www.apnic.net/community/policy/resources#2.2.3.-Assigned-address-space


> 
> One more request for the secretariat. Could you please provide stats on 
the number of ISP (not end-users) assignments, for example in the last 12-15 
years, in order to understand if this is a real requirement?

Noted! Secretariat will provide the stats soon.

Regards
Sunny

> 
> Anyone can provide examples of why an ISP could need and assignment 
instead of using their own allocation?
> 
> Thanks!
> 
> Regards,
> Jordi
> @jordipalet
>   
>   
> 
> 
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> 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
> 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-134: PDP Update withdrawn by author

[JORDI PALET MARTINEZ]

Hi Bertrand, all,

As indicated in the meeting, the withdraw of this proposal is "temporary", in 
view of the commitment from the EC/secretariat to review the discrepancies in 
the actual PDP and SIG guidelines, assuming that this will be brought back to 
the community, following the bottom-up-approach, but the next meeting (maximum).

I still thing that this should not be a task done only by the EC/secretariat 
but instead a Taks Force should be setup. I hope the EC can still consider 
setting up this TF.

As a result of the EC review or TF review the community should be able to 
decide how to move on, including, if needed, new policy proposals.

Regards,
Jordi
@jordipalet
 
 

El 24/2/20 3:57, "Bertrand Cherrier"  escribió:

Dear colleagues

Version 2 of prop-134: PDP Update, did not reach consensus and was 
withdrawn by the author at the APNIC 49 Open Policy Meeting.

Proposal details, including the full text of the proposal, history, and 
links to previous versions are available at:

https://www.apnic.net/community/policy/proposals/prop-134/

We'd like to thank the author and everyone for taking the time to 
discuss this proposal.

Regards
Sumon, Bertrand, Ching-Heng
Policy SIG Chairs
*  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




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Of course, no issue, thanks!

 

Safe flights for everyone!

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/2/20 12:21, "Sanjaya Sanjaya"  escribió:

 

Hi Jordi and all,

Will respond on Monday as we're currently recuperating from the APRICOT week :) 
Stay tuned.

Sanjaya 

Sent from my mobile. 

 

From: sig-policy-boun...@lists.apnic.net  
on behalf of JORDI PALET MARTINEZ 
Sent: Saturday, February 22, 2020 1:20:59 PM
To: mailman_SIG-policy 
Subject: Re: [sig-policy] prop-133: Clarification on Sub-Assignments 

 

Hi all,

After my previous response to Owen, I can't find anymore any the text in the 
actual policy (neither guidelines)  about assignments. So, I'm wondering if I 
was wrong, or it has been removed at some point and I don't recall it ... Could 
the secretariat point out to the specific text about that? If it has been 
removed, clearly there is a need to further update section 2.2.3 to remove that 
reference and avoid the mismatch.

One more request for the secretariat. Could you please provide stats on the 
number of ISP (not end-users) assignments, for example in the last 12-15 years, 
in order to understand if this is a real requirement?

Anyone can provide examples of why an ISP could need and assignment instead of 
using their own allocation?

Thanks!

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi all,

After my previous response to Owen, I can't find anymore any the text in the 
actual policy (neither guidelines)  about assignments. So, I'm wondering if I 
was wrong, or it has been removed at some point and I don't recall it ... Could 
the secretariat point out to the specific text about that? If it has been 
removed, clearly there is a need to further update section 2.2.3 to remove that 
reference and avoid the mismatch.

One more request for the secretariat. Could you please provide stats on the 
number of ISP (not end-users) assignments, for example in the last 12-15 years, 
in order to understand if this is a real requirement?

Anyone can provide examples of why an ISP could need and assignment instead of 
using their own allocation?

Thanks!

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Owen,

 

APNIC policy allows ISPs to get, in addition to the allocation, an assignment 
for their infrastructure.

 

I don’t think this is needed and I recall it doesn’t longer exist in other 
RIRs. May be is something else to consider and to amend as well.

 

The issue we are having, is that without inputs in the list, there is no way we 
can move on, otherwise, every 6 months, we fail again and again …

 

Regards,

Jordi

@jordipalet

 

 

 

El 22/2/20 10:30, "Owen DeLong"  escribió:

 

Assigned address space isn’t generally delegated to LIRs,… It’s generally 
delegated to end-users. Address space delegated to LIRs may then be reassigned 
by the LIR to itself for internal purposes.

 

Unless there’s a case where an LIR is receiving an assignment instead of an 
allocation, I think we can limit it to space that is delegated to an end-user 
by the RIR.

 

Owen

 



On Feb 20, 2020, at 20:20 , JORDI PALET MARTINEZ  
wrote:

 

Thanks Bertrand,

I’m fine as well with this option. Repeating it here:

"Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate and may not be sub-assigned".

Could the secretariat let us know if they still believe there is any text that 
is "unnecessarily duplicated" or if they could live with that?

Note that it seems that emails using DMARC still get wrong to the mailing list. 
It will be very important that the secretariat resolves that, otherwise, some 
participants are not getting emails from some of us (including me). So, no 
wonder that they don’t respond!

Regards,
Jordi
@jordipalet



El 21/2/20 15:14, "Bertrand Cherrier" 
<mailto:sig-policy-boun...@lists.apnic.net en nombre de 
mailto:b.cherr...@micrologic.nc> escribió:

Hello everyone,
Thank you Jordi for this revised prop.
How about this :

Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate and may not be sub-assigned.

It would be nice to have inputs from other members of the Policy SIG, 
especially from those who opposed this proposal.
Regards,
Cordialement,

Bertrand Cherrier
Administration Systèmes - R
Micro Logic Systems
mailto:b.cherr...@micrologic.nc
https://www.mls.nc
Tél : +687 24 99 24
VoIP : 65 24 99 24
SAV : +687 36 67 76 (58F/min)

On 21 Feb 2020, at 11:09, JORDI PALET MARTINEZ wrote:
Hi all,

As you know, we have decided to continue the discussion of this proposal in the 
mailing list.

I've been thinking in a possible way to keep the "documented purposes" text as 
some indicated in the mike.

So, what do you feel about these two choices:

Option a)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate.

Option b)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate and may not be sub-assigned to other networks.

My personal preference, and following the staff analysis in v2, will be option 
a, but just in case the community prefers to re-state "and may not be 
sub-assigned to other networks" (I believe, and also according to the staff 
inputs that "exclusive" is already indicating it).

Just as a reminder, the actual proposal (v2) is at:
https://www.apnic.net/wp-content/uploads/2020/02/prop-133-v002.txt

Regards,
Jordi
@jordipalet





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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
* sig-policy: APNIC SIG on resource management policy * 
___ sig-policy mailing list 
sig-

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Thanks Bertrand,

I’m fine as well with this option. Repeating it here:

"Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate and may not be sub-assigned".

Could the secretariat let us know if they still believe there is any text that 
is "unnecessarily duplicated" or if they could live with that?

Note that it seems that emails using DMARC still get wrong to the mailing list. 
It will be very important that the secretariat resolves that, otherwise, some 
participants are not getting emails from some of us (including me). So, no 
wonder that they don’t respond!

Regards,
Jordi
@jordipalet



El 21/2/20 15:14, "Bertrand Cherrier" 
<mailto:sig-policy-boun...@lists.apnic.net en nombre de 
mailto:b.cherr...@micrologic.nc> escribió:

Hello everyone,
Thank you Jordi for this revised prop.
How about this :

Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate and may not be sub-assigned.

It would be nice to have inputs from other members of the Policy SIG, 
especially from those who opposed this proposal.
Regards,
Cordialement,

Bertrand Cherrier
Administration Systèmes - R
Micro Logic Systems
mailto:b.cherr...@micrologic.nc
https://www.mls.nc
Tél : +687 24 99 24
VoIP : 65 24 99 24
SAV : +687 36 67 76 (58F/min)

On 21 Feb 2020, at 11:09, JORDI PALET MARTINEZ wrote:
Hi all,

As you know, we have decided to continue the discussion of this proposal in the 
mailing list.

I've been thinking in a possible way to keep the "documented purposes" text as 
some indicated in the mike.

So, what do you feel about these two choices:

Option a)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate.

Option b)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate and may not be sub-assigned to other networks.

My personal preference, and following the staff analysis in v2, will be option 
a, but just in case the community prefers to re-state "and may not be 
sub-assigned to other networks" (I believe, and also according to the staff 
inputs that "exclusive" is already indicating it).

Just as a reminder, the actual proposal (v2) is at:
https://www.apnic.net/wp-content/uploads/2020/02/prop-133-v002.txt

Regards,
Jordi
@jordipalet





**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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
* 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



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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] prop-133: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi all,

As you know, we have decided to continue the discussion of this proposal in the 
mailing list.

I've been thinking in a possible way to keep the "documented purposes" text as 
some indicated in the mike.

So, what do you feel about these two choices:

Option a)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate.

Option b)
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific, documented purposes and exclusive use within the 
infrastructure they operate and may not be sub-assigned to other networks.

My personal preference, and following the staff analysis in v2, will be option 
a, but just in case the community prefers to re-state "and may not be 
sub-assigned to other networks" (I believe, and also according to the staff 
inputs that "exclusive" is already indicating it).

Just as a reminder, the actual proposal (v2) is at:
https://www.apnic.net/wp-content/uploads/2020/02/prop-133-v002.txt

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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

Re: [sig-policy] New version - prop-134-v002: PDP Update

[JORDI PALET MARTINEZ]

Hi again ... see below ...

 

El 17/2/20 15:28, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum.

I would like to share key feedback in our community for prop-134,
based on a meeting we organised on 4th Feb to discuss these proposals.

We discussed this proposal dividing into 3 parts below.

1. Wording of "rough consensus"
Many opposing opinions were expressed.
 - Rough consensus seems something that almost attendees agrees, but
the consensus in OPM is a consensus that the chair decides based on
grounds, so the term rough consensus may be different.

[Jordi] If you follow the recent email exchange with Adam, I think it is clear 
that we are talking of the same (minor objections is consensus, major is not).

2. electronic means
Many opposing opinions were expressed about electronic means.
 - I support using the electronic system like a CONFER to gauge
support for a policy proposal, but oppose voting by using current
electronic system because of lack of identification.

[Jordi] We always have said that is not a voting. The proposal is not changing 
that! Never has been identified the people even in the meeting room, neither in 
the list or confer! The proposal is not changing that.

 - The specification is unclear about introducing an electronic
statement of intention.

[Jordi] Today we use confer. It was not used a few years ago. Tomorrow it can 
be a different tool to gauge the support. The PDP must have a language that, as 
much as possible, is self-adaptative to different tools. If we state "confer" 
and tomorrow the secretariat finds a better tool, we need to pass it thru the 
PDP. In fact, user confer today is *against* the PDP, because it is not 
explicitly supported. Even more than that, today following the PDP the few 
inputs in the list (including your emails), can't be formally considered as 
part of the consensus decision by the chairs. It makes sense to include that in 
the PDP.

 - It is necessary to use a means such as a registered name to avoid
the organized vote.

[Jordi] If we decide to use voting, and ask everyone in the meeting room to be 
also identified, they we should change our model. Otherwise, the same done in 
the meeting room should be done here. For example, if the NIRs are talking from 
the inputs provided by their own communities, should also the people 
partiticipating in the NIRs also be identified?


3. Expiring the proposal
Many supporting opinions were expressed about expiring the proposal.
In Japan, the same policy already make a consensus at last Japan Open
policy Meeting.

[Jordi] Just to make sure I got it correctly. You mean that you support this 
specific change as well?

Regards,
Satoru Tsurumaki / JPOPF Steering Team

2020年2月16日(日) 18:32 Bertrand Cherrier :
>
> Dear Chairs,
>
> Here is the draft email for new version of prop-134. Please review/edit
> and post to mailing list soon.
>
> Subject: prop-134-v002: PDP Update
>
> Thanks
> Sunny
>
> 
>
> Dear SIG members
>
> A new version of the proposal "prop-134-v002: PDP Update" has been sent
> to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-134
>
> You are encouraged to express your views on the proposal:
>
> - Do you support or oppose the proposal?
> - Is there anything in the proposal that is not clear?
> - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
> 
>
> prop-134-v002: PDP Update
>
> 
>
> Proposer: Jordi Palet Martínez
> jordi.pa...@theipv6company.com
>
> 1. Problem statement
>
> The actual PDP doesn’t support the usage of electronic means to
> “measure” the consensus.
> However, “Confer” is being used. This should be clarified, or otherwise
> the process is not
> fair (remote participants don’t know about it reading the PDP) and can
> be considered a
> violation of the PDP itself.
>
> The PDP also don’t have a formal process to withdraw a proposal, and
> doesn’t force the authors
> to keep editing it according the community inputs, or otherwise, allow
> the SIG chairs to
> declared it as expired.
>
> Finally, as editorial change, the expression “rough consensus” (RFC7282)
> is used instead of
> “general agreement”, so it is consistent with the actual practice.
>
> 2. Objective of policy change
>
> To resolve the issues above 

Re: [sig-policy] New version - prop-133-v002: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi again and responding below ...

 

El 17/2/20 15:24, "Tsurumaki, Satoru"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum.

I would like to share key feedback in our community for prop-133,
based on a meeting we organised on 4th Feb to discuss these proposals.

Many opposing opinions were expressed about this proposal.

(comment details)
 - In the discuss about previous proposal, prop-124, some opinions
were expressed as to who was in trouble and who needed to change, but
it seems that the proposer did not respond to these opinions in this
proposal.

[Jordi] I've responded to that, please review the videos of the previous SIG. 
We can't put all the discussions in the proposal text. In summary. The actual 
text talks about documented purposes. If an end-user organization asked APNIC 
for an IPv4 (not using NAT, as some universities still do) or IPv6 prefix for 
their own systems (documented purpose), and later on they decide to run a guest 
or employees WiFi, they are not anymore using the assigned space for the 
documented purpose. It is a new purpose in additional for the original 
documented one. I think it is clear that the intend of the original text was 
not to restrict this, but instead to restrict that this assignment is not 
provided to "external third parties". Which this simple clarification, we 
resolve the problem. Instead we have the case for many organizations, that may 
be breaking the rules.

 - IP addresses should be delegated on an as-needed basis, and if this
proposal is passed, there is concern that clarification of the
intended use at the time of acquisition will be lost.

[Jordi] Need basis is, in this case "I need space for my organization". Right 
now, if you strictly follow the policy and you said "I need space for my 
organization systems", you are violating the rules. It is a tiny difference, or 
it looks like that, but we should make sure that we follow the original intend, 
which was not to be so restrictive as "if you didn't over-specified every 
detail, now you're lost".

 - While it may be good to loosen the policy operationally, we oppose
easing the policy itself.

[Jordi] I'm not sure to understand this.

 - This proposal seems not to aim "Clarification" of Sub assignment.

[Jordi] For me it is a clarification if we look at the intend of the policy: it 
was not to be restrictive in "how you use the resources in your organization", 
the idea was "the resources are only for your organization". There is no need 
to "document every tiny detail" if we can just make sure that it is clear that 
"it is for your organization, not for providing to others".

Regards,
Satoru Tsurumaki / JPOPF Steering Team

2020年2月16日(日) 18:31 Bertrand Cherrier :
>
> Dear SIG members
>
> A new version of the proposal "prop-133-v002: Clarification on
> Sub-Assignments" has been sent to the Policy SIG for review.
>
> Information about earlier versions is available from:
>
> http://www.apnic.net/policy/proposals/prop-133
>
> You are encouraged to express your views on the proposal:
>
> Do you support or oppose the proposal?
> Is there anything in the proposal that is not clear?
> What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
    >
> 
>
> prop-133-v002: Clarification on Sub-Assignments
>
> 
>
> Proposer: Jordi Palet Martinez
> jordi.pa...@theipv6company.com
>
> 1. Problem statement
>
> Note that this proposal is ONLY relevant when end-users obtain direct
> assignments from APNIC,
> or when a LIR obtains, also from APNIC, and assignment for exclusive use
> within its infrastructure.
> Consequently, this is NOT relevant in case of LIR allocations.
>
> The intended goal of assignments is for usage by end-users or LIRs in
> their own infrastructure (servers,
> equipment, interconnections, employees, guest devices, subcontractors,
> only within that infrastructure),
> not for sub-assignment in other networks.
>
> The current text uses a “must” together with “documented purposes”. As a
> consequence, if there is a request
> with a documented purpose, and in the future the assigned space is used
> for some other purposes, it will
> violate the policy.
>
> For example, a university may docum

Re: [sig-policy] prop-130-v002: Secretariat impact assessment

[JORDI PALET MARTINEZ]

s 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 available at:
> > http://www.apnic.net/policy/proposals/prop-130
> >
> > Regards
> >
> > Sumon, Bertrand, Ching-Heng
> > APNIC Policy SIG Chairs
> >
> > 
> >
> > prop-130-v002: Modification of transfer policies
> >
> > 
> >
> > Proposer: Jordi Palet Martinez
> > jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com>
> >
> >
> > 1. Problem statement
> >
> > Existing transfer policies for IPv4, IPv6 and ASN resources have some
> > differences
> > among what is allowed and what not, if in the case of intra-RIR and
> > inter-RIR, and
> > it is not clear if in case of merger and acquisitions it is referring to
> > a complete
> > company, part of it, or even if in case of a company reorganization or
> > relocation,
> > the policy is supportive to that case.
> >
> > In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> > policy or
> > procedure that allows it.
> >
> >
> > 2. Objective of policy change
> >
> > To ensure that the policy text is clarified, if those cases are
> > supported by the
> > community. It will also facilitate companies or business units, moving
> > or being established
> > in other regions.
> >
> >
> > 3. Situation in other regions
> >
> > There is a variety of support of all those cases in different regions.
> > The one more open is
> > RIPE, followed by ARIN. Similar policy proposals are being submitted in
> > LACNIC and AFRINIC.
> >
> >
> > 4. Proposed policy solution
> >
> > Actual Text
> > 8.4. Mergers & acquisitions
> >
> > APNIC will process and record the transfer of IPv4 resources as the
> > result of merger or acquisition.
> >
> > 11.0. Transfer of IPv6 resources
> >
> > APNIC will only recognize the transfer or IPv6 addresses as the result
> > of Merger & Acquisition activity.
> > The following conditions and consequences apply.
> >
> > 13.3. Mergers & acquisitions
> >
> > APNIC will recognize the transfer of ASNs as the result of merger or
> > acquisition.
> >
> > Proposed Text
> > 8.4. Mergers, acquisitions and relocations
> >
> > APNIC will process and record the transfer of IPv4 resources as the
> > result of a partial or complete merger,
> > acquisition, reorganization or relocation, in both cases, intra-RIR and
> > inter-RIR.
> >
> > In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> > policy/procedure that allows it.
> >
> > 11.0. Transfer of IPv6 resources
> >
> > APNIC will only recognize the transfer or IPv6 addresses as the result
> > of a partial or complete merger,
> > acquisition, reorganization or relocation activity, in both cases,
> > intra-RIR and inter-RIR. The following
> > conditions and consequences apply.
> >
> > In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> > policy/procedure that allows it.
> >
> > 13.3. Mergers, acquisitions and relocations
> >
> > APNIC will recognize the transfer of ASNs as the result of a partial or
> > complete merger, acquisition,
> > reorganization or relocation activity, in both cases, intra-RIR and
> > inter-RIR.
> >
> > In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> > policy/procedure that allows it.
> >
> >
> > 5. Advantages / Disadvantages
> >
> > Advantage

Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Adam,

 

(thanks a lot, very good inputs!)

 

 

El 18/2/20 13:19, "Adam Gosling"  escribió:

 

Hi Jordi

 

Sorry, but I have a very close knowledge of these documents. They are not 
perfect (or even good). Everybody may not always understand them, or apply 
them. That is why I want to make sure people understand what it is they are 
changing from and what they are changing to.

 

-> I see your point, and fully agree. However, I think jugging a policy because 
the title says clarification may bring to wrong assumptions, depending on who 
reads that. I think it is clear that it depends on the perspective. And I can 
ensure that my point was not to convince anyone that this is minor change or 
anything like that, but saying that the guidelines are part of the PDP is also 
wrong, so the PDP doesn’t have a formal definition of “general agreement”.



On 17 Feb 2020, at 1:30 pm, JORDI PALET MARTINEZ  
wrote:

 

Hi Adam,

 

-> The first problem we have here is that those guidelines were developed long 
time ago (2 decades or so), when we had many SIGs, and they were developed by 
the SIG chairs, not the community. The 2nd issue is that the PDP doesn’t 
mention anything about the guidelines.

 

Then propose that we add a reference to the Guidelines into the PDP. We can 
easily reach consensus and move on.

 

-> I don’t think is that easy. Does the community agree that the guidelines are 
valid? It is a much more complicated task than a single reference.

 

This is not a mere editorial comment, it requires the community to accept those 
guidelines in a modification (thru a policy proposal) of the PDP. The third 
problem is that the PDP talks about “general agreement”, while the guidelines 
talks about “consensus”. It is a matter of English wording? I don’t know, but 
making it clear is good for everyone. Otherwise a newcomer will not see in the 
meeting that we are following our own process (because we aren’t!).

-> If I recall correctly, when asked at least one of the co-chairs about what 
they recognize as consensus, and I believe is the way they explain at the 
beginning of each Policy SIG, they use the rough consensus definition and I’m 
almost sure they even mention the IETF RFC.

 

The only reference Google finds to RFC7282 on the www.apnic.net or 
conference.apnic.net site is your presentation 

https://www.google.com.au/search?q=site:www.apnic.net+rfc7282=1=gTxLXuOENLuX4-EPpp-I8Ac

 

I checked the slides presented at the beginning of APNIC 46 and 47. These 
explain Consensus = ‘general agreement’ and the concept of Minor and Major 
Objections. They also provide the URL for the PDP and SIG Guidelines.

 

Anybody that says APNIC Policy runs on ‘rough consensus’ has made an assumption 
or is using the phrase to make it easier for you to understand to idea of 
'general agreement'.

 

 

 

The RFC is similar, but fundamentally different. Changing this in the PDP is 
not just a word tweak. It would result in a different approach from the Chairs 
and participants. There is no concept of “Minor” and “Major” objections in RFC 
7282, for example.

-> The RFC doesn’t provide the “operational” details, it is an informational 
document, so nothing precludes the co-chairs for their assessment to still make 
some “classification”, but again,  the guidelines aren’t part of the PDP, 
unless we change it. I think they key here, and again, I believe is the 
understanding of the chairs, if I got it correctly, we aren’t counting hands or 
votes, but instead we declare consensus “when all the issues are addressed, but 
not necessarily accommodated”, which is the “short” description of the RFC.

 

My reading of the Guidelines and the practice I have noticed from past Chairs 
is that Minor Objections can be 'addressed but not necessarily accommodated'. 
For Major Objections the guidelines say "When this happens, the Chair should 
encourage the proponent and the community to continue discussion and develop a 
more widely accepted proposal to be presented at the following meeting.” 

 

-> And this is rough consensus. So, there is consensus when there are minor 
objections. If there are major objections, then we need to continue the 
discussion and possibly have a new version: no consensus. I don’t see the 
difference with RFC7282.

 

I’m not saying that it is bad to change. I am just saying that we should be 
aware of what change we are making.

 


If there is no consensus on a proposal, the authors can decide to
withdraw it.

 

This removes discretion from the Chair (and the SIG), to abandon a proposal if 
an Author repeatedly persists with the same unpopular idea. I think that’s 
interesting and worth discussing if that’s what we want.

 

 

-> Which I think is wrong. It is inappropriate (in my opinion) that (and it may 
be again an English understanding) chairs can “abandon” on behalf of the 
authors (I will understand “force withdrawal”). If there is an unpopular

Re: [sig-policy] Criteria of resubmission the proposal

[JORDI PALET MARTINEZ]

Hi Sumon, Satoru-San, all,

 

Let me also provide my point of view on this:
If you look at the videos of the previous presentations, there were some people 
in support of those policies. In fact, I used the videos and all the inputs (as 
in the list, unfortunatelly, basically there were only inputs from yourself). 
In fact, for the sub-assigment clarification, the proposal advanced from the 2 
previous APNIC meetings thanks to the inputs from our colleagues from India. 
And again, from the inputs from Aftab, it advanced once more to the actual 
version, highly simplified.
I’ve said this before. The PDP doesn’t state anything about if the chairs can 
“abandon” a policy proposal. In fact, this may be not the right term. I read 
abandon as “I abandon”, not somebody “abandon for me”, which will be “force 
abandon” or something-like. I understand that the chairs are following 
guidelines, that were developed by the existing chairs but not the community, 2 
decades ago, in the scope of many SIGs. The PDP and all related to the PDP is 
developed by the community as a whole, not a subset of. Furthermore, the PDP 
doesn’t have *ANY* link, decided by  the community, to the guidelines. We 
should update this. Just consider how negative/surprising is for anyone 
(specially newcommers), to read the PDP and then see that “something else is 
behind the PDP”.
We have seen this lots of times. A proposal doesn’t reach consensus the 1st 
time. Because there are no inputs in the list, in can’t get improved with the 
community inputs. It doesn’t passes the 2nd time, but it reach consensus the 
3rd time. Another proposal takes 5 rounds. Another proposal reach consensus on 
the 1st round. Another proposal fails during 2 rounds, but then after 1 year of 
pause, it comes back and reach consensus. This is *normal* and it should be 
like that. Different proposals need more or less discussion, more or less 
inputs, if the inputs don’t come in the list, then it takes more cyles. How you 
put the limit in the number of times it can come back before it gets “abandon” 
? You can’t. If the authors are getting the inputs, you should allow them to 
continue. It is a different case, if the authors ignore the inputs from the 
community. If you have 3 inputs *only* (just an example) 2 against – 1 in 
favour, this is not sufficient to say “abandon”. PDP is a slow process because 
it looks for consensus. This is completely normal. If authors don’t follow the 
community inputs and there are newer proposals or more important ones, the 
chairs have the way to de-prioritize them to the last part of the agenda, in 
case there is no sufficient time. Why “abandon” after 3 times, and not 2, or 5? 
It is impossible to decide upfront, each proposal has different complexity and 
may take more or less time. I’ve seen proposals that take 3 years to reach 
consensus (and they reached it), it is just fine! Other proposals didn’t reach 
consensus the first time and it was obvious, even for the authors that there is 
no point to continue. But even if there is a small fraction of the community 
that was supporting a proposal, I don’t see the point to abandon it after “n” 
times.
 

Besides those specific proposals, I think this discussion is very important and 
interesting to have.

 

Regards,

Jordi

@jordipalet

 

 

 

El 18/2/20 11:44, "Sumon Ahmed Sabir"  escribió:

 

Dear Satoru-San and all,

 

Thank you very much for sharing your feedbacks  and raising your concerns.

 

I do agree that the concern is valid and it may repeat similar discussions and 
we will be discussing similar issues.

 

>From SIG Chair Point of view, we have abandoned the earlier proposals as it 
>didn't reached consensus in three consecutive meetings and there were merely 
>any support for the proposal.

 

You are correct that if a proposal is abandoned then there will be no further 
discussions about the proposals.

 

But if proposer feels that it is important for community and needed to be 
discussed again and comes with a new proposal, as Policy Chair, it is our duty 
to accommodate that as long as it falls under PDP guidelines. 

 

And lastly it does not happen very often. So let us see how APNIC Community 
think about the proposal in next three days.

 

best regards,

 

Sumon Ahmed Sabir

Chair, Policy SIG

 

 

 

 

 

 

 

On Mon, Feb 17, 2020 at 3:13 PM Tsurumaki, Satoru  wrote:

Dear SIG Chair and all,

I am Satoru Tsurumaki from Japan Open Policy Forum.

I would like to share key feedback in our community for criteria for
adopting the proposal based on a meeting we organised on 4th Feb.

First of all, it should be pointed out that there is no intention to
limit the proposals where the problem statement or proposal has
changed.

Japanese community concerned that it might repeated similar
discussions if the resubmission of a proposal that was previously
abandoned.

My understanding is that "abandon" is a proposal that chair has
decided that no further discussions 

Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Adam,

 

By the way, thanks a lot for all the inputs, just sorry that we only get them 
from one person and they are so late. If we can get discussions more time ahead 
the meetings, we can get much better text, for sure!

 

Below, in-line.

 

El 17/2/20 11:55, "Adam Gosling"  escribió:

 

Hi Jordi 

My comments are inline

 

 

New version:

Step 2: Consensus Determination
Consensus is defined as “rough consensus” (RFC7282) as observed by the Chairs.

 

You are making a significant change, but presenting it as a “clarification”. 

 

-> Again, for me, in my native language, this is clarifying the situation. I 
don’t think it makes sense to discuss that, otherwise, we turn each proposal 
into a language discussion, which in turn, it will be differently understood by 
every non-native English speaker. The relevant thing here is what we actually 
do in the process and adapt the text to it, otherwise, we aren’t following our 
own PDP (our own rules).

It is okay to consider adoption of IETF definitions of “rough consensus” to use 
in the APNIC Policy Process, but this is not a clarification. To be clear, the 
SIG doesn’t currently use the “rough consensus” model in RFC 7282. It uses the 
consensus model in the APNIC SIG Guidelines. 
https://www.apnic.net/community/participate/sigs/sig-guidelines/#steps

-> The first problem we have here is that those guidelines were developed long 
time ago (2 decades or so), when we had many SIGs, and they were developed by 
the SIG chairs, not the community. The 2nd issue is that the PDP doesn’t 
mention anything about the guidelines. This is not a mere editorial comment, it 
requires the community to accept those guidelines in a modification (thru a 
policy proposal) of the PDP. The third problem is that the PDP talks about 
“general agreement”, while the guidelines talks about “consensus”. It is a 
matter of English wording? I don’t know, but making it clear is good for 
everyone. Otherwise a newcomer will not see in the meeting that we are 
following our own process (because we aren’t!).

-> If I recall correctly, when asked at least one of the co-chairs about what 
they recognize as consensus, and I believe is the way they explain at the 
beginning of each Policy SIG, they use the rough consensus definition and I’m 
almost sure they even mention the IETF RFC.

 

 

The RFC is similar, but fundamentally different. Changing this in the PDP is 
not just a word tweak. It would result in a different approach from the Chairs 
and participants. There is no concept of “Minor” and “Major” objections in RFC 
7282, for example.

-> The RFC doesn’t provide the “operational” details, it is an informational 
document, so nothing precludes the co-chairs for their assessment to still make 
some “classification”, but again,  the guidelines aren’t part of the PDP, 
unless we change it. I think they key here, and again, I believe is the 
understanding of the chairs, if I got it correctly, we aren’t counting hands or 
votes, but instead we declare consensus “when all the issues are addressed, but 
not necessarily accommodated”, which is the “short” description of the RFC.

 

Consensus is determined first considering the SIG mailing list, other 
electronic means, and the SIG session, and afterwards at the Member Meeting.

 

I’m supportive of the spirit of this change.

It’s a bit late in the day to be proposing changes, but I would have written: 

“The Chair(s) assess if the SIG has reached consensus on a proposal by 
considering discussions both on the mailing list and at the Open Policy (Policy 
SIG) Meeting. The Chair(s) may use measurement techniques to take the 
temperature of the room. Consensus must be reached first at the SIG session and 
afterwards at the Member Meeting for the process to continue."

-> I think is not late if we get some other inputs in the list … people 
supporting this one? I’m fine either way. For me the shorter version works 
fine, but again, there may be tiny English language details … What about (also 
reading your next paragraph and assuming that it is the Executive Council 
Chair, but this is easy to change in the final text if we send a new version 
and my recall or the actual situation is wrong):

“The Chair(s) assess if a proposal has reached consensus by considering 
discussions both on the mailing list, other electronics means and at the SIG 
Meeting. Consensus must be afterwards sustained at the Member Meeting for the 
process to continue, as observed by the Executive Council Chair.”

-> Note that my wording allows changing/evolving the (electronic) tools without 
requiring a PDP change (even incorporating several to facilitate the 
participation increase), and then there is no need to explicitly say that the 
tools are used for “measuring”, because that’s part of the consensus process. 
Also use SIG because this PDP seems to apply to policies developed by other 
SIGs, right? (if this is not currently the case).

I think retaining the 

Re: [sig-policy] prop-133-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

, each time we make a change (on the justification 
requirements), we will be affecting it. In this concrete proposal, we aren’t, 
as explained before, changed the original intent. The original intent was not 
“give me an exact description of how are you using each of the IPv6 addresses 
in the /48 PI that you will receive”, but instead “this is only for you within 
your network, NOT for sub-assignment to other parties in other networks”.

Regards,

Adam

 


Please, update the version number of this proposal with this change, which I 
guess it clears your impact assesment as well.

Regards,
Jordi
@jordipalet



El 14/2/20 14:48, "Srinivas Chendi"  escribió:

   Dear SIG members,

   Here is the Secretariat impact assessment for proposal “prop-133-v001: 
   Clarification on Sub-Assignments” and the same is also published at:

https://www.apnic.net/community/policy/proposals/prop-133/

   Staff comments
   --

   This proposal appears to be straightforward. APNIC notes the expansion 
   policy text to elaborate on IPv6 assignment, and it is unlikely to 
   change current practices for evaluating IPv6 requests.

   The proposed text “and may not be sub-assigned to other networks.” is 
   redundant as assigned address space cannot be sub-assigned to other 
   networks.


   Technical comments
   --

   No comments.


   Legal comments
   --

   No comments.


   Implementation
   --

   within 3 months.


   Regards
   Sunny


   On 20/01/2020 10:18 am, Bertrand Cherrier wrote:


Dear SIG members

The proposal "prop-133-v001: Clarification on Sub-Assignments" has been
sent to the Policy SIG for review.

(This is a new version of "prop-124" proposal abandoned after APNIC 48
as it did not reach consensus at APNIC 46, APNIC 47, and APNIC 48.)

It will be presented during the Open Policy Meeting at APNIC 49 in
Melbourne, Australia on Thursday, 20 February 2020.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. 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 available at:
http://www.apnic.net/policy/proposals/prop-133

Regards

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs



prop-133-v001: Clarification on Sub-Assignments

--------

Proposer: Jordi Palet Martinez
jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com>


   1. Problem statement

Note that this proposal is ONLY relevant when end-users obtain direct
assignments from APNIC, or when a LIR obtains, also from APNIC, and 
assignment
for exclusive use within its infrastructure.
Consequently, this is NOT relevant in case of LIR allocations.

The intended goal of assignments is for usage by end-users or LIRs in
their own infrastructure (servers, equipment, interconnections, employees,
guest devices, subcontractors, only within that infrastructure),
not for sub-assignment in other networks.

The current text uses a “must” together with “documented purposes”. As a
consequence, if there is a request with a documented purpose, and in the
future the assigned space is used for some other purposes, it will
violate the policy.

For example, a university may document in the request, that the assigned
addressing space will be used for their own network devices and serves, but
afterwards they also sub-assign to the students in the campus
(still same infrastructure). This last purpose was not documented, so it
will fall out of the policy.


   2. Objective of policy change

Clarification of the text, by rewording it.


   3. Situation in other regions

This situation, has already been corrected in AFRINIC, ARIN, LACNIC and
RIPE.


   4. Proposed policy solution

Actual text:
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user, for specific use within the Internet infrastructure they operate.
Assignments must only be made for specific, documented purposes and may not
be sub-assigned.

Proposed text:
2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user, for exclusive use within the infrastructure they operate, and may
not be sub-assigned to other networks.


   5. Advantages / Disadvantages

Advantages:
Advantages of the proposal:
Fulfilling the objective above ind

Re: [sig-policy] prop-130-v002: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Adam,

 

I’m not native english speaker either, and probably, because I learnt it by 
myself, have a lot of deficiences.

 

All the policies may have implementation issues. I don’t think this is a 
problem at all, just increase the implementation time, that’s just fine, and 
this was my response to that.

 

The policy doesn’t pretend to be an Inter-RIR IPv6 transfer. The policy 
recognize that if there is an M (which are happening every other day),  where 
several type of resources are involved, it should be possible to get a solution 
for all them. It will not make sense to do an M for IPv4 only, when we try to 
move to IPv6. It is an incredible innecesary ban to ask a corporation that 
acquired another (or part of it) “renumber”, if for example, they are just 
moving the VMs from one datacenter in Amsterdam to a data center in Brisbane 
(or the other way around). Because with VMs you just need to resync them, and 
once done, get activated in the new location and deactivated in the old one.

 

I can’t believe that anyone suggest that we can tell this organization: we 
allow you to do that for IPv4 but for IPv6, you need to renumber.

 

When I said full implementation I mean that the implementation involving 
several RIRs can be finished, let’s say in 6 months for APNIC, RIPE may take 
just 4, and maybe LACNIC needs 8. It is just an example. Consequently, after 
APNIC finish the implementation, if there in an M case APNIC-RIPE, it will be 
possible, but may be a case APNIC-LACNIC needs to wait for 2 additional months 
to be completed (at least using “automation” between the systems of both RIRs).

 

Regards,

Jordi

@jordipalet

 

 

 

El 17/2/20 11:54, "Adam Gosling"  escribió:

 

Hi Jordi

Please stop saying you are “clarifying” policy text when you are actually 
changing policy. People with English as a second language may misunderstand 
what is happening.

I’m supportive of more specific language in the M policy, but this is 
basically an inter-RIR IPv6 transfer policy.

I do not support this policy proposal because I doubt there are sufficient 
legitimate use cases to justify the significant implementation burden, 
technical issues, and legal work this would create for the Secretariat(s). 

Your response to the assessment provided by Sunny doesn’t address the technical 
implementation issues. When the Secretariat tells you that it is a 6-month 
timeframe it is because it is complex and expensive to do. Simply saying you 
understand the implementation issues for APNIC and other RIRs doesn’t change 
this. It should mean that you have to work hard to demonstrate there is a 
community need for the change. Also, I’m not sure what you mean by “full” 
implementation. You can’t have a half implemented Policy.

In my opinion, you haven’t provided sufficient justification for this change in 
policy and I think it’s a bad idea for a host of reasons.

My recommendation is that the Secretariat editorially “clarify” Sections 8.4, 
11.0, and 13.3 to explicitly say "APNIC will only recognize the intra-RIR 
transfer of…."

Regards,

Adam

 



On 16 Feb 2020, at 11:55 am, JORDI PALET MARTINEZ  
wrote:

 

Hi Sunny, all,

I understand that your assesment for this proposal is only informational inputs 
and not suggesting any text changes, in the sense that:

1) The M from/to other regions will need to be verified by the counter-party 
RIR. I expect that this is part of the operational procedure, and I suggest to 
use the same as you actually have for Inter-RIR transfers, may be requiring 
slight modifications. However, I don't think it is relevant to include that in 
the policy text, and instead should be fully managed by the staff.

2) I fully understand that there are implementation implications, not only in 
APNIC systems, but also in couter-party RIRs, and the "full" implementation 
will depend on all that.

Let me know if otherwise you think "anything" should be added/clarified in the 
policy proposal.

Regards,
Jordi
@jordipalet



El 14/2/20 14:49, "Srinivas Chendi"  escribió:

   Dear SIG members,

   Here is the Secretariat impact assessment for proposal “prop-130-v002: 
   Modification of transfer policies” and the same is also published at:

https://www.apnic.net/community/policy/proposals/prop-130/

   Staff comments
   --

   Possible difficulties in verifying mergers, acquisition, reorganization, 
   or relocation from out of APNIC region due to unfamiliarity of languages 
   and legal systems.

   The NRO comparative policy matrix indicates APNIC Members outside of the 
   region must have network presence in the Asia Pacific. Additionally, 
   some RIRs have an ‘out of region’ policy which restricts where they can 
   use their resources.

   Members may face difficulties updating their domain objects if there has 
   been a partial IPv6 transfer where a larger block has been de-aggregated.


   Technical comments

Re: [sig-policy] prop-130-v002: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I understand that your assesment for this proposal is only informational inputs 
and not suggesting any text changes, in the sense that:

1) The M from/to other regions will need to be verified by the counter-party 
RIR. I expect that this is part of the operational procedure, and I suggest to 
use the same as you actually have for Inter-RIR transfers, may be requiring 
slight modifications. However, I don't think it is relevant to include that in 
the policy text, and instead should be fully managed by the staff.

2) I fully understand that there are implementation implications, not only in 
APNIC systems, but also in couter-party RIRs, and the "full" implementation 
will depend on all that.

Let me know if otherwise you think "anything" should be added/clarified in the 
policy proposal.

Regards,
Jordi
@jordipalet
 
 

El 14/2/20 14:49, "Srinivas Chendi"  escribió:

Dear SIG members,

Here is the Secretariat impact assessment for proposal “prop-130-v002: 
Modification of transfer policies” and the same is also published at:

 https://www.apnic.net/community/policy/proposals/prop-130/

Staff comments
--

Possible difficulties in verifying mergers, acquisition, reorganization, 
or relocation from out of APNIC region due to unfamiliarity of languages 
and legal systems.

The NRO comparative policy matrix indicates APNIC Members outside of the 
region must have network presence in the Asia Pacific. Additionally, 
some RIRs have an ‘out of region’ policy which restricts where they can 
use their resources.

Members may face difficulties updating their domain objects if there has 
been a partial IPv6 transfer where a larger block has been de-aggregated.


Technical comments
--

APNIC’s current systems are not configured to handle inter-RIR IPv6 
reverse DNS. This will need to be developed.

APNIC cannot predict when other RIRs will support IPv6 reverse DNS 
fragments incoming to their systems.


Legal comments
--

This will affect how APNIC verifies M documents. May require cross RIR 
coordination.


Implementation
--

6 months


Regards
Sunny


On 20/01/2020 10:16 am, Bertrand Cherrier wrote:
> Dear SIG members,
> 
> A new version of the proposal "prop-130: Modification of transfer 
policies"
> has been sent to the Policy SIG for review.
> 
> It will be presented during the Open Policy Meeting at APNIC 49 in
> Melbourne,
> Australia on Thursday, 20 February 2020.
> 
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
> 
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. 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 available at:
> http://www.apnic.net/policy/proposals/prop-130
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> 
> prop-130-v002: Modification of transfer policies
> 
> 
> 
> Proposer: Jordi Palet Martinez
> jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com>
> 
> 
> 1. Problem statement
> 
> Existing transfer policies for IPv4, IPv6 and ASN resources have some
> differences
> among what is allowed and what not, if in the case of intra-RIR and
> inter-RIR, and
> it is not clear if in case of merger and acquisitions it is referring to
> a complete
> company, part of it, or even if in case of a company reorganization or
> relocation,
> the policy is supportive to that case.
> 
> In the case of inter-RIR, the counterpart RIR need to have a reciprocal
> policy or
> procedure that allows it.
> 
> 
> 2. Objective of policy change
> 
> To ensure that the policy text is clarified, if those cases are
> supported by the
> community. It will also

Re: [sig-policy] prop-134-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I agree that we can improve this adding an explicit reference to the RFC7282, 
and making clear that the policy expires if not updated by the next OPM, so we 
don't depend on exact 6-months period, which not necessary will match from 
meeting to meeting.

So, I think we should make a new version using the following text changes:

Previous version:

Step 2: Consensus Determination
Consensus is defined as “rough consensus” as observed by the Chairs.

Consensus is determined first considering the SIG mailing list, other 
electronic means, and the SIG session, and afterwards at the Member Meeting.

If there is no consensus on a proposal, the authors can decide to
withdraw it.

Otherwise, the proposal will expire in six months, unless a new version
is provided, restarting the discussions with the community.


New version:

Step 2: Consensus Determination
Consensus is defined as “rough consensus” (RFC7282) as observed by the Chairs.

Consensus is determined first considering the SIG mailing list, other 
electronic means, and the SIG session, and afterwards at the Member Meeting.

If there is no consensus on a proposal, the authors can decide to
withdraw it.

Otherwise, the proposal will be considered as expired by the next OPM, unless a 
new version
is provided, restarting the discussions with the community.


Please, update the version number of this proposal with these changes, which I 
guess clears your impact assessment as well.

Regards,
Jordi
@jordipalet
 
 

El 14/2/20 14:47, "Srinivas Chendi"  escribió:

Dear SIG members,

Here is the Secretariat impact assessment for proposal “prop-134-v001: 
PDP Update” and the same is also published at:

 https://www.apnic.net/community/policy/proposals/prop-134/

Staff comments
--

No foreseen change on APNIC Services procedures or systems as a result 
of this policy proposal.

For reference and definition of “Rough Consensus” suggest adding RFC 
7282 to the proposed text.

It is difficult to keep track of proposals “expire in six months” may be 
change to “expire at the next OPM”.


Technical comments
--

No comments.


Legal comments
--

Given that rough consensus is defined under RFC 7282 - no further comments.


Implementation
--

within 3 months.


Regards
Sunny


On 20/01/2020 10:23 am, Bertrand Cherrier wrote:
> Dear SIG members
> 
> The proposal "prop-134-v001: PDP Update" has been sent to the Policy SIG 
> for review.
> 
> (This is a new version of "prop-126" proposal abandoned after APNIC 48 
> as it did not reach consensus at APNIC 46, APNIC 47, and APNIC 48.)
> 
> It will be presented during the Open Policy Meeting at APNIC 49 in 
> Melbourne, Australia on Thursday, 20 February 2020.
> 
> We invite you to review and comment on the proposal on the mailing list 
> before the meeting.
> 
> The comment period on the mailing list before an APNIC meeting is an 
> important part of the policy development process. 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 available at:
> http://www.apnic.net/policy/proposals/prop-134
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> 
> prop-134-v001: PDP Update
> 
> 
> 
> Proposer: Jordi Palet Martínez
> jordi.pa...@theipv6company.com 
> 
> 
> 1. Problem statement
> 
> The actual PDP doesn’t support the usage of electronic means to 
> “measure” the consensus.
> However, “Confer” is being used. This should be clarified, or otherwise 
> the process is not fair (remote participants don’t know about it reading 
> the PDP) and can be considered a violation of the PDP itself.
> 
> The PDP also don’t have a formal process to withdraw a proposal, and 
> doesn’t force the authors to keep editing it according the community 
> inputs, or otherwise, allow the SIG chairs to declared it as expired.
> 
> Finally, as editorial change, the expression “rough consensus” (RFC7282) 
> is used instead of “general agreement”, so it is consistent with the 
> actual 

Re: [sig-policy] prop-133-v001: Secretariat impact assessment

[JORDI PALET MARTINEZ]

Hi Sunny, all,

I agree that we can improve this removing the redundant text (as I've added 
"exclusive" it is now clearly duplicating the meaning).

So, I think we should make a new version using this "shortened" text:

Actual:

2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user, for exclusive use within the infrastructure they operate, and may
not be sub-assigned to other networks.

New version:

2.2.3. Assigned address space
Assigned address space is address space that is delegated to an LIR, or
end-user, for exclusive use within the infrastructure they operate.

Please, update the version number of this proposal with this change, which I 
guess it clears your impact assesment as well.

Regards,
Jordi
@jordipalet
 
 

El 14/2/20 14:48, "Srinivas Chendi"  escribió:

Dear SIG members,

Here is the Secretariat impact assessment for proposal “prop-133-v001: 
Clarification on Sub-Assignments” and the same is also published at:

 https://www.apnic.net/community/policy/proposals/prop-133/

Staff comments
--

This proposal appears to be straightforward. APNIC notes the expansion 
policy text to elaborate on IPv6 assignment, and it is unlikely to 
change current practices for evaluating IPv6 requests.

The proposed text “and may not be sub-assigned to other networks.” is 
redundant as assigned address space cannot be sub-assigned to other 
networks.


Technical comments
--

No comments.


Legal comments
--

No comments.


Implementation
--

within 3 months.


Regards
Sunny


On 20/01/2020 10:18 am, Bertrand Cherrier wrote:
> Dear SIG members
> 
> The proposal "prop-133-v001: Clarification on Sub-Assignments" has been
> sent to the Policy SIG for review.
> 
> (This is a new version of "prop-124" proposal abandoned after APNIC 48
> as it did not reach consensus at APNIC 46, APNIC 47, and APNIC 48.)
> 
> It will be presented during the Open Policy Meeting at APNIC 49 in
> Melbourne, Australia on Thursday, 20 February 2020.
> 
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
> 
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. 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 available at:
> http://www.apnic.net/policy/proposals/prop-133
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> 
> prop-133-v001: Clarification on Sub-Assignments
> 
> 
> 
> Proposer: Jordi Palet Martinez
> jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com>
> 
> 
> 1. Problem statement
> 
> Note that this proposal is ONLY relevant when end-users obtain direct
> assignments from APNIC, or when a LIR obtains, also from APNIC, and 
> assignment
> for exclusive use within its infrastructure.
> Consequently, this is NOT relevant in case of LIR allocations.
> 
> The intended goal of assignments is for usage by end-users or LIRs in
> their own infrastructure (servers, equipment, interconnections, employees,
> guest devices, subcontractors, only within that infrastructure),
> not for sub-assignment in other networks.
> 
> The current text uses a “must” together with “documented purposes”. As a
> consequence, if there is a request with a documented purpose, and in the
> future the assigned space is used for some other purposes, it will
> violate the policy.
> 
> For example, a university may document in the request, that the assigned
> addressing space will be used for their own network devices and serves, 
but
> afterwards they also sub-assign to the students in the campus
> (still same infrastructure). This last purpose was not documented, so it
> will f

Re: [sig-policy] Call for Papers: 5th IEEE/IFP International Workshop on Analytics for Network and Service Management (AnNet 2020)

[JORDI PALET MARTINEZ]

I wonder if the policy mailing is appropriate for CfP and if there is an AUP 
that clearly indicate that.

We receive frequent CfP in this list, which doesn't happen in other RIRs and I 
guess the people sending them (which from time to time I recall is the same 
people), should be warned and if they don't stop, get their posting rights ban.

Regards,
Jordi
@jordipalet
 
 

El 26/11/19 3:26, "Sandrine VATON"  escribió:

[Sorry for multiple receptions]

===

5th IEEE/IFP International Workshop on Analytics for Network and Service 
Management (AnNet 2020)

In conjunction with the IEEE/IFP Network Operations and Management 
Symposium (NOMS 2020) in Budapest, Hungary, April 20-24, 2020

https://annet2020.loria.fr/

(Submissions due:  January 5, 2020)
===

The Fifth IEEE/IFIP International Workshop on Analytics for Network and 
Service Management (AnNet 2020) will be held in conjunction with the IEEE/IFIP 
Network Operations and Management Symposium (NOMS 2020) in Budapest, Hungary, 
April 20-24, 2020. 

Following the success of  its previous editions, AnNet aims to present 
research and experience results in the area of data analytics and machine 
learning for network and service management.  Approaches such as statistical 
analysis, data mining, and machine learning are promising mechanisms to harness 
the immense stream of operational data and to improve operations and management 
of IT systems and networks. 

AnNet 2020 will include original full-papers presentations, a keynote, and 
short-paper sessions. The workshop attendees will be stimulated to participate 
in interesting discussions. To this end, short papers describing late-breaking 
advances and work-in-progress reports from ongoing research and experimental 
work are also welcome.

---
Topics of Interest

Authors are invited to submit papers that fall into or are related to one 
or multiple topic areas listed below:

Data Analytics:
- Analysis, modeling and visualization
- Operational analytics and intelligence 
- Event and log analytics Big data analytics
- Network traffic analysis 
- Anomaly detection and prediction 
- Monitoring and measurements for management 
- Predictive and real-time analytics
- Harnessing social data for management

Machine Learning Techniques:
- Supervised, semi-supervised and unsupervised learning 
- Clustering and data mining 
- Reinforcement learning 
- Multi-agent based learning 
- Deep learning 
- Bayesian methods 
- Ensemble methods 
- Cognitive computing 
- Mining spatiotemporal and time series data

Network Management Paradigms:  
- Autonomous and autonomic networks
- Fog/edge computing
- In-network processing

- Bio-inspired networks self-management 
- Cognitive and software defined networks 
- Network function virtualization 
- Security, fault, performance and resource management

Application Domains:
- Computer Networks
- Mobile ad-hoc networks Wireless sensor networks 
- Clouds and data centers 
- Virtualized infrastructures
- Internet of Things 
- Computing and network services 
- IT service management, Storage resource management
---
Paper Submission

Paper submissions must present original, unpublished research or 
experiences. Only original papers that have not been published or
submitted for publication elsewhere can be submitted. Each submission must 
be written in English, accompanied by a 75 to 200 words abstract that clearly 
outlines the scope and contributions of the paper. There is a length limitation 
of 6 pages (including title, abstract, all figures, tables, and references) for 
regular papers, and 4 pages for short papers describing work in progress. 
Submissions must be in IEEE 2-column style. Self-plagiarized papers will be 
rejected without further review.

Authors should submit their papers via JEMS: 
https://jems.sbc.org.br/home.cgi?c=3497

Papers accepted for AnNet 2020 will be included in the conference 
proceedings, IEEE Xplore, IFIP database and EI Index. IFIP and IEEE reserve the 
right to remove any paper from the IFIP database and IEEE Xplore if the paper 
is not presented at the workshop. Awards will be presented to the best paper at 
the workshop.

---
Important Dates

- Paper Registration: December 29, 2019 
- Paper Submission Deadline: January 5, 2020 
- Acceptance Notification: January 26, 2020 
- Camera-Ready Papers: 

Re: [sig-policy] editorial clarification on prop-131

[JORDI PALET MARTINEZ]

No issue !

Thanks a lot!

Regards,
Jordi
@jordipalet
 
 

El 18/9/19 1:58, "Srinivas Chendi"  escribió:

Hi Jordi,

Apologies for the error. This is now corrected and published.

Regards
Sunny

On 12/09/2019 3:43 pm, JORDI PALET MARTINEZ wrote:
> Sorry, confusing myself (again).
> 
> The right wording in both places of the text is:
> 
> 5.2.4.3. Assignments shorter than a /48 to a single End Site
> 
> The problem was created when editing the text version, my "word" original 
version was ok.
> 
> Regards,
> Jordi
> @jordipalet
    >   
>   
> 
> El 12/9/19 12:34, "JORDI PALET MARTINEZ" 
 
escribió:
> 
>  Hi all,
>  
>  Following the suggestion in the mic during the today SIG session, in 
section 5.2.4.3. the new title is "Assignment of multiple /48s to a single end 
site", however in section 10.1.4.1. Initial assignment, is was using a 
reference to "5.2.4.3. Assignments shorter than a /48 to a single End-Site".
>  
>  Obviously, this is an editorial mistake, and the reference should be 
as well to the new title:
>  
>  "5.2.4.3. Assignment of multiple /48s to a single end site"
>  
>  Thanks!
>  
>  Regards,
>  Jordi
>  @jordipalet
>   
>   
>  
>  
>  
>  **
>  IPv4 is over
>  Are you ready for the new Internet ?
>  http://www.theipv6company.com
>  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
>  **
>  IPv4 is over
>  Are you ready for the new Internet ?
>  http://www.theipv6company.com
>  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 ?
> http://www.theipv6company.com
> 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.
> 
>

Re: [sig-policy] Version 4 of prop-126 PDP Update

[JORDI PALET MARTINEZ]

Hi Amrita,

 

Thanks a lot for your inputs!

 

I don’t think the policy can be changed without running thru the PDP. If some 
text is not sufficiently clear, if it is open to different interpretations it 
must be resolved.

 

It is not approriate, for example, to have a discrepancy on anyone reading the 
manual and the staff having a differente read on the same point. Take my 
example in my proposal for sub-assignment clarification. According to the staff 
a DC or an ISP must use an allocation for providing service to customers. 
However, if we consider the equipments connected as part of the infrastructure, 
anyone reading the same text will agree that it is possible to use an 
assignment as well. This is insane. In IPv4 is not a problem, but in IPv6 to 
make it possible you will provide a single IPv6 address to a complete customer 
network, or a single host that runs multiple VMs, which means, in turn, that 
you will need some kind of crazy non-standard NAT “function”.

 

Editorial changes are allowed to policy proposals, even after reaching 
consensus, but not once they become implemented, and consequently, once the 
text is already in the policy manual.

 

Regarding the 4 weeks period. I disagree. The current PDP text allows to have 
it variable, and I think that it must be a very clear and well defined time, so 
it is not possible to be “subjective” or “discriminate” among different policy 
proposal. All them should be treated the same. If a policy proposal in the 
“last-call” period is creating too much conflicting discussion (and specially 
on new aspect not discussed before), it definitively it should be interpreted 
as a sign for the chairs that the consensus is not clear, and probably instead 
of extending that period, should be send back to the list for a complete new 
discussion.

 

Regards,

Jordi

@jordipalet

 

 

 

El 12/9/19 13:03, "Amrita"  escribió:

 

Hi 

 

Had a few comments based on today’s presentation, during the Policy SIG meeting.

 

>From what I understood making information about policy more easily and readily 
>available does not need a policy change . It  just needs to have existing 
>information more readily and easily available .

 

Secondly, as shared by many people who commented, the four week input period is 
normally sufficient for most PDPs, therefore it does not need any change . 
Policy timelines are not set for exceptional situations, but for general 
situations. If a policy discussion takes more that 4 weeks , as clarified, the 
chairs can already extend it. Therefore, no changes need to be paid in the 
policy discussion timeline.

 

However, perhaps the community may want to work on setting up  a mechanism  for 
reviewing  policies that have been implemented. 

 

Regards

 

Amrita 

 

From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
Sent: Tuesday, September 10, 2019 4:57 AM
To: JORDI PALET MARTINEZ
Cc: Policy SIG
Subject: Re: [sig-policy] Version 4 of prop-126 PDP Update

 

I took the liberty of reformatting the message into a consistent font and size.

 




On Sep 9, 2019, at 02:41 , JORDI PALET MARTINEZ  
wrote:

 

Hi Owen,

 

 

El 27/8/19 8:15, "Owen DeLong"  escribió:

 

 





On Aug 26, 2019, at 03:05 , JORDI PALET MARTINEZ  
wrote:

 

Hi Javed,

 

I don’t agree, let me explain why.

 

The current process only talks about the meeting and the chairs have clearly 
indicated that they take in consideration the list and the confer. Anyone from 
the community that dislikes a consensus/non-consensus decision, could create a 
trouble even in courts, because we are accepting consensus from sources not 
documented in the PDP. Rewording it resolves the problem.

 

Furthermore, the current process has not an “in-process” appeal procces. This 
will be ilegal in may legislations (may be only the AU applies, but considering 
that the community is “the entire Internet”, may be this may be declared 
illegal in another country where a member decides to claim for). The only way 
(actually) to appeal, will be going to the courts. We should not aim to that. 
We should have an internal way.

 

While there is no appeal process, there are sufficient iterations of approval 
and ratification in the current process that I am not convinced an appeal 
process is necessary.

 

I don’t agree on that. If today chairs decide that something is out-of-scope, 
nobody has a way to change that decision. There is no way the community will be 
able to discuss the policy proposal as a “policy proposal”, because the chairs 
don’t accept it.

 

Is there any history of the chairs determining that something was out of scope 
erroneously? To the best of my knowledge, this is not the case in the APNIC 
region.

 


In the case of ARIN, there is a kind of appeal process with is the “petition 
process”. Here we don’t have that. And is the only region where we don’t have 
that.

 

Yes,

Re: [sig-policy] editorial clarification on prop-131

[JORDI PALET MARTINEZ]

Sorry, confusing myself (again).

The right wording in both places of the text is:

5.2.4.3. Assignments shorter than a /48 to a single End Site

The problem was created when editing the text version, my "word" original 
version was ok.

Regards,
Jordi
@jordipalet
 
 

El 12/9/19 12:34, "JORDI PALET MARTINEZ"  escribió:

Hi all,

Following the suggestion in the mic during the today SIG session, in 
section 5.2.4.3. the new title is "Assignment of multiple /48s to a single end 
site", however in section 10.1.4.1. Initial assignment, is was using a 
reference to "5.2.4.3. Assignments shorter than a /48 to a single End-Site".

Obviously, this is an editorial mistake, and the reference should be as 
well to the new title:

"5.2.4.3. Assignment of multiple /48s to a single end site"

Thanks!

Regards,
Jordi
@jordipalet
 
 



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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
**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 ?
http://www.theipv6company.com
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

Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy

[JORDI PALET MARTINEZ]

Hi Hiroki,

Just sent a response to this in the previous email.

Note this is only a minor editorial change in the policy proposal, the rest of 
the text is much more relevant than just this detail.

Regards,
Jordi
@jordipalet
 
 

El 6/9/19 15:45, "Hiroki Kawabata"  escribió:

Hi all,

We oppose this proposal. APNIC should always check references to documents
which written by other bodies, so we think that it should be kept to the 
minimum necessary.
If the goal is to simplify the policy document, how about putting it in a 
guideline document?

Regards,
Hiroki

---
Hiroki Kawabata
Japan Network Information Center(JPNIC)


Subject: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy
Date: Fri, 9 Aug 2019 15:59:08 +0600
From: Sumon Ahmed Sabir 

> Dear SIG members,
> 
> The proposal "prop-131-v001: Editorial changes in IPv6 Policy" has been
> sent to
> the Policy SIG for review.
> 
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
> 
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
> 
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. 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 available at:
> http://www.apnic.net/policy/proposals/prop-131
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> --
> 
> prop-131-v001: Editorial changes in IPv6 Policy
> 
> --
> 
> Proposer: Jordi Palet Martínez
> jordi.pa...@theipv6company.com
> 
> 
> 1. Problem Statement
> 
> 
> This proposal suggests multiple (mainly) editorial changes in the IPv6
> Policy.
> The intent is to remove non-necessary text, and simplify the policy.
> 
> Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is
> removed,
> as it is something obvious that operators need to assign some space for
> different
> parts of their own infrastructure.
> 
> Section 5.2.4.3. explicitly states that it was drafted at a time when
> there was no
> experience with IPv6 deployment, which is this is longer the case, it
> does not make
> sense to have NIR/RIR to evaluate each instance where an LIR has an End
> User whose
> end site(s) requires a shorter prefix than a /48.
> 
> Finally, section 10.1.4.1. is reworded, taking advantage of some of the
> editorial
> changes in the precedent sections, so to avoid duplicating text.
> 
> 
> 
> 2. Objective of policy change
> -
> 
> Fulfil the above indicated edits.
> 
> 
> 3. Situation in other regions
> -
> 
> A similar proposal has been submitted to RIPE.
> 
> 
> 4. Proposed policy solution
> ---
> 
> Current Text
> 5.2.4.2. Assignment address space size
> 
> ...
> 
> End-users are assigned an end site assignment from their LIR or ISP. The
> exact size of
> the assignment is a local decision for the LIR or ISP to make, using a
> minimum value of
> a /64 (when only one subnet is anticipated for the end site) up to the
> normal maximum of
> /48, except in cases of extra large end sites where a larger assignment
> can be justified.
> 
> ...
> 
> 
> New Text
> 5.2.4.2. Assignment address space size
> 
> ...
> 
> End Users are assigned an end site assignment from their LIR or ISP. The
> size of the
> assignment is a local decision for the LIR or ISP to make, using a value
> of "n" x /64.
> BCOP RIPE690 Section 4.2, provides guidelines about this.
> 
> ...
> 
> ==
> 
> Current Text
> 5.2.4.3. Assignment of multiple /48s to a single end site
> 
> When a single end site requires an additional /48 address block, it must
> request the
> assignment with documentation or materials that justify the request.
> Requests for multiple
> or 

Re: [sig-policy] prop-131-v001: Editorial changes in IPv6 Policy

[JORDI PALET MARTINEZ]

Hi Satoru, all,

I understand your point. I'm happy to remove the text "BCOP RIPE690 Section 
4.2, provides guidelines about this.". It was only a reference and mentioning 
it in the policy proposal introduction (which is not part of the policy text) 
is enought.

So I'm going to send an updated version in a minute, which this minor editorial 
change.

Anyway, note the this is not a "RIPE" document, it is a document that was 
written by people from 4 RIRs. We disseminated the document in all the regions 
during a couple of years before a formal publication, unfortunatelly didn't got 
responses from this region to incorporate as well a local author.

Regards,
Jordi
@jordipalet
 
 

El 2/9/19 17:39, "Satoru Tsurumaki"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-131, based
on a meeting we organized on 21th Aug to discuss these proposals.

Many participants expressed a opposing for the proposal with reasons
that the policy document should not refer the document(RIPE BCOP)
which was made and managed by out of our community and if the document
is unintentionally modified or obsolete, we cannot control it.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年8月9日(金) 18:59 Sumon Ahmed Sabir :

>
>
> Dear SIG members,
>
> The proposal "prop-131-v001: Editorial changes in IPv6 Policy" has been
> sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. 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 available at:
> http://www.apnic.net/policy/proposals/prop-131
>
> Regards
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
>
> prop-131-v001: Editorial changes in IPv6 Policy
>
> --
>
> Proposer: Jordi Palet Martínez
>jordi.pa...@theipv6company.com
>
>
> 1. Problem Statement
> 
>
> This proposal suggests multiple (mainly) editorial changes in the IPv6
> Policy.
> The intent is to remove non-necessary text, and simplify the policy.
>
> Section 5.2.4.2. is reworded to mention a RIPE BCOP, and 5.2.4.4. is
> removed,
> as it is something obvious that operators need to assign some space for
> different
> parts of their own infrastructure.
>
> Section 5.2.4.3. explicitly states that it was drafted at a time when
> there was no
> experience with IPv6 deployment, which is this is longer the case, it
> does not make
> sense to have NIR/RIR to evaluate each instance where an LIR has an End
> User whose
> end site(s) requires a shorter prefix than a /48.
>
> Finally, section 10.1.4.1. is reworded, taking advantage of some of the
> editorial
> changes in the precedent sections, so to avoid duplicating text.
>
>
>
> 2. Objective of policy change
> -
>
> Fulfil the above indicated edits.
>
>
> 3. Situation in other regions
> -
>
> A similar proposal has been submitted to RIPE.
>
>
> 4. Proposed policy solution
> ---
>
> Current Text
> 5.2.4.2. Assignment address space size
>
> ...
>
> End-users are assigned an end site assignment from their LIR or ISP. The
> exact size of
> the assignment is a local decision for the LIR or ISP to make, using a
> minimum value of
> a /64 (when only one subnet is anticipated for the end site) up to the
> normal maximum of
> /48, except in cases of extra large end sites where a larger assignment
> can be justified.
>
> ...
>
>
> New Text
> 5.2.4.2. Assignment address space size
>
> ...
>
> End Users are assigned an end site assignment from their LIR or ISP. The
> size of the
> assignment is a local decision 

Re: [sig-policy] Policy Proposal: prop-130-v001: Modification of transfer policies

[JORDI PALET MARTINEZ]

Hi Hiroki, all,

Thanks for your inputs, allow me to clarify below, in-line. 
 

El 6/9/19 16:25, "Hiroki Kawabata"  escribió:

Hi all,

About the part of IPv6, we oppose this. other parts are neutral.

We have to make efforts to aggrigate IPv6 routes and to maintain sparse 
allocation
mechanism. Since each registry has enough IPv6 prefix,
it is better to receive a new prefix from the registry, especially partial 
M case.

If I recall correctly, when I talked about this with the staff, they confirmed 
that already accept partial M cases. My text only clarifies it.

We know perfectly that even if we don't like disaggregation (and I encourage to 
avoid it), LIRs will do it anyway. Existing policy doesn't forbid it. Is only 
recommended. So not having this text, doesn't disallow it.

The other point that you raise, this is not changing sparse allocation. The 
prefixes we are discussion about, are already allocated or assigned to 
LIRs/end-users, so the APNIC internal sparse allocation doesn't change.

Last, but not least. When a company acquires another, they have the rights to 
acquire all their assets, and legally, you can't avoid that. Even if policies 
say "not", legally they have acquired all or part of the assets (including the 
right to use the addressing space).

Having a policy that doesn't allow it will not change a legal right.

About inter-RIR, there are not consensus about (M and/or market)transfer 
IPv6 address
between RIRs.  First of all, we think we need to discuss about it.

This has been accepted already in RIPE (long time ago). LACNIC staff confirmed, 
in the impact analysis of an equivalent policy proposal, that when a company is 
involved in an M, they merge "all the resources, not just IPv4".

Do you really think, you can forbid a company, never mind is from one region or 
another, to "not transfer" the resources that are part of the legal agreement 
that they have acquired (when they buy a company which is APNIC member, they 
"buy" all the contracts)? We like it or not, this is a lost battle in my 
opinion. You can't say, transfer IPv4, renumber your ASN and IPv6!

Regards,
Hiroki

---
Hiroki Kawabata
Japan Network Information Center(JPNIC)


Subject: [sig-policy] Policy Proposal: prop-130-v001: Modification of 
transfer policies
Date: Thu, 14 Mar 2019 18:59:19 +0600
From: Sumon Ahmed Sabir 

> Dear SIG members,
> 
> The proposal "prop-130-v001: Modification of transfer policies"
> has been sent to the Policy SIG for review.
> 
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
> 
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
> 
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. 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 available at:
> 
>  http://www.apnic.net/policy/proposals/prop-130
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> *  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:  APNIC SIG on resource management policy 
  *
___
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy




**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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 

Re: [sig-policy] Version 4 of prop-126 PDP Update

[JORDI PALET MARTINEZ]

Dear Saturo,

See responses below, in-line.
 
Regards,
Jordi
@jordipalet
 
 

El 2/9/19 17:37, "Satoru Tsurumaki"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-126, based
on a meeting we organized on 21th Aug to discuss these proposals.

Many participants expressed a supporting for the proposal with reasons
that discussions in the mailing list will be reflected more than ever,
also with the reason that expiring policy of the proposal at Step 4
sound good both author and community.

And a few question were expressed as below:
- In Step2, it seems difficult to understand the process. Which is correct?
 1. Consensus is determined...
Firstly SIG mailing list/other electronic means/the SIG session
  and then
Member Meeting
 2. Consensus is determined...
 Firstly SIG mailing list/other electronic means
   and then
 SIG Session
   Afterward
 Member Meeting

I think it is clear from my text that I was referring to 1 above. However, if 
you think that there is something that can be improved in the way is written, I 
believe is still possible at this time, as it doesn't change the "intended 
meaning". An alternative way to write the same is:

"Consensus is determined considering:
- the SIG mailing list
- other electronic means
- and the SIG session
Afterwards it must be re-confirmed at the Member Meeting.

So basically, what I'm doing in STEP 2 is just to clarify that formally the 
mailing list+other electronics means (such as CONFER)+the SIG meeting are 
considered as part of the chair's decision-making process.

- What is "other electronic means" ? Is it CONFER?
  If it is CONFER, I am concerned that CONFER does not know the exact
number of people who voted.

Today it is CONFER, tomorrow can be something different or something else. This 
is provided by the staff. I don't want to mention CONFER, just to keep the door 
open to other means that we may agree to have in the future (so we don't need 
to change it with every possible electronic mean).

I don't think is a matter of "votes", because consensus is not about "how 
many", but if there is a strong opposition with objections raised and not 
resolved vs strong support.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年8月9日(金) 3:14 Sumon Ahmed Sabir :

>
>
> Dear SIG members
>
> A new version of the proposal "prop-126: PDP Update" has been sent to
> the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> Information about earlier versions is available from:
> https://www.apnic.net/community/policy/proposals/prop-126/
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
>
> prop-126-v004: PDP Update
>
> --
>
> Proposer: Jordi Palet Martínez
>jordi.pa...@theipv6company.com
>
>
> 1. Problem Statement
> 
>
> With its requirement of face-to-face participation at the OPM, the current
> PDP might – at least partially – be the cause of the low levels of
> community
> participation in the process by using the policy mailing list.
>
> This proposal would allow an increased participation, by explicitly
> considering
>   the comments in the list for the consensus determination. So,
> consensus would
> be determined balancing the mailing list and the forum, and would 
therefore
> increase community participation.
>
> Even if this is actually done by the chairs, it is not part of the
> actual PDP,
> and thus constitutes a very clear and explicit violation of the PDP and
> the risk
> is that anyone from the community could appeal any decision based on that.
>
> Finally, it completes the PDP by adding a simple mechanism for solving
> disagreements
> during an appeals phase and an improved definition of ‘consensus’, as
> well as a
> complete definition of the “consensus” and “last-call”.
>
>
> 2. Objective of policy change
> -
>
> To allow that consensus is determined formally looking at the opinions
> of community
> 

Re: [sig-policy] Version 4 of prop-126 PDP Update

[JORDI PALET MARTINEZ]

Hi Owen, 

 

 

El 27/8/19 8:15, "Owen DeLong"  escribió:

 

 



On Aug 26, 2019, at 03:05 , JORDI PALET MARTINEZ  
wrote:

 

Hi Javed,

 

I don’t agree, let me explain why.

 

The current process only talks about the meeting and the chairs have clearly 
indicated that they take in consideration the list and the confer. Anyone from 
the community that dislikes a consensus/non-consensus decision, could create a 
trouble even in courts, because we are accepting consensus from sources not 
documented in the PDP. Rewording it resolves the problem.

 

Furthermore, the current process has not an “in-process” appeal procces. This 
will be ilegal in may legislations (may be only the AU applies, but considering 
that the community is “the entire Internet”, may be this may be declared 
illegal in another country where a member decides to claim for). The only way 
(actually) to appeal, will be going to the courts. We should not aim to that. 
We should have an internal way.

 

While there is no appeal process, there are sufficient iterations of approval 
and ratification in the current process that I am not convinced an appeal 
process is necessary.

 

I don’t agree on that. If today chairs decide that something is out-of-scope, 
nobody has a way to change that decision. There is no way the community will be 
able to discuss the policy proposal as a “policy proposal”, because the chairs 
don’t accept it.

 

In the case of ARIN, there is a kind of appeal process with is the “petition 
process”. Here we don’t have that. And is the only region where we don’t have 
that.

 

I really think is very bad not having it.

 

I’m convinced the chairs always act on their best good faith and willingness, 
but this scheme, without a way for the community to oversee the chair’s 
decision is “per se” against the bottom-up approach.

 

Just imagine if we have a set of chairs that aren’t really acting in good 
faith, but on personal interest (please understand is just an example, not 
saying at all it is the present case). I don’t think we even have a way to 
remove them.

 

 

Calling out the (remote) possibility that some jurisdiction might have a 
problem with it is a red herring and absent actual legal doctrine within the 
APNIC service region, I think it’s a bit far fetched to put that argument 
forward.

 

Agree, but we need to understand that for sure there is a jurisdiction. And in 
my knowledge (not being a lawyer), any process that doesn’t have an implicit 
appeal process has lot of chances to be defeated in *any* jurisdiction. It is 
much better to avoid that, right ?

 

This is now even more relevant to be resolved, because by chance, the chairs 
have denied to accept one of the policy proposal that I’ve submited. They 
consider it out-of-scope, and my reading is that is in-scope (it has also been 
submitted and in-scope to RIPE, LACNIC and AFRINIC). I think their decision is 
wrong and this has many implications that we need to work out. The best avenue 
is having an “in-house” appeal process, of course.

 

You’ve been wrong about what should be in-scope before. I won’t cite the 
specifics unless you insist, but you are more than welcome to discuss your 
concerns about it with 

 

I’m not talking here about any specific policy proposal, as said before, this 
happened by chance. The inclusion of the appeal process in this PDP update was 
done one year in advance this situation, so not related to it.

 

Paul and/or the EC and I’m certain you will get an appropriate response. While 
it’s not a formal appeal process, I’m certain that if they agree with you that 
the co-chairs erred, they will discuss the situation with the co-chairs and 
come to an appropriate resolution.

 

Agree, and I talked to Paul about it. If I recall correctly, he only suggested 
to go to the open forum, not him, not the EC. However, we don’t have time 
allocated for it.

 

And furthermore, I don’t think it is savvy if this happens, that we must wait 6 
months for discussing it in a meeting.

 

If you read the PDP, there is no definition of the scope and there is a 
contradiction in the text 
(https://www.apnic.net/about-apnic/corporate-documents/documents/policy-development/development-process/),
 as it says:

“Policy proposals are proposals which have been officially submitted for the 
consideration of the APNIC community …” and then “A formal proposal paper must 
be submitted to the SIG mailing list and to the SIG Chair”, while the *actual 
process* is sending to the chairs, so they decide if is being sent to the list 
or not!

 

Should anyone ignore the actual process and just send the proposals to the list?

 

Note that I didn’t knew, when I submitted the PDP update (which is a new 
version from a the previous year proposal), that one of my proposals will be 
considered by the chairs as out-of-scope. Clarification just so nobody believes 
that it is related to that rejection! Chairs can confirm that.

 

I don’t th

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Satoru,

Thanks for investing time in the several policy proposals.

I think that the last couple of emails could help all you to better understand 
the problem.

Clearly, if different people read the current policy text in a different way, 
it will be much better to find a way so we have a single and unique "reading" 
and no different ways to interpret it. Right?

Regards,
Jordi
@jordipalet
 
 

El 2/9/19 17:37, "Satoru Tsurumaki"  escribió:

Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-124,based
on a meeting we organized on 21th Aug to discuss these proposals.

Many participants expressed a neutral for the proposal with reasons
that the problem in the current policy is something vague.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年8月10日(土) 23:33 Sumon Ahmed Sabir :

>
> Dear SIG members
>
> A new version of the proposal "prop-124: Clarification on Sub-Assignments"
> has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> Information about earlier versions is available from:
> https://www.apnic.net/community/policy/proposals/prop-124
>
> You are encouraged to express your views on the proposal:
>
>   - Do you support or oppose the proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
>
> Please find the text of the proposal below.
>
> Kind Regards,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> --
>
> prop-124-v006: Clarification on Sub-Assignments
>
> --
>
> Proposer: Jordi Palet Martínez
>jordi.pa...@theipv6company.com
>
>
> 1. Problem Statement
> 
>
> Note that this proposal is ONLY relevant when end-users obtain direct
> assignments
> from APNIC, or when a LIR obtains, also from APNIC, and assignment for
> exclusive
> use within its infrastructure. Consequently this is NOT relevant in case
> of LIR
> allocations.
>
> When the policy was drafted, the concept of assignments/sub-assignments
> did not
> consider a practice very common in IPv4 which is replicated and even
> amplified
> in IPv6: the use of IP addresses for point-to-point links or VPNs.
>
> In IPv4, typically, this is not a problem if NAT is being used, because
> the assigned
> addresses are only for the WAN link, which is part of the infrastructure
> or interconnection.
>
> In the case of IPv6, instead of unique addresses, the use of unique
> prefixes
> (/64) is increasingly common.
>
> Likewise, the policy failed to consider the use of IP addresses in
> hotspots hotspots
> (when is not an ISP, for example, associations or community networks),
> or the use of
> IP addresses by guests or employees in Bring Your Own Device (BYOD) and
> many other
> similar cases.
>
> One more case is when an end-user contracts a third-party to do some
> services in their
> own network and they need to deploy their own devices, even servers,
> network equipment,
> etc. For example, security surveillance services may require that the
> contractor provides
> their own cameras, recording system, even their own firewall and/or
> router for a dedicated
> VPN, etc. Of course, in many cases, this surveillance system may need to
> use the addressing
> space of the end-user.
>
> Finally, the IETF has recently approved the use of a unique /64 prefix
> per interface/host
> (RFC8273) instead of a unique address. This, for example, allows users
> to connect to a hotspot,
> receive a /64 such that they are “isolated” from other users (for
> reasons of security,
> regulatory requirements, etc.) and they can also use multiple virtual
> machines on their
> devices with a unique address for each one (within the same /64).
>
>
> 2. Objective of policy change
> -
>
> Section 2.2.3. (Definitions/Assigned Address Space), explicitly
> prohibits such assignments,
> stating that “Assigned ... may not be sub-assigned”.
>
> It also clarifies that the usage of sub-assignments in ISPs, data
> centers and similar cases
> is not allowed, according to the existing practices of APNIC.
>
>
> 3. Situation in other regions
> -
>
> This situation, has already been 

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Javed,

 

I actually think this is in the other way around.

 

I believe you’re confusing different terms, clearly described in the 
definitions section of the policy manual:

 

2.2.1. Delegated address space

APNIC "delegates" addresses to its account holders. These delegations can be 
for use on the organization's own infrastructure (an "assignment") or for 
subsequent delegation by the organization to its customers (an "allocation").

 

2.2.2. Allocated address space

Allocated address space is address space that is distributed to IRs or other 
organizations for the purpose of subsequent distribution by them.

 

2.2.3. Assigned address space

Assigned address space is address space that is delegated to an LIR, or 
end-user, for specific use within the Internet infrastructure they operate. 
Assignments must only be made for specific, documented purposes and may not be 
sub-assigned.

 

This policy is only relevant to “assigments”.

 

When an ISP (LIR) is getting addresses from APNIC for further distribution to 
customers, that space falls into the definition of “allocation”, so it is fine 
to further dirstribute it to other organizations.

 

When an ISP (LIR) is getting “assigned” space from ACPNIC, is not for 
re-distribution. This is what I’m triyng to clarify.

 

The fact that you are confused, I think, demonstrates that the actual text is 
subjected to multiple interpretations.

 

As an ISP/LIR, which the current text, for different people reading it, a p2p 
link may be or not considered part of the infratructure. Perhaps you can say, 
it is ok to use for a p2p if the CPE is from the ISP, but otherwise not.

 

My text clarify all the possible cases.

 

Regards,

Jordi

@jordipalet

 

 

 

El 29/8/19 2:49, "Javed Khan"  escribió:

 

Yes but the proposed text is not clear. In with the current policy text, LIRs 
are not allowed to make sub-assignments from their assigned address space 
outside of their infrastructure. So I do not support this change in policy.

 

J Khan

 

From: sig-policy-boun...@lists.apnic.net  
on behalf of Owen DeLong 
Sent: Saturday, 24 August 2019 12:45 AM
To: Simon Sohel Baroi / Global Business / 01847102243 / 

Cc: Sumon Ahmed Sabir ; Policy SIG 
Subject: Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments 

 

I think the current text isn’t really a problem because reasonable people apply 
a reasonable interpretation of intent rather than the literal meaning. 

 

The proposal brings literal meaning more in line with well understood intent. 

 

While I don’t believe there is an actual problem to solve here, I do think the 
proposal provides greater clarity in the language and therefore support it. 

 

Owen

 


On Aug 23, 2019, at 01:11, Simon Sohel Baroi / Global Business / 01847102243 / 
 wrote:

Dear Sir,

 

Also, Requesting to the Author to represent the Proposal with Example and 
Graphical Representation.

The example should have comparison with Present situation and the Propose 
Solution of the problem.

 

 

- with regards

 

SIMON.

 

On Sat, Aug 10, 2019 at 8:33 PM Sumon Ahmed Sabir  wrote:

Dear SIG members

A new version of the proposal "prop-124: Clarification on Sub-Assignments"
has been sent to the Policy SIG for review.

It will be presented at the Open Policy Meeting at APNIC 48 in
Chiang Mai, Thailand on Thursday, 12 September 2019.

Information about earlier versions is available from:
https://www.apnic.net/community/policy/proposals/prop-124

You are encouraged to express your views on the proposal:

  - Do you support or oppose the proposal?
  - Is there anything in the proposal that is not clear?
  - What changes could be made to this proposal to make it more effective?

Please find the text of the proposal below.

Kind Regards,

Sumon, Bertrand, Ching-Heng
APNIC Policy SIG Chairs


--

prop-124-v006: Clarification on Sub-Assignments

--

Proposer: Jordi Palet Martínez
   jordi.pa...@theipv6company.com


1. Problem Statement


Note that this proposal is ONLY relevant when end-users obtain direct 
assignments
from APNIC, or when a LIR obtains, also from APNIC, and assignment for 
exclusive
use within its infrastructure. Consequently this is NOT relevant in case 
of LIR
allocations.

When the policy was drafted, the concept of assignments/sub-assignments 
did not
consider a practice very common in IPv4 which is replicated and even 
amplified
in IPv6: the use of IP addresses for point-to-point links or VPNs.

In IPv4, typically, this is not a problem if NAT is being used, because 
the assigned
addresses are only for the WAN link, which is part of the infrastructure 
or interconnection.

In the case of IPv6, instead of unique addresses, the use of unique 
prefixes
(/64) is increasingly common.

Likewise, the policy failed to consider the use of IP addresses in 

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[JORDI PALET MARTINEZ]

Hi Owen, all,

 

Sorry the late answer … been too busy the last weeks.

 

Responses below, in-line.

 

Regards,

Jordi

@jordipalet

 

 

 

El 27/8/19 8:05, "Owen DeLong"  escribió:

 

 



On Aug 26, 2019, at 03:19 , JORDI PALET MARTINEZ  
wrote:

 

Hi Javed,

 

I think you’re getting something wrong.

 

Policies aren’t there so APNIC can verify “everything” to “every” member. This 
will be impossible.

 

Policies are there so everybody know the rules, and try their best to avoid 
breaking them.

 

Policies are there to avoid bad-intentions from bad-Internet actors, in order 
to protect the majority (the good ones).

 

If we only accept policies when they can be verified, then we will have an 
empty policy book :-)

 

If APNIC does a verification, for whatever reason (any suspicius, a claim from 
another member, etc.), and a rule is broken, APNIC should take measures if the 
member doesn’t correct it. In some cases those measures may mean member 
closure, resource recovery, etc. This is a completely different discussion 
which has policy and service agreement implications.

 

Please, note before continue reading that this only affects end-user direct 
assignments by APNIC or the NIRs. Not clarifiying this caused some confusion in 
the discussion of the last meeting. So if you’re an ISP (I’m not sure if that’s 
your case), this proposal doesn’t affect you.

 

It only affect you, if you are getting a direct assignment from APNIC or any of 
the NIRs.

 

The fact here is that if, for example, an university, which got a direct 
assignment from APNIC, is providing the students public addresses (IPv4) or 
global addresses (IPv6), it is against the policy.

 

No, this does not violate current policy. The students are part of the 
University every bit as much as employees of a company are entitled to receive 
valid public addresses for their BYO smart phones/whatever in the office.

 

The problem here is that it depends on if you consider the WiFi devices part of 
the infrastructure or not.

 

As you indicated in a previous email, this is proposal is a clarification that 
is good to have (and has been done the same in all the other RIRs for a good 
reason), it doesn’t create any issue and avoids any misinterpretation.

 

What happens (which the current text) if the students instead bring “servers” 
and have other devices behind those servers. Is that still part of the 
university infrastructure or not? What if instead of a single address a /64 is 
allocated, because they are running VMs?

 

What happens if instead of a university is a hotspot provider, may be even for 
free services to the community (community hot spot, for example a neighborhood).

 

What happens if it is a VPN service? It may be used to provide Internet 
connectivity to others, same as p2p links.

 

What happens if a DataCenter instead of becoming an LIR, uses end-user space 
directly assigned by APNIC to provide service to the customers?

 

I think all those points are perfectly clarified with the new text, and avoid 
subjective miss-interpretations.

 

That’s not sub assignment or reassignment, that’s just utilization within the 
Universities own network.

 

In the case of IPv4, the solution is easy, use NAT and private addresses (but 
not all the universities do that). However in IPv6 this is not the solution, we 
don’t have NAT.

 

NAT is not required by current policy. The policy text as it stands does not 
prohibit the (temporary) use of public addresses on LAN or WLAN segments 
controlled by the entity holding the prefix even if the device(s) are not 
owned/directly controlled by the University. Especially in the case where the 
devices are in the possession/control of employees/students of the institution 
in question.

 

Agree. I’m not saying that the policy requires NAT. I say that “typically” this 
doesn’t happen in the case of IPv4, because most of the resource-holders use 
NAT, but may be cases where we will have the same “open interpretation” with 
the current policy text, if the resource-holder decides not to use NAT and 
provide IPv4 public addresses.

 

If you think that is the case, then you have misunderstood the current policy.

 

Owen

 

I can put many other similar examples (remember again, this is only the case 
when the addresses are directly assigned to the end-user by APNIC or the NIR, 
not by an ISP): a point to point link from the university to another network, 
an employee getting addresses from a company, thir party companies offering 
services to that company or university, a municipality offering WiFi to 
citizens, etc.

 

The proposal solves both cases, the IPv4 and the IPv6 one.

 

Note that this has been already corrected in all the other RIRs (ARIN, AFRINIC, 
LACNIC and RIPE). All them had the same problem in their policy text.

 

Regards,

Jordi

@jordipalet

 

 

 

El 23/8/19 16:01, "Javed Khan"  escribió:

 

I do not support this proposal. Intentio