[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

> On Dec 20, 2023, at 17:03, Luke Thompson  wrote:
> 
> The logic on both sides seems valid to me. I think ultimately it's about 
> supporting the demise of v4 (in that, the rise of efficient smaller 
> operators).
> 

I’ll slightly disagree here… The demise of v4 is best resolved by v6, not by 
ever stranger contortions to try and make things fit in the very limited v4 
address space.

> There is what seems a valid case to shift this to /26 minimum, and also 
> bedded-down tradition where the existing baseline is unlikely to 
> significantly change - especially for what should be a primarily yesteryear 
> technology. I think there may be a silently resistant subset of operators who 
> don't want to get into the nitty gritty of smaller assignments at scale, not 
> that it is necessarily good form. 
> 
The level of pain once we run out of v4 for IXPs is zero to push the peering 
sessions for new exchange points to be v4/v6 NRLI via IPv6 peering. It’s super 
easy to configure, presents no significant hurdles or additional training 
requirements vs. dual-stack peering in separate sessions.

As such, I see absolutely no reason to change the v4 prefix size for IXPs or 
worry about running out of them.
> From my understanding of the BGP arena, which is lacking, administratively 
> and in terms of routing table size /24 is already quite small. However at the 
> same time, small operators shouldn't have to take up "large" (to their scale) 
> prefixes to establish basic requirements. It does seem unreasonable that you 
> can't get down into /26 per-site, especially as density increase could 
> potentially be up to 3x more yield from a /24?
> 

In general, IXP prefixes shouldn’t be carried in the routing table anyway, so 
this is a questionable issue.

> With a view forwards, and v4 becoming more of an 
> enabling-what-doesn't-do-v6-well technology as it slowly slowly (slowly) 
> sunsets, I think this proposal will make even more sense. To that end, making 
> the change sooner than later seems prudent in preserving resources, 
> especially as this proposal has provision for up to /22 conditionally.
> 
> To Owen's point it is also "just another change" towards prolonging the end 
> of v4 and one many are tired of. I think the pathway out of v4 has proven to 
> be remarkably slow and resistant, that it makes sense to aid the sunset 
> rather than push against it. 
> 
Yes, so let’s aid it in part by just letting the prefixes run out instead of 
aiding the prolonging of it even further.
> At the same time, should this gain consensus then where does the line get 
> drawn?
> 
Excellent question, which is why I hope this does not gain consensus.

Owen
 Again, members define policy (be it a routing policy or otherwise). If a 
 community member presents a policy about the routability of prefixes 
 longer than a /24 at an open policy meeting and it reaches consensus with 
 the wider community, why should we not accept it? RIRs do so much more 
 than just administering addresses and if that's all they did, I believe 
 the internet would not be the way that it is today.
Well, there’s a good deal of debate about that, but the simple reality is that 
people who run routers define the longest prefix they are willing to accept. 
Sure, the community can apply pressures on that (possibly through RIR policy, 
though I question that), but at the end of the day, an RIR policy insisting 
that people carry longer prefixes in their routing tables probably carries 
about as much weight as a prepend in an as-path. It’s a suggestion at best and 
often ignored.

The RIR can set policy for how it administers the registration database. It 
cannot set policy for much more than that and have its policies remain 
meaningful. Certainly the RIR’s ability to enforce policy is limited to how it 
runs the registry and possibly other aspects of how the RIR is run. Attempting 
to enforce policy on how people manage their routing tables or other aspects of 
their business is unlikely to meet with much success, at least in most of the 
world.
>>> Well, at least in the ARIN region, there is a concept of scope of the PDP 
>>> and policy proposals which are out of scope are rejected out of hand.
>> Unfortunately I do not know enough about ARIN's PDP so I'm probably not the 
>> best person to comment on this specifically.

Having spent nearly 15 years on the ARIN advisory council, I am quite well 
versed in the ARIN PDP. As such, I am happy to answer any questions you may 
have about it. You can also easily contact any current advisory council member 
or reach out to any of ARIN’s policy analyst or John Sweeting or John Curran, 
all of whom are quite accessible.

Owen

___
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 proposal: prop-158-v001: IPv6 auto-allocation for each IPv4 request

[Owen DeLong via SIG-policy]

This proposal is yet another gift from the bad idea fairy… Wait… It’s actually 
a regift from someone else who got it from the bad idea fairy on its last 
go-around.

While I’m all for reuse and recycling, this one needs to go to the landfill.

It was a bad idea the first several times it was proposed and nothing has 
changed to make it a good idea now.

Owen


> On Jan 29, 2024, at 16:24, Sunny Chendi  wrote:
> 
> Dear SIG members,
> 
> The Secretariat's impact assessment for this proposal is provided below as 
> well as published at:
> http://www.apnic.net/policy/proposals/prop-158
> 
> APNIC notes that this proposal suggests automatically delegating IPv6 address 
> resource to new and initial IPv4 requests to accelerate IPv6 implementation.
> 
> APNIC also notes that this proposal is applicable to both APNIC and NIR 
> account holders.
> 
> Questions/Comments:
> - The current APNIC Membership form allows account holders to request 
> multiple IP resources (IPv4, IPv6, and ASN) while applying for APNIC 
> membership. Account holders can also simply get an IPv6 delegation by 
> one-click process in MyAPNIC.
> 
> - The proposal suggests “Automatically delegated IPv6 address should be put 
> into deployment within two years from the date of the delegation”. Is the 
> intention that the outcome of not complying with this policy is the 
> revocation of just the IPv6 resources, also the IPv4 resources applied for at 
> the same time, or an alternative option?
> 
> - If the account holder requests a /23 IPv4 and is also automatically 
> delegated a /32 IPv6, the fees payable by the account holder will increase as 
> the fee for /32 IPv6 is greater than /23 IPv4.
> 
> Implementation:
> If this proposal reaches consensus, implementation may be completed within 
> three months.
> 
> Regards,
> Sunny
> APNIC Secretariat
> 
> 
> On 15/01/2024 9:39 am, Bertrand Cherrier via SIG-policy wrote:
>> Dear SIG members,
>> 
>> A new proposal "prop-158-v001: IPv6 auto-allocation for each IPv4 request"
>> has been sent to the Policy SIG for review.
>> 
>> It will be presented at the Open Policy Meeting (OPM) at APNIC 57 on
>> Thursday, 29 February 2024.
>> 
>> https://2024.apricot.net/program/program/#/day/9/
>> 
>> 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-158
>> 
>> Regards,
>> Bertrand, Shaila, and Anupam
>> APNIC Policy SIG Chairs
>> 
>> --
>> 
>> prop-158-v001: IPv6 auto-allocation for each IPv4 request
>> 
>> ---
>> 
>> Proposers: David Aditya Yoga Pratama (da...@idnic.net)
>>  M. Andri Setiawan (an...@idnic.net)
>> 
>> 
>> 1. Problem statement
>> -
>> 
>> Based on this 
>> https://www.apnic.net/manage-ip/ipv4-exhaustion/#how-much-apnic-has, APNIC 
>> still has around 2,539,776 available IPv4 addresses and may claimed another 
>> 2,479,360 reserved IPv4 addresses.
>> 
>> APNIC member still can get /24 of IPv4 addresses based on the current APNIC 
>> policy.
>> 
>> Most of the new IPv4 requestors are not allocated or requesting IPv6 even 
>> though they are eligible to do so.
>> 
>> The rates of IPv4 allocation is faster than IPv6 allocation and it may keep 
>> slow the deployment of IPv6.
>> 
>> APNIC associate member can get IPv6 without additional cost (proposal-155), 
>> so APNIC member should be able to do the same when they request IPv4 address.
>> 
>> 2. Objective of policy change
>> --
>> 
>> Allocate IPv6 addresses to each IPv4 addresses requests to speed up the IPv6 
>> adoption and deployment rates.
>> 
>> 3. Situation in other regions
>> 
>> 
>> AFRINIC - No such policy
>> ARIN - No such policy and it has no available address space to be offered
>> RIPE NCC - No such policy and it has no available address space to be offered
>> LACNIC - IPv6 allocation request is used as “requirements” for any IPv4 
>> request as mentioned in their policy point 2.3.3.1 - 2.3.3.4 and 2.3.4. “The 
>> applicant must already have at least one IPv6 block assigned by LACNIC or, 
>> if not, must simultaneously request an initial IPv6 block in accordance with 
>> the corresponding appl

[sig-policy] Re: New proposal - prop-157-v001: Temporary IPv4 Transfers

[Owen DeLong via SIG-policy]

I would think that in any case where there is a (valid and verified) request 
which cannot be fulfilled otherwise, but could be fulfilled by early 
termination of the quarantine period that APNIC should contact the requestor 
and offer them the option of accepting the space in that condition. Once 
informed consent is obtained, I would expect APNIC to make a good faith effort 
to complete any remaining quarantine activities (with added caution not to step 
on the new recipient).

If this requires a policy proposal I can submit one, but I think it’s a fairly 
common sense approach to the circumstance, should it arise.

Owen


> On Jan 29, 2024, at 16:20, Sunny Chendi  wrote:
> 
> Dear SIG members,
> 
> The Secretariat's impact assessment for this proposal is provided below as 
> well as published at:
> http://www.apnic.net/policy/proposals/prop-157
> 
> APNIC notes that this proposal suggests a policy modification that would 
> allow for temporary transfers between account holders (applying to intra-RIR 
> transfers, e.g. APNIC and NIR account holders, but not inter-RIR transfers, 
> e.g. APNIC to another RIR).
> 
> Questions/Comments:
> - APNIC would like to remind the community that the current policy outlined 
> in Section 11.1.2. “Conditions on the source of the transfer” which applies 
> to ‘permanent’ transfers would also apply to ‘temporary’ transfers if this 
> proposal reaches consensus.
> 
> - Based on the current wording of the APNIC Fee Schedules, Transfer Fees 
> would be applicable to the temporary transfers.
> 
> - The intent of the proposed text appears to be that APNIC update the 
> existing transfer log to include temporary transfers, however this would 
> change the meaning of the file in a fundamental way that will likely cause 
> problems for some clients (mainly because an entry in that log no longer 
> represents a permanent transfer). APNIC suggests that the temporary transfers 
> should be logged separately from permanent transfers for this reason.
> 
> - The proposal suggests that the transfer contract "include terms of transfer 
> cancellation in case of usage of the resources for network abuse." If the 
> intention is that APNIC revoke resources for network abuse, APNIC will not be 
> able to do so under this provision as APNIC cannot enforce the terms of a 
> contract it is not a party to.
> 
> - Does the author propose that APNIC will implement a temporary transfers 
> agreement template and standardised the process in a similar way to RIPE NCC?
> 
> - Ensuring compliance with MANRS practices would require APNIC to monitor and 
> enforce policies over which it has no control. How does the author propose 
> APNIC ensure compliance with ‘11.1.4. Additional conditions for temporary 
> transfers’, especially "The recipient must follow MANRS best practices."?
> 
> Implementation:
> This proposal may require changes to APNIC systems. If this proposal reaches 
> consensus, implementation may be completed within three months.
> 
> Regards,
> Sunny
> APNIC Secretariat
> 
> On 14/12/2023 12:55 pm, Bertrand Cherrier wrote:
>> Dear SIG members,
>> 
>> A new proposal "prop-157-v001: Temporary IPv4 Transfers" has been sent to
>> the Policy SIG for review.
>> 
>> It will be presented at the Open Policy Meeting (OPM) at APNIC 57 on
>> Thursday, 29 February 2024.
>> 
>> https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2F2024.apricot.net%2Fprogram%2Fprogram%2F%23%2Fday%2F9%2F&data=05%7C02%7C%7C96c320a0c7bb4e6a778008dbfc501ddd%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C638381193266052234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wHJMNZRDt48kdnbwDKs2Sc2uGR9ZleDC7IY2kAaAwXQ%3D&reserved=0
>>  
>> 
>> 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-157
>> 
>> Regards,
>> Bertrand, Shaila, and Anupam
>> APNIC Policy SIG Chairs
>> 
>> ---
>> 
>> prop-157-v001: Temporary IPv4 Transfers
>> 
>> 
>> 
>> Proposer: Jordi Palet Martinez (jordi.pa...@theipv6company.com)
>> 
>> 
>> 1. Problem statement
>> 
>> When in the community we discuss the need for leasing, understood b

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

> On Dec 20, 2023, at 16:33, Christopher Hawker  wrote:
> 
>> Longer prefixes are misguided for a number of reasons, but I was’t referring 
>> to that.
>> I was calling the idea of deluding ourselves into believing that the useful 
>> lifetime of IPv4 can be extended by these ever increasing extreme measures 
>> misguided.
> 
> This is starting to digress from the original purpose of this discussion, so 
> I'll keep it short. Using longer prefixes is by no means delusional, rather 
> it is significantly beneficial in allowing smaller and newer network 
> operators to establish more than two points of presence, and it most 
> certainly prevents wastage at IXes.

I never said longer prefixes were delusional. Misguided, yes. Ill-advised, yes. 
Delusional, no.
Believing that we can keep extending the useful life of IPv4 by such 
shenanigans, OTOH, is delusional.

>>> Again, members define policy (be it a routing policy or otherwise). If a 
>>> community member presents a policy about the routability of prefixes longer 
>>> than a /24 at an open policy meeting and it reaches consensus with the 
>>> wider community, why should we not accept it? RIRs do so much more than 
>>> just administering addresses and if that's all they did, I believe the 
>>> internet would not be the way that it is today.
>> Well, at least in the ARIN region, there is a concept of scope of the PDP 
>> and policy proposals which are out of scope are rejected out of hand.
> 
> Unfortunately I do not know enough about ARIN's PDP so I'm probably not the 
> best person to comment on this specifically.

Happy to answer any questions you may have. I spent nearly 15 years as a member 
of the ARIN AC.

Owen

___
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-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

> On Dec 20, 2023, at 03:40, Christopher Hawker  wrote:
> 
>>> My problem still lies with the community not accepting prefixes longer than 
>>> a /24 for global routability. We can't prevent IXPs with prefixes longer 
>>> than a /24 from routing their prefixes, when those with shorter than or 
>>> equal to a /24 can. It's either all can, or none can.
>> My problem is with the whole idea that RIRs should be issuing IPv4 prefixes 
>> longer than /24 in a misguided effort to extend the “useful” life of IPv4.
> 
> I don't believe it's misguided at all. There is no technical or policy-based 
> reason as to why longer prefixes cannot be delegated or routed. Back in the 
> AUNIC and early APNIC days, much shorter delegations were being made, when 
> exhaustion wasn't thought about (or at least considered), and this was the 
> norm. Why can /25 prefixes not be considered the new norm for resource 
> delegations?

Longer prefixes are misguided for a number of reasons, but I was’t referring to 
that.

I was calling the idea of deluding ourselves into believing that the useful 
lifetime of IPv4 can be extended by these ever increasing extreme measures 
misguided.

 RIRs should not be in the business of dictating routing policy to anyone.
>>> APNIC does not "dictate" how we can and cannot route resources, the 
>>> community defines policy (see the PDP). APNIC simply facilitates this 
>>> process.
>> Permit me to rephrase…
>> Routing Policy should be out of scope for RIR policies.
> 
> Again, members define policy (be it a routing policy or otherwise). If a 
> community member presents a policy about the routability of prefixes longer 
> than a /24 at an open policy meeting and it reaches consensus with the wider 
> community, why should we not accept it? RIRs do so much more than just 
> administering addresses and if that's all they did, I believe the internet 
> would not be the way that it is today.

Well, at least in the ARIN region, there is a concept of scope of the PDP and 
policy proposals which are out of scope are rejected out of hand.

YMMV.

Owen

___
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-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

>> RIRs should not be in the business of dictating routing policy to anyone.
> 
> Well yes, that is commonly said and sometimes too generically, but as the 
> entity responsible for setting the rules for IP assignment there may be any 
> necessary usage restriction for that type of assignment if the community 
> finds it necessary and reasonable. So don't write it on stone.

Stone is good.

IMNSHO, this should be written in stone and very generically. Changing it is 
neither reasonable nor necessary and it makes about as much sense as the bad 
old days when the IETF thought they could use RFCs to dictate RIR policy. We 
all saw how well that went.

Address administration is not routing. RIRs do address administration. Network 
Operators do routing.

Owen

___
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-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

> My problem still lies with the community not accepting prefixes longer than a 
> /24 for global routability. We can't prevent IXPs with prefixes longer than a 
> /24 from routing their prefixes, when those with shorter than or equal to a 
> /24 can. It's either all can, or none can.

My problem is with the whole idea that RIRs should be issuing IPv4 prefixes 
longer than /24 in a misguided effort to extend the “useful” life of IPv4.

>> RIRs should not be in the business of dictating routing policy to anyone.
> 
> APNIC does not "dictate" how we can and cannot route resources, the community 
> defines policy (see the PDP). APNIC simply facilitates this process.

Permit me to rephrase…

Routing Policy should be out of scope for RIR policies.

Owen

___
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-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

> On Dec 18, 2023, at 11:06, Fernando Frediani  wrote:
> 
> Hello
> 
> On 11/12/2023 09:38, Christopher Hawker wrote:
>> 
>> 
>> 1. If a current IXP applies for space under this policy, they should be 
>> restricted from transferring new or existing delegations under any transfer 
>> conditions to prevent existing IXPs from applying for resources under this 
>> policy, renumbering their existing IXPs and then selling their old space. 
>> Should there be a requirement for a transfer under Mergers & Acquisitions, 
>> then the recipient acquiring the IXP or the organisation that the IXP is 
>> being merged into should be required to apply for a new delegation and 
>> renumber accordingly. This will not apply if the source and recipient 
>> members are identical in structure (i.e. same directors and shareholders, 
>> and the transfer is simply an organisation restructure).
> I tend to agre with this restriction. It would not be fair with the community 
> with such behavior. If an IXP applies and receives space under this policy 
> this could be for a newer location,but not to be used in a existing one to be 
> sold/transferred to make money if it.
> If there is a Merger & Acquisition the newer entity must be an IXP, otherwise 
> this space should be returned to ARIN and be used exclusively for the same 
> proposes initially justified.

This is a proposed APNIC policy… Why on EARTH would an IXP that got their space 
from APNIC “return” it to ARIN?


>> 
>> 2. New IXPs need to be able to demonstrate that they have the infrastructure 
>> to do so, to prevent people from applying for the sake of holding space and 
>> not actually using it. Given that new IXPs may not be willing to procure 
>> equipment for the operation of the IXP or enter into an contract with a 
>> datacentre provider unless the application for resources is approved, the 
>> APNIC Secretariat may elect to provide pre-approval for IP space, subject to 
>> the provisioning of a contract or other service agreement with a datacentre 
>> operator and purchase documentation (in the name of the organisation 
>> operating the IXP) being provided for space and infrastructure to operate 
>> the IXP.
> Sure thing.
>> 
>> 3. IXP delegations should have a caveat placed upon them that prevents them 
>> from being globally routed, regardless of the size.
> I often hear this about blocks assigned to IXPs and I don't fully agree. IXPs 
> may choose to use globally routed blocks for its own infrastructure (portal, 
> etc) and that is a fair usage. Normally it is not necessary for most cases 
> and specially for the block used for the MLPA but may not be for all cases.
> I reckon it may make more difficult for APNIC to keep an eye that the 
> receiver is using it correctly but at the end it still may be a justifiable 
> usage.

I think a restriction that requires them to be used for an IXP and only for an 
IXP is sufficient.

There are models of IXPs that do have reason to route the IXP segment. They are 
not the most common model, but they do exist.

RIRs should not be in the business of dictating routing policy to anyone.

Owen
(Who remains opposed to this policy in its entirety)


___
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-154: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

I remain opposed to this proposal. It is an unnecessary and pointless 
rearranging of deck chairs
with zero benefit to the community.

When we run out of /24s to give to new IXs, It is utterly harmless for IXs to 
become IPv6 only
fabrics. IPv4 NRLI can be exchanged over IPv6 peering sessions with zero issues.

Owen


> On Sep 8, 2023, at 16:06, Shaila Sharmin  wrote:
> 
> Dear SIG members,
> 
> A new version of the proposal "prop-154: Resizing of IPv4 assignment for 
> the IXPs"
> has been sent to the Policy SIG for review.
> 
> Information about earlier versions is available from:
> 
> http://www.apnic.net/policy/proposals/prop-154
> 
> 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-154-v002: Resizing of IPv4 assignment for the IXPs
> 
> 
> 
> Proposer: Simon Sohel Baroi (sba...@gmail.com )
>Aftab Siddiqui
> 
> 
> 1. Problem statement
> 
> According to APNIC Internet Number Resource Policies ( Ref – APNIC-127, 
> Dated: 22 DEC, 2022 ), an Internet Exchange Point ( IXP ) is eligible to 
> receive a maximum /23 of IPv4 and /48 of IPv6 resources. Usually APNIC 
> assign one /24 to start a new IXP. But from analysis through PeeringDB, 
> we found most of places the resources have been underutilized and new 
> IXPs are wasting a large amount of valuable IPv4 space. On the other 
> side there are large IXP, who can’t grow due to lack of IP resources, 
> where /23 is not enough as the membership size is big. The size of the 
> minimum and maximum range of IP delegation to new or existing IXPs is 
> the main problem in the current policy.
> 
> Present IXP Status in APAC region from PeeringDB [5] :
> +---+---++---+---+
> |  IX Names | Peers | Vs | Peers |  IX 
> Names |
> +---+---+ +---+---+
> | BBIX Tokyo|  299  ||   17  | 
> BBIX-Thailand |
> +---+---+ +---+---+
> | JPIX TOKYO|  257  ||   3   | 
> MekongIX  |
> +---+---+ +---+---+
> | Equinix Tokyo |  131  ||   2   | Equinix 
> Mumbai|
> +---+---+ +---+---+
> | JPNAP Tokyo   |  211  ||   13  | npIX 
> JWL  |
> +---+---+ +---+---+
> | HKIX  |  296  ||   3   | Vanuatu Internet 
> Exchange |
> +---+---+ +---+---+
> | Equinix Hong Kong |  216  ||   4   | 
> MyNAP |
> +---+---+ +---+---+
> | Equinix Singapore |  422  ||   25  | DE-CIX Kuala 
> Lumpur   |
> +---+---+ +---+---+
> | IIX-Jakarta   |  449  ||   13  | 
> IIX-Lampung   |
> +---+---+ +---+---+
> | DECIX-Mumbai  |  446  ||   14  | Decix 
> Kolkata |
> +---+---+ +---+---+
> | MegaIX Sydney |  232  ||   46  | EdgeIX - 
> Melbourne|
> +---+---++---+---+
> 
> 
> 2. Objective of policy change
> -
> The objective of this proposal is to modify the default size of IPv4 
> assignments for IXPs from up to /23 to /26, which can receive a 
> replacement up to a maximum of a /22, provided the IXP returns the IPv4 
> address space previously assigned to them.
> 
> 3. Situation in other regions
> -
> Similar policy has been adopted by RIPE NCC ( ripe-733 :  IPv4 Address 
> Allocation and Assignment Policies for the RIPE NCC Service Region ) [4]
> 
> 
> 4. Proposed policy solution
> ---
> 
> Current Policy text :
> 
> 6.2.4. IPv4 for Internet Exchange Points
> 
> Internet Exchange Points (IXP) are eligible to receive a delegation from 
> APNIC to be used exclusively to connect the IXP participant devices to 
> the Exchange Point.
> 
> Global routability of the delegation is left to the discretion of the 
> IXP and its participants.
> 
> New Policy text :
> 
> 6.2.4. IPv4 for Internet Exchange Points
> 
> By default, a /26 of IPv4 address block 

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

[Owen DeLong via SIG-policy]

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

This simply isn’t the fact.

In ARIN, Leasing is not permitted as justification for obtaining addresses and 
addresses leased
without associated connectivity are not considered utilized for the purpose of 
obtaining additional
addresses. However, that does not mean that leasing is not authorized. Leasing 
is neither authorized,
nor prohibited by ARIN policy at this time.

> Nothing is currently mentioned in RIPE about this and originally it was 
> not acceptable as a justification of the need.

Having done away with Need as a justification, however, there is no longer a 
prohibition of leasing
in any form in the RIPE region. That which is not prohibited is permitted.

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

Not considered as valid for justification is different from prohibited. Once 
one has acquired addresses
from an RIR, one is free to utilize them for any purpose not explicitly 
prohibited by policy, RSA, or
the bylaws of the RIR.

> A similar proposal is under discussion in LACNIC and ARIN.

Similar proposals have repeatedly failed in ARIN before and the current one 
does not, IMHO, have
much support.

> 4. Proposed policy solution
> ---
> 5.8. Leasing of Internet Number Resources
> 
> In the case of Internet number resources delegated by APNIC or a NIR, 
> the justification of the need implies the need to use on their own 
> infrastructure and/or network connectivity services provided to 
> customers. As a result, any form of IP address leasing is unacceptable, 
> nor does it justify the need, unless otherwise justified in the original 
> request. Even for networks that are not connected to the Internet, any 
> form of 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 transfers.

The first sentence remains incongruous with the remainder of the paragraph and 
I remain opposed
to this proposal on that basis.

Other than the first sentence, the rest of the paragraph still purports to 
prohibit all forms of leasing
which would include:

Providers providing dynamic addresses to customers via DHCP
Providers providing addresses to customers for a fee for a certain time 
period

> APNIC should proactively investigate lack of compliance with the 
> original resource request justification, including suspected cases for 
> any form of leasing and also initiate the investigation in case of 
> reports by means of a form, email address or other means developed by APNIC.

The RIRs were never intended to be the internet police and expanding their role 
in this manner
runs contrary to their core mission (the maintenance of an accurate registry of 
unique delegations).

> 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 are leasing or using them for any purposes not specified in the 
> initial request.

This is the most objectionable part of this policy. It basically says that if a 
provider has a /24 that was
previously issued to XYZ Company and XYZ Company changes providers, but wishes 
to pay to retain
the addresses for use with their other providers, this transaction cannot be 
permitted. This is a common
transaction and prohibiting it would be very disruptive. Especially if that /24 
is a single /24 in a /20 or
even larger block nd the entire block is revoked as a result.

Further, things change rapidly on the internet. It is not at all unusual for 
providers to have to pivot
to new business opportunities. This stretches far beyond leasing and seeks to 
cause revocations for
any shift in the business environment (or at the very least a requirement for 
RIR approval of any
new business model).

That’s egregious, IMHO.

Owen

> 
> 
> 5. Advantages / Disadvantages
> -
> Advantages:
> Fulfilling the objective above indicated and making the policy clear.
> 
> Disadvantages:
> None. APNIC can already do this today, however, existing policies don’t 
> explicit them clearly.
> 
> 
> 6. Impact on resource holders
> -
> None, unless they violate policies, but this proposal don’t change that, 
> only clarify it.
> 
> 
> 7. References
> -
> • https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_308_v2/
> • https://politicas.lacnic.net/politicas/detail/id/LAC-2022-2/language/en
> 

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

[Owen DeLong via SIG-policy]

The vast majority of representatives in various countries are not actually 
elected by majorities… Usually they are elected by mere pluralities.

Owen


> On Sep 2, 2023, at 03:38, jordi.palet--- via SIG-policy 
>  wrote:
> 
> Laws aren’t ONLY made by means of elected representatives of majority of the 
> population. Minorities together in parliaments also make laws.
> 
> But further than that, individuals, not elected, can make laws (by means of 
> law changes). At least in my country, a certain number of signatures properly 
> documented from (non-elected) citizens, can do that.
> 
> Also a single individual can fight in courts against laws. I’ve got success a 
> couple of times in my country by means of Constitutional Courts cases against 
> my government and specific laws, and my claim triggered law changes, good for 
> all. This is what I mean when say that any individual can contribute to the 
> good of the community, if you do the effort.
> 
> Regards,
> Jordi
> 
> @jordipalet
> 
> 
>> El 2 sept 2023, a las 12:24, Lu Heng  escribió:
>> 
>> Law maker are elected representative of majority population.
>> 
>> Jordi, remind me who elected you?
>> 
>> On Sat, 2 Sep 2023 at 18:20 jordi.palet--- via SIG-policy 
>> mailto:sig-policy@lists.apnic.net>> wrote:
>>> Ignorance of the law doesn’t mean you’re bind to it. Same here.
>>> 
>>> The PDP is open to all, is not about 20 or 2.000.000 people. All Internet 
>>> users on the earth can participate, is not an exclusive club.
>>> 
>>> Regards,
>>> Jordi
>>> 
>>> @jordipalet
>>> 
>>> 
 El 2 sept 2023, a las 12:13, Lu Heng >>> > escribió:
 
  
 ignorance does not constitute consensus.
 
 And that is the fundamental problem of this list, a small group of people 
 think they can represent all internet user on earth.
 
 No, you can not, policy pass here does not reflect true community wish, 
 policy pass here only reflect the consensus of people participating in the 
 discussion, in which by my count, only 20 people?
 
 People haven’t pay attention or don’t care, does not mean they agree what 
 you.
 
 
 
 On Sat, 2 Sep 2023 at 18:09 Lu Heng >>> > wrote:
> Standard form contract favors the party who not doing the drafting.
> 
> And I would say many members disagree, a simple questionnaire to members 
> “do you want to own your IPs?”receives overwhelming positive answer.
> 
> And it’s just a policy of a private limited company.
> 
> It does not constitute law.
> 
> And this part of policy need to be changed and updated in the future to 
> reflect the market reality.
> 
> On Sat, 2 Sep 2023 at 18:05 jordi.palet--- via SIG-policy 
> mailto:sig-policy@lists.apnic.net>> wrote:
>> Existing policies, with the consensus of the community, which are part 
>> of the membership agreement and consequently accepted by all the members:
>> 
>> 4.0. Resource License
>> 
>> It is contrary to the goals of this document and is not in the interests 
>> of the Internet community as a whole, for Internet number resources to 
>> be considered freehold property.
>> 
>> Neither delegation nor registration confers ownership of resources. 
>> Account holders that use them are considered “custodians” rather than 
>> “owners” of the resource and are not entitled to sell or otherwise 
>> transfer that resource to other parties outside the provisions in this 
>> document.
>> 
>> Internet resources are regarded as public resources that should only be 
>> distributed according to demonstrated need.
>> 
>> The policies in this document are based upon the understanding that 
>> globally unique unicast address space is licensed for use rather than 
>> owned. 
>> 
>> 
>> Regards,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 2 sept 2023, a las 11:59, Lu Heng >> > escribió:
>>> 
>>> Hi Jordi:
>>> 
>>> Who define those legal rights?
>>> 
>>> Who said it is not a property?
>>> 
>>> 
>>> 
>>> On Sat, 2 Sep 2023 at 17:55 jordi.palet--- via SIG-policy 
>>> mailto:sig-policy@lists.apnic.net>> wrote:
 Really ugly and unfortunate that you compare those things, and I guess 
 against code of conduct.
 
 I just can insist that you can’t sell something that is not a 
 property. You have the usage rights. You can own a house or have the 
 right to use it (rental), and the right to use it may allow you to 
 transfer that right to another person or not. So not the same 
 reselling that transferring addresses, is not just a matter of 
 wording, but about the real meaning of those words, from a legal 
 perspective.
 
 Regards,
 Jordi

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

[Owen DeLong via SIG-policy]

> On Sep 2, 2023, at 03:36, Lu Heng  wrote:
> 
> When PDP have such vast impact on the internet, such model will not work 
> well, a good example here is you being a good person, but hugely disconnected 
> from the real will of the community.
> 
> And I understand how things started, it make perfect sense 30 years ago while 
> internet was made of few nerds.
> 
> It is not today.
> 
> Just like you can not leave your nation’s law making system to “whoever want 
> to participate”, so does PDP.

I actually think that the law making system would be improved if it were open 
to whoever wants to participate.

Owen

> 
> 
> 
> On Sat, 2 Sep 2023 at 18:31 jordi.palet--- via SIG-policy 
> mailto:sig-policy@lists.apnic.net>> wrote:
>> Nobody needs to be elected to participate in the PDP, nobody needs to be 
>> elected to contribute to improve things in any aspect of the community. It 
>> is just a matter of willingness to do the right thing, never mind you don’t 
>> have a personal or business interest on that.
>> 
>> Regards,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 2 sept 2023, a las 12:24, Lu Heng >> > escribió:
>>> 
>>> Law maker are elected representative of majority population.
>>> 
>>> Jordi, remind me who elected you?
>>> 
>>> On Sat, 2 Sep 2023 at 18:20 jordi.palet--- via SIG-policy 
>>> mailto:sig-policy@lists.apnic.net>> wrote:
 Ignorance of the law doesn’t mean you’re bind to it. Same here.
 
 The PDP is open to all, is not about 20 or 2.000.000 people. All Internet 
 users on the earth can participate, is not an exclusive club.
 
 Regards,
 Jordi
 
 @jordipalet
 
 
> El 2 sept 2023, a las 12:13, Lu Heng  > escribió:
> 
>  
> ignorance does not constitute consensus.
> 
> And that is the fundamental problem of this list, a small group of people 
> think they can represent all internet user on earth.
> 
> No, you can not, policy pass here does not reflect true community wish, 
> policy pass here only reflect the consensus of people participating in 
> the discussion, in which by my count, only 20 people?
> 
> People haven’t pay attention or don’t care, does not mean they agree what 
> you.
> 
> 
> 
> On Sat, 2 Sep 2023 at 18:09 Lu Heng  > wrote:
>> Standard form contract favors the party who not doing the drafting.
>> 
>> And I would say many members disagree, a simple questionnaire to members 
>> “do you want to own your IPs?”receives overwhelming positive answer.
>> 
>> And it’s just a policy of a private limited company.
>> 
>> It does not constitute law.
>> 
>> And this part of policy need to be changed and updated in the future to 
>> reflect the market reality.
>> 
>> On Sat, 2 Sep 2023 at 18:05 jordi.palet--- via SIG-policy 
>> mailto:sig-policy@lists.apnic.net>> wrote:
>>> Existing policies, with the consensus of the community, which are part 
>>> of the membership agreement and consequently accepted by all the 
>>> members:
>>> 
>>> 4.0. Resource License
>>> 
>>> It is contrary to the goals of this document and is not in the 
>>> interests of the Internet community as a whole, for Internet number 
>>> resources to be considered freehold property.
>>> 
>>> Neither delegation nor registration confers ownership of resources. 
>>> Account holders that use them are considered “custodians” rather than 
>>> “owners” of the resource and are not entitled to sell or otherwise 
>>> transfer that resource to other parties outside the provisions in this 
>>> document.
>>> 
>>> Internet resources are regarded as public resources that should only be 
>>> distributed according to demonstrated need.
>>> 
>>> The policies in this document are based upon the understanding that 
>>> globally unique unicast address space is licensed for use rather than 
>>> owned. 
>>> 
>>> 
>>> Regards,
>>> Jordi
>>> 
>>> @jordipalet
>>> 
>>> 
 El 2 sept 2023, a las 11:59, Lu Heng >>> > escribió:
 
 Hi Jordi:
 
 Who define those legal rights?
 
 Who said it is not a property?
 
 
 
 On Sat, 2 Sep 2023 at 17:55 jordi.palet--- via SIG-policy 
 mailto:sig-policy@lists.apnic.net>> wrote:
> Really ugly and unfortunate that you compare those things, and I 
> guess against code of conduct.
> 
> I just can insist that you can’t sell something that is not a 
> property. You have the usage rights. You can own a house or have the 
> right to use it (rental), and the right to use it may allow you to 
> transfer that right to another person or not. So not the same 
>>>

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

[Owen DeLong via SIG-policy]

First of all, RIRs don’t convey usage rights. They convey unique registrations.

Now the vast majority of (virtually all) ISPs (fortunately) choose to cooperate 
with the existing registry system,
so that the unique registrations in that registry system are roughly equivalent 
to a right to use, but every RIR
makes it very clear that the registration is _NOT_ a right to route or a 
guarantee that anyone outside of the
RIR system will honor your use of addresses on their routers in any way, shape, 
or form.

Nor does the registration of a prefix in the RIR system convey any exclusive 
right to announce that prefix or
prevent anyone else from doing so. It is the cooperation of ISPs and others who 
actually run routers that provides
that capability to prefix registrants in the RIR system. They are each 
individually free to honor or not any
particular registration in that system as they see fit. There is nothing 
binding upon them to do otherwise.

So you are both sort of correct and both equally wrong.

IP addresses are integers. Claiming ownership of 5 makes about as much sense as 
claiming ownership of
a bank account number or a credit card number or virtually any other number. 
You can’t own an integer
because one of the definitions of ownership is the right to exclude others from 
using that thing.

However, you can own and you can resell the registration of a particular number 
(or set of numbers)
within the RIR system. We routinely get lazy in language and refer to this as 
selling (or transferring)
the numbers themselves, but in reality, what we are transferring is the 
registration of those numbers as
uniquely assigned to us within a particular registry (namely the RIR) system.

It’s also true that the registries themselves don’t want to get involved in the 
business side of those transfers.
If party A and party B appropriately approach the registry and the transfer of 
the addresses is done in
conformance to their policies, they will happily transfer the resources from A 
to B regardless of how much
money was exchanged between B and A or in which direction.

While I think Mr. Lu’s choice to compare it to prostitution was in poor taste, 
I doubt that it violated the CoC
and like it or not, the comparison he was drawing isn’t so far from the truth. 
While some RIR policies
prohibit certain forms of “reselling addresses”, the reality is that remains a 
very gray area of those
policies. To make matters worse, legitimate paid transfers and address resale 
really are much harder
to distinguish than one would first imagine. Especially if you’re attempting to 
make that distinction in
policy language.

Just as it can be hard (impossible) to distinguish money exchanged for time 
spent together vs.
money exchanged for performance of specific “tasks” during that time. The 
latter is illegal in
many jurisdictions while the former is not, but proving that the purpose of the 
exchange was
the latter and not the former can be complicated at best.

YMMV

The bottom line is that this is still a policy proposal which should not be 
adopted for the following
reasons:

1.  It fails to define leasing in a manner which would not allow 
interpretations which are hostile
to common current practice that the authors have stated it is not their 
intent to prohibit.

2.  It fails to achieve solve the problem outlined in the problem statement.

3.  If interpreted literally, it would have very negative ramifications to 
most existing service
providers and their customers.

4.  It’s a deep dive into the minutiae of a tiny fraction of IPv4 
utilization all because it offends
someone’s moral sensibilities without regard for any practical or 
useful policy concern.

5.  IPv4 should have died years ago and this form of rearranging the deck 
chairs simply doesn’t
help the community to move forward. Put the energy that has gone into 
advocating this
proposal into getting key content providers that are still IPv4-only 
moving forward and we
can stop worrying about the scarcity of IPv4.

Owen


> On Sep 2, 2023, at 02:54, jordi.palet--- via SIG-policy 
>  wrote:
> 
> Really ugly and unfortunate that you compare those things, and I guess 
> against code of conduct.
> 
> I just can insist that you can’t sell something that is not a property. You 
> have the usage rights. You can own a house or have the right to use it 
> (rental), and the right to use it may allow you to transfer that right to 
> another person or not. So not the same reselling that transferring addresses, 
> is not just a matter of wording, but about the real meaning of those words, 
> from a legal perspective.
> 
> Regards,
> Jordi
> 
> @jordipalet
> 
> 
>> El 2 sept 2023, a las 11:43, Lu Heng  escribió:
>> 
>> Hi Jordi:
>> 
>> Tell me the difference between reselling and transferring?
>> 
>> Does it equal to the 500 USD someone paid to the girl he met last night? Of 
>> course it’s not prostitution, jus

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

[Owen DeLong via SIG-policy]

> On Aug 31, 2023, at 22:26, Noah  wrote:
> 
> 
> 
> On Thu, 31 Aug 2023, 07:29 Sanjeev Gupta,  > wrote:
>> 
>> 
>> > 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. 
>> 
>> Wait, so NIRs can no longer hand out addresses unless they provide 
>> connectivity?
> 
> 
> Connectivity means addresses being put to proper use...


This is a new definition of the term that I’ve never seen anywhere and does not 
match the plain
English meaning of the word. Can you please provide a written source for this 
definition?

Most importantly, could you provide a reference for the definition of “proper 
use”?

> 
>>   I believe
> 
> 
> So, you are not sure?

I am certain… His belief is correct.

> 
>> they assign/allocate IR without providing connectivity.
> 
> 
> How and why would they do that?

An NIR is a National Internet Registry (e.g. JPNIC). They act much like an RIR,
which also assigns/allocates IR without providing connectivity.

Any assignment or allocation which is revocable, especially when provided for
a time period governed by the payment of a fee could be considered a lease.

Therefore, arguably, RIRs and NIRs lease addresses without connectivity (by any
standard English definition of the term connectivity).

It gets a lot muddier if we adopt your definition of the term connectivity, but 
if we
do that, then an entity leasing to an end user who actually uses the addresses
for legitimate purpose is also perfectly fine and this policy’s stated
intent would be turned completely on its head as the repeatedly stated intent
from the policy authors is to prohibit leasing not associated with connectivity
services.

Of course, one could argue that connectivity services can be achieved by
something as simple as a heavily prepended bop announcement in front
of a GRE tunnel, but that’s a whole other argument.

Owen

___
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

[Owen DeLong via SIG-policy]

If that is the intent, then write a prooposal that says that.

The current proposal does not.

Current policies sort of do and staff certainly has wiggle room to justify the 
actions you describe within the existing proposal.

The proposal you have drafted creates the potential for an argument that ALL 
leasing is prohibited and would, thus, create
a potential to reclaim or revoke existing allocations that are (even by your 
own words) currently perfectly valid.

I remain opposed to this proposal because it doesn’t create policy whose 
outcomes are (necessarily) aligned with its stated objectives.


Owen

> On Aug 30, 2023, at 01:02, jordi.palet--- via SIG-policy 
>  wrote:
> 
> Hi Owen,
> 
> In this version of the proposal, we mention leasing only as an indication of 
> what is not allowed in APNIC policies, despite there is not a definition of 
> that in the policies neither in the proposal, because, as you said, there are 
> many possible cases that will fall into what is allowed (somehow “leasing 
> bundled with connectivity services”). The quid is to properly define what is 
> connectivity service.
> 
> However, what is clear, is that if you approached APNIC to request IP 
> addresses in order to lease them without connectivity services, your request 
> will be rejected, as confirmed by APNIC. So if you say in the request “I will 
> provide ADSL together with the addresses” and in the future you move to 
> “GPON”, that’s fine, is a technological evolution and you’re not going 
> against your original justification of the need, however, if you stop your 
> connectivity services and just lease the addresses not bundled with any kind 
> of connectivity, that’s clearly against the original justified need and it is 
> considered as a policy violation.
> 
> This proposal just want to make that more evident, because today, you need to 
> find it in pieces of text across the policy manual.
> 
> Regards,
> Jordi
> 
> @jordipalet
> 
> 
>> El 4 ago 2023, a las 21:18, Owen DeLong via SIG-policy 
>>  escribió:
>> 
>> As written, this policy is absurd.
>> 
>> Virtually all internet numbers in use are leased by the providers that they 
>> are registered to.
>> 
>> The question here is whether or not to require that connectivity services be 
>> provided as part of the lease arrangement.
>> 
>> I’m OK with whatever the community decides in this regard, though I think 
>> that requiring connectivity services
>> isn’t going to actually have the desired policy effect (there are lots of 
>> cheap ways to provide connectivity
>> to leased addresses that would circumvent the intent of the author).
>> 
>> The situation in other reasons is also mis-stated (or stated in a misleading 
>> way). For example, in ARIN, the actual
>> staff determination (not specified in policy, so subject to challenge) is 
>> that addresses utilized for leasing without
>> connectivity services associated with them do not count as utilized for 
>> purposes of determining eligibility for an
>> additional allocation/assignment. There is no policy or procedure by which 
>> ARIN would attempt to reclaim such
>> addresses based on the fact that they are utilized for non-connected leasing.
>> 
>> Examples of leased addresses in common practice:
>> 
>> 1.   Party Y gets a circuit from $ISP_A. $ISP_A provides party Y with a /24
>>  and allows party Y to announce that /24 to its other providers.
>> 
>> 2.   $CABLECO issues DHCP leases of addresses to residential customers.
>> 
>> 3.   $CABLECO rents blocks of static addresses to Party Y for $X/Month.
>> 
>> 4.   Party Y places servers in a colocation facility and orders network 
>> connecivity
>>  services from $ISP_A, $ISP_B, and $ISP_C. Each of those ISPs provide 
>> some
>>  number of addresses to Party Y for the duration of their contract with 
>> Party Y.
>> 
>> These are all examples of IP leasing that I am pretty sure the author does 
>> not intend
>> to prohibit, yet would technically be prohibited by th policy as written.
>> 
>> Owen
>> 
>> 
>>> On Aug 4, 2023, at 09:59, 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 expr

[sig-policy] Re: Prop-152-v001: Reduce the IPv4 delegation from /23 to /24

[Owen DeLong via SIG-policy]

That makes little to no sense. All that will accomplish is increasing the unused addresses held by those that don’t need them while limiting the ability of those that need addresses to acquire them from those that have them available. I’m not one for abandoning needs-basis, nor am I in favor of hoarding, but this proposal ignores the historical realities of the internet and the current addressing situation. Further, continuing to contort ourselves around the ability to pretend that IPv4 can somehow be sustained is folly. We are long past the point that we should realize that we need a larger address space. For better or worse, v6 is what we have available and the sooner we can progress towards sufficient v6 deployment and the retirement of v4, the better off we will all be. Even Amazon is (finally) publishing  records now, so we are getting closer to the day when eyeball networks can start treating v4 as optional. It’s time to ask sites like Ali Baba, 163, and ten cent to get off the dime. It’s especially pathetic in tencent’s case because their front end is already Akamai where all they have to do is opt in. Akamai will deliver v6 on behalf of their v4 backend. OwenOn Aug 24, 2023, at 04:10, Rajesh Panwala  wrote:Hi Team,As per my opinion, to stop the menace of hoarding of resources and depriving it to the real user, that as new allocation is restricted to/23 , same way transfer from resources holder should also be restricted to /23 in a year This may put some check on hoarding or sort of black marketing. Need to frame policy for the same. Any constructive feedback is welcome.Regards,Rajesh PanwalaFor Smartlink Solutions Pvt Ltd+91-9227886001+91-9426110781On Thu, 24 Aug, 2023, 13:28 Delong.com via SIG-policy,  wrote:

> On Aug 22, 2023, at 05:16, Ashish Agarwal  wrote:
> 
> 
> 
> One basic question, are auctions/ IPV4 brokers  like these permitted  by  IANA / APNIC  ? If  so it makes 
> the   implementation of any restriction very difficult.
> 
> thanks 

Your question sounds simple enough, but it’s very complex.

What possible recourse would APNIC have to restrict an auction of addresses by a US company on behalf of a provider registered in RIPE NCC?

I suppose APNIC could, theoretically block the inbound transfer (assuming that the winning bidder chooses to transfer the addresses into APNIC), but since the transfer (presumably) meets all of the outbound eligibility criteria for RIPE NCC (I’m sure there are some, but I’m equally sure RIPE NCC makes them pretty minimal), but that would violate the APNIC policy as currently written. Changing the APNIC policy to block this would probably make it incompatible with the ARIN policy and open a different can of worms.

So, exactly  what restrictions do you want that don’t currently exist and why do you think they would be beneficial?

Owen

___
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: prop-155-v001: IPv6 PI assignment for associate members

[Owen DeLong via SIG-policy]

In my opinion, any special restrictions on transfers should be removed from the 
proposal. Transfer or not of IPv6 space is an independent policy matter and 
there is no need for any special provisions in this proposal. 

Owen


> On Aug 22, 2023, at 05:04, Srinivas (Sunny) Chendi  wrote:
> 
> -
> 
> Secretariat Impact Assessment: prop-155-v001
> 
> --
> 
> APNIC notes that this proposal aims to allow any Associate member
> to receive a /48 IPv6 Provider Independent (PI) assignment without
> any justification or have any existing IPv4 addresses. Also, the
> proposal recommends the APNIC EC update the APNIC Membership:
> Tiers and Voting Rights Section 2.2 without making any changes to the
> Associate member fee schedule.
> 
> Questions/Comments:
> --
> - This proposal suggests that IPv6 PI address space will be
> non-transferable. However, as per the current IPv6 transfer policy,
> APNIC will recognize and process the transfer of IPv6 addresses as
> the result of a Merger & Acquisition. If the authors' intent is to
> stop the transfer of IPv6 PI assignments, a proposal to amend the
> current policy Section 13.0 IPv6 Transfers would be required.
> 
> Implementation:
> --
> This proposal's implementation is dependent on the APNIC EC review
> of APNIC Membership: Tiers and Voting Rights.
> 
> Regards,
> Sunny
> 
>> On 18/08/2023 12:34 pm, Bertrand Cherrier wrote:
>> Dear SIG members,
>> 
>> A new proposal "prop-155-v001: IPv6 PI assignment for associate members"
>> has been sent to the Policy SIG for review.
>> 
>> It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on
>> Thursday, 14 September 2023.
>> 
>> https://conference.apnic.net/56/program/program/#/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-155
>> 
>> Regards,
>> Bertrand, Shaila, and Anupam
>> APNIC Policy SIG Chairs
>> 
>> 
>> ---
>> 
>> prop-155-v001: IPv6 PI assignment for associate members
>> 
>> 
>> 
>> Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)
>>   Simon Baroi (sba...@gmail.com)
>> 
>> 
>> 1. Problem statement
>> 
>> The first tier of membership in APNIC is called "Associate." According to 
>> APNIC-121 (APNIC Membership: Tiers and Voting rights) Section 2.1 and 2.2, 
>> Associate members do not receive any IPv4 or IPv6 address space. However, 
>> APNIC Members with a delegated IPv4 address block but no IPv6 space are 
>> instantly eligible for an appropriately sized IPv6 block without 
>> restrictions.
>> 
>> If an entity requests only IPv6 assignment and has no IPv4 delegation, then 
>> as per APNIC-127 section 9.1.4 "Provider Independent IPv6 assignments” they 
>> must submit a detailed usage plan for at least 12 months following the 
>> allocation, with a minimum assignment size of /48. This incurs annual fees 
>> of AUD 1,180 based on the HD ratio.
>> 
>> This policy is seen as a barrier to deploying IPv6, especially for personal 
>> use, as it doesn't incentivize IPv6 assignment alone. The proposal aims to 
>> address this issue by providing a Provider Independent assignment to 
>> Associate members with minimum justifiable eligibility. This change will 
>> remove the barrier and facilitate IPv6 deployment.
>> 
>> 
>> 2. Objective of policy change
>> -
>> Provide an incentive to small enterprises and academia/researchers to 
>> receive IPv6 assignment.
>> 
>> 
>> 3. Situation in other regions
>> -
>> RIPE NCC: IPv6 PI can be sponsored by an LIR (EUR 50/yr)
>> ARIN: As an end-user IPv6 only can be requested following certain criteria
>> AFRINIC: Must not be an LIR
>> LACNIC: Not been an LIR or ISP, submit addressing plans for at least a year
>> 
>> https://www.nro.net/wp-content/uploads/RIR-Comparative-Policy-Overview-2023-Q2.pdf
>>  
>> Section 3.4.3 - END USERS
>> 
>> 
>> 4. Proposed policy solution
>> ---
>> Summary of Proposed Changes:
>

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

[Owen DeLong via SIG-policy]

Assigned is still leased in one form or another unless that assignment is portable and the customer can take it with them when they leave the carrier I. Question. That’s not generally the case. OwenOn Aug 13, 2023, at 02:49, Noah  wrote:I know a lot of end-users who went to the RIR to ask for /24 assignments.I also know customers who are assigned /24 by their connectivity providers. The key word is assigned not leased. Infact they often have to justify to their connectivity providers why they need a /24 assigned above and beyond the /30 or /31 that enables the services between the customer and their providers.Owen, it's not leasing. Its assignment since an LIR is mandated to do so to end users.Cheers,./noahOn Sun, Aug 13, 2023 at 8:10 AM Owen DeLong via SIG-policy <sig-policy@lists.apnic.net> wrote:There are many customers that have a /24 or more leased from their provider. Claiming that anyone needing a /24 or shorter prefix must go to an RIR or the market is current reality, but not historically true. Lots of older provider assignments of /24 and shorter prefixes exist in the wild and persist in use today.

Owen


> On Aug 12, 2023, at 05:12, Christopher H <ch...@thesysadmin.dev> wrote:
> 
> Hello Team,
> 
> I am in support of the concept, however I believe some policy wording changes need to be made, in order to ensure that it does not impact members who have a legitimate business case for leasing IP addresses.
> 
> There are businesses who do lease IP resources as part of a service, for example, businesses may also lease subnets smaller than a /24 to customers who may have a business internet service. In circumstances where a resource user requires greater than a /25 (i.e. a /24 or larger) they either need to acquire resources directly from APNIC or through a market transfer. I don't believe it is the intention of this policy to restrict these types of services however under the current wording would technically be in breach of the policy.
> 
> The policy needs to be worded in a way, that prevents members from leasing IP resources themselves as the only service, without any other services (such as transit) from being supplied. This is generally what organisations may do when they hold resources they no longer require or obtain resources from the registry with the sole intention of leasing them, and provide false or misleading information to acquire them.
> 
> Should APNIC make a determination that a resource holder is leasing out resources in breach of this policy, then the resource holder needs to either transfer the resources directly to the lessee or return the resources back to APNIC for further delegations to other members/applicants.
> 
> Regards,
> Christopher H.
> ___
> 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 - 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

[Owen DeLong via SIG-policy]

There are many customers that have a /24 or more leased from their provider. 
Claiming that anyone needing a /24 or shorter prefix must go to an RIR or the 
market is current reality, but not historically true. Lots of older provider 
assignments of /24 and shorter prefixes exist in the wild and persist in use 
today.

Owen


> On Aug 12, 2023, at 05:12, Christopher H  wrote:
> 
> Hello Team,
> 
> I am in support of the concept, however I believe some policy wording changes 
> need to be made, in order to ensure that it does not impact members who have 
> a legitimate business case for leasing IP addresses.
> 
> There are businesses who do lease IP resources as part of a service, for 
> example, businesses may also lease subnets smaller than a /24 to customers 
> who may have a business internet service. In circumstances where a resource 
> user requires greater than a /25 (i.e. a /24 or larger) they either need to 
> acquire resources directly from APNIC or through a market transfer. I don't 
> believe it is the intention of this policy to restrict these types of 
> services however under the current wording would technically be in breach of 
> the policy.
> 
> The policy needs to be worded in a way, that prevents members from leasing IP 
> resources themselves as the only service, without any other services (such as 
> transit) from being supplied. This is generally what organisations may do 
> when they hold resources they no longer require or obtain resources from the 
> registry with the sole intention of leasing them, and provide false or 
> misleading information to acquire them.
> 
> Should APNIC make a determination that a resource holder is leasing out 
> resources in breach of this policy, then the resource holder needs to either 
> transfer the resources directly to the lessee or return the resources back to 
> APNIC for further delegations to other members/applicants.
> 
> Regards,
> Christopher H.
> ___
> 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: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

Renumbering an enterprise is hard.

Renumbering an IXP even a large one is relatively simple and has been done 
multiple times.

I still don’t support the proposal, but I think that the “renumbering is hard” 
argument rings a bit hollow when it comes to IXPs.

The process boils down to:
1.  send out notice and map of old addresses to new addresses.
2.  Add new addresses to route servers (if applicable)
3.  Give time for providers to bring up all the new peering 
sessions on the new addresses (in parallel to the existing ones)
4.  Turn off the peering sessions with the old addresses on the 
route servers (if applicable)
5.  Set a flag day for turning off peering sessions on old 
addresses.
6.  Filter TCP/179 traffic to old addresses on flag day. (let other 
traffic continue to pass)
7.  Wait for traffic from deprecated peering sessions to drain off
8.  Set a flag day to deprecate the old addresses
9.  Filter the old addresses on the flag day.

Is it pain free? Not entirely, but relatively so. Main source of pain is 
providers that have to scramble after they
ignore the flag day notices.

Is it particularly complicated or difficult? No, not really and if providers 
are paying attention and cooperate before
the flag day, it can be non-disruptive and relatively pain free.

Owen


> On Aug 12, 2023, at 00:37, Christopher H  wrote:
> 
> Hello Team,
> 
> I support parts of this proposal, while I oppose others.
> 
> In some economies (to use Australia as an example), there are significant 
> numbers of network operators. If an IXP were to start out and then have a 
> requirement to re-number and expand, the bigger the IX becomes the harder it 
> becomes to renumber. Let's look at MegaIX Sydney, and hypothesise that this 
> policy was in place when they were reaching 80% utilisation (204 IP 
> addresses) of a /24 subnet. It would be a significant challenge for all 204 
> peers, plus the route servers, to renumber and re-establish their peering 
> sessions. The more peers you have, the harder it becomes.
> 
> Let's look at other economies such as Vanuatu, where they have such a small 
> IX. I feel that in circumstances like this, it's not justifiable to allocate 
> an entire /24 to an IX which has less than 5 peers. Given the size of the 
> economy, it's unlikely (for the foreseeable future) that they will see 
> requirements for anything greater than a /26 subnet.
> 
> Having said the above, we cannot discriminate economies based on the number 
> of participants in delegating assignments. It may be better suited to 
> restrict delegations to a /24 then if the need arises to renumber to a /23 
> they are given a 6-month window to return the former holding, and if they 
> need to go from a /22 they are given 12 months. Whilst they hold these 
> resources during the transition, they are responsible for any membership fees.
> 
> Regards,
> Christopher H.
> ___
> 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: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

>  
>> The providers on the exchange points can still exchange IPv4 NLRI via IPv6 
>> peering sessions and forward IPv4 data grams to the correct MAC next-hop 
>> learned via IPv6 ND. 
>> 
>> This is already in widespread use. It’s a bit hacking, but it works and 
>> doesn’t require additional IPv4 addresses. 
> 
> Can you give me an example of IXP where the peering lan is IPv6 only?
>  

I cannot (yet), but I can point to plenty of peering sessions where IPv4 and 
IPv6 NLRI are passed over a single IPv6 peering session. Some on exchanges, 
many on private links. 

Point is that an IXP doesn’t technically need IPv4 addresses on the IX in order 
to support dual stack peering sessions. It’s a nice to have and less confusing 
to have v4 over v4 and v6 over v6, but when we run out of v4 addresses for 
IXPs, that won’t be as painful as, say not being able to put v4 addresses on 
web servers or DNS servers. 

Owen

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

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

[Owen DeLong via SIG-policy]

Oppose. Rearranging deck chairs to smaller ixp prefixes is a step away from goodness. I do support removing the /23 cap for IXPs that demonstrate need for shorter prefixes. I do not support RIR assignments or allocations longer than /24 in IPv4 or /48 in IPv6. When we run out, IXPs can move to v6only. The providers on the exchange points can still exchange IPv4 NLRI via IPv6 peering sessions and forward IPv4 data grams to the correct MAC next-hop learned via IPv6 ND. This is already in widespread use. It’s a bit hacking, but it works and doesn’t require additional IPv4 addresses. OwenOn Aug 7, 2023, at 21:14, Shaila Sharmin  wrote:Dear SIG members,A new proposal "prop-154-v001: Resizing of IPv4 assignment for the IXPs" has been sent to the Policy SIG for review.It will be presented at the Open Policy Meeting (OPM) at APNIC 56 on Thursday, 14 September 2023. https://conference.apnic.net/56/program/program/#/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-154Regards,Bertrand, Shaila, and AnupamAPNIC Policy SIG Chairs---prop-154-v001: Resizing of IPv4 assignment for the IXPsProposer: Simon Sohel Baroi (sba...@gmail.com)       Aftab Siddiqui1. Problem statementAccording to APNIC Internet Number Resource Policies ( Ref – APNIC-127,Dated: 22 DEC, 2022 ),an Internet Exchange Point ( IXP ) is eligible to receive a maximum /23of IPv4 and /48 of IPv6resources. Usually APNIC assign one /24 to start a new IXP. But fromanalysis through PeeringDB,we found most of the places the resources have been under-utilised and newIXPs are wasting a largeamount of valuable IPv4 spaces. On the other side there are large IXP,who can’t grow due tolack of IP resources, where /23 is not enough as the membership numberis big. The size of theminimum and maximum range of IP delegation to new or existing IXPs isthe main problem in thecurrent policy.Present IXP Status in APAC region from PeeringDB [5] :+---+---++---+---+|  IX Names | Peers | Vs | Peers |  IXNames |+---+---+ +---+---+| BBIX Tokyo    |  299  |    |   17  |BBIX-Thailand |+---+---+ +---+---+| JPIX TOKYO    |  257  |    |   3   |MekongIX  |+---+---+ +---+---+| Equinix Tokyo |  131  |    |   2   | EquinixMumbai    |+---+---+ +---+---+| JPNAP Tokyo   |  211  |    |   13  | npIXJWL  |+---+---+ +---+---+| HKIX  |  296  |    |   3   | Vanuatu InternetExchange |+---+---+ +---+---+| Equinix Hong Kong |  216  |    |   4   |MyNAP |+---+---+ +---+---+| Equinix Singapore |  422  |    |   25  | DE-CIX KualaLumpur   |+---+---+ +---+---+| IIX-Jakarta   |  449  |    |   13  |IIX-Lampung   |+---+---+ +---+---+| DECIX-Mumbai  |  446  |    |   14  | DecixKolkata |+---+---+ +---+---+| MegaIX Sydney |  232  |    |   46  | EdgeIX -Melbourne    |+---+---++---+---+2. Objective of policy change-The objective of this proposal is to modify the default size of IPv4assignments for IXPsfrom /23 to /26, which can receive a replacement up to a maximum of a/22, provided theIXP returns the IPv4 address space previously assigned to them.3. Situation in other regions-Similar policy has been adopted by RIPE NCC ( ripe-733 :  IPv4 AddressAllocation andAssignment Policies for the RIPE NCC Service Region ) [4]4. Proposed policy solution---Current Policy text:6.2.4. IPv4 for Internet Exchan

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

[Owen DeLong via SIG-policy]

As written, this policy is absurd.

Virtually all internet numbers in use are leased by the providers that they are 
registered to.

The question here is whether or not to require that connectivity services be 
provided as part of the lease arrangement.

I’m OK with whatever the community decides in this regard, though I think that 
requiring connectivity services
isn’t going to actually have the desired policy effect (there are lots of cheap 
ways to provide connectivity
to leased addresses that would circumvent the intent of the author).

The situation in other reasons is also mis-stated (or stated in a misleading 
way). For example, in ARIN, the actual
staff determination (not specified in policy, so subject to challenge) is that 
addresses utilized for leasing without
connectivity services associated with them do not count as utilized for 
purposes of determining eligibility for an
additional allocation/assignment. There is no policy or procedure by which ARIN 
would attempt to reclaim such
addresses based on the fact that they are utilized for non-connected leasing.

Examples of leased addresses in common practice:

1.  Party Y gets a circuit from $ISP_A. $ISP_A provides party Y with a /24
and allows party Y to announce that /24 to its other providers.

2.  $CABLECO issues DHCP leases of addresses to residential customers.

3.  $CABLECO rents blocks of static addresses to Party Y for $X/Month.

4.  Party Y places servers in a colocation facility and orders network 
connecivity
services from $ISP_A, $ISP_B, and $ISP_C. Each of those ISPs provide 
some
number of addresses to Party Y for the duration of their contract with 
Party Y.

These are all examples of IP leasing that I am pretty sure the author does not 
intend
to prohibit, yet would technically be prohibited by th policy as written.

Owen


> On Aug 4, 2023, at 09:59, 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 
> )
>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 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 
> connectivity service, as it was documented with the original need 
> justification.
> 
> 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 purpo

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

[Owen DeLong via sig-policy]

In use != Announced.

There are many uses for IP addresses (including legitimate uses of GUA) that 
don’t make their way into any routing table you can see.

Owen


> On Jan 26, 2023, at 22:06, Rajesh Panwala  wrote:
> 
> Hello Sunny and Team,
> 
> Is there any routing table analysis available, which shows how many of these 
> historical pools are really in use ( announced) ? This can help for better 
> decision making while framing policy.
> 
> Regards,
> 
> Rajesh Panwala
> For Smartlink Solutions Pvt. Ltd.
> +91-9227886001
> +91-9426110781
> 
> On Fri, Jan 27, 2023 at 11:30 AM Srinivas (Sunny) Chendi  > wrote:
>> Hi Guarav and all,
>> 
>> Sorry for the delay. These are the current total number of historical IPv4 
>> addresses in each economy under APNIC management.
>> 
>>  
>> Economy
>> 
>> Historical IPv4 (number of /24s)
>> 
>> JP 
>> 
>> 155026
>> 
>> au 
>> 
>> 64043
>> 
>> tw 
>> 
>> 14878
>> 
>> kr 
>> 
>> 12471
>> 
>> nz 
>> 
>> 7408
>> 
>> hk 
>> 
>> 3953
>> 
>> sg 
>> 
>> 2957
>> 
>> th 
>> 
>> 2934
>> 
>> cn 
>> 
>> 1861
>> 
>> in 
>> 
>> 1149
>> 
>> id 
>> 
>> 817
>> 
>> bn 
>> 
>> 514
>> 
>> my 
>> 
>> 512
>> 
>> mo 
>> 
>> 265
>> 
>> fj 
>> 
>> 264
>> 
>> ph 
>> 
>> 172
>> 
>> lk 
>> 
>> 128
>> 
>> pg 
>> 
>> 18
>> 
>> pk 
>> 
>> 17
>> 
>> mu 
>> 
>> 8
>> 
>> bd 
>> 
>> 6
>> 
>> np 
>> 
>> 6
>> 
>> nf 
>> 
>> 5
>> 
>> nc 
>> 
>> 4
>> 
>> sb 
>> 
>> 2
>> 
>> gu 
>> 
>> 1
>> 
>> pf 
>> 
>> 1
>> 
>> us 
>> 
>> 1
>> 
>>  
>> Regards,
>> Sunny
>> 
>> 
>> On 20/01/2023 2:02 pm, Gaurav Kansal wrote:
>>> I would request APNIC Secretariat to publish country wise number of 
>>> historical account holder and number of IP owned by each account holder.
>>> For the sake of privacy, account holder name may not be published.
>>> 
>>> Regards,
>>> Gaurav Kansal
>>> 
>>> 
 On 20-Jan-2023, at 08:22, sig-policy@lists.apnic.net 
  wrote:
 
 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-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN

[Owen DeLong via sig-policy]

I think the problem is overstated in that a ROA authorizing origination from an 
unallocated ASN is not necessarily a security risk.

Personally, I don’t see significant benefit to this proposal. I think 
guidelines are sufficient. People who wish to violate the guidelines, well, to 
quote Mr. Bush, “I encourage my competitors to try this.”

Owen


> On Jan 29, 2023, at 16:54, Bertrand Cherrier  wrote:
> 
> Dear SIG members,
> 
> A new version of the proposal "prop-150: ROA/whois object with Private,
> Reserved and Unallocated (reserved/available) Origin ASN" has been sent to
> the Policy SIG for review.
> 
> It will be presented at the Open Policy Meeting (OPM) at APNIC 55 on
> Wednesday, 1 March 2023.
> 
> https://conference.apnic.net/55/program/schedule/#/day/10
> 
> We invite you to review and comment on the proposal on the mailing list
> before the OPM.
> 
> The comment period on the mailing list before the OPM is an important
> part of the Policy Development Process (PDP). We encourage you to
> express your views on the proposal:
> 
>   - Do you support or oppose this proposal?
>   - Does this proposal solve a problem you are experiencing? If so,
> tell the community about your situation.
>   - Do you see any disadvantages in this proposal?
>   - Is there anything in the proposal that is not clear?
>   - What changes could be made to this proposal to make it more effective?
> 
> Information about this proposal is appended below as well as available at:
> 
> http://www.apnic.net/policy/proposals/prop-150
> 
> Regards,
> Bertrand, Shaila, and Anupam
> Chairing the best SIG of all : The APNIC Policy SIG
> 
> 
> --
>  
> 
> prop-150-v002: ROA/whois object with Private, Reserved and Unallocated 
> (reserved/available) Origin ASN
> 
> --
>  
> 
> Proposer: Aftab Siddiqui (aftab.siddi...@gmail.com)
> 
> 
> 1. Problem statement
> 
> Prop-138v2 was converted into a guideline with the understanding that it will 
> help members to understand not to create ROA with Private, Reserved and 
> unallocated ASN range. Unfortunately, there are still ROAs with specified 
> ranges.
> 
> Additionally, if a member creates a ROA with someone else's ASN as Origin and 
> if APNIC reclaims that ASN due to any policy reason (non-payment, account 
> closure etc) then this leaves a security issue for the member.
> 
> 
> 2. Objective of policy change
> -
> Restrict APNIC members to create ROAs with private, reserved or unallocated 
> ASN. Also, notify members if the Origin ASN in their ROA has been unallocated 
> (reserved/available) and don't automatically renew those ROAs with 
> unallocated (reserved/available) ASN.
> 
> 
> 3. Situation in other regions
> -
> ROAs containing Private and Reserved ASN are visible from APNIC, LACNIC and 
> RIPE NCC region.
> 
> 
> 4. Proposed policy solution
> ---
> Route Origin Authorisation (ROA) is an RPKI object signed by a prefix holder 
> authorising origination of said prefix from an origin AS specified in said 
> ROA. It verifies whether an AS is authorised to announce a specific IP prefix 
> or not. ROA contains 3 mandatory fields Prefix, Origin AS and Maxlength.
> 
> Prefix: The prefix you would like to originate from the specified ASN. IPv4 
> and IPv6 Prefixes listed under "Internet Resources" on My APNIC portal can 
> only be used here.
> 
> Origin AS: The authorised ASN which can originate the "Prefix". The origin AS 
> can only be from the IANA specified range and MUST not contain an ASN from:
> 
> - 23456# AS_TRANS RFC6793
> - 64496-64511  # Reserved for use in docs and code RFC5398
> - 64512-65534  # Reserved for Private Use RFC6996
> - 65535# Reserved RFC7300
> - 65536-65551  # Reserved for use in docs and code RFC5398
> - 65552-131071 # Reserved
> - 42-4294967294# Reserved for Private Use RFC6996
> - 4294967295   # Reserved RFC7300
> 
> And any IANA unallocated ASN. Route Management system should inform the 
> member why these Origin ASNs are not acceptable. AS0 (zero) is also a 
> Reserved ASN (RFC7607) but will be exempted from this restriction as AS0 is 
> reserved by the IANA such that it may be used to identify non-routed networks 
> (RFC6483 Sec 4).
> 
> - Same policy should be applied to corresponding route/route6 whois objects.
> - ROAs and route/route6 objects already in the database with Private, 
> Reserved and unallocated ASN MUST NOT be renewed (after expiry) and deleted 
> respectively after notifying the prefix holder.
> 
> Part B - Notify in case of Origin ASN has been marked as unallocated 
> (reserved/available)
> 
> When a member creates a ROA with Ori

[sig-policy] Re: SIG elections changes proposal

[Owen DeLong via sig-policy]

Correct me if I’m wrong, but doesn’t conference registration usually open some 
time prior to the start of the conference?

Suggest amending 3.4.3(1) to read as follows:

1. Registered and attending the current conference in person. The
attendee must be checked-in at the on-site registration desk at any time
from the opening of on-site registration until 10:00 AM (conference local
time) on the final day of the conference.

3.7 needs greater specificity as to who needs to come to consensus and how
and by whom that consensus is determined.

The final paragraph under 3.7 really should be a new numbered topic (3.8?)

Owen


> On Jan 26, 2023, at 19:04, Bertrand Cherrier  wrote:
> 
> Dear colleagues,
> 
> Please note that a proposal to change the APNIC SIG Guidelines will be
> discussed at APNIC 55 in Manila, Philippines on 28 February 2023.
> 
> The proposal will be presented at a Joint SIGs meeting for community
> input and support. If agreed, the new document will be circulated for
> an Editorial Draft comment period following APNIC 55.
> 
> Please find the proposal text below.
> 
> The current SIG Guidelines are available here:
> 
> https://www.apnic.net/community/participate/sigs/sig-guidelines/
> 
> We encourage you to express your views regarding the proposed changes on
> the mailing list and/or at the Joint SIGs meeting.
> 
> Kind regards,
> Joy and Bertrand
> 
> 
> 
> 
> Update election procedures in the SIG Guidelines
> 
> 
> 
> Proposers:Bertrand Cherrier (b.cherr...@mynet.nc)
>   Joy Chan (joyc...@twnic.tw)
> 
> 
> 1. Problem statement
> 
> During the community elections held at APNIC 54, anomalies were observed
> in the conference registration list and in patterns of online
> participation. An analysis of the data showed there was no impact on the
> APNIC 54 SIG elections. However, APNIC 54 registration and attendance
> data did indicate significant potential for manipulation of the existing
> rules and procedures in future elections.
> 
> A copy of the election analysis report is available:
> https://blog.apnic.net/wp-
> content/uploads/2022/10/APNIC54-Election-report.pdf
> 
> A high number (291) of questionable registrations from a single
> organisation was notable, as the suspect registrations will be entitled
> to vote in future elections, under current rules. This may be
> interpreted as a manipulation of the election rules, in an attempt to
> dominate future elections.
> 
> The implications are significant. SIG elections normally attract 50-100
> votes; therefore an organised voting bloc of 250+ would determine
> election results in future.
> 
> The difficulty of confirming the identities of voters indicates a
> further vulnerability to SIG elections. Prior to online elections, all
> SIG voting was in-person at a conference so voter identities could be
> confirmed.
> 
> 
> 2. Objective of policy change
> -
> To ensure the integrity of APNIC SIG elections.
> 
> 
> 3. Situation in other regions
> -
> Following are links to the election processes for similar roles in other
> RIR regions. Each region uses a different method for electing or
> appointing community representatives.
> 
> AFRINIC Policy Development Working Group:
> https://afrinic.net/policy/development-working-group#selection
> 
> ARIN Advisory Council:
> https://www.arin.net/participate/oversight/elections/processes/
> 
> LACNIC Public Policy Forum Chairs:
> https://www.lacnic.net/736/2/lacnic/process-and-requerimentos-for-the-
> elections-of-the-public-policy-forum
> 
> RIPE WG Chairs: https://www.ripe.net/publications/docs/ripe-692
> 
> 
> 4. Proposed solution
> 
> The SIG Guidelines document the procedures for SIG elections:
> https://www.apnic.net/community/participate/sigs/sig-guidelines/#
> _Toc70085862
> 
> Replace sections 3.3, 3.4, 3.4.1, 3.4.3, 3.4.5, and 3.7 in the SIG
> Guidelines with the following text:
> 
> 3.3 Criteria for election If more than one nomination is received by the
> closure date, an election must be held. If there is only one candidate,
> the candidate will be elected via acclamation in the SIG meeting room.
> 
> 3.4 Election procedures Elections will use the same online voting system
> as APNIC EC and NRO NC elections.
> 
> 3.4.1 Nominations
> - Nominations are managed by the APNIC Secretariat.
> - Nominees must reside within the Asia Pacific service region. Staff
> members of any Regional Internet Registry (RIR) are ineligible for
> nomination.
> - Individuals cannot hold more than one elected position
> (EC, SIG, or NRO NC). Those who are elected to a new position must
> resign from any other currently held EC, SIG or NRO NC position as soon
> as practicable but no later than 30 days following the election.
> - Self-nominations are permitted

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

[Owen DeLong via sig-policy]

RIPE does have specified processes for dealing with Legacy resources without 
contract.

So neither the first half nor the second half holds true.

Also, AFRINIC preserves legacy status across transfers IIRC.

Owen


> On Jan 20, 2023, at 15:40, Owen DeLong via sig-policy 
>  wrote:
> 
>> 
>> 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

___
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

[Owen DeLong via sig-policy]

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

[sig-policy] Re: Sec 4.2.1 - Recovery of Unused Historical Resources

[Owen DeLong via sig-policy]

I will point out that unannounced != unused. There are plenty of legitimate 
cases for needing globally unique addresses that are not necessarily announced 
in the global routing table. Exchange points are one example. Private networks 
that interact with multiple internet-connected networks is another. 

Owen


> On Aug 2, 2022, at 03:47, Anupam Agrawal  wrote:
> 
> 
> All-
> 
> Section 4.2.1 of APNIC Internet Number Resource Policies (APNIC -127) states 
> that a significant amount of historical resources registered in the APNIC 
> Whois database are not announced to the global routing table.  What's the 
> number we are talking about?
> 
> Further, it has been mandated in the same section that APNIC needs to contact 
> networks responsible for resources not globally used for a reasonable period 
> of time. What's the period being considered currently? Will it make sense to 
> have a time period included for proactive action?
> 
> Regards
> 
> Anupam Agrawal | India Internet Foundation - Chair | 91 990 399 2838
> 
> ___
> 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

Re: [sig-policy] prop-141-v003: Change maximum delegation, size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses

[Owen DeLong]

Opposed.

Not in favor of moving to non-prefix aligned allocations from an RIR.

Owen


> On Sep 14, 2021, at 20:37 , Bertrand Cherrier  
> wrote:
> 
> Dear SIG members,
> 
> A new version of the proposal "prop-141-v003: Change maximum delegation
> size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses" 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 earlier versions is available at:
> 
> http://www.apnic.net/policy/proposals/prop-141
> 
> Regards,
> Bertrand and Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> --
>  
> 
> prop-141-v003: Change maximum delegation size of IPv4 address from 512 ( /23 
> ) to 768 (/23+/24) addresses.
> 
> ---
>  
> 
> Proposer: Simon Sohel Baroi (sba...@gmail.com)
>   Aftab Siddiqui (aftab.siddi...@gmail.com)
> 
> 
> 1. Problem statement
> 
> According to the APNIC IPv4 Address 
> Report,(https://www.apnic.net/manage-ip/ipv4-exhaustion/ ) the available
> and reserve pool size is as follows:
> 
> Available Pool : IP Address 3,782,144 | 14,774 Of /24
> Reserved Pool : IP Address 1,831,680 | 7,155 Of /24
> 
> If APNIC continues to delegate IPv4 in size of /23 with the average growth 
> rate of 145 x /23 delegations per
> month the pool will be exhausted around Aug/Sep 2027. Which means the huge 
> number of IPv4 addresses will be
> unused for a long time and large community members will still remain behind 
> the NAT box or even without
> Internet Connectivity.
> 
> 
> 2. Objective of policy change
> -
> The current final /8 allocation policy [1] advise that the current minimum 
> delegation size for IPv4 is 256 (/24)
> addresses and each APNIC account holder is only eligible to receive IPv4 
> address delegations totaling a maximum
> 512 (/23) addresses from the APNIC 103/8 IPv4 address pool. (6.1. Minimum and 
> maximum IPv4 delegations)
> 
> This is a proposal to change the maximum size of IPv4 address delegations 
> from the available IPv4 address pool to
> a totaling of 768 (/23+/24) addresses. This proposal also indicates how APNIC 
> will distribute the IPv4 resources
> systematically when the available pool size reduces.
> 
> Increasing the maximum IPv4 delegation size from 512 ( /23 ) to 768 (/23+/24) 
> address pool will allow Newcomers
> and also Existing APNIC account holders to get maximum number of IPv4 address 
> resources.
> 
> 
> 3. Situation in other regions
> -
> There is no similar policy in place in other RIR regions.
> 
> 
> 4. Proposed policy solution
> ---
> It is recommended to increase the IPv4 address delegation size from 512 max 
> (/23) to 768 (/23 + /24). The address
> space can now be allocated from the available 103/8 last /8 block and/or from 
> non 103/8 recovered address blocks.
> This policy will continue until the available + reserved pool comes down to 
> 900,096 IPv4 addresses i.e. < 3516x/24,
> once reaching this threshold the maximum delegation size will revert back to 
> 512 IPv4 addresses (/23) and will
> continue to do so until the available + reserved pool comes down to 256,000 
> IPv4 addresses i.e 1000x/24 then the
> delegation size will further reduce to 256 IPv4 addresses i.e. /24.
> 
> The very first time the reserved and available pool goes below 190,000 IPv4 
> addresses, then the IPv4 reserved pool
> (APNIC-127 Section 5.1.1) for Future Use of /16 (i.e. 256 x /24s) will be 
> added to the available pool.
> 
> It is proposed to modify the section 6.1 maximum IPv4 delegations of the 
> APNIC Internet Number Resource Policies [1]
> accordingly.
> 
> Current Policy text :
> 
> Since Thursday, 28 February 2019, each APNIC account holder is only eligible 
> to receive IPv4 address delegations
> totalling a maximum /23 from the APNIC 103/8 IPv4 address pool.
> 
> New Policy text :
> 
> New APNIC Member is only eligible to receive IPv4 address delegations 
> totalling a maximum 768 (/23+/24) from the
> APNIC availab

Re: [sig-policy] prop-141-v002: Change maximum delegation, size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses

[Owen DeLong]

I have no strong opinion positive or negative towards the proposal overall.

I do oppose going from /23 to 0.75 /22. If we’re going to do this, let’s just go
from /23 to /22 and keep things on prefix boundaries.

Owen


> On Sep 7, 2021, at 15:02 , Bertrand Cherrier  wrote:
> 
> Dear SIG members,
> 
> A new version of the proposal "prop-141-v002: Change maximum delegation
> size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses" 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 earlier versions is available at:
> 
> http://www.apnic.net/policy/proposals/prop-141
> 
> Regards,
> Bertrand and Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> --
>  
> 
> prop-141-v002: Change maximum delegation size of IPv4 address from 512 ( /23 
> ) to 768 (/23+/24) addresses.
> 
> ---
>  
> 
> Proposer: Simon Sohel Baroi (sba...@gmail.com)
>   Aftab Siddiqui (aftab.siddi...@gmail.com)
> 
> 
> 1. Problem statement
> 
> According to the APNIC IPv4 Address 
> Report,(https://www.apnic.net/manage-ip/ipv4-exhaustion/ ) the available
> and reserve pool size is as follows:
> 
> Available Pool : IP Address 3,782,144 | 14,774 Of /24
> Reserved Pool : IP Address 1,831,680 | 7,155 Of /24
> 
> If APNIC continues to delegate IPv4 in size of /23 with the average growth 
> rate of 145 x /23 delegations per
> month the pool will be exhausted around Aug/Sep 2027. Which means the huge 
> number of IPv4 addresses will be
> unused for a long time and large community members will still remain behind 
> the NAT box or without Internet
> Connectivity.
> 
> 
> 2. Objective of policy change
> -
> The current final /8 allocation policy [1] advise that the current minimum 
> delegation size for IPv4 is 256 (/24)
> addresses and each APNIC account holder is only eligible to receive IPv4 
> address delegations totaling a maximum
> 512 (/23) addresses from the APNIC 103/8 IPv4 address pool. (6.1. Minimum and 
> maximum IPv4 delegations)
> 
> This is a proposal to change the maximum size of IPv4 address delegations 
> from the available IPv4 address pool to
> a totaling of 768 (/23+/24) addresses. This proposal also indicates how APNIC 
> will distribute the IPv4 resources
> systematically when the available pool size reduces.
> 
> Increasing the maximum IPv4 delegation size from /23 to /23+/24 IPv4 address 
> pool will allow Newcomers and also
> Existing APNIC account holders who only received /23 after Thursday, 28 
> February 2019 to receive 256 (/24) IPv4
> addresses.
> 
> 
> 3. Situation in other regions
> -
> There is no similar policy in place in other RIR regions.
> 
> 
> 4. Proposed policy solution
> ---
> It is recommended to increase the IPv4 address delegation size from 512 max 
> (/23) to 768 (/23 + /24). The address
> space can now be allocated from the available 103/8 last /8 block and/or from 
> non 103/8 recovered address blocks.
> This policy will continue until the available + reserved comes down to less 
> than 900,000 IPv4 addresses i.e.
> < 3515x/24, once reaching this threshold the maximum delegation size will 
> revert back to 512 IPv4 addresses (/23)
> and will continue to do so until the available + reserved block comes down to 
> 256,000 IPv4 addresses i.e 1000x/24
> then the delegation size will further reduce to 256 IPv4 addresses i.e. /24. 
> The very first time the reserved and
> available pool goes below 190,000 IPv4 addresses then the IPv4 reserved pool 
> (APNIC-127 Section 5.1.1) for Future
> Use of /16 (i.e. 256 x /24s) will be added to the available pool.
> 
> Thresholds for IPv4 addresses (Available + Reserved):
> 
> - More than 900,000 IPv4 addresses: Delegation /23 + /24
> - Less than 900,000 IPv4 addresses AND More than 256,000 IPv4 addresses: 
> Delegation /23
> - Less than 256,000 IPv4 addresses: Delegation /24
> - Less than 190,000 IPv4 addresses - add APNIC-127 5.1.1 Reserved /16 to 
> availa

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

[Owen DeLong]

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" 
>   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&D
> 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
> 

Re: [sig-policy] New version - prop-133-v002: Clarification on Sub-Assignments

[Owen DeLong]

I agree… I don’t think there is any benefit to this policy and I oppose adding 
IPv6 to inter-RIR transfers of any form.

Owen


> On Feb 16, 2020, at 20:20 , Tsurumaki, Satoru  wrote:
> 
> 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.
> - 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.
> - While it may be good to loosen the policy operationally, we oppose
> easing the policy itself.
> - This proposal seems not to aim "Clarification" of Sub assignment.
> 
> 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 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.
>> 
>> 5. Advantages / Disadvantages
>> 
>> Advantages:
>> Advantages of the proposal:
>> Fulfilling the objective above indicated and making sure to match the
>> real situation in the market.
>> 
>> Disadvantages:
>> Disadvantages of the proposal:
>> None foreseen.
>> 
>> 6. Impact on resource holders
>> 
>> Impact on resource holders:
>> None.
>> 
>> 7. References
>> 
>> AFRINIC: https://www.afrinic.net/policy/2018-v6-002-d3#details
>> 
>> ARIN:
>> https://www.arin.net/participate/policy/nrpm/#2-5-allocation-assignment-reallocation-reassignment
>> and https://www.arin.net/participate/policy/drafts/2019_15/
>> 
>> LACNIC:
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2018-7?language=en
>> 
>> RIPE NCC: https://www.ripe.net/participate/policies/proposals/2016-04
>> 
>> *  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] Version 4 of prop-126 PDP Update

[Owen DeLong]

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" mailto:o...@delong.com>> 
> escribió:
>  
>  
> 
> 
>> On Aug 26, 2019, at 03:05 , JORDI PALET MARTINEZ > <mailto:jordi.pa...@consulintel.es>> 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, and not once has that appeal process successfully changed an AC out of 
scope ruling. As you are aware, the board upheld the AC decision and you, 
yourself eventually realized that your original proposal as written was, in 
fact, out of scope.
 
> I really think is very bad not having it.

I remain unconvinced of its necessity. The ARIN process is different… It has 
appeals built in at every step of the PDP. ARIN operates in the US which is an 
inherently litigious environment and the appeals serve (IMHO) as a safety valve 
to avoid litigation.

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

Again, I disagree. If you enough of the community feels that the chairs erred 
in determining a proposal out of scope, I have no doubt that the community is 
capable of communicating this to the chairs and asking them to reconsider their 
decision. Further, I think the chairs would do so in good faith under that 
circumstance.
 
> 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.

I think this is unlikely in the APNIC region, and, if it were to happen, 
proposals being declared out of scope becomes the least or our concerns, 
frankly.

IIRC, there is a process for replacing the co-chairs which seems to me to be 
the better solution to this particular problem. If there is not and you wish to 
propose such a process, I might be more inclined to support something like that.

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

I do not believe you are correct about that. Again, I am not convinced that 
that law exists in any jurisdiction within the APNIC region either as written 
law or as case law or precedent. Unless and until you can provide such an 
example, I think your argument here is quite hollow.

Please don’t confuse what I said above about the US and litigation as an 
example here. I believe that the ARIN appeal process s

Re: [sig-policy] prop-132-v002: AS0 for Bogons

[Owen DeLong]

Thanks, Sunny!

This is very helpful.

Given the potential for this to produce outages, I’d like to propose that APNIC 
consider
an additional step in the process.

I think there should be a way for a resource holder (or former resource holder) 
to log
in to the APNIC web site and trigger a suspension of the AS0 ROA for any of 
their
prefixes until the matter can be reviewed by staff during business hours.

For reasonable protection, I think this should only be available for prefixes 
that received
AS0 ROA status within the preceding 10 days and only once.

Staff would review any such suspensions during their next regular work period 
and
make a determination to either extend the suspension for further investigation 
and
work with the resource holder in question, uphold the AS0 status, or restore the
resources to the resource holder.

I think this would provide a useful safety net to networks that could be 
adversely
impacted by this. It does provide a very short window in there is a very limited
potential for abuse (someone who had their resources revoked could, 
theoretically
get up to a 72 hour reprieve), but I think that’s pretty low risk in the grand 
scheme
of things.

Owen


> On Aug 29, 2019, at 21:42 , Srinivas Chendi  wrote:
> 
> Hi all,
> 
> If this proposal reaches consensus and endorsed by the APNIC EC, this is 
> how we would implement the policy.
> 
> **Creation of AS0 (Zero) ROA
> - Based on the publicly available “delegated-apnic-extended-latest” 
> stats file at https://ftp.apnic.net/stats/apnic/
> - All resources (IPv4 and IPv6) flagged as “Available” and “Reserved” 
> will be added to the AS0 ROA.
> - On average 15 records are updated in the 
> “delegated-apnic-extended-latest" file daily.
> - AS0 ROA will be updated at the same time as resource (IPv4 and IPv6) 
> delegation to exclude these prefixes.
> - Relying party will see the changes when the propagation of updated AS0 
> ROA is completed and this may take up to 24 hours.
> - As a reference, the default sync periods of some relying party 
> validation tools are as follows:
> 
>  - RIPE validator v2: every hour
>  - RIPE validator v3: every 10 minutes
>  - Routinator: every hour
>  - rcynic: every hour
> 
> **Account closure
> - APNIC makes extensive effort to contact the Member
> - If all efforts failed, APNIC will decide to terminate and reclaim all 
> resources delegated to that member. At the same time/day all whois 
> objects for that account will be deleted.
> - “delegated-apnic-extended-latest” stats file is updated within 24hours 
> to flag the reclaimed resources as “Reserved”
> - Reclaimed resource prefixes will be added to the AS0 ROA at the time 
> of reclamation.
> - If the closed member created any ROAs these will be deleted at the 
> time of reclamation.
> 
> **Account reactivation
> - If the APNIC Member reactivates the account within 3 months from the 
> account closure, APNIC will re-delegate the reclaimed resources and 
> reinstates whois objects and ROAs.
> - “delegated-apnic-extended-latest” stats file is updated within 24hours 
> to flag the re-delegated resources as “Allocated or Assigned”
> - At the time of reactivation, AS0 ROA will be updated to exclude the 
> re-delegated prefixes
> 
> 
> **Clarifications requested:
> 
> The way in which the ROAs appear in the RPKI needs to be considered. 
> Currently, the hierarchy involves a TA (for 0/0, ::/0, etc.), an 
> intermediate CA (same resource set), five further CAs (one for IANA and 
> one for each other RIR), and then the member CAs
> 
> (see diagram on slide 8 of 
> https://conference.apnic.net/44/assets/files/APCS549/Transitioning-to-a-single-TA.pdf).
> 
> Three possible options are:
> 
> - have the intermediate CA issue an AS0 ROA;
> - have each of the IANA/RIR CAs issue an AS0 ROA;
> - construct a separate CA under each of the IANA/RIR CAs
> containing the relevant unallocated resources, and have each of
> those CAs issue an AS0 ROA.
> 
> Does the community have any preference out of these three options?
> 
> Regards
> Sunny
> ___
> 
> Srinivas (Sunny) Chendi
> Senior Advisor - Policy and Community Development
> 
> Asia Pacific Network Information Centre (APNIC) |  Tel: +61 7 3858 3100
> PO Box 3646 South Brisbane, QLD 4101 Australia  |  Fax: +61 7 3858 3199
> 6 Cordelia Street, South Brisbane, QLD  |  http://www.apnic.net
> ___
> 
> 
> On 27/08/2019 9:25 am, Srinivas (Sunny) Chendi wrote:
>> Hi Javed,
>> 
>> Thanks for your email and for your participation in the policy 
>> development process.
>> 
>> We're consulting our experts to provide a response to your query soon. 
>> Please allow us sometime.
>> 
>> Regards
>> Sunny
>> 
>> On 24/08/2019 12:28 am, Javed Khan wrote:
>>> For now, I'm neither for or against this proposal. I think the 
>>> intention of the author is good but the implementa

Re: [sig-policy] prop-132-v002: AS0 for Bogons

[Owen DeLong]

> On Aug 28, 2019, at 20:37 , Aftab Siddiqui  wrote:
> 
> 
> Hi Owen,
>  cutting some stuff out, just to keep the thread small.
> 
> Anyone can very quickly put just about anything in RADB if they want to. It’s 
> also relatively easy to put nearly anything in the current ARIN IRR (not to 
> be confused with the ARIN RIR database). There are also some other IRRs that 
> accept almost anything at face value.
> 
> Exactly, thats why you have so much garbage in RADB and other IRR db. 

It’s also why the RIR withdrawing an entry isn’t as likely to cause an 
unmitigable outage than would occur under this policy.

>  
> 
> Finally, route object based filters tend to get updated rather slowly and not 
> everyone updates in sync, so it’s a gradually progressing outage that allows 
> some reaction time before becoming completely catastrophic.
> 
> Similarly, not everyone is doing ROV. But for the first time people are 
> worried about consequences of their laziness because RPKI is going to work 
> much better than IRR based filtering. 

I’m not sure that’s a completely fair characterization of the situation, but 
for whatever reason, despite its inability to do more than provide a really 
good cryptographically signed hint at what to forge in your hijacking 
announcements, RPKI is spreading like an unstoppable cancer and more and more 
people are beginning to do ROV in a mode which permits unknowns, but rejects 
known invalids.

RIRs implementing AS0 raises the stakes by giving RIRs the power to create 
“known invalids” where the previous state would be “unknown”.

> 
>> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA 
>> for the entire netback, then you’re (potentially) talking about near total 
>> catastrophic routing failure for this ISP and all of his customers.
>> 
>> Let’s assume they accidentally delete the registration for any reason there 
>> are cooling off periods in place which goes up to 60 days or we can put 
>> measures in place through policy to have decent cooking off periods. Also 
>> let’s talk about stats, how many times how many RIRs have deleted their 
>> members by mistake? Do you have any case? 
> 
> Honestly, I have no way to know. Such an event would likely not be made 
> particularly public. The RIR would consider it confidential to the affected 
> party and the affected party would have little motivation to announce it to 
> the world after the fact.
> 
> So we are debating a scenario which we are not even aware ever happened. I'm 
> still not saying that it never happened and will not happen but likelihood of 
> such incident is just very small. 

No… You asked for an example of how an AS0 ROA could get into the wild 
erroneously and I presented one scenario which you are now arguing is unlikely.
I agree that particular scenario may well be unlikely, but I’m not convinced it 
is the only circumstance in which such an event could occur.
Depending on how AS-0 ROAs are generated, I see lots of possible ways for 
fat-finger incidents at the RIR to result in dangerous issuances.

>  
> 
>>> So I am not in favor of asking the RIR to create AS0 ROA.
>>> 
>>> Thats absolutely fine we can agree to disagree but let’s have a clear 
>>> understanding of the policy. 
>> 
>> What makes you think he does not understand the policy?
>> 
>> Because the policy only addresses the bogon, how an address space becomes a 
>> bogon is APNIC operating procedure. Do you see the problem of understanding 
>> here? 
> 
> Yes, but it’s not his. The policy creates new more severe consequences for 
> things moving “routable” -> “bogon”. When you increase the consequences of an 
> action, it’s often a good idea to review the potential causes of that action 
> and consider what avenues exist for erroneous triggers.
> 
> Absolutely, its a good idea to have measures in place to avoid any erroneous 
> triggers and thats why I said APNIC can put operational practices in place 
> for that. Its shouldn't be part of the policy.

I never advocated for making it part of the policy. I advocated for reviewing 
it as part of the considerations BEFORE consenting to implementation of the 
policy.

I never asked for a change to the policy text. I asked for APNIC to publish 
their anticipated operational procedures for review so that the community can 
consider them in determining whether or not to come to consensus on this policy 
proposal.

In other words, I agree they shouldn’t be part of the policy, but they MUST be 
part of the policy deliberation, IMHO.

>> Also it’s seems you are fine with people advertising bogons just because 
>> fixing it might make one/two people unhappy. 
> 
> I’m not necessarily fine with people advertising bogons, but I’m also not 
> necessarily convinced that I want the RIRs to become the routing police.
> 
> This proposal literally moves the routing police role from the hands of those 
> who run routers into the hands of the RIRs (well, specifically it moves part 
> of that r

Re: [sig-policy] prop-132-v002: AS0 for Bogons

[Owen DeLong]

> On Aug 28, 2019, at 16:40 , Aftab Siddiqui  wrote:
> 
> 
> 
> On Thu, 29 Aug 2019 at 9:04 am, Owen DeLong  <mailto:o...@delong.com>> wrote:
> 
> 
>> On Aug 28, 2019, at 13:44 , Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>> wrote:
>> 
>> Hi Javed,
>> 
>> On Thu, 29 Aug 2019 at 6:33 am, Javed Khan > <mailto:javedkha...@outlook.com>> wrote:
>> We may think we are living in a perfect world but we are not.
>> 
>> of course 
>> 
>> With this proposal I'm more worried about the network downtime as managing 
>> an AS0 ROA by an RIR may be prone to errors as we all do regardless if its a 
>> manual or automated solution.
>> 
>> Would you like to explain how AS0 ROA can create network downtime? 
> 
> One possible way I can think of (I’m sure there are others)…
> 
> ISP Q is issued 2001:db8::/32 by APNIC.
> 
> ISP Q does not participate in RPKI and does not create ROAs.
> 
> APNIC accidentally issues an incorrect AS 0 ROA for 2001:db8:8000::/33, 
> taking down some fraction (up to half) of ISP Q’s customers and possibly 
> their infrastructure.
> 
> Since there is no AS0 ROA today so let’s focus on your later example. 
> 
> 
>> 
>> Operators network downtime doesn't have any effect on APNIC business as they 
>> can simply say we stuffed up and fixing it.
>> 
>> But think about those networks facing the downtime and their business 
>> obligations to their customers, who will bear this liability. Sure these 
>> operators can drag APNIC to the courts but that costs money that they cannot 
>> afford but accept the stuff ups.
>> 
>> Still you don’t understand how AS0 ROA works and what this policy is trying 
>> to address. If a network operator is using a Bogon (unallocated address 
>> space) then trust me mate that network has no chance defending that case in 
>> any court. In fact APNIC should be dragging these network operators to 
>> court. 
> 
> No, he understands (or at least I don’t see anything to say he doesn’t. 
> However, he and I also understand that we don’t live in a perfect world and 
> we’re talking about what happens when something goes wrong.
> 
> Right now, say APNIC accidentally deletes the above registration from the 
> database… Nothing super bad happens. Some possibility that his RDNS stops 
> working, but his packets still get routed. Some of his RDNS continues to 
> function for a while due to caching, so the damage is potentially 
> significant, but not total.
> 
> Many IXes filtering on valid route objects will stop accepting their 
> prefixes. Many upstreams also filtering on route objects will stop accepting 
> the prefix. Total outage. 

In my experience, these are actually relatively few and far between. Also, 
route objects are usually considered valid if they are present in ANY IRR, not 
necessarily the RIR based IRR.

Anyone can very quickly put just about anything in RADB if they want to. It’s 
also relatively easy to put nearly anything in the current ARIN IRR (not to be 
confused with the ARIN RIR database). There are also some other IRRs that 
accept almost anything at face value.

Finally, route object based filters tend to get updated rather slowly and not 
everyone updates in sync, so it’s a gradually progressing outage that allows 
some reaction time before becoming completely catastrophic.

> OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA 
> for the entire netback, then you’re (potentially) talking about near total 
> catastrophic routing failure for this ISP and all of his customers.
> 
> Let’s assume they accidentally delete the registration for any reason there 
> are cooling off periods in place which goes up to 60 days or we can put 
> measures in place through policy to have decent cooking off periods. Also 
> let’s talk about stats, how many times how many RIRs have deleted their 
> members by mistake? Do you have any case? 

Honestly, I have no way to know. Such an event would likely not be made 
particularly public. The RIR would consider it confidential to the affected 
party and the affected party would have little motivation to announce it to the 
world after the fact.

>> So I am not in favor of asking the RIR to create AS0 ROA.
>> 
>> Thats absolutely fine we can agree to disagree but let’s have a clear 
>> understanding of the policy. 
> 
> What makes you think he does not understand the policy?
> 
> Because the policy only addresses the bogon, how an address space becomes a 
> bogon is APNIC operating procedure. Do you see the problem of understanding 
> here? 

Yes, but it’s not his. The policy creates new more severe consequences for 
things mo

Re: [sig-policy] prop-132-v002: AS0 for Bogons

[Owen DeLong]

> On Aug 28, 2019, at 13:44 , Aftab Siddiqui  wrote:
> 
> Hi Javed,
> 
> On Thu, 29 Aug 2019 at 6:33 am, Javed Khan  <mailto:javedkha...@outlook.com>> wrote:
> We may think we are living in a perfect world but we are not.
> 
> of course 
> 
> With this proposal I'm more worried about the network downtime as managing an 
> AS0 ROA by an RIR may be prone to errors as we all do regardless if its a 
> manual or automated solution.
> 
> Would you like to explain how AS0 ROA can create network downtime? 

One possible way I can think of (I’m sure there are others)…

ISP Q is issued 2001:db8::/32 by APNIC.

ISP Q does not participate in RPKI and does not create ROAs.

APNIC accidentally issues an incorrect AS 0 ROA for 2001:db8:8000::/33, taking 
down some fraction (up to half) of ISP Q’s customers and possibly their 
infrastructure.

> 
> Operators network downtime doesn't have any effect on APNIC business as they 
> can simply say we stuffed up and fixing it.
> 
> But think about those networks facing the downtime and their business 
> obligations to their customers, who will bear this liability. Sure these 
> operators can drag APNIC to the courts but that costs money that they cannot 
> afford but accept the stuff ups.
> 
> Still you don’t understand how AS0 ROA works and what this policy is trying 
> to address. If a network operator is using a Bogon (unallocated address 
> space) then trust me mate that network has no chance defending that case in 
> any court. In fact APNIC should be dragging these network operators to court. 

No, he understands (or at least I don’t see anything to say he doesn’t. 
However, he and I also understand that we don’t live in a perfect world and 
we’re talking about what happens when something goes wrong.

Right now, say APNIC accidentally deletes the above registration from the 
database… Nothing super bad happens. Some possibility that his RDNS stops 
working, but his packets still get routed. Some of his RDNS continues to 
function for a while due to caching, so the damage is potentially significant, 
but not total.

OTOH, if APNIC accidentally deletes the registration and issues an AS0 ROA for 
the entire netback, then you’re (potentially) talking about near total 
catastrophic routing failure for this ISP and all of his customers.

> 
> 
> So I am not in favor of asking the RIR to create AS0 ROA.
> 
> Thats absolutely fine we can agree to disagree but let’s have a clear 
> understanding of the policy. 

What makes you think he does not understand the policy?

Owen

> 
> 
> J Khan
> 
> From: Aftab Siddiqui  <mailto:aftab.siddi...@gmail.com>>
> Sent: Tuesday, 27 August 2019 6:16 PM
> To: Owen DeLong mailto:o...@delong.com>>
> Cc: Javed Khan mailto:javedkha...@outlook.com>>; 
> Policy SIG mailto:sig-pol...@apnic.net>>; Sumon Ahmed 
> Sabir mailto:sasa...@gmail.com>>
> 
> Subject: Re: [sig-policy] prop-132-v002: AS0 for Bogons
>  
> Hi Owen,
>  
> I don’t think you actually addressed his concern…
> 
> Well, let me try again then :) 
>  
>> On Aug 26, 2019, at 17:17 , Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>> wrote:
>> 
>> Hi Javed,
>> I understand your concern, let me try to explain.
>> 
>> AS-0 ROA is an attestation by the holder of a prefix that the prefix 
>> described in the ROA, and any more specific prefix, should not be used in a 
>> routing context. The route validation consider a "valid" outcome if "ANY" 
>> ROA matches the address prefix and origin AS, even if other valid ROAs would 
>> provide an "invalid" validation outcome if used in isolation.  Since, its 
>> not possible to generate a prefix with AS-0 there fore it is not possible 
>> that valid ROA will impact the routing of a prefix even if there is an AS-0 
>> ROA for that prefix. Also, AS 0 ROA has a lower relative preference than any 
>> other ROA that has a routable AS.  
> 
> Presumably, APNIC would withdraw/invalidate any other ROA for the prefix (or 
> its subordinates) at or before the time when they would issue an AS-0 ROA.
> 
> Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to 
> UNVALIDATED/UNKNOWN status in any route validator. This would not affect the 
> routing table in most cases since there won’t be a validated route (in this 
> instance) to supersede the UNVALIDATED/UNKNOWN route which was previously 
> VALIDATED/GOOD.
> 
> Issuing the AS-0 ROA would subsequently move the prefix from VALIDATED/GOOD 
> or UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus causing most 
> validating routers to discard the route.
> 
> There are only few reasons why APNIC would remove a val

Re: [sig-policy] prop-132-v002: AS0 for Bogons

[Owen DeLong]

> On Aug 27, 2019, at 03:16 , Aftab Siddiqui  wrote:
> 
> Hi Owen,
>  
> I don’t think you actually addressed his concern…
> 
> Well, let me try again then :) 
>  
>> On Aug 26, 2019, at 17:17 , Aftab Siddiqui > > wrote:
>> 
>> Hi Javed,
>> I understand your concern, let me try to explain.
>> 
>> AS-0 ROA is an attestation by the holder of a prefix that the prefix 
>> described in the ROA, and any more specific prefix, should not be used in a 
>> routing context. The route validation consider a "valid" outcome if "ANY" 
>> ROA matches the address prefix and origin AS, even if other valid ROAs would 
>> provide an "invalid" validation outcome if used in isolation.  Since, its 
>> not possible to generate a prefix with AS-0 there fore it is not possible 
>> that valid ROA will impact the routing of a prefix even if there is an AS-0 
>> ROA for that prefix. Also, AS 0 ROA has a lower relative preference than any 
>> other ROA that has a routable AS.  
> 
> Presumably, APNIC would withdraw/invalidate any other ROA for the prefix (or 
> its subordinates) at or before the time when they would issue an AS-0 ROA.
> 
> Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to 
> UNVALIDATED/UNKNOWN status in any route validator. This would not affect the 
> routing table in most cases since there won’t be a validated route (in this 
> instance) to supersede the UNVALIDATED/UNKNOWN route which was previously 
> VALIDATED/GOOD.
> 
> Issuing the AS-0 ROA would subsequently move the prefix from VALIDATED/GOOD 
> or UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus causing most 
> validating routers to discard the route.
> 
> There are only few reasons why APNIC would remove a valid ROA from member's 
> account.
> - Due to Non-payment and APNIC reclaiming the resources and closing the 
> account
> - Returned address space by the member for any reason and the space becomes 
> part of free pool. 
> 
> In either case there are some cooling off period as I shared in previous 
> email which goes up to 60 days before APNIC can mark those resources as 
> free/available. IMO, there is absolutely no reason to have those ROAs in 
> place but again this is an operational issue and this policy is not dealing 
> with it. But can you suggest any reason when those ROAs should not be removed?

What if the payment status is in dispute?
There are likely other scenarios that haven’t been considered.

My point is not to claim that the current process is unacceptable. My point is 
that in order to consider whether or not this proposal has unintended 
consequences, we need a clear statement from staff how ROAs would be treated 
with this policy in place in these various situations to conduct a useful 
evaluation of the consequences in question.

I agree that these are operational matters, but they are operational matters 
that affect the outcome of this policy in a very real and potent way that is 
unique to this particular policy. Most policies do not enable staff actions 
that can disrupt routing. This one potentially does. I’m not saying that’s a 
bad thing, but I am saying that the community as a whole should get the 
information from staff about the implementation details and then evaluate those 
impacts very carefully before passing judgment on the policy proposal.


>> For Example,
>> - APNIC creates AS-0 ROA for 103.8.194.0/24  (This is 
>> an unallocated prefix announced AS135754, a bogon).
>> - If I'm doing ROV then this prefix (103.8.194.0/24 ) 
>> will become invalid for me because it doesn't have a valid ROA. Anyone not 
>> doing ROV or any other form of bogon filtering will still accept this prefix 
>> and keep on treating it as normal.
>> - Now, APNIC delegates this prefix to someone else after some time (remember 
>> the AS-0 ROA still exist). That someone is AS139038 (myself).
>> - Because this prefix is now under my administration I can create ROA with 
>> my own ASN i.e. AS139038
>> - Before delegating the prefix to me APNIC should have delete that AS-0 ROA 
>> but lets assume they forgot to do so or some technical glitch happened and 
>> the AS-0 ROA still exist for this prefix even after delegating it to me
>> - Since I have created a ROA with my ASN i.e. AS139038 then the validators 
>> will mark the prefix originating from my ASN as valid even though there is 
>> an AS-0 ROA for that prefix. 
> 
> Different example:
> 
> APNIC issues 2001:db8:feed::/48 to XYZ Corp. who creates a ROA for AS65551.
> If you’re doing ROV, then this prefix 2001:db8:feed::/48 is validated 
> assuming you receive the route with an AS PATh that matches "* 65551 $”.
> Subsequently, XYZ Corp forgets to pay their APNIC invoice and APNIC revokes 
> the space.
> Under current policy, APNIC Simply deletes the ROA and anyone doing ROV no 
> longer sees 2001:db8:feed::/48 as valid, but they don’t see it as invalid. It 
> moves to unknown.
>   I

Re: [sig-policy] Version 4 of prop-126 PDP Update

[Owen DeLong]

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

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.
 
> 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 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.
 
> 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 think anyone is questioning your motives, Jordi. We all know that your 
heart is generally in the right place, even if we don’t agree with you about 
your desired actions.

We all know that you like how things work in the RIPE region. I will say that 
I’m not as fond of the RIPE process as you are. I will also point out that 
general apathy is not necessarily a bad thing. It depends on the reasons for 
the apathy. If the apathy is because nothing bad enough to motivate people to 
action is happening, then apathy is not the worst possible outcome. If the 
apathy is because people feel disenfranchised and unable to make a difference, 
then the cause of the apathy must desperately be addressed with all due haste. 
I do not believe that people are disenfranchised in the APNIC region or that 
anything horrible is happening in the APNIC policy arena.

I’m far less active on the APNIC list(s) than ARIN and AfriNIC. I’m more active 
in the ARIN region because it is my home region and because I (currently) have 
a leadership role there. I’m more active in AfriNIC because I believe there are 
more problems there and policy development there needs all the help it can get. 
I participate in APNIC when I feel I have something useful to contribute to the 
discussion. Otherwise, I mostly lurk. I’d probably watch LACNIC if I spoke 
better spanish. I’ve never actually subscribed to the RIPE PDP list. RIPE seems 
to be doing what RIPE does well enough without my contribution.

Owen

>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 23/8/19 15:48, "Javed Khan"   en nombre de 
> javedkha...@outlook.com > escribió:
>  
> I do not support this proposal as I have complete trust in the current APNIC 
> PDP and this community.
>  
> Kind regards
> Javed Khan
> MSCE and CCSP
>  
> From: sig-policy-boun...@lists.apnic.net  
> on behalf of Sumon Ahmed Sabir 
> Sent: Friday, 9 August 2019 2:13 AM
> To: Policy SIG 
> Subject: [sig-policy] Version 4 of prop-126 PDP Update
>  
>  
> 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/

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[Owen DeLong]

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

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.

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"   en nombre de 
> javedkha...@outlook.com > escribió:
>  
> I do not support this proposal. Intention is good but no one is really 
> concerned nor can verify this in practice. I think the current policy text is 
> good.
>  
> Kind regards
> Javed Khan
> MSCE and CCSP
>  
> From: sig-policy-boun...@lists.apnic.net 
>  
>  > on behalf of Sumon Ahmed Sabir 
> mailto:sasa...@gmail.com>>
> Sent: Saturday, 10 August 2019 10:33 PM
> To: Policy SIG mailto:sig-pol...@apnic.net>>
> Subject: [sig-policy] prop-124-v006: Clarification on Sub-Assignments
>  
> 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
> 
> -

Re: [sig-policy] prop-132-v002: AS0 for Bogons

[Owen DeLong]

Aftab,

I don’t think you actually addressed his concern…


> On Aug 26, 2019, at 17:17 , Aftab Siddiqui  wrote:
> 
> Hi Javed,
> I understand your concern, let me try to explain.
> 
> AS-0 ROA is an attestation by the holder of a prefix that the prefix 
> described in the ROA, and any more specific prefix, should not be used in a 
> routing context. The route validation consider a "valid" outcome if "ANY" ROA 
> matches the address prefix and origin AS, even if other valid ROAs would 
> provide an "invalid" validation outcome if used in isolation.  Since, its not 
> possible to generate a prefix with AS-0 there fore it is not possible that 
> valid ROA will impact the routing of a prefix even if there is an AS-0 ROA 
> for that prefix. Also, AS 0 ROA has a lower relative preference than any 
> other ROA that has a routable AS.  

Presumably, APNIC would withdraw/invalidate any other ROA for the prefix (or 
its subordinates) at or before the time when they would issue an AS-0 ROA.

Revoking the previously valid ROAs moves the prefix from VALIDATED/GOOD to 
UNVALIDATED/UNKNOWN status in any route validator. This would not affect the 
routing table in most cases since there won’t be a validated route (in this 
instance) to supersede the UNVALIDATED/UNKNOWN route which was previously 
VALIDATED/GOOD.

Issuing the AS-0 ROA would subsequently move the prefix from VALIDATED/GOOD or 
UNVALIDATED/UNKNOWN status to INVALID/KNOWN status, thus causing most 
validating routers to discard the route.



> 
> For Example,
> - APNIC creates AS-0 ROA for 103.8.194.0/24  (This is 
> an unallocated prefix announced AS135754, a bogon).
> - If I'm doing ROV then this prefix (103.8.194.0/24 ) 
> will become invalid for me because it doesn't have a valid ROA. Anyone not 
> doing ROV or any other form of bogon filtering will still accept this prefix 
> and keep on treating it as normal.
> - Now, APNIC delegates this prefix to someone else after some time (remember 
> the AS-0 ROA still exist). That someone is AS139038 (myself).
> - Because this prefix is now under my administration I can create ROA with my 
> own ASN i.e. AS139038
> - Before delegating the prefix to me APNIC should have delete that AS-0 ROA 
> but lets assume they forgot to do so or some technical glitch happened and 
> the AS-0 ROA still exist for this prefix even after delegating it to me
> - Since I have created a ROA with my ASN i.e. AS139038 then the validators 
> will mark the prefix originating from my ASN as valid even though there is an 
> AS-0 ROA for that prefix. 

Different example:

APNIC issues 2001:db8:feed::/48 to XYZ Corp. who creates a ROA for AS65551.
If you’re doing ROV, then this prefix 2001:db8:feed::/48 is validated assuming 
you receive the route with an AS PATh that matches "* 65551 $”.
Subsequently, XYZ Corp forgets to pay their APNIC invoice and APNIC revokes the 
space.
Under current policy, APNIC Simply deletes the ROA and anyone doing ROV no 
longer sees 2001:db8:feed::/48 as valid, but they don’t see it as invalid. It 
moves to unknown.
In the current (and foreseeable future) world, and unknown route is 
probably still going to be accepted by the vast majority of peers, so this has 
little effect on routing.
Under the proposed policy, at some point, APNIC issues a new ROA for 
2001:db8:feed::/48 tied to AS0.
This has two effects that are not present in the current situation:
1.  The route with origin AS6551 is no tagged as “Invalid” — There 
is no matching VALID ROA since they were all revoked by the RIR.
2.  Most peers doing ROV will likely drop the prefix. While unknown 
prefixes are not likely dropped, known invalid prefixes are a different matter 
and
even though some ROV operators will not drop them 
today, more and more will sooner rather than later.

This means that the RIR now has much greater direct power over influencing 
routing decisions than in the pre-RPKI/ROV days. I’m not saying
whether this is good or bad (who am I to judge at this point), but I am saying 
it’s a valid concern and a huge potential operational consequence
of this proposed policy.

> You can also check prefix 103.114.191.0/24  via any 
> validator you are running which has both AS-0 ROA (created by them) and also 
> a ROA with their routable ASN (AS397702). Many operators have created AS-0 
> ROAs along side the ROA with their own routable ASN. 

Yes, but this doesn’t cover the case Javed expressed concern about.

> I hope this helps answer you concern. Please let me know if you still have 
> any question.

Even if Javed is somehow satisfied with your answer, I think that we need a 
detailed explanation from staff how this policy would be implemented and
what measures would be taken to avoid the erroneous (and potentially 
disastrous) combination of revocation of all previous ROAs and issuance of
an AS-0 ROA. Also, a clear des

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

[Owen DeLong]

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 
>> 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 corrected in AFRINIC, ARIN, LACNIC and 
>> RIPE.
>> 
>> 
>> 4. Proposed policy solution
>> ---
>> 
>> Current 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 n

Re: [sig-policy] prop-132-v002: AS0 for Bogons

[Owen DeLong]

Most, if not all RIRs have a process for address recycling with appropriate 
hold-down times and grace periods for the resource holder to act to preserve 
their claim on the resources.

It seems to me that lining this up with those procedures can be left as an 
operational manner at the discretion of staff, but I wouldn’t be opposed to 
specific minimums being elaborated in policy if people feel that is needed.

Staff should always be given the flexibility to accommodate entities staff 
believes to be acting in good faith, IMHO and the unintended consequences of 
any hard maximum time limits in policy could, be dire.

Owen


> On Aug 22, 2019, at 13:36 , David Farmer  wrote:
> 
> The problem statement says;
> 
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC)...
> 
> So that raises a question, what about resources that are deregisterd because 
> they are returned, revoked, or otherwise reclaimed, for any of a myriad of 
> reasons, including non-payment of fees? Do they become Bogons with AS0 ROAs 
> the moment they are deregistered? Later, if so when? What if there is a ROA 
> for them in the system? Are the ROAs removed, if so when? 
> 
> Personally I think they should be deregistered for some amount of time before 
> the becoming Bogons and have an AS0 ROA created them, also for the AS0 ROA to 
> be effective any ROAs for these deregistered resources need to be removed as 
> well.
> 
> I would propose something like the following;
> Upon de-reregistration any existing ROAs are removed from RPKI
> 30 days after de-registraion, AS0 ROAs are created except for non-payment fees
> 90 days after de-registraion, AS0 ROAs are created in the case of non-payment 
> fees
> Thanks.
> 
> On Thu, Aug 22, 2019 at 12:52 AM Sumon Ahmed Sabir  > wrote:
> Dear SIG members
> 
> A new version of the proposal "prop-132: AS0 for Bogons"
> has been sent to the Policy SIG for review.
> 
> Information about earlier versions is available from:
> http://www.apnic.net/policy/proposals/prop-132 
> 
> 
> 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-132-v002: AS0 for Bogons
> 
> --
> 
> Proposer: Aftab Siddiqui
>aftab.siddi...@gmail.com 
> 
> 
> 1. Problem statement
> 
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC) as well as all addresses reserved for private or special use by
> RFCs.  See [RFC3330] and [RFC1918].
> 
> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global 
> routing
> table. In the past, several attempts have been made to filter out such 
> bogons
> through various methods such as static filters and updating them 
> occasionally
> but it is hard to keep an up to date filters, TeamCymru and CAIDA 
> provides full
> bogon list in text format to update such filters. TeamCymru also 
> provides bogon
> BGP feed where they send all the bogons via a BGP session which then can be
> discarded automatically. Beside all these attempts the issue of Bogon 
> Advertisement
> hasn't be resolved so far.
> 
> 
> 2. Objective of policy change
> -
> The purpose of creating AS0 (zero) ROAs for unallocated address space by 
> APNIC
> is to resolve the issue of Bogon announcement. When APNIC issues an AS0 
> ROA for
> unallocated address space under APNIC’s administration then it will be 
> marked as
> “Invalid” if someone tries to advertise the same address space.
> 
> 
> Currently, in the absence of any ROA, these bogons are marked as 
> “NotFound”. Since
> many operators have implemented ROV and either planning or already 
> discarding “Invalid”
> then all the AS0 ROAs which APNIC will create for unallocated address 
> space will be
> discarded as well.
> 
> 3. Situation in other regions
> -
> No such policy in any region at the moment.
> 
> 
> 4. Proposed policy solution
> ---
> APNIC will create AS0(zero) ROAs for all the unallocated address space 
> (IPv4 and IPv6)
> for which APNIC is the current administrator. Any resource holder (APNIC 
> member) can
> create AS0 (zero

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

Fair enough. I tend to think of Bogons as “Those addresses which shouldn’t be 
advertised _EVER_” (e.g. 10.0.0.0/8) while I tend to think of Unallocated as 
being more transient in nature.

I realize that makes 224.0.0.0/4 classification as a bogon a bit of a grey 
area, while including all unallocated space makes a cleaner definition.

I suppose part of the reason for that was I always tended to maintain bogons 
and unallocated as separate lists in ACLs and I usually kept the unallocated 
one in the dynamic configuration (in Juniper land) since it tended to need 
frequent update.

Owen


> On Aug 21, 2019, at 16:02 , Aftab Siddiqui  wrote:
> 
> Hi Owen,
> 
> On Thu, Aug 22, 2019 at 7:10 AM Owen DeLong  <mailto:o...@delong.com>> wrote:
> I don’t tend to regard unallocated as “bogons”,
> 
> Why is that? 
> RFC3871 <https://tools.ietf.org/html/rfc3871> - Bogon: A "Bogon" (plural: 
> "bogons") is a packet with an IP source address in an address block not yet 
> allocated by IANA or the Regional Internet Registries (ARIN, RIPE, APNIC...) 
> as well as all addresses reserved for private or special use by RFCs.
>  
> but sure, if this proposal is strictly about unallocated space in the APNIC 
> free pool(s), then I have no problem with that.
> 
> Yes, the policy is strictly talking about "unallocated address space" in 
> APNIC free pool.
>  
> 
> Owen
> 
> 
>> On Aug 15, 2019, at 17:15 , Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>> wrote:
>> 
>> Hi Owen,
>> Just to give you an example, all unallocated address space from 103/8 are 
>> under APNIC's management unless they were transferred to other RIRs and then 
>> reclaimed by that RIR due to whatever reason. This policy covers all 
>> unallocated address space under APNIC's management and asking APNIC to 
>> create AS0 ROAs for all those unallocated addresses. 
>> 
>> Regards,
>> 
>> Aftab A. Siddiqui
>> 
>> 
>> On Fri, Aug 16, 2019 at 9:03 AM Owen DeLong > <mailto:o...@delong.com>> wrote:
>> Since we are talking about bigots, other than Unallocated space in RIR 
>> inventory, I’m not sure how you would consider a bogota to be within any 
>> particular RIRs jurisdiction. As such, I was under the impression from the 
>> policy proposal that the intent was for APNIC to issue AS0 ROAs for global 
>> bogons. 
>> 
>> Owen
>> 
>> 
>> On Aug 15, 2019, at 15:12, Andrew Dul > <mailto:andrew@quark.net>> wrote:
>> 
>>> 
>>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>>>> Hi Owen,
>>>> 
>>>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong >>> <mailto:o...@delong.com>> wrote:
>>>> Looks like IETF wants the global BOGONs to be attested by IANA rather than 
>>>> by an RIR from what you quoted.
>>>> 
>>>> Yes, for resources not allocated by IANA or marked as Reserved But IANA 
>>>> has nothing to do with resources allocated to RIRs already.
>>>>  
>>>> Any reason APNIC feels the need to usurp that process?
>>>> 
>>>> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have 
>>>> unallocated IPv4 address space. 
>>>> 103/8  APNIC   2011-02 whois.apnic.net <http://whois.apnic.net/>   
>>>> https://rdap.apnic.net/ <https://rdap.apnic.net/>   ALLOCATED
>>>> The policy is addressing the unallocated address space within APNIC
>>>>  
>>> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which are 
>>> administered by APNIC, it should be noted that because of inter-RIR 
>>> transfers of IPv4 addresses between regions RIRs other than APNIC are now 
>>> administering sub-portions of the larger IANA allocated blocks.  There are 
>>> portions of a /8 for example which are now delegated to other RIRs for 
>>> registrations in those regions.   Should it be assumed that those 
>>> sub-portions administered by RIRs now are considered allocated (and not 
>>> bogons) for purposes of this policy?
>>> 
>>> Andrew
>>> 
>>>> 
>>>> Owen
>>>> 
>>>> 
>>>>> On Aug 14, 2019, at 21:58 , Aftab Siddiqui >>>> <mailto:aftab.siddi...@gmail.com>> wrote:
>>>>> 
>>>>> Hi Owen,
>>>>> Thanks for your response, sorry for replying late though. 
>>>>> 
>>>>> IMO, IETF has done its part already.
>>>>> 
>>>>> RFC648

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

I don’t tend to regard unallocated as “bogons”, but sure, if this proposal is 
strictly about unallocated space
in the APNIC free pool(s), then I have no problem with that.

Owen


> On Aug 15, 2019, at 17:15 , Aftab Siddiqui  wrote:
> 
> Hi Owen,
> Just to give you an example, all unallocated address space from 103/8 are 
> under APNIC's management unless they were transferred to other RIRs and then 
> reclaimed by that RIR due to whatever reason. This policy covers all 
> unallocated address space under APNIC's management and asking APNIC to create 
> AS0 ROAs for all those unallocated addresses. 
> 
> Regards,
> 
> Aftab A. Siddiqui
> 
> 
> On Fri, Aug 16, 2019 at 9:03 AM Owen DeLong  <mailto:o...@delong.com>> wrote:
> Since we are talking about bigots, other than Unallocated space in RIR 
> inventory, I’m not sure how you would consider a bogota to be within any 
> particular RIRs jurisdiction. As such, I was under the impression from the 
> policy proposal that the intent was for APNIC to issue AS0 ROAs for global 
> bogons. 
> 
> Owen
> 
> 
> On Aug 15, 2019, at 15:12, Andrew Dul  <mailto:andrew@quark.net>> wrote:
> 
>> 
>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>>> Hi Owen,
>>> 
>>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong >> <mailto:o...@delong.com>> wrote:
>>> Looks like IETF wants the global BOGONs to be attested by IANA rather than 
>>> by an RIR from what you quoted.
>>> 
>>> Yes, for resources not allocated by IANA or marked as Reserved But IANA has 
>>> nothing to do with resources allocated to RIRs already.
>>>  
>>> Any reason APNIC feels the need to usurp that process?
>>> 
>>> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have 
>>> unallocated IPv4 address space. 
>>> 103/8   APNIC   2011-02 whois.apnic.net <http://whois.apnic.net/>   
>>> https://rdap.apnic.net/ <https://rdap.apnic.net/>   ALLOCATED
>>> The policy is addressing the unallocated address space within APNIC
>>>  
>> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which are 
>> administered by APNIC, it should be noted that because of inter-RIR 
>> transfers of IPv4 addresses between regions RIRs other than APNIC are now 
>> administering sub-portions of the larger IANA allocated blocks.  There are 
>> portions of a /8 for example which are now delegated to other RIRs for 
>> registrations in those regions.   Should it be assumed that those 
>> sub-portions administered by RIRs now are considered allocated (and not 
>> bogons) for purposes of this policy?
>> 
>> Andrew
>> 
>>> 
>>> Owen
>>> 
>>> 
>>>> On Aug 14, 2019, at 21:58 , Aftab Siddiqui >>> <mailto:aftab.siddi...@gmail.com>> wrote:
>>>> 
>>>> Hi Owen,
>>>> Thanks for your response, sorry for replying late though. 
>>>> 
>>>> IMO, IETF has done its part already.
>>>> 
>>>> RFC6483 defines the term “Disavowal of Routing Origination”.
>>>> 
>>>> “A ROA is a positive attestation that a prefix holder has authorized an AS 
>>>> to originate a route for this prefix into the inter-domain routing system. 
>>>>  It is possible for a prefix holder to construct an authorization where no 
>>>> valid AS has been granted any such authority to originate a route for an 
>>>> address prefix.  This is achieved by using a ROA where the ROA’s subject 
>>>> AS is one that must not be used in any routing context.  Specifically, AS0 
>>>> is reserved by the IANA such that it may be used to identify non-routed 
>>>> networks
>>>> 
>>>> A ROA with a subject of AS0 (AS0 ROA) is an attestation by the holder of a 
>>>> prefix that the prefix described in the ROA, and any more specific prefix, 
>>>> should not be used in a routing context. The route validation procedure 
>>>> will provide a “valid” outcome if any ROA 
>>>> matches the address prefix and origin AS even if other valid ROAs would 
>>>> provide an “invalid” validation outcome if used in isolation.  
>>>> Consequently, an AS0 ROA has a lower relative preference than any other 
>>>> ROA that has a routable AS, as its subject.  This allows a prefix holder 
>>>> to use an AS0 ROA to declare a default condition that any route that is 
>>>> equal to or more specific than the prefix to be considered “i

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

Since we are talking about bigots, other than Unallocated space in RIR 
inventory, I’m not sure how you would consider a bogota to be within any 
particular RIRs jurisdiction. As such, I was under the impression from the 
policy proposal that the intent was for APNIC to issue AS0 ROAs for global 
bogons. 

Owen


> On Aug 15, 2019, at 15:12, Andrew Dul  wrote:
> 
> 
>> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote:
>> Hi Owen,
>> 
>>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong  wrote:
>>> Looks like IETF wants the global BOGONs to be attested by IANA rather than 
>>> by an RIR from what you quoted.
>> 
>> Yes, for resources not allocated by IANA or marked as Reserved But IANA has 
>> nothing to do with resources allocated to RIRs already.
>>  
>>> Any reason APNIC feels the need to usurp that process?
>> 
>> Accordingly to IANA 103/8 was allocated to APNIC and now they don't have 
>> unallocated IPv4 address space. 
>> 103/8APNIC   2011-02 whois.apnic.net https://rdap.apnic.net/ 
>> ALLOCATED
>> The policy is addressing the unallocated address space within APNIC
>>  
> If this policy is only speaking to /8 IPv4 blocks & IPv6 blocks which are 
> administered by APNIC, it should be noted that because of inter-RIR transfers 
> of IPv4 addresses between regions RIRs other than APNIC are now administering 
> sub-portions of the larger IANA allocated blocks.  There are portions of a /8 
> for example which are now delegated to other RIRs for registrations in those 
> regions.   Should it be assumed that those sub-portions administered by RIRs 
> now are considered allocated (and not bogons) for purposes of this policy?
> 
> Andrew
> 
>>> 
>>> Owen
>>> 
>>> 
>>>> On Aug 14, 2019, at 21:58 , Aftab Siddiqui  
>>>> wrote:
>>>> 
>>>> Hi Owen,
>>>> Thanks for your response, sorry for replying late though. 
>>>> 
>>>> IMO, IETF has done its part already.
>>>> 
>>>> RFC6483 defines the term “Disavowal of Routing Origination”.
>>>> 
>>>> “A ROA is a positive attestation that a prefix holder has authorized an AS 
>>>> to originate a route for this prefix into the inter-domain routing system. 
>>>>  It is possible for a prefix holder to construct an authorization where no 
>>>> valid AS has been granted any such authority to originate a route for an 
>>>> address prefix.  This is achieved by using a ROA where the ROA’s subject 
>>>> AS is one that must not be used in any routing context.  Specifically, AS0 
>>>> is reserved by the IANA such that it may be used to identify non-routed 
>>>> networks
>>>> 
>>>> A ROA with a subject of AS0 (AS0 ROA) is an attestation by the holder of a 
>>>> prefix that the prefix described in the ROA, and any more specific prefix, 
>>>> should not be used in a routing context. The route validation procedure 
>>>> will provide a “valid” outcome if any ROA matches the address prefix and 
>>>> origin AS even if other valid ROAs would provide an “invalid” validation 
>>>> outcome if used in isolation.  Consequently, an AS0 ROA has a lower 
>>>> relative preference than any other ROA that has a routable AS, as its 
>>>> subject.  This allows a prefix holder to use an AS0 ROA to declare a 
>>>> default condition that any route that is equal to or more specific than 
>>>> the prefix to be considered “invalid”, while also allowing other 
>>>> concurrently issued ROAs to describe valid origination authorizations for 
>>>> more specific prefixes.”
>>>> 
>>>> RFC6491 says - "IANA SHOULD issue an AS 0 ROA for all reserved IPv4 and 
>>>> IPv6 resources not intended to be routed." also "IANA SHOULD issue an AS 0 
>>>> ROA for all Unallocated Resources." 
>>>> 
>>>> Once allocated to RIRs then IANA can't issue any ROA (they are not doing 
>>>> it to any resource anyway) but there is unallocated address space with 
>>>> RIRs, they can issue AS0 ROAs.
>>>> 
>>>> I hope this clarifies your point of IETF's involvement first.
>>>> 
>>>> Regards,
>>>> 
>>>> Aftab A. Siddiqui
>>>> 
>>>>> On Sat, Aug 10, 2019 at 6:40 AM Owen DeLong  wrote:
>>>>> IMHO, while I’m perfectly fine with APNIC administering this and 
>>>>> maintaining the ROAs, etc., I believe that the decision to allocate AS0 
&

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

Looks like IETF wants the global BOGONs to be attested by IANA rather than by 
an RIR from what you quoted.

Any reason APNIC feels the need to usurp that process?

Owen


> On Aug 14, 2019, at 21:58 , Aftab Siddiqui  wrote:
> 
> Hi Owen,
> Thanks for your response, sorry for replying late though. 
> 
> IMO, IETF has done its part already.
> 
> RFC6483 defines the term “Disavowal of Routing Origination”.
> 
> “A ROA is a positive attestation that a prefix holder has authorized an AS to 
> originate a route for this prefix into the inter-domain routing system.  It 
> is possible for a prefix holder to construct an authorization where no valid 
> AS has been granted any such authority to originate a route for an address 
> prefix.  This is achieved by using a ROA where the ROA’s subject AS is one 
> that must not be used in any routing context.  Specifically, AS0 is reserved 
> by the IANA such that it may be used to identify non-routed networks
> 
> A ROA with a subject of AS0 (AS0 ROA) is an attestation by the holder of a 
> prefix that the prefix described in the ROA, and any more specific prefix, 
> should not be used in a routing context. The route validation procedure will 
> provide a “valid” outcome if any ROA matches the address prefix and origin AS 
> even if other valid ROAs would provide an “invalid” validation outcome if 
> used in isolation.  Consequently, an AS0 ROA has a lower relative preference 
> than any other ROA that has a routable AS, as its subject.  This allows a 
> prefix holder to use an AS0 ROA to declare a default condition that any route 
> that is equal to or more specific than the prefix to be considered “invalid”, 
> while also allowing other concurrently issued ROAs to describe valid 
> origination authorizations for more specific prefixes.”
> 
> RFC6491 says - "IANA SHOULD issue an AS 0 ROA for all reserved IPv4 and IPv6 
> resources not intended to be routed." also "IANA SHOULD issue an AS 0 ROA for 
> all Unallocated Resources." 
> 
> Once allocated to RIRs then IANA can't issue any ROA (they are not doing it 
> to any resource anyway) but there is unallocated address space with RIRs, 
> they can issue AS0 ROAs.
> 
> I hope this clarifies your point of IETF's involvement first.
> 
> Regards,
> 
> Aftab A. Siddiqui
> 
> On Sat, Aug 10, 2019 at 6:40 AM Owen DeLong  <mailto:o...@delong.com>> wrote:
> IMHO, while I’m perfectly fine with APNIC administering this and maintaining 
> the ROAs, etc., I believe that the decision to allocate AS0 to this purpose 
> and documentation of this intent should be done through the IETF and be 
> documented in an STD or RFC.
> 
> I support the idea, but I believe the proper place to start is the IETF.
> 
> Owen
> 
> 
>> On Aug 9, 2019, at 3:01 AM, Sumon Ahmed Sabir > <mailto:sasa...@gmail.com>> wrote:
>> 
>> 
>> Dear SIG members,
>> 
>> The proposal "prop-132-v001: AS0 for Bogons" 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-132 
>> <http://www.apnic.net/policy/proposals/prop-132>
>> 
>> Regards
>> 
>> Sumon, Bertrand, Ching-Heng
>> APNIC Policy SIG Chairs
>> 
>> 
>> --
>> 
>> prop-132-v001: AS0 for Bogons
>> 
>> --
>> 
>> Proposer: Aftab Siddiqui
>>aftab.siddi...@gmail.com <mailto:aftab.siddi...@gmail.com>
>> 
>> 
>> 1. Problem statement
>> 
>> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
>> with an IP source address in an addre

Re: [sig-policy] prop-132-v001 AS0 for Bogons

[Owen DeLong]

IMHO, while I’m perfectly fine with APNIC administering this and maintaining 
the ROAs, etc., I believe that the decision to allocate AS0 to this purpose and 
documentation of this intent should be done through the IETF and be documented 
in an STD or RFC.

I support the idea, but I believe the proper place to start is the IETF.

Owen


> On Aug 9, 2019, at 3:01 AM, Sumon Ahmed Sabir  wrote:
> 
> 
> Dear SIG members,
> 
> The proposal "prop-132-v001: AS0 for Bogons" 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-132 
> 
> 
> Regards
> 
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
> 
> 
> --
> 
> prop-132-v001: AS0 for Bogons
> 
> --
> 
> Proposer: Aftab Siddiqui
>aftab.siddi...@gmail.com 
> 
> 
> 1. Problem statement
> 
> Bogons are defined in RFC3871, A "Bogon" (plural: "bogons") is a packet
> with an IP source address in an address block not yet allocated by IANA
> or the Regional Internet Registries (ARIN, RIPE NCC, APNIC, AFRINIC and
> LACNIC) as well as all addresses reserved for private or special use by
> RFCs.  See [RFC3330] and [RFC1918].
> 
> As of now, there are 287 IPv4 bogons and 73 IPv6 bogons in the global
> routing table. In the past, several attempts have been made to filter
> out such bogons through various methods such as static filters and updating
> them occasionally but it is hard to keep an up to date filters, 
> TeamCymru and
> CAIDA provides full bogon list in text format to update such filters. 
> TeamCymru
> also provides bogon BGP feed where they send all the bogons via a BGP 
> session
> which then can be discarded automatically. Beside all these attempts the 
> issue
> of Bogon Advertisement hasn't be resolved so far.
> 
> 
> 2. Objective of policy change
> -
> The purpose of creating AS0 (zero) ROAs for unallocated address space by 
> APNIC
> is to resolve the issue of Bogon announcement. When APNIC issues an AS0 
> ROA for
> unallocated address space in its bucket then it will be marked as 
> “Invalid” if
> someone tries to advertise the same address space.
> 
> Currently, in the absence of any ROA, these bogons are marked as 
> “NotFound”. Since
> many operators have implemented ROV and either planning or already 
> discarding “Invalid”
> then all the AS0 ROAs which APNIC will create for unallocated address 
> space will be
> discarded as well.
> 
> 
> 3. Situation in other regions
> -
> No such policy in any region at the moment.
> 
> 
> 
> 4. Proposed policy solution
> ---
> APNIC will create AS0(zero) ROAs for all the unallocated address space 
> in its bucket
> (IPv4 and IPv6). Any resource holder can create AS0 (zero) ROAs for the 
> resources they
> have under their account.
> 
> A ROA is a positive attestation that a prefix holder has authorised an 
> AS to originate a
> route for this prefix whereas, a ROA for the same prefixes with AS0 
> (zero) origin shows
> negative intent from the resource holder that they don't want to 
> advertise the prefix(es)
> at this point but they are the rightful custodian.
> 
> Only APNIC has the authority to create ROAs for address space not yet 
> allocated to the members
> and only APNIC can issue AS0 (zero) ROAs. Once they ROA is issued and 
> APNIC wants to allocate
> the address space to its member, simply they can revoke the ROA and 
> delegate the address space
> to members. (this proposal doesn't formulate operational process).
> 
> 
> 5. Advantages / Disadvantages
> -
> Advantages:
> Those implementing ROV globally and discarding the invalids will be able 
> to discard bogons from
> APNIC region automatically.
> 
> Disadvantages:
> No apparent disadvantage
> 
> 
> 
> 6. Impact on resource holders
> -
> No impact to APNIC or respective NIR resource holders not implementing 
> ROV. Those im

Re: [sig-policy] Amendment of SIG Charter

[Owen DeLong]

My own opinion only and not speaking on behalf of or for the AC...

In the case of ARIN, your proposal was not to modify the PDP and addressed 
primarily the detailed operational practices of ARIN staff. It did not address 
the administration and registration of number resources, but rather the 
behavior of individuals external to ARIN with regard to how they configure 
their routers. 

In ARIN, the PDP is under the control of the board and is not modifiable via 
the PDP. 

I see no connection between your efforts here and your out of scope proposal 
there. 

Owen


> On May 14, 2019, at 06:15, Srinivas Chendi  wrote:
> 
> Hi Jordi,
> 
> Thanks for your contribution to this discussion so far.
> 
> As per the SIG Guidelines, Policy SIG Chair is responsible to accept or 
> reject a proposal and to check if it is in scope of the active SIG charter.
> 
> Please refer to the section 2.4 of SIG Guidelines
> https://www.apnic.net/community/participate/sigs/sig-guidelines/
> 
> 
> Accept or reject proposals for discussion at the forthcoming SIG (and 
> suggest an alternative forum if the topic is not relevant to that 
> particular SIG) [1]
> 
> [1] The Chair may decide that a proposal is not suitable for discussion 
> at the forthcoming SIG session if:
> 
> The proposal is out of scope for the SIG
> The proposal is insufficiently developed to be the basis for a 
> useful discussion
> The agenda has already been filled by topics of greater priority
> 
> 
> Regards
> Sunny
> 
>> On 14/05/2019 8:11 pm, JORDI PALET MARTINEZ wrote:
>> I’m not interpreting the PDP as part of that, however, I’m fine if the 
>> staff confirms that it is in-scope according to their understanding.
>> 
>> We have a recent experience of policies (resource hijacking is a policy 
>> violation) being declared out-of-scope in ARIN by the AC. I know the PDP 
>> is very different, but let’s make sure we don’t have this situation 
>> replicated in other APNIC.
>> 
>> 
>> Regards,
>> 
>> Jordi
>> 
>> El 11/5/19 18:05, "Owen DeLong" > <mailto:o...@delong.com>> escribió:
>> 
>> 
>> On May 11, 2019, at 06:13, JORDI PALET MARTINEZ 
>> mailto:jordi.pa...@consulintel.es>> wrote:
>> 
>>Just to make it clear. Do you believe that the PDP update is out of
>>the scope?
>> 
>> No
>> 
>> 
>> 
>>I think that the PDP is not related to resource management, but the
>>“self-management” of the way the community discusses the resource
>>management and agree on the way it should be managed.
>> 
>> The pdp is absolutely related to the management of resources in that it 
>> is the process by which we develop those policies.
>> 
>> 
>> 
>>And for me as more we restrict the wording, more risks to wrongly
>>get things that today are in-scope, to be left out.
>> 
>> Agreed. However, in my view, your proposal is not less restrictive, just 
>> more verbose.
>> 
>> Owen
>> 
>> 
>> 
>> 
>>Regards,
>> 
>>Jordi
>> 
>>El 11/5/19 1:27, "Owen DeLong" ><mailto:o...@delong.com>> escribió:
>> 
>>That’s not more generic, Jordi, it’s just more words.
>> 
>>There’s nothing within the scope of the policy manual or its updates
>>that doesn’t relate to the management and use of internet address
>>resources.
>> 
>>Owen
>> 
>> 
>> 
>> 
>>On May 10, 2019, at 09:30 , JORDI PALET MARTINEZ
>>mailto:jordi.pa...@consulintel.es>>
>>wrote:
>> 
>>Hi Paul, all,
>> 
>>I feel that this proposed charter is not good enough.
>> 
>>Let me try to explain it.
>> 
>>In RIPE we have a WG for every kind of “topic”, for example,
>>addressing, abuse, routing, etc. The PDP updates are discussed
>>in the “plenary” (we have recent small update and this was not
>>really clear).
>> 
>>However, in all the other regions, all the “topics” are within
>>the same “unique” WG. There is an exception for ARIN (if I’m
>>correct) where the PDP is not part of this “policy discussion
>>group”.
>> 
>>The proposed charter, may fail to cover for example the PDP
>>update, but I feel there are many other topics that may be in
>>the future in the same situation.
>> 
>>So why not something more generic in the line of:
>> 
>>“The Policy SIG c

Re: [sig-policy] Amendment of SIG Charter

[Owen DeLong]

> On May 11, 2019, at 06:13, JORDI PALET MARTINEZ  
> wrote:
> 
> Just to make it clear. Do you believe that the PDP update is out of the scope?
>  
No

> I think that the PDP is not related to resource management, but the 
> “self-management” of the way the community discusses the resource management 
> and agree on the way it should be managed.

The pdp is absolutely related to the management of resources in that it is the 
process by which we develop those policies. 

> And for me as more we restrict the wording, more risks to wrongly get things 
> that today are in-scope, to be left out.

Agreed. However, in my view, your proposal is not less restrictive, just more 
verbose. 

Owen

> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> El 11/5/19 1:27, "Owen DeLong"  escribió:
>  
> That’s not more generic, Jordi, it’s just more words.
>  
> There’s nothing within the scope of the policy manual or its updates that 
> doesn’t relate to the management and use of internet address resources.
>  
> Owen
>  
> 
> 
> On May 10, 2019, at 09:30 , JORDI PALET MARTINEZ  
> wrote:
>  
> Hi Paul, all,
>  
> I feel that this proposed charter is not good enough.
>  
> Let me try to explain it.
>  
> In RIPE we have a WG for every kind of “topic”, for example, addressing, 
> abuse, routing, etc. The PDP updates are discussed in the “plenary” (we have 
> recent small update and this was not really clear).
>  
> However, in all the other regions, all the “topics” are within the same 
> “unique” WG. There is an exception for ARIN (if I’m correct) where the PDP is 
> not part of this “policy discussion group”.
>  
> The proposed charter, may fail to cover for example the PDP update, but I 
> feel there are many other topics that may be in the future in the same 
> situation.
>  
> So why not something more generic in the line of:
> “The Policy SIG charter is to develop policies which relate to the management 
> and use of Internet address resources within the Asia Pacific region, 
> including any topics under the scope of the Policy manual or updates of it”.
> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> El 9/5/19 23:51, "Paul Wilson"  de pwil...@apnic.net> escribió:
>  
> Dear Sumon and all,
> To reduce confusion over ISP/LIR/etc terminology, perhaps the charter could 
> be stated more simply, along these lines:
> “The Policy SIG charter is to develop policies which relate to the management 
> and use of Internet address resources within the Asia Pacific region. …”
>  
> My 2c, with best regards,
>  
> 
> Paul Wilson, Director-General, APNIC d...@apnic.net
> http://www.apnic.net @apnicdg
> On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote:
>  
> Thank you very much Aftab and Owen for your constructive feedback. We will 
> definitely consider those views.
>  
> If any one has any different perspective please jump in and share your 
> thoughts.
>  
> Sincerely,
>  
> Sumon
>  
>   
>  
> On Mon, May 6, 2019 at 10:52 AM Owen DeLong  wrote:
> Aftab, I think you misread the proposed language. 
>  
> First, neither the current version nor the proposed version refer to members 
> at all, but to the actions of the APNIC, NIRs, and ISPs. The one change I 
> think should be made there is to replace ISPs with LIRs since not all LIRs 
> are technically ISPs, though that is certainly the most common case.
>  
> As to your “not limited to” or “services related to resources”, I fail to see 
> how that is not addressed by the proposed “…and related services”.
>  
> I support the language proposed by Sumon whether or not he chooses to take my 
> NIR suggestion.
>  
> Owen
>  
> 
> 
> 
> On May 5, 2019, at 03:21 , Aftab Siddiqui  wrote:
>  
> Thanks Sumon bhai for the initiative, 
>  
> 
> Revised text suggest that all members/resource holders in APNIC are ISPs 
> only, I would suggest to make it "APNIC and NIR members or resource holders 
> in Asia Pacific region". Because not all members are resource holders.
>  
> Secondly, when you start mentioning topics in the charter then it may create 
> confusion moving forward that only these topics can be covered so how about 
> adding "not limited to" or "services related to resources" or something like 
> that. 
> 
>  
>  
> Regards,
> 
> Aftab A. Siddiqui
>  
>  
> On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir  wrote:
> Dear Members,
> 
> 
> 
> In the last APNIC meeting in Daejoan there was a discussion that there is a 
> perception 
> That Policy SIG discusses 

Re: [sig-policy] Amendment of SIG Charter

[Owen DeLong]

That’s not more generic, Jordi, it’s just more words.

There’s nothing within the scope of the policy manual or its updates that 
doesn’t relate to the management and use of internet address resources.

Owen


> On May 10, 2019, at 09:30 , JORDI PALET MARTINEZ  
> wrote:
> 
> Hi Paul, all,
>  
> I feel that this proposed charter is not good enough.
>  
> Let me try to explain it.
>  
> In RIPE we have a WG for every kind of “topic”, for example, addressing, 
> abuse, routing, etc. The PDP updates are discussed in the “plenary” (we have 
> recent small update and this was not really clear).
>  
> However, in all the other regions, all the “topics” are within the same 
> “unique” WG. There is an exception for ARIN (if I’m correct) where the PDP is 
> not part of this “policy discussion group”.
>  
> The proposed charter, may fail to cover for example the PDP update, but I 
> feel there are many other topics that may be in the future in the same 
> situation.
>  
> So why not something more generic in the line of:
> “The Policy SIG charter is to develop policies which relate to the management 
> and use of Internet address resources within the Asia Pacific region, 
> including any topics under the scope of the Policy manual or updates of it”.
> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> El 9/5/19 23:51, "Paul Wilson"  <mailto:sig-policy-boun...@lists.apnic.net> en nombre de pwil...@apnic.net 
> <mailto:pwil...@apnic.net>> escribió:
>  
> Dear Sumon and all,
> 
> To reduce confusion over ISP/LIR/etc terminology, perhaps the charter could 
> be stated more simply, along these lines:
> 
> “The Policy SIG charter is to develop policies which relate to the management 
> and use of Internet address resources within the Asia Pacific region. …”
> 
>  
> My 2c, with best regards,
> 
>  
> 
> Paul Wilson, Director-General, APNIC d...@apnic.net
> http://www.apnic.net <http://www.apnic.net/> @apnicdg
> 
> On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote:
> 
>>  
>> Thank you very much Aftab and Owen for your constructive feedback. We will 
>> definitely consider those views.
>>  
>> If any one has any different perspective please jump in and share your 
>> thoughts.
>>  
>> Sincerely,
>>  
>> Sumon
>>  
>>   
>>  
>> On Mon, May 6, 2019 at 10:52 AM Owen DeLong > <mailto:o...@delong.com>> wrote:
>>> Aftab, I think you misread the proposed language. 
>>>  
>>> First, neither the current version nor the proposed version refer to 
>>> members at all, but to the actions of the APNIC, NIRs, and ISPs. The one 
>>> change I think should be made there is to replace ISPs with LIRs since not 
>>> all LIRs are technically ISPs, though that is certainly the most common 
>>> case.
>>>  
>>> As to your “not limited to” or “services related to resources”, I fail to 
>>> see how that is not addressed by the proposed “…and related services”.
>>>  
>>> I support the language proposed by Sumon whether or not he chooses to take 
>>> my NIR suggestion.
>>>  
>>> Owen
>>>  
>>> 
>>> 
>>>> On May 5, 2019, at 03:21 , Aftab Siddiqui >>> <mailto:aftab.siddi...@gmail.com>> wrote:
>>>>  
>>>> Thanks Sumon bhai for the initiative, 
>>>>  
>>>> 
>>>> Revised text suggest that all members/resource holders in APNIC are ISPs 
>>>> only, I would suggest to make it "APNIC and NIR members or resource 
>>>> holders in Asia Pacific region". Because not all members are resource 
>>>> holders.
>>>>  
>>>> Secondly, when you start mentioning topics in the charter then it may 
>>>> create confusion moving forward that only these topics can be covered so 
>>>> how about adding "not limited to" or "services related to resources" or 
>>>> something like that. 
>>>> 
>>>>  
>>>>  
>>>> Regards,
>>>> 
>>>> Aftab A. Siddiqui
>>>>  
>>>>  
>>>> On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir >>> <mailto:sasa...@gmail.com>> wrote:
>>>>> Dear Members,
>>>>> 
>>>>> 
>>>>> In the last APNIC meeting in Daejoan there was a discussion that there is 
>>>>> a perception 
>>>>> That Policy SIG discusses only about “Address Policy”. On the ot

Re: [sig-policy] Amendment of SIG Charter

[Owen DeLong]

Works for me.

Owen


> On May 9, 2019, at 20:50 , Paul Wilson  wrote:
> 
> Dear Sumon and all,
> 
> To reduce confusion over ISP/LIR/etc terminology, perhaps the charter could 
> be stated more simply, along these lines:
> 
> “The Policy SIG charter is to develop policies which relate to the management 
> and use of Internet address resources within the Asia Pacific region. …”
> 
> 
> My 2c, with best regards,
> 
> 
> 
> Paul Wilson, Director-General, APNIC d...@apnic.net
> http://www.apnic.net <http://www.apnic.net/> @apnicdg
> 
> On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote:
> 
> 
> Thank you very much Aftab and Owen for your constructive feedback. We will 
> definitely consider those views.
> 
> If any one has any different perspective please jump in and share your 
> thoughts.
> 
> Sincerely,
> 
> Sumon
> 
>   
> 
> On Mon, May 6, 2019 at 10:52 AM Owen DeLong  <mailto:o...@delong.com>> wrote:
> Aftab, I think you misread the proposed language.
> 
> First, neither the current version nor the proposed version refer to members 
> at all, but to the actions of the APNIC, NIRs, and ISPs. The one change I 
> think should be made there is to replace ISPs with LIRs since not all LIRs 
> are technically ISPs, though that is certainly the most common case.
> 
> As to your “not limited to” or “services related to resources”, I fail to see 
> how that is not addressed by the proposed “…and related services”.
> 
> I support the language proposed by Sumon whether or not he chooses to take my 
> NIR suggestion.
> 
> Owen
> 
> 
>> On May 5, 2019, at 03:21 , Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>> wrote:
>> 
>> Thanks Sumon bhai for the initiative,
>> 
>> 
>> Revised text suggest that all members/resource holders in APNIC are ISPs 
>> only, I would suggest to make it "APNIC and NIR members or resource holders 
>> in Asia Pacific region". Because not all members are resource holders.
>> 
>> Secondly, when you start mentioning topics in the charter then it may create 
>> confusion moving forward that only these topics can be covered so how about 
>> adding "not limited to" or "services related to resources" or something like 
>> that. 
>> 
>> 
>> 
>> Regards,
>> 
>> Aftab A. Siddiqui
>> 
>> 
>> On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir > <mailto:sasa...@gmail.com>> wrote:
>> Dear Members,
>> 
>> In the last APNIC meeting in Daejoan there was a discussion that there is a 
>> perception 
>> That Policy SIG discusses only about “Address Policy”. On the other hand 
>> there is a understanding 
>> that Policy SIG covers a wider range of registry issues, RPKI or any other 
>> topics that requires a
>> procedures and rules. 
>> 
>> To avoid confusion and to bring clarity in the Policy Charter few proposals 
>> came in. That either we can change the Name of the Policy SIG to cover wider 
>> range or to amend the Policy-SIG Charter to bring clarity about the scope of 
>> Policy SIG.
>> 
>> After discussions chairs feels that we can make some changes in the SIG 
>> Charter to bring clarity:
>> 
>> 
>> Current SIG Charter https://www.apnic.net/community/policy/policy-sig/ 
>> <https://www.apnic.net/community/policy/policy-sig/> says:
>> 
>> 
>> ‘The Policy SIG charter is to develop policies and procedures which relate 
>> to the management and 
>> use of Internet address resources by APNIC, NIRs, and ISPs within the Asia 
>> Pacific region.”
>> 
>> And here is the possible changes proposed:
>> 
>>  “The Policy SIG charter is to develop policies which relate to the 
>> management and use of Internet  address resources by APNIC, NIRs, and ISPs 
>> within the Asia Pacific region.  These include policies for resource 
>> allocation, recovery and transfer, and for resource registration within 
>> whois, reverse DNS, RPKI and related services.”
>> 
>> Please share your views, comments or suggestions in this regard.
>> 
>> 
>> Sincerely,
>> 
>> Sumon, Bertrand and Ching-Heng
>> Chairs, Policy-SIG
>> *  sig-policy:  APNIC SIG on resource management policy  
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>> https://mailman.apnic.net/mailman/listinfo/sig-policy 
>> <ht

Re: [sig-policy] Amendment of SIG Charter

[Owen DeLong]

Aftab, I think you misread the proposed language.

First, neither the current version nor the proposed version refer to members at 
all, but to the actions of the APNIC, NIRs, and ISPs. The one change I think 
should be made there is to replace ISPs with LIRs since not all LIRs are 
technically ISPs, though that is certainly the most common case.

As to your “not limited to” or “services related to resources”, I fail to see 
how that is not addressed by the proposed “…and related services”.

I support the language proposed by Sumon whether or not he chooses to take my 
NIR suggestion.

Owen


> On May 5, 2019, at 03:21 , Aftab Siddiqui  wrote:
> 
> Thanks Sumon bhai for the initiative,
> 
> 
> Revised text suggest that all members/resource holders in APNIC are ISPs 
> only, I would suggest to make it "APNIC and NIR members or resource holders 
> in Asia Pacific region". Because not all members are resource holders.
> 
> Secondly, when you start mentioning topics in the charter then it may create 
> confusion moving forward that only these topics can be covered so how about 
> adding "not limited to" or "services related to resources" or something like 
> that. 
> 
> 
> 
> Regards,
> 
> Aftab A. Siddiqui
> 
> 
> On Sun, May 5, 2019 at 4:31 PM Sumon Ahmed Sabir  > wrote:
> Dear Members,
> 
> In the last APNIC meeting in Daejoan there was a discussion that there is a 
> perception 
> That Policy SIG discusses only about “Address Policy”. On the other hand 
> there is a understanding 
> that Policy SIG covers a wider range of registry issues, RPKI or any other 
> topics that requires a
> procedures and rules. 
> 
> To avoid confusion and to bring clarity in the Policy Charter few proposals 
> came in. That either we can change the Name of the Policy SIG to cover wider 
> range or to amend the Policy-SIG Charter to bring clarity about the scope of 
> Policy SIG.
> 
> After discussions chairs feels that we can make some changes in the SIG 
> Charter to bring clarity:
> 
> 
> Current SIG Charter https://www.apnic.net/community/policy/policy-sig/ 
>  says:
> 
> 
> ‘The Policy SIG charter is to develop policies and procedures which relate to 
> the management and 
> use of Internet address resources by APNIC, NIRs, and ISPs within the Asia 
> Pacific region.”
> 
> And here is the possible changes proposed:
> 
>  “The Policy SIG charter is to develop policies which relate to the 
> management and use of Internet  address resources by APNIC, NIRs, and ISPs 
> within the Asia Pacific region.  These include policies for resource 
> allocation, recovery and transfer, and for resource registration within 
> whois, reverse DNS, RPKI and related services.”
> 
> Please share your views, comments or suggestions in this regard.
> 
> 
> Sincerely,
> 
> Sumon, Bertrand and Ching-Heng
> Chairs, Policy-SIG
> *  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

*  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-128-v001: Multihoming not required for ASN

[Owen DeLong]

> The point is, I’ve no doubt that the staff is smart to allow two consecutive 
> requests for addresses first and one instant after the ASN. However, this is 
> totally artificial in my opinion. No need for that.

It’s not artificial…

If you don’t have IP addresses, then you don’t have a routing policy and you 
don’t need an ASN.

If you are applying simultaneously for both, that’s all well and good and I’m 
sure that APNIC staff will serialize the requests for you to cope with the 
policy requirements.
 
> Second main issue. Yes, people can commit fraud, but policies should not 
> “facilitate that” if we can avoid it. Asking people to say “I will 
> multihome”, is not coherent if not verified, so let’s try to avoid “promises”.

I agree, but I don’t think asking people to provide some bare minimum assurance 
that they need a resource before we give it to them is “facilitating fraud”. I 
think it’s “responsible number resource policy”.

I think that the idea of giving out resources without first making some 
rudimentary verification of legitimate need is not “preventing fraud”, it’s 
actually "facilitating irresponsible resource usage" (which I don’t think we 
should do either).

Owen

> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> De: Owen DeLong mailto:o...@delong.com>>
> Fecha: viernes, 22 de febrero de 2019, 19:00
> Para: JORDI PALET MARTINEZ  <mailto:jordi.pa...@consulintel.es>>
> CC: Satoru Tsurumaki  <mailto:satoru.tsurum...@g.softbank.co.jp>>, Policy SIG  <mailto:sig-pol...@apnic.net>>
> Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN
>  
>  
> 
> 
>> On Feb 21, 2019, at 22:20 , JORDI PALET MARTINEZ > <mailto:jordi.pa...@consulintel.es>> wrote:
>>  
>> Hi again Satoru, and once more many thanks for the inputs,
>>  
>> If we keep “it holds previously-allocated provider independent address 
>> space”, then it means an organization, for example, deploying only IPv6, 
>> will not be able to get an ASN.
>  
> Why can’t they get previously-allocated IPv6 Provider Independent space?
>  
> 
>> Or even an organization willing to get IPv4, can’t get it from APNIC. Should 
>> them then wait for available IPv4 space and not have their own ASN meanwhile?
>  
> If they don’t have address space to advertise, what, exactly, are they going 
> to use the AS Number for in the mean time?
>  
> I’m not opposed to deleting the phrase, but I am truly curious if you have an 
> actual use case where removing it is harmful.
>  
> 
>> Or should they “promise” “I will multihome” and actually never do it? (there 
>> is no a concrete time term defined in the policy).
>  
> Ideally, no.
>  
> 
>> Or going to the extreme. Should the organization get IPv4 PI, but actually 
>> not use it?
>  
> This part still doesn’t make sense to me. The phrase mentioned does not 
> specify IPv4, yet you seem to be assuming that is a requirement. Am I missing 
> something?
>  
> 
>> Or should the organization request IPv6 PI today and tomorrow an ASN ? It is 
>> artificial!
>  
> Previously doesn’t necessarily mean separation by days. I think that the RIR 
> staff can be trusted to accept applications contemporaneously and issue the 
> addresses first, followed by he ASN, thus meeting the requirement in the 
> policy.
>  
> If you have a better way to address the issue they are bringing up, then 
> propose that and let’s discuss it as a community.
>  
> As I understand their message, the concern is issuing ASNs that have no 
> actual use/need. I don’t think anyone is trying to put up artificial barriers 
> to entry, but there is a desire to ensure that ASN acquisition doesn’t become 
> some form of network fashion statement.
>  
> 
>> If we really want to ensure that those organizations multihome, we really 
>> need to fix in how much time, and that was already changed in proposal 114. 
>> I think this proposal improves that, going to the point where probably 
>> prop-114 wanted to be (but sometimes you need to go step by step …).
>  
> I seem to recall Skeeve put forth a proposal to eliminate the multihoming 
> requirement some years back because it was becoming problematic in a number 
> of situations where peering was desirable, but multihoming couldn’t 
> necessarily be achieved (or at least had a longer than permitted time frame).
>  
> At the time, I had suggested the use of “Multihomed or otherwise demonstrate 
> a unique routing policy.” which actually pretty well covers any situation in 
> which you would need an ASN.
>  
> 
>> In general, I don’t think restricting non-scarce resources as ASN is a good 
>> thing, and if that

Re: [sig-policy] prop-124-version 5: Clarification on IPv6 Sub-Assignments

[Owen DeLong]

I express opposition to this policy change.

There seems to me a misunderstanding of the term sub assignments in the 
proposal.

A subassignment is an issuance of a portion of your prefix to an external third 
party recorded at the RIR level or provided in a public database (e.g. whois, 
rwhois, or RDAP).

Point to point prefixes are generally exempt from being reported to the 
registry. In the case of a guest WiFi or VPN, again, these are not generally 
considered to be external subassignments subject to reporting.

The intent of the policy as written as I understand it (and staff, please 
clarify if APNIC is applying different interpretation) is to cover situations 
where an LIR (whether service provider or otherwise) is making recorded 
delegations of smaller blocks of address space to external entities (e.g. when 
an ISP assigns a /48 to a customer end site). It is not intended to and does 
not (to the best of my knowledge) preclude any of the use cases you have 
mentioned.

Owen


> On Feb 21, 2019, at 21:46 , JORDI PALET MARTINEZ  
> wrote:
> 
> Dear Satoru, all,
>  
> First of all, thanks a lot for your inputs!
>  
> Let me try to clarify this.
>  
> The text of the problem statement has been the same (maybe minor variations) 
> across the 4 previous versions, so it is difficult to understand what is not 
> clear now, which can have been addressed before.
>  
> In any case, what it matters in a policy proposal, is the policy text and the 
> objective of the change.
>  
> What happens with current policy is that if you’re an enterprise with 
> assigned addressing space, you can only use it for your own infrastructure 
> and within it.
>  
> If you want to have a “guest” WiFi (visitors in the company, students in a 
> University), or you need to provide it via VPN, or point-to-point links, it 
> is not allowed. The problem statement just provides more examples and cases, 
> but everything boils down to the same.
>  
> I don’t think that was the intended purpose of the original policy, but that 
> text has been carried out from IPv4 policies, and in most of the cases, there 
> you don’t have the same problem because you’re providing to the visitors or 
> students private addressing space behind a NAT.
>  
> Let me know please, if this is clearer as a “short” for the problem statement 
> and objective of the policy change.
> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> De:  en nombre de Satoru Tsurumaki 
> 
> Fecha: viernes, 22 de febrero de 2019, 12:29
> Para: Policy SIG 
> Asunto: Re: [sig-policy] prop-124-version 5: Clarification on IPv6 
> Sub-Assignments
>  
> 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 12th Feb to discuss these proposals.
>  
> Many participants expressed a neutral for the proposal with reasons that
> the problem in the current policy is something vague.
>  
> And a few opposing comments were expressed with same reason as above.
>  
>  
> Best Regards,
>  
> Satoru Tsurumaki
> JPOPF-ST
>  
> 2019年1月10日(木) 13:28 Bertrand Cherrier  >:
>> Dear SIG members,
>> 
>> We wish you all the best for this new year !
>> 
>> A new version of the proposal "prop-124: Clarification on IPv6
>> Sub-Assignments"
>> has been sent to the Policy SIG for review.
>> 
>> 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-v005: Clarification on IPv6 Sub-Assignments
>> 
>> Proposer: Jordi Palet Martínez
>> jordi.pa...@theipv6company.com 
>> 1. Problem Statement
>> 
>> 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 because the usage of NAT.
>> 
>> 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 n

Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

[Owen DeLong]

> On Feb 21, 2019, at 22:20 , JORDI PALET MARTINEZ  
> wrote:
> 
> Hi again Satoru, and once more many thanks for the inputs,
>  
> If we keep “it holds previously-allocated provider independent address 
> space”, then it means an organization, for example, deploying only IPv6, will 
> not be able to get an ASN.

Why can’t they get previously-allocated IPv6 Provider Independent space?
 
> Or even an organization willing to get IPv4, can’t get it from APNIC. Should 
> them then wait for available IPv4 space and not have their own ASN meanwhile?

If they don’t have address space to advertise, what, exactly, are they going to 
use the AS Number for in the mean time?

I’m not opposed to deleting the phrase, but I am truly curious if you have an 
actual use case where removing it is harmful.
 
> Or should they “promise” “I will multihome” and actually never do it? (there 
> is no a concrete time term defined in the policy).

Ideally, no.
 
> Or going to the extreme. Should the organization get IPv4 PI, but actually 
> not use it?

This part still doesn’t make sense to me. The phrase mentioned does not specify 
IPv4, yet you seem to be assuming that is a requirement. Am I missing something?
 
> Or should the organization request IPv6 PI today and tomorrow an ASN ? It is 
> artificial!

Previously doesn’t necessarily mean separation by days. I think that the RIR 
staff can be trusted to accept applications contemporaneously and issue the 
addresses first, followed by he ASN, thus meeting the requirement in the policy.

If you have a better way to address the issue they are bringing up, then 
propose that and let’s discuss it as a community.

As I understand their message, the concern is issuing ASNs that have no actual 
use/need. I don’t think anyone is trying to put up artificial barriers to 
entry, but there is a desire to ensure that ASN acquisition doesn’t become some 
form of network fashion statement.
 
> If we really want to ensure that those organizations multihome, we really 
> need to fix in how much time, and that was already changed in proposal 114. I 
> think this proposal improves that, going to the point where probably prop-114 
> wanted to be (but sometimes you need to go step by step …).

I seem to recall Skeeve put forth a proposal to eliminate the multihoming 
requirement some years back because it was becoming problematic in a number of 
situations where peering was desirable, but multihoming couldn’t necessarily be 
achieved (or at least had a longer than permitted time frame).

At the time, I had suggested the use of “Multihomed or otherwise demonstrate a 
unique routing policy.” which actually pretty well covers any situation in 
which you would need an ASN.
 
> In general, I don’t think restricting non-scarce resources as ASN is a good 
> thing, and if that happens APNIC should report it back to the community and 
> then we may consider it back.

Having trouble parsing this sentence. If restriction of the resources occurs, 
it will be through policy, so I’m not sure what APNIC would need to report back 
to the community.
 
> Current text is artificial in the sense that already prop-114 expressed. 
> People can just lie “I will …”.

People can commit fraud in a number of ways in a variety of circumstances. I 
don’t think that the answer in most situations is to permit all the benefits by 
removing the rules to make it impossible to commit fraud (or at least 
pointless). It’s sort of like saying “Everyone on this freeway is always doing 
200Kph, therefore we should raise the speed limit to 200Kph.” If someone 
obtains resources from a falsified application, then they are committing fraud 
and I’m sure the APNIC legal team is quite capable of addressing that situation 
should sufficient evidence come to light.

Owen

> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> De:  en nombre de Satoru Tsurumaki 
> 
> Fecha: viernes, 22 de febrero de 2019, 12:30
> Para: Policy SIG 
> Asunto: Re: [sig-policy] prop-128-v001: Multihoming not required for ASN
>  
> 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-128,
> based on a meeting we organized on 12th Feb to discuss these proposals.
>  
> Substantial support expressed, subject to not deleting the 
> "it holds previously-allocated provider independent address space" 
> described in the current policy text.
>  
> * In this proposal, "it holds previously-allocated provider independent 
> address space" is erased. it should keep it in order to prevent unnecessary
> application of AS number.
>  
> * In the case of IPv6, the NAT disappears and the global address is assigned
> to all device in the organization. If each organization uses a PI address
> that is not locked in to a upper provider, there is a great merit that
> there is no need to procure the second transit.
>  
> *There are areas where have only one transit as pointed out by the proposer.
> This p

Re: [sig-policy] Prop124 version 4

[Owen DeLong]

> On Sep 11, 2018, at 16:19 , JORDI PALET MARTINEZ  
> wrote:
> 
> Hi Owen,
>  
> For me (and a couple of other folks that I checked around this morning), your 
> wording is more difficult to read.
> 

> This may be because we aren’t native English speakers.

Interesting… Probably be. As a native English speaker, frankly, your version 
simply doesn’t parse. The grammar doesn’t really work.

Examples:

“Providing addressing space” is an invalid construct. You could correct 
this with “Providing address space” to fix the grammar, but it doesn’t
really fix the remaining awkwardness of the rest of the sentence. I 
chose the words “Providing IP number resources” to match the common
technical phrase used in a lot of RIR policy to cover IPv4, IPv6, and 
possibly ASNs.

If you want to limit it to just IP addresses, including both v4 and v6 
(and possible future protocols), we could use “Providing IP address(es)”
instead.

The construct non-permanently is awkward and does not read well. 
Perhaps it works in other languages, but in English a native speaker
would either use some conjugation of “impermanent” or more often, 
“temporary” (e.g. temporarily). Since I know you previously had some
negative emotional reaction to the idea of replacing non-permanent with 
“temporary”, I decided to try “impermanent”

I also removed a number of improper commas that really really made it 
hard to parse properly.
 
> Also, your wording has an “or” and I was using “and/or” to make sure to allow 
> the cases when the holder needs “both” (has an external contractor using 
> on-site devices and has employees visiting the network).
>  
> Nevertheless, I think I’m fine either way if we replace the “or” with the 
> “and/or”.

Yep… That’s an easy solution to your concern. However, FWIW, to a native 
speaker, in that context, the or is clearly intended to be inclusive rather 
than exclusive as an exclusive or would be nonsensical.

So I guess the question is do we want to write policies in english that are 
best suited for foreign readers while ill suited to parsing by native speakers, 
or, do we want
to write policies in grammatically proper english.

Don’t get me wrong, I’m the first to admit I make my share of spelling and 
grammar errors. The person I’d defer to for judgment on any such issue would be 
Lee Howard.

I’m actually OK either way, but, it seems to me that if we want the former, we 
have a slippery slope of problems, including, but not limited to:

+   Which language(s) native speakers are we optimizing for?
+   How do we resolve conflicts in optimizing for multiple 
different non-english languages in our english 
+   If we have some other target language we prefer to optimize 
for, why aren’t we just using that language in the first place?

At the end of the day, my only dog in the fight is wanting to have clear policy 
that is understood by all who must live with and/or implement it.

Owen


> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> De: Owen DeLong mailto:o...@delong.com>>
> Fecha: miércoles, 12 de septiembre de 2018, 4:17
> Para: JORDI PALET MARTINEZ  <mailto:jordi.pa...@consulintel.es>>
> CC: Satoru Tsurumaki  <mailto:satoru.tsurum...@g.softbank.co.jp>>, SIG policy  <mailto:sig-pol...@apnic.net>>
> Asunto: Re: [sig-policy] Prop124 version 4
>  
> Rather than explain each part of your text, I think it would be more useful 
> if you explained where my text doesn’t convey the same intent.
>  
> Owen
>  
> 
> 
>> On Sep 10, 2018, at 22:16 , JORDI PALET MARTINEZ > <mailto:jordi.pa...@consulintel.es>> wrote:
>>  
>> Hi Owen, all,
>>  
>> In previous versions I tried to make a shorter text and didn’t worked.
>>  
>> Let me try to explain each part:
>>  
>> 1.   “Providing addressing space to third party devices including 
>> addresses for 
>> point-to-point links”
>>  
>> This covers the case of a subcontractor with devices siting on the holders 
>> network may be for several years, and in this case they are “permanently” 
>> connected (during the duration of the contract), explained in my problem 
>> statement as:
>>  
>> 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.
>> 

Re: [sig-policy] Prop124 version 4

[Owen DeLong]

Rather than explain each part of your text, I think it would be more useful if 
you explained where my text doesn’t convey the same intent.

Owen


> On Sep 10, 2018, at 22:16 , JORDI PALET MARTINEZ  
> wrote:
> 
> Hi Owen, all,
>  
> In previous versions I tried to make a shorter text and didn’t worked.
>  
> Let me try to explain each part:
>  
> “Providing addressing space to third party devices including addresses for 
> point-to-point links”
>  
> This covers the case of a subcontractor with devices siting on the holders 
> network may be for several years, and in this case they are “permanently” 
> connected (during the duration of the contract), explained in my problem 
> statement as:
>  
> 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.
>  
> Of course, the 2nd part of the sentence is for the point-to-point links, I 
> think that’s very obvious.
>  
> “and/or non-permanently providing addressing space to third Parties”
>  
> This covers the other cases, BYOD (employee or guest of a corporation, 
> student of a university, visitor in a hot-spot, etc.), which are more 
> commonly for some hours or minutes, even days.
>  
> “The provision of addressing space for permanent or semi-permanent 
> connectivity, 
> such as broadband services, is still considered a sub-assignment.”
>  
> We want to make sure that ISPs, typically offering broadband services, aren’t 
> end-users, as they should be LIRs.
> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> De: Owen DeLong mailto:o...@delong.com>>
> Fecha: martes, 11 de septiembre de 2018, 15:29
> Para: JORDI PALET MARTINEZ  <mailto:jordi.pa...@consulintel.es>>
> CC: Satoru Tsurumaki  <mailto:satoru.tsurum...@g.softbank.co.jp>>, SIG policy  <mailto:sig-pol...@apnic.net>>
> Asunto: Re: [sig-policy] Prop124 version 4
>  
> Aside from the question of examples or not examples, I offer the following 
> suggestion… The wording is quite awkward and difficult to parse. So much so, 
> I am not 100% certain of the intent.
>  
> I offer the following suggestion for a rewrite hoping that I have captured 
> the intent accurately:
>  
> ===
>  
> Providing IP number resources to third party devices, including addresses for 
> point-to-point links or addresses provided on an impermanent basis, for use 
> on a network managed and operated by the assignment holder shall not be 
> considered a sub-assignment.
>  
> Providing IP number resources for permanent or semi-permanent connectivity, 
> such as broadband services is still considered a sub-assignment.
>  
> ===
>  
> Owen
>  
> 
> 
>> On Sep 10, 2018, at 20:55 , JORDI PALET MARTINEZ > <mailto:jordi.pa...@consulintel.es>> wrote:
>>  
>> Hi Satoru,
>>  
>> Thanks for commenting on this.
>>  
>> The current proposal text has not examples, I think it is quite neutral in 
>> this aspect:
>>  
>> Providing addressing space to third party devices including addresses for 
>> point-to-point links and/or non-permanently providing addressing space to 
>> third 
>> parties, for use on a network managed and operated by the assignment holder, 
>> shall not be considered a sub-assignment.
>>  
>> The provision of addressing space for permanent or semi-permanent 
>> connectivity, 
>> such as broadband services, is still considered a sub-assignment.
>>  
>> I think having the examples in the “objective” of the policy proposal is 
>> needed to clarify the reason for it. You don’t think so?
>> 
>> Regards,
>> Jordi
>> 
>>  
>> 
>>  
>>  
>> De: > <mailto:sig-policy-boun...@lists.apnic.net>> en nombre de Satoru Tsurumaki 
>> > <mailto:satoru.tsurum...@g.softbank.co.jp>>
>> Fecha: martes, 11 de septiembre de 2018, 14:02
>> Para: SIG policy mailto:sig-pol...@apnic.net>>
>> Asunto: Re: [sig-policy] Prop124 version 4
>>  
>> Dear Colleagues,
>>  
>> I am Satoru Tsurumaki from Japan Open Policy Forum.
>>  
>> I would like to share key feedback in our community for prop-124,
>> based on a meeting we organised on 22nd Aug to discuss these proposals.
>>  
>> M

Re: [sig-policy] Prop124 version 4

[Owen DeLong]

Aside from the question of examples or not examples, I offer the following 
suggestion… The wording is quite awkward and difficult to parse. So much so, I 
am not 100% certain of the intent.

I offer the following suggestion for a rewrite hoping that I have captured the 
intent accurately:

===

Providing IP number resources to third party devices, including addresses for 
point-to-point links or addresses provided on an impermanent basis, for use on 
a network managed and operated by the assignment holder shall not be considered 
a sub-assignment.

Providing IP number resources for permanent or semi-permanent connectivity, 
such as broadband services is still considered a sub-assignment.

===

Owen


> On Sep 10, 2018, at 20:55 , JORDI PALET MARTINEZ  
> wrote:
> 
> Hi Satoru,
>  
> Thanks for commenting on this.
>  
> The current proposal text has not examples, I think it is quite neutral in 
> this aspect:
>  
> Providing addressing space to third party devices including addresses for 
> point-to-point links and/or non-permanently providing addressing space to 
> third 
> parties, for use on a network managed and operated by the assignment holder, 
> shall not be considered a sub-assignment.
>  
> The provision of addressing space for permanent or semi-permanent 
> connectivity, 
> such as broadband services, is still considered a sub-assignment.
>  
> I think having the examples in the “objective” of the policy proposal is 
> needed to clarify the reason for it. You don’t think so?
> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> De:  en nombre de Satoru Tsurumaki 
> 
> Fecha: martes, 11 de septiembre de 2018, 14:02
> Para: SIG policy 
> Asunto: Re: [sig-policy] Prop124 version 4
>  
> Dear Colleagues,
>  
> I am Satoru Tsurumaki from Japan Open Policy Forum.
>  
> I would like to share key feedback in our community for prop-124,
> based on a meeting we organised on 22nd Aug to discuss these proposals.
>  
> Many supporting opinions were expressed on this proposal.
> However, also many concerning comment was expressed to explain the specific 
> examples.
> For this matter, the same opinion was given also at JPOPM34.
>  
>   - It is better to stop specific examples because they tend to fall into 
> discussion of adding / not applying / not applicable.
>   - I think that specific examples should be stated in the guidelines rather 
> than policies.
> 
> Regards,
> Satoru Tsurumaki
>  
>  
> 2018-09-09 18:37 GMT+11:00 Bertrand Cherrier  >:
>> Dear SIG members
>> 
>> A new version of the proposal "prop-124: Clarification on IPv6 
>> Sub-Assignments"
>> has been sent to the Policy SIG for review.
>> 
>> 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-v004: Clarification on IPv6 Sub-Assignments
>> 
>> Proposer: Jordi Palet Martínez
>> jordi.pa...@theipv6company.com 
>> 1. Problem Statement
>> 
>> 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 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,
>> 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
>> 
>> Secti

Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy

[Owen DeLong]

> On Jan 31, 2018, at 11:52 , Mike Burns  wrote:
> 
> “This is, IMHO, the kind of speculation in 103/8 blocks that the policy 
> (original 2 year limit) was intended to target.”
>  
> Not to my thinking. The thing that was targeted by policy was the tapping of 
> the free pool in order to then turn around and sell.  The problem foreseen 
> was a recurrence of the RIPE problem, where new LIRs are spun up just to 
> avail themselves of the pool reserved for new applicants.
>  
> In the case I mentioned, the buyer, who did not tap the pool but instead paid 
> money, is now prevented from resale.

True, but the person he bought the registration from, OTOH, was only able to 
sell due to the loophole, so I have little sympathy for this particular corner 
case.

> If the target of the policy is the protection of the remaining pool reserved 
> for new entrants, preventing *prior* recipients from selling is missing that 
> target, because the free pool is not affected.

This is the same logic that failed with Ivory.
 
> That is why I could support a waiting period moving forward, as that will 
> protect the pool as intended. I would concur with your 24 month period as 
> being more reasonable.

As I stated previously in reply to Skeeve. The statistics don’t bear out the 
problem I thought would exist, so I’m no longer objecting to this proposal. 
However, I don’t grant the premise of your argument above.

Owen

>  
> Regards,
> Mike
>  
>  
>  
>  
>  
> From: Owen DeLong [mailto:o...@delong.com <mailto:o...@delong.com>] 
> Sent: Wednesday, January 31, 2018 2:39 PM
> To: Mike Burns mailto:m...@iptrading.com>>
> Cc: Skeeve Stevens  <mailto:skeeve+sigpol...@eintellegonetworks.asia>>; Bertrand Cherrier 
> mailto:b.cherr...@micrologic.nc>>; 
> sig-pol...@apnic.net <mailto:sig-pol...@apnic.net>
> Subject: Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
>  
> We can agree to disagree.
>  
> This is, IMHO, the kind of speculation in 103/8 blocks that the policy 
> (original 2 year limit) was intended to target.
>  
> The expansion of this to a 5 year limit, while excessive IMHO, seems to 
> likely be community reaction to just this sort of behavior, so I have no 
> problem with the result.
>  
> Owen
>  
>> On Jan 31, 2018, at 09:06 , Mike Burns > <mailto:m...@iptrading.com>> wrote:
>>  
>> We brokered a sale of a 103 block when it was within policy to do so.
>>  
>> Now that buyer, who paid money for the block with the understanding that he 
>> could resell it, has had the situation changed to his detriment by the new 
>> restrictive policy.
>>  
>> I support the grandfathering-in of 103 blocks allocated prior to the recent 
>> 5 year policy, allowing them to be resold but preventing those who receive 
>> 103 blocks after the 5 year policy was implemented from reselling before 5 
>> years.  (Although  5 years is too long, IMO)
>>  
>> I support this policy.
>>  
>>  
>>  
>> From: sig-policy-boun...@lists.apnic.net 
>> <mailto:sig-policy-boun...@lists.apnic.net> 
>> [mailto:sig-policy-boun...@lists.apnic.net 
>> <mailto:sig-policy-boun...@lists.apnic.net>] On Behalf Of Skeeve Stevens
>> Sent: Wednesday, January 31, 2018 11:40 AM
>> To: Bertrand Cherrier > <mailto:b.cherr...@micrologic.nc>>
>> Cc: sig-pol...@apnic.net <mailto:sig-pol...@apnic.net> SIG List 
>> mailto:sig-pol...@apnic.net>>
>> Subject: Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
>>  
>> I very much support this policy. A policy should not be retrospectively 
>> applied otherwise anything any of us may do or plan to do can be considered 
>> guaranteed, and I would see a case for requesting APNIC to return funds for 
>> any services provided that have been negated by policy changes.
>>  
>> I also very much object to the 5 year period that snuck in at the last APNIC 
>> meeting. I was happy with 2 years, but 5 years is unreasonable.
>>  
>> I was going to make a submission to change this back to 2 years, but 
>> unfortunately, work got in the way and I did not get the submission in on 
>> time. Next meeting maybe.
>> 
>> 
>> ...Skeeve
>>  
>> Skeeve Stevens - Founder & The Architect - eintellego Networks (Cambodia) 
>> Pte Ltd.
>> Email: ske...@eintellegonetworks.asia 
>> <mailto:ske...@eintellegonetworks.asia> ; Web: eintellegonetworks.asia 
>> <http://eintellegonetworks.asia/>
>> Cell +61 (0)414 753 383 ; Skype: skeeve
>> Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks&g

Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]

[Owen DeLong]

Actually, I have to agree.

I’m pleasantly surprised by the statistics.

Owen

> On Feb 1, 2018, at 07:11 , Skeeve Stevens 
>  wrote:
> 
> With these statistics, I fail to see the problem that was being addressed as 
> opposed to the problem is now causes by limiting the way people do their 
> business.
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Founder & The Architect - eintellego Networks (Cambodia) Pte 
> Ltd.
> Email: ske...@eintellegonetworks.asia <mailto:ske...@eintellegonetworks.asia> 
> ; Web: eintellegonetworks.asia <http://eintellegonetworks.asia/>
> Cell +61 (0)414 753 383 ; Skype: skeeve <>
> Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; 
> Twitter: eintellego <https://twitter.com/eintellego>
> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile 
> <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve 
> <https://keybase.io/skeeve>
> 
> Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises
> 
> On Thu, Feb 1, 2018 at 7:29 PM, Guangliang Pan  <mailto:g...@apnic.net>> wrote:
> Hello Owen,
> 
>  
> 
> There is 1.86% of the delegations from 103/8 block have been transferred by 
> M&A. Out of that, only 5 ranges transferred more than once.
> 
>  
> 
> There are 152 members acquired 103/8 ranges via M&A transfers. It is 1% of 
> the total membership (includes members under NIRs). Out of that, 123 members 
> received one range, 16 members received two ranges and 13 members received 
> more two ranges. 
> 
>  
> 
> Kind regards,
> 
> Guangliang
> 
> ==
> 
>  
> 
>  
> 
>  
> 
> From: Owen DeLong [mailto:o...@delong.com <mailto:o...@delong.com>] 
> Sent: Thursday, 1 February 2018 3:00 AM
> To: Skeeve Stevens  <mailto:skeeve%2bsigpol...@eintellegonetworks.asia>>
> Cc: Guangliang Pan mailto:g...@apnic.net>>; 
> mailman_SIG-policy mailto:sig-pol...@apnic.net>>
> Subject: Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy 
> [SECURITY=UNCLASSIFIED]
> 
>  
> 
> I would argue that 257 probably represents a significant fraction of the 
> distributed portion of 103/8.
> 
>  
> 
> I would be interested if staff can answer what percentage of the issued 103/8 
> resources have been subject
> 
> to one or more M&A transfers since issuance. I’d be especially interested in 
> the number instances where
> 
> the same entity has “acquired” more than entity that holds 103/8 block(s).
> 
>  
> 
> I am concerned that there could be an emerging pattern of:
> 
>  
> 
>   1.   Stand up shell entity
> 
>   2.   Subscribe shell entity to APNIC and obtain 103/8 
> block.
> 
>   3.   Merge shell entity into parent entity and M&A 
> transfer block into parent’s holdings.
> 
>   4.   Lather, rinse, repeat.
> 
>  
> 
> Owen
> 
>  
> 
> On Jan 31, 2018, at 08:47 , Skeeve Stevens 
>  <mailto:skeeve+sigpol...@eintellegonetworks.asia>> wrote:
> 
>  
> 
> This number is so small in the scheme of things it should NOT have been 
> enshrined in policy.
> 
> 
> 
> 
> ...Skeeve
> 
>  
> 
> Skeeve Stevens - Founder & The Architect - eintellego Networks (Cambodia) Pte 
> Ltd.
> 
> Email: ske...@eintellegonetworks.asia <mailto:ske...@eintellegonetworks.asia> 
> ; Web: eintellegonetworks.asia <http://eintellegonetworks.asia/>
> Cell +61 (0)414 753 383 ; Skype: skeeve
> 
> Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; 
> Twitter: eintellego <https://twitter.com/eintellego>
> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile 
> <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve 
> <https://keybase.io/skeeve>
>  
> 
> Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises
> 
>  
> 
> On Tue, Jan 30, 2018 at 1:11 PM, Guangliang Pan  <mailto:g...@apnic.net>> wrote:
> 
> Hi Aftab,
> 
>  
> 
> The number of M&A transfers involved 103/8 address block from 15 April 2011 
> to 14 Sep 2017 is 257.
> 
>  
> 
> Kind regards,
> 
> Guangliang
> 
> ==
> 
>  
> 
> From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com 
> <mailto:aftab.siddi...@gmail.com>] 
> Sent: Monday, 29 January 2018 8:49 PM
> To: Guangliang Pan mailto:g...@apnic.net>>
> Cc: Sanjeev Gupta mailto:sanj...@dcs1.biz>>; 
> mailman_SIG-policy mailto:sig-pol...@apnic.

Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy

[Owen DeLong]

We can agree to disagree.

This is, IMHO, the kind of speculation in 103/8 blocks that the policy 
(original 2 year limit) was intended to target.

The expansion of this to a 5 year limit, while excessive IMHO, seems to likely 
be community reaction to just this sort of behavior, so I have no problem with 
the result.

Owen

> On Jan 31, 2018, at 09:06 , Mike Burns  wrote:
> 
> We brokered a sale of a 103 block when it was within policy to do so.
>  
> Now that buyer, who paid money for the block with the understanding that he 
> could resell it, has had the situation changed to his detriment by the new 
> restrictive policy.
>  
> I support the grandfathering-in of 103 blocks allocated prior to the recent 5 
> year policy, allowing them to be resold but preventing those who receive 103 
> blocks after the 5 year policy was implemented from reselling before 5 years. 
>  (Although  5 years is too long, IMO)
>  
> I support this policy.
>  
>  
>  
> From: sig-policy-boun...@lists.apnic.net 
>  
> [mailto:sig-policy-boun...@lists.apnic.net 
> ] On Behalf Of Skeeve Stevens
> Sent: Wednesday, January 31, 2018 11:40 AM
> To: Bertrand Cherrier  >
> Cc: sig-pol...@apnic.net  SIG List 
> mailto:sig-pol...@apnic.net>>
> Subject: Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
>  
> I very much support this policy. A policy should not be retrospectively 
> applied otherwise anything any of us may do or plan to do can be considered 
> guaranteed, and I would see a case for requesting APNIC to return funds for 
> any services provided that have been negated by policy changes.
>  
> I also very much object to the 5 year period that snuck in at the last APNIC 
> meeting. I was happy with 2 years, but 5 years is unreasonable.
>  
> I was going to make a submission to change this back to 2 years, but 
> unfortunately, work got in the way and I did not get the submission in on 
> time. Next meeting maybe.
> 
> 
> ...Skeeve
>  
> Skeeve Stevens - Founder & The Architect - eintellego Networks (Cambodia) Pte 
> Ltd.
> Email: ske...@eintellegonetworks.asia  
> ; Web: eintellegonetworks.asia 
> Cell +61 (0)414 753 383 ; Skype: skeeve
> Facebook: eintellegonetworks  ; 
> Twitter: eintellego 
> LinkedIn: /in/skeeve  ; Expert360: Profile 
>  ; Keybase: https://keybase.io/skeeve 
> 
>  
> Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises
>  
> On Fri, Jan 26, 2018 at 2:27 PM, Bertrand Cherrier  > wrote:
>> Dear SIG members,
>> 
>> The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has
>> been sent to the Policy SIG for review.
>> 
>> It will be presented at the Open Policy Meeting at APNIC 45 in
>> Kathmandu, Nepal on Tuesday, 27 February 2018.
>> 
>> 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-123 
>> 
>> 
>> Regards
>> 
>> Sumon, Bertrand, Ching-Heng
>> APNIC Policy SIG Chairs
>> 
>> https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt 
>>  
>> 
>> ---
>>  
>> prop-123-v001: Modify 103/8 IPv4 transfer policy
>>  
>> ---
>>  
>> Proposer:Alex Yang
>>  yang...@126.com 
>>  
>>  
>> 1. Problem statement
>> ---
>>  
>> Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in 
>> the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep 
>> 2017. Since that APNIC has stopped all the IPv4 transfers from 103/8 
>> block if the delegation date is less than 5 years.
>>  
>> However, some of the 103/8 ranges were delegated before 14 Sep 2017. 
>> Those resources should not be subjected to 5 years restriction. The 
>> community wa

Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]

[Owen DeLong]

> On Jan 31, 2018, at 10:09 , Skeeve Stevens 
>  wrote:
> 
> Owen,
> 
> Of course, there is the possibility (probability) of this, but that would be 
> stupid as the costs of maintaining companies would exceed CGN or other 
> methods to alleviate the need.

Maintaining? Once you do the merge, there’s no need to maintain.

Standing up a shell company is pretty cheap and easy in most places. I’m sure 
there’s at least one country somewhere in the APNIC region where this is true. 
If there’s no stricture on M&A acquisitions of 103/8 space, not even a minimal 
time limit, then I would argue it’s pretty hard to distinguish this activity 
from “real M&A” on a policy basis. After all, a real company (albeit a shell 
company, this is very hard to detect) is applying for and receiving space and 
then “really” being “acquired” by the “independent” organization that spun it 
up in the first place. On paper it’s 100% legitimate normal business practice 
and it’s virtually impossible to distinguish this from (e.g. 3Com spinning off 
Palm and then later acquiring it, then spinning it off where it was eventually 
acquired by HP).

I agree that 5 years is way too long and exceeds the useful delay here, but I 
think that a 24 month waiting period after acquiring is not at all unreasonable.

Owen

> The issue here is that APNIC needs to be satisfied it is a real M&A, which 
> should not be that hard to do.
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Founder & The Architect - eintellego Networks (Cambodia) Pte 
> Ltd.
> Email: ske...@eintellegonetworks.asia <mailto:ske...@eintellegonetworks.asia> 
> ; Web: eintellegonetworks.asia <http://eintellegonetworks.asia/>
> Cell +61 (0)414 753 383 ; Skype: skeeve <>
> Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; 
> Twitter: eintellego <https://twitter.com/eintellego>
> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile 
> <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve 
> <https://keybase.io/skeeve>
> 
> Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises
> 
> On Thu, Feb 1, 2018 at 4:00 AM, Owen DeLong  <mailto:o...@delong.com>> wrote:
> I would argue that 257 probably represents a significant fraction of the 
> distributed portion of 103/8.
> 
> I would be interested if staff can answer what percentage of the issued 103/8 
> resources have been subject
> to one or more M&A transfers since issuance. I’d be especially interested in 
> the number instances where
> the same entity has “acquired” more than entity that holds 103/8 block(s).
> 
> I am concerned that there could be an emerging pattern of:
> 
>   1.  Stand up shell entity
>   2.  Subscribe shell entity to APNIC and obtain 103/8 block.
>   3.  Merge shell entity into parent entity and M&A transfer block 
> into parent’s holdings.
>   4.  Lather, rinse, repeat.
> 
> Owen
> 
>> On Jan 31, 2018, at 08:47 , Skeeve Stevens 
>> > <mailto:skeeve+sigpol...@eintellegonetworks.asia>> wrote:
>> 
>> This number is so small in the scheme of things it should NOT have been 
>> enshrined in policy.
>> 
>> 
>> ...Skeeve
>> 
>> Skeeve Stevens - Founder & The Architect - eintellego Networks (Cambodia) 
>> Pte Ltd.
>> Email: ske...@eintellegonetworks.asia 
>> <mailto:ske...@eintellegonetworks.asia> ; Web: eintellegonetworks.asia 
>> <http://eintellegonetworks.asia/>
>> Cell +61 (0)414 753 383 ; Skype: skeeve <>
>> Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; 
>> Twitter: eintellego <https://twitter.com/eintellego>
>> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile 
>> <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve 
>> <https://keybase.io/skeeve>
>> 
>> Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises
>> 
>> On Tue, Jan 30, 2018 at 1:11 PM, Guangliang Pan > <mailto:g...@apnic.net>> wrote:
>> Hi Aftab,
>> 
>>  
>> 
>> The number of M&A transfers involved 103/8 address block from 15 April 2011 
>> to 14 Sep 2017 is 257.
>> 
>>  
>> 
>> Kind regards,
>> 
>> Guangliang
>> 
>> ==
>> 
>>  
>> 
>> From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com 
>> <mailto:aftab.siddi...@gmail.com>] 
>> Sent: Monday, 29 January 2018 8:49 PM
>> To: Guangliang Pan mailto:g...@apnic.net>>
>> Cc: Sanjeev Gupta mailto:sanj...@dcs1.biz>>; 
>>

Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]

[Owen DeLong]

I would argue that 257 probably represents a significant fraction of the 
distributed portion of 103/8.

I would be interested if staff can answer what percentage of the issued 103/8 
resources have been subject
to one or more M&A transfers since issuance. I’d be especially interested in 
the number instances where
the same entity has “acquired” more than entity that holds 103/8 block(s).

I am concerned that there could be an emerging pattern of:

1.  Stand up shell entity
2.  Subscribe shell entity to APNIC and obtain 103/8 block.
3.  Merge shell entity into parent entity and M&A transfer block 
into parent’s holdings.
4.  Lather, rinse, repeat.

Owen

> On Jan 31, 2018, at 08:47 , Skeeve Stevens 
>  wrote:
> 
> This number is so small in the scheme of things it should NOT have been 
> enshrined in policy.
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Founder & The Architect - eintellego Networks (Cambodia) Pte 
> Ltd.
> Email: ske...@eintellegonetworks.asia  
> ; Web: eintellegonetworks.asia 
> Cell +61 (0)414 753 383 ; Skype: skeeve <>
> Facebook: eintellegonetworks  ; 
> Twitter: eintellego 
> LinkedIn: /in/skeeve  ; Expert360: Profile 
>  ; Keybase: https://keybase.io/skeeve 
> 
> 
> Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises
> 
> On Tue, Jan 30, 2018 at 1:11 PM, Guangliang Pan  > wrote:
> Hi Aftab,
> 
>  
> 
> The number of M&A transfers involved 103/8 address block from 15 April 2011 
> to 14 Sep 2017 is 257.
> 
>  
> 
> Kind regards,
> 
> Guangliang
> 
> ==
> 
>  
> 
> From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com 
> ] 
> Sent: Monday, 29 January 2018 8:49 PM
> To: Guangliang Pan mailto:g...@apnic.net>>
> Cc: Sanjeev Gupta mailto:sanj...@dcs1.biz>>; 
> mailman_SIG-policy mailto:sig-pol...@apnic.net>>
> Subject: Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy 
> [SECURITY=UNCLASSIFIED]
> 
>  
> 
> Hi Guangliang,
> 
> How many M&A were processed for 103/8 address block from 15 April 2011 to 14 
> Sep 2017.
> 
>  
> 
> On Mon, 29 Jan 2018 at 06:43 Guangliang Pan  > wrote:
> 
> Hi Sanjeev,
> 
>  
> 
> The number of delegations from 103/8 pool since 29 Jan 2013 (Five years count 
> back from today) to 14 Sep 2017 is 10868. These are the delegations are not 
> allowed to transfer as of today according to prop-116-v006.
> 
>  
> 
> Kind regards,
> 
> Guangliang
> 
> =
> 
>  
> 
>  
> 
> From: sig-policy-boun...@lists.apnic.net 
>  
> [mailto:sig-policy-boun...@lists.apnic.net 
> ] On Behalf Of Sanjeev Gupta
> Sent: Monday, 29 January 2018 3:34 PM
> To: Henderson Mike, Mr  >
> Cc: mailman_SIG-policy mailto:sig-pol...@apnic.net>>
> Subject: Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy 
> [SECURITY=UNCLASSIFIED]
> 
>  
> 
> Hi,
> 
>  
> 
> I see this as more of a "do not make policy retroactively".  People who 
> "bought" an "asset" in good faith should not be told it is worth different 
> now.
> 
>  
> 
> I am amenable to changing the cut-off date in Prop-123 to the date it was 
> sent to the Policy SIG, as that might have given warning to people the rules 
> were changing.
> 
>  
> 
> APNIC Secretariat, how many transfers will be affected by Prop-123?
> 
>  
> 
> 
> 
> -- 
> Sanjeev Gupta
> +65 98551208http://sg.linkedin.com/in/ghane 
> 
>  
> 
> On Mon, Jan 29, 2018 at 4:16 AM, Henderson Mike, Mr 
> mailto:michael.hender...@nzdf.mil.nz>> wrote:
> 
> Not supported
> 
>  
> 
> The proposal should in my opinion be amended to read:
> 
> ___
> 
> Disadvantages:
>  
> None Completely negates the purpose of prop-116-v006: Prohibit to transfer 
> IPv4 addresses in 
> the final /8 block.
> ___
> 
>  
> 
>  
> 
> Regards
> 
>  
> 
>  
> 
> Mike
> 
>  
> 
> From: sig-policy-boun...@lists.apnic.net 
>  
> [mailto:sig-policy-boun...@lists.apnic.net 
> ] On Behalf Of Bertrand Cherrier
> Sent: Friday, 26 January 2018 4:28 p.m.
> To: sig-pol...@apnic.net 
> Subject: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
> 
>  
> 
> Dear SIG members,
> 
> The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has
> been sent to the Policy SIG for review.
> 
> It will be presented at the Open Policy Meeting at APNIC 45 in
> Kathmandu, Nepal on Tuesday, 27 February 2018.
> 
> We invite you to review and comment on the proposal on the mailing lis

Re: [sig-policy] sig-policy Digest, Vol 160, Issue 27--- apply in the address allocated after the policy officially issued

[Owen DeLong]

IIRC, it’s part of the contract that you agree to accept policy changes adopted 
by the community, so I see no reason to grandfather.

Owen

> On Oct 13, 2017, at 02:36 , Brown Kevin  wrote:
> 
> There is a big problem what is the range of the transfer prohibition,
> all the allocated 103/8 or new allocated after this policy officially
> issued.
> I noticed that in the current policy, there is no special prohibit
> term for 103/8 transfer. and the ploicy is part of the contract
> between members and NIRs or LIRs or APNIC.
> If the modified policy applied in these old 103/8 address which was
> applied befeore this new policy. Is it a kind of break contract?
> I think this policy should only apply the address applied after the
> policy officially issued.
> 
> 
> Best Regards,
> Kevin
> *  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

Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

[Owen DeLong]

> On Aug 18, 2017, at 2:38 AM, Lu Heng  wrote:
> 
> Hi Aftab:
> 
> I believe your understanding of spammer operation is not at all based on 
> reality. 

Aftab’s description of spammer operations is very much based in reality.

> Spammers merely need one to two-month space, and they disappear soon. Thus, 
> there is no point for them to undergo this temporary transfer in order to 
> sort out all the APNIC membership with a huge amount of paper work when they 
> can simply pay (or hijack) for an announcement and have their spam job done.

You’d be surprised.

> Have you ever experienced during your operation history: a spammer come to 
> you and say, 'hey we want to have a proper RIR registration in our name. For 
> this we are so scared that you will take away space from us while we are 
> spamming?’

Usually they aim for RIR registration in the name of one of their shell 
companies, but I don’t see any reason that this temporary transfer policy 
wouldn’t also be used that way.

> Could you answer that directly?  
> 
> The policy which aims to bring more accurate whois database for today's 
> leasing market of space actually forces leaser to register their leaser's 
> information in the whois database by offering protection of leasee and 
> leaser's interest and by agreeing to set an amount time of ownership. One of 
> the biggest risks faced by leasee is the probability of the leaser cancelling 
> assignment or sub-allocation. This will lead to operation problem if they are 
> not ready for network renumbering. In this sense, the protection can be an 
> incentive for leasees to register their information properly.

In my observation, the primary users of today’s “leasing market” of IPv4 
address space are, in fact, snowshoe spammers, so you’re kind of making Aftab’s 
case here.

Owen

> 
> On 18 August 2017 at 07:22, Aftab Siddiqui  > wrote:
>  
> It is already a possibility in the RIPE region to do such transfers.
> 
>  
> And? 
>  
> It is really to cover a corner case where organisations are not able
> or interested in receiving the IP space in form of assignments or
> sub-allocations, but need them to be part of their own registry for
> full control of the space and only for a pre-set amount of time.
> 
> Solution is simple, if the organization is not interested in receiving the 
> resources as assignments and sub-allocations then just buy it. 
> 
> What is full control? creation of route-objects? or anything which can't be 
> done by sending an email to helpd...@apnic.net ?
>  
> I do not believe that spammer would benefit from this policy as they
> would have to register with APNIC as members and provide all the
> needed paperwork such as company registration papers, ID/passports,
> billing address etc...
> 
> It will definitely support the spammers by all means. You temperorary 
> transfer resource to Spammer, they do their thing and get black listed 
> everywhere and then you get the resources back and ask everyone that we are 
> the new owner of this resource so kindly remove all the listing. REPEAT.
>  
> They are much better off renting a /24 from the black market with no
> traces or documented changes ion the address block.
> 
> Yup, let them pay black market rates for black market business model. 
>  
> And what will be the temporary transfer fees? same as permanent transfer 
> fees? or free? 
> 
> In order to resolve a corner case it will open up opertunities for spammers. 
> I stronly oppose it.
> -- 
> Best Wishes,
> 
> Aftab A. Siddiqui
> 
> *  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 
> 
> 
> 
> 
> -- 
> --
> Kind regards.
> Lu
> 
> *  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

Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

[Owen DeLong]

I oppose this policy.

Any legitimate case for a “temporary transfer” that I can envision would be 
supported through SWIP from an LIR providing services.

Otherwise, this amounts to a lease-style transaction which is most popular when 
related to activities that are generally considered harmful to the internet 
(snowshoe spamming being the most common example).

Owen

> On Aug 9, 2017, at 2:16 AM, chku  wrote:
> 
> Dear SIG members
> 
> The proposal "prop-119: Temporary transfers" was sent to the Policy SIG
> Mailing list in May 2017.
> 
> It will be presented at the Open Policy Meeting at APNIC 44 which will 
> be held in Taichung, Taiwan on Wednesday and Thursday, 14 & 15 September 
> 2017.
> 
> Information about the proposal is available from:
> 
>http://www.apnic.net/policy/proposals/prop-119
> 
> You are encouraged to express your views on the proposal:
> 
> - Do you support or oppose the proposal?
> - 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?
> 
> Please find the text of the proposal below.
> 
> Kind Regards,
> 
> Sumon, Ching-Heng, Bertrand
> APNIC Policy SIG Chairs
> 
> 
> 
> 
> prop-119-v001: Temporary transfers
> 
> 
> 
> Proposer:   David Hilario
>d.hila...@laruscloudservice.net
> 
> 1. Problem statement
> 
> 
> It is currently not possible for an organisation to receive a temporary
> transfer under the current policy framework. Some organisations do not
> want to have address space registered as assignments or sub-allocations,
> but would rather have the address space registered as "ALLOCATED PA". 
> 
> 
> 2. Objective of policy change
> 
> 
> Create a possibility for temporary transfers that would allow
> organisations to have resources directly registered under them while
> they are the custodians of these resources on the Internet. While also
> guaranteeing that the offering party will under the APNIC policy be able
> to recover the resources once the “lease” time has expired unless
> specifically renewed.
> 
> 
> 3. Situation in other regions
> 
> 
> RIPE region has a concept of temporary transfers in their policies. This
> concept is not found in the other RIRs for the moment.
> 
> 
> 4. Proposed policy solution
> 
> 
> Adding to section "8.2.1. Conditions on the space to be transferred" the
> following paragraphs: It must be specified if the transfer is a
> permanent or temporary transfer.
> 
> A temporary transfer must have an end date, upon the end date the
> resources will be transferred back to the same origin account or its
> successor in the event of merger and acquisitions, unless the transfer
> is specifically prolonged and confirmed by both parties.
> 
> If the source account does no longer exist and has no successor, the
> space will then be returned to the origin RIR for the space. Temporary
> transfers cannot be further transferred.
> 
> 
> 5. Advantages / Disadvantages
> 
> 
> Advantages:
> Gives a greater flexibility in how LIRs manage and distribute their free
> pool. Enables organisation to receive address space in the way they
> intend.
> 
> Disadvantages:
> These transfers would be treated and appear as regular transfers, only
> APNIC the offering and receiving party will be aware of their temporary
> nature. 
> 
> Organisations receiving such space, if they further assign it, must make
> be ready to renumber/revoke space from their customers and services then
> the lease expires, this is no different than a sub-allocation and
> implies the same limitations.
> 
> 
> 6. Impact on resource holders
> 
> none
> 
> 
> 7. References
> -
> 
> 
> 
> 
> 
> 
> 
> ___
> Sig-policy-chair mailing list
> sig-policy-ch...@apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy-chair
> <00.txt>*  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

Re: [sig-policy] prop-118-v001: No need policy in APNIC region

[Owen DeLong]

I disagree…

I believe that needs testing still preserves the idea of distributing addresses 
to those with need even in a post-exhaustion world.

This serves to discourage speculative transactions and other transfers to those 
not actually needing addresses which would only drive prices up and not provide 
any benefit to the community.

Owen

> On Feb 24, 2017, at 08:32 , Pacswitch Email  wrote:
> 
> Hello all,
> 
> I agreed that APNIC should accept all transfer without question because IP 
> resource could be count into a assets to the IP holder in accounting. That's 
> mean the ip holder have the right to request transfer to or from other APNIC 
> members or other RIR.
> 
> Ernest Tse
> 
> Sent from Mobile
> 
> David Hilario  > 於 2017年2月24日 22:04 寫道：
> 
>> 
>> 
>> Hi Aftab,
>> 
>> This is only to simplify things, need based policies are there to protect 
>> the free pool from exhaustion and ensure fair distribution.
>> 
>> Space that is already out there can already be transferred without much 
>> hassle, removing the need base justification just simplifies the whole 
>> process, making the transfer faster and smoother.
>> 
>> 
>> David Hilario
>> 
>> IP Manager
>> 
>> Larus Cloud Service Limited
>> 
>> p: +852 29888918   m: +359 89 764 1784 
>> 
>> f: +852 29888068 
>> a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
>> w: laruscloudservice.net/uk   
>> e: d.hila...@laruscloudservice.net 
>> On 22 February 2017 at 10:04, Aftab Siddiqui > > wrote:
>> Thanks Guangliang for the update.
>> 
>> Hi David, what are we trying to fix?
>> 
>> On Wed, 22 Feb 2017 at 14:13 Guangliang Pan > > wrote:
>> Hi Aftab,
>> 
>>  
>> 
>> We don't have a case that rejected because the recipient could not 
>> demonstrate need. However, during the evaluation process, APNIC Hostmasters 
>> often ask for more support documents before approve large transfers.
>> 
>>  
>> 
>> Kind regards,
>> 
>>  
>> 
>> Guangliang
>> 
>> ==
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com 
>> ] 
>> Sent: Wednesday, 22 February 2017 12:23 AM
>> To: David Hilario; Guangliang Pan
>> Cc: sig-pol...@apnic.net 
>> 
>> Subject: Re: [sig-policy] prop-118-v001: No need policy in APNIC region
>> 
>>  
>> 
>> Hi Guangliang,
>> 
>> Do you have any stats on rejection rate due to weak requirement 
>> justifications? 
>> 
>>  
>> 
>> On Tue, 21 Feb 2017 at 18:34 David Hilario > > wrote:
>> 
>> Dear Benny,
>> 
>>  
>> 
>> Thank you for asking for clarifications. 
>> 
>>  
>> 
>> This proposal is for any transfer, within in or out of region.
>> 
>>  
>> 
>> The need based part is only needed to match any registry requiring a need 
>> based justification, this can be another RIR or even an NIR.
>> 
>>  
>> 
>> 
>> 
>> David Hilario
>> 
>> IP Manager
>> 
>> Larus Cloud Service Limited
>> 
>> p: +852 29888918   m: +359 89 764 1784 
>> 
>> f: +852 29888068 
>> a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
>> w: laruscloudservice.net/uk   
>> e: d.hila...@laruscloudservice.net 
>>  
>> 
>> On 21 February 2017 at 05:38, Guangliang Pan > > wrote:
>> 
>> Dear David,
>> 
>>
>> 
>> From implementation point of view, I would like to double check if the 
>> following proposal will also apply to transfers within the APNIC region.
>> 
>>
>> 
>> - APNIC shall accept all transfers of Internet number resources to its
>> 
>>service region, provided that they comply with the policies relating
>> 
>>to transfers within its service region.
>> 
>>
>> 
>> Best regards,
>> 
>>  
>> 
>> Guangliang Pan (Benny)
>> 
>> Registration Services Manager, APNIC
>> 
>> Email: g...@apnic.net 
>> SIP: g...@voip.apnic.net 
>> Phone: +61 7 3858 3188 
>> http://www.apnic.net 
>> -
>> 
>> * You can now call APNIC Helpdesk for free using Skype. For more information
>> 
>> visit: www.apnic.net/helpdesk 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: sig-policy-boun...@lists.apnic.net 
>>  
>> [mailto:sig-policy-boun...@lists.apnic.net 
>> ] On Behalf Of David Hilario
>> Sent: Friday, 17 February 2017 12:17 AM
>> To: sig-pol...@apnic.net 
>> Subject: Re: [sig-policy] prop-118-v001: No need policy in APNIC region
>> 
>>  
>> 
>>  
>> 
>> Dear list,
>> 
>>  
>> 
>> We are only a few days away from the meeting in Saigon.
>> 
>> There h

Re: [sig-policy] Prop-115 revised.

[Owen DeLong]

Sanjaya,

I think that’s a fine idea.

I don’t think that this is “too operational” for the main policy document so 
much as it’s simply not a matter of policy.

Policy and the existing database already fully enable the practice outlined in 
the proposal. Therefore, there is no need for policy
in order to enable it.

Since the proposal seeks to make this an optional use of  free-form text field 
in the database rather than mandatory, all the
necessary policy is already in place.

All that is needed now is to somehow identify and convince those that may wish 
to participate in this optional step.

That’s not a policy matter. That’s a matter for something like a best practices 
document.

Owen

> On Mar 9, 2016, at 20:56 , Sanjaya Sanjaya  wrote:
> 
> Ruri and all,
> 
> I've been wondering if we could perhaps, as a community, develop a "[APNIC] 
> Whois & Internet Routing Registry Best Practice Guide for Network Operators" 
> that could include the solution to the problem raised here? This could be a 
> way out for those who think that the suggestion Ruri proposed is too 
> 'operational' to be included in the main APNIC Policy document.
> 
> My 2 cents.
> 
> Cheers,
> Sanjaya
> APNIC Deputy Director General
> 
> -Original Message-
> From: sig-policy-boun...@lists.apnic.net 
> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Ruri Hiromi
> Sent: Thursday, 10 March 2016 2:37 PM
> To: Mark Foster
> Cc: sig-pol...@apnic.net; 藤崎智宏
> Subject: Re: [sig-policy] Prop-115 revised.
> 
> Hello, Mark and all in the list.
> 
> Thanks for your comment.
> 
> Your thoughts in the mail is just we want to describe as policy proposal.
> 
> Someone in the meeting place said that is not "policy　issue" but I think it 
> should be going with policy decision among policy-SIG members if implemented 
> in the whois DB.
> 
> We also had a comment that this is related to privacy issue.
> As Mr.Mark also pointed out in his mail, it is nothing to do with privacy of 
> users because LIR/ISP just add their "standard size of assignment for 
> customers" and does not specify who has the address.　But Am I missing some 
> points?
> 
> Which is the best choice of implementation?
> I also think whois DB is the best one, which is useful and reasonable.
> 
> Any comments and questions are welcomed, thank you.
> 
> Regards,
> 
> On 2016/02/25 6:41, Mark Foster wrote:
>> Hello,
>> I would like to thank Ruri Hiromi for presenting during the Policy-SIG 
>> today at APRICOT.
>> I confess to having only limited time to review this discussion group 
>> and as such, the presentation as made to the SIG was the first that I 
>> was aware of this discussion.
>> The discussion and result of the meeting caused me to search my email 
>> for this discussion and I found this email, which helped me understand 
>> the intent.
>> 
>> As I understand it, the level of detail that is being suggested for 
>> addition to 'whois', is simply a generic statement as regards to the 
>> 'standard' size of an allocation from within an IPv^ supernet?  And 
>> that the purpose for this, is to allow third parties wish to filter 
>> traffic at a level which limits 'collateral damage' when applying that 
>> filter, perhaps with a view to blocking traffic from insecure or 
>> poorly configured IoT devices that may receive an IPv6 address from 
>> within a customer allocation?
>> 
>> If this is the case, then I would suggest the 'path of least resistance'
>> would be to have this documented as an optional standard, that service 
>> providers may choose to adopt.
>> Important for the understanding of the community is that (if my 
>> understanding is correct) this is simply a two-line type addition to 
>> the supernet whois entry - 'The standard allocation size in this 
>> network is /56' (or similar) - so that a third party wishing to apply 
>> a filter to only a single customer of said service provider, may apply 
>> it to the /56 from which the offending /132 (or /64) originates and 
>> ensure then that other customers of said service provider are not 
>> inadvertantly filtered.
>> 
>> Am I right?
>> If this is the extent, then I would revise my position and endorse 
>> this proposal as an optional recommendation to service providers in 
>> the initial stages, perhaps to measure the usefulness of the change 
>> and determine if it should become something more compelling down-track?
>> 
>> Thanks,
>> Mark.
>> 
>> PS: I believe that 'whois' is the right place for this information; it 
>> was already noted that this can be done in 'remarks' right now. Any 
>> service provider looking to implement a filter against malicious 
>> traffic, etc, is likely going to need to use whois to determine the 
>> source (and scope) of the problem they are addressing in any case. It 
>> would seem to be a low-noise, low-drama way of imparting a potentially 
>> useful piece of information. As such I support only the 'whois' option 
>> presented below at this point.
>> 
>> 
>> On Mon, Feb 15

Re: [sig-policy] An interesting policy question

[Owen DeLong]

Lu, as I stated elsewhere, I did read your post, but I do not trust you.

Owen

> On Dec 6, 2015, at 01:13 , h...@anytimechinese.com wrote:
> 
> I have explained the reasoning of asking it fairly well in one of the list 
> and Owen just didn't read it and speculate my action, fair warning, read to 
> Owen, do not speculate people's action on public space without ground.l, 
> especially such action was already explained publicly. 
> 
> On 6 Dec 2015, at 5:06 AM, Owen DeLong  <mailto:o...@delong.com>> wrote:
> 
>> Fair warning, Lu asked the identical question on the ARIN list and (I 
>> presume the RIPE list since he left RIPE in all
>> the key places in the one he posted to ARIN).
>> 
>> It seems to me that he may be doing some form of registry policy shopping.
>> 
>> Owen
>> 
>>> On Dec 4, 2015, at 06:07 , Skeeve Stevens >> <mailto:ske...@v4now.com>> wrote:
>>> 
>>> Hi Lu,
>>> 
>>> 1st: I would say no.  There are no followups after allocation and there 
>>> should not be due to the many complication issues that can happen.
>>> 
>>> 2nd: I would say no.  The changing of network infrastructure should NOT 
>>> invalidate the original request which is approved. 
>>> 
>>> 
>>> 
>>> ...Skeeve
>>> 
>>> Skeeve Stevens - Senior IP Broker
>>> v4Now - an eintellego Networks service
>>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
>>> <http://www.v4now.com/>
>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
>>> facebook.com/v4now <http://facebook.com/v4now> ;  
>>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
>>> <http://linkedin.com/in/skeeve>
>>> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
>>> www.theispguy.com <http://www.theispguy.com/> ; Keybase: 
>>> https://keybase.io/skeeve <https://keybase.io/skeeve>
>>> 
>>> IP Address Brokering - Introducing sellers and buyers
>>> 
>>> On Fri, Dec 4, 2015 at 8:12 PM, Lu Heng >> <mailto:h...@anytimechinese.com>> wrote:
>>> Hi
>>> 
>>> I have an policy question regarding the "need".
>>> 
>>> We all know when RIR makes approves assignment LIR made if it is beyond 
>>> LIR's assignment window, while the "need" has changed, the assignment 
>>> become invalid.
>>> 
>>> The question come to what the definition of need, as a young people here, I 
>>> am a bit confused, Below I have few examples, please enlighten me if anyone 
>>> has an thought about it.
>>> 
>>> First one:
>>> 
>>> Company A provides 100 customer dedicated server service at location A, RIR 
>>> makes an assignment for 100 IP for his infrastructure, if, under condition 
>>> that no other factor was changed, Company A moved his infrastructure to 
>>> location B, but still providing same service to same customer, does the 
>>> company's action need to be notified  to RIR? And does this action 
>>> considered invalid the original assignment?
>>> 
>>> Second one:
>>> 
>>> Company A provides web hosting service, but any casted in 3 location, and 
>>> has provided the evidence of 3 location to the RIR during the time the 
>>> company getting valid assignment, then A decided to cut 3 location to 2 
>>> location, does this invalid original assignment and need to be notified to 
>>> RIR?
>>> 
>>> So the bottom line is, what is the definition of need, is it defined as the 
>>> service you are providing or defined as whole package of any of original 
>>> justification material was provided, if was the later, then does it imply 
>>> that anything, including location of the infrastructure, upstream providers 
>>> etc has changed due to operational need, it will be considered as change of 
>>> purpose of use and need to be notified to RIR?
>>> 
>>> What should be the right interpretation of the policy by then?
>>> 
>>> 
>>> -- 
>>> --
>>> Kind regards.
>>> Lu
>>> 
>>> 
>>> *  sig-policy:  APNIC SIG on resource management policy 
>>>   *
>>> ___
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy 
>>> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
>>> 
>>> 
>>> *  sig-policy:  APNIC SIG on resource management policy 
>>>   *
>>> ___
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy 
>>> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
>> 

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] An interesting policy question

[Owen DeLong]

Fair warning, Lu asked the identical question on the ARIN list and (I presume 
the RIPE list since he left RIPE in all
the key places in the one he posted to ARIN).

It seems to me that he may be doing some form of registry policy shopping.

Owen

> On Dec 4, 2015, at 06:07 , Skeeve Stevens  wrote:
> 
> Hi Lu,
> 
> 1st: I would say no.  There are no followups after allocation and there 
> should not be due to the many complication issues that can happen.
> 
> 2nd: I would say no.  The changing of network infrastructure should NOT 
> invalidate the original request which is approved. 
> 
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com  ; www.v4now.com 
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
> facebook.com/v4now  ;  
> linkedin.com/in/skeeve 
> 
> twitter.com/theispguy  ; blog: 
> www.theispguy.com  ; Keybase: 
> https://keybase.io/skeeve 
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On Fri, Dec 4, 2015 at 8:12 PM, Lu Heng  > wrote:
> Hi
> 
> I have an policy question regarding the "need".
> 
> We all know when RIR makes approves assignment LIR made if it is beyond LIR's 
> assignment window, while the "need" has changed, the assignment become 
> invalid.
> 
> The question come to what the definition of need, as a young people here, I 
> am a bit confused, Below I have few examples, please enlighten me if anyone 
> has an thought about it.
> 
> First one:
> 
> Company A provides 100 customer dedicated server service at location A, RIR 
> makes an assignment for 100 IP for his infrastructure, if, under condition 
> that no other factor was changed, Company A moved his infrastructure to 
> location B, but still providing same service to same customer, does the 
> company's action need to be notified  to RIR? And does this action considered 
> invalid the original assignment?
> 
> Second one:
> 
> Company A provides web hosting service, but any casted in 3 location, and has 
> provided the evidence of 3 location to the RIR during the time the company 
> getting valid assignment, then A decided to cut 3 location to 2 location, 
> does this invalid original assignment and need to be notified to RIR?
> 
> So the bottom line is, what is the definition of need, is it defined as the 
> service you are providing or defined as whole package of any of original 
> justification material was provided, if was the later, then does it imply 
> that anything, including location of the infrastructure, upstream providers 
> etc has changed due to operational need, it will be considered as change of 
> purpose of use and need to be notified to RIR?
> 
> What should be the right interpretation of the policy by then?
> 
> 
> -- 
> --
> Kind regards.
> Lu
> 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net 
> http://mailman.apnic.net/mailman/listinfo/sig-policy 
> 
> 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] The status of APNIC's IPv4 resources

[Owen DeLong]

> On Sep 15, 2015, at 17:58 , Paul Wilson  wrote:
> 
> Thanks Owen.
> 
> On 16 Sep 2015, at 10:00, Owen DeLong wrote:
>> I fully support the plan George described.
>> 
>> If George states that policy is useful in pursuing that plan, I say we pass 
>> a policy that codifies the plan.
>> 
>> Otherwise, I say let’s focus our efforts on IPv6 and let IPv4 disintegrate 
>> as it will.
> 
> I agree with the sentiment, however let’s remember that there is demonstrated 
> demand for IPv4 addresses, and ongoing interest in how the address space is 
> managed.  It is not for APNIC (Secretariat) to judge that or do anything 
> other than respond as we are requested to do so (both in terms of services 
> provided and participation in discussions as they arise).
> 

It certainly wasn’t my intent to state otherwise. My point is that as a member 
of the community, I’d like to see the community pursue effective IPv6 
deployment rather than wasting energy on rearranging the IPv4 deck chairs 
unless we identify an area where rearrangement is critical.

Since George has identified what I believe to be an excellent course of action 
that will be followed in the absence of policy development, I believe there is 
no need for policy development here. However, it may be that having policy to 
back up their actions is somehow useful to the staff in a way I don’t obviously 
see, so it may be that there is a need to codify this plan in policy that I am 
unaware of. As such, my intent was to request that staff make the community 
aware if that is the case.

Otherwise, I think there is nothing to do here and we can get on with the 
business of deploying IPv6 and running our networks.

I apologize for any misunderstanding.

(Skeeve summed up what I intended to say quite well, for example).

Owen

> All the best!
> 
> Paul.
> 
> 
> 
>> 
>> Owen
>> 
>>> On Sep 15, 2015, at 15:10 , Skeeve Stevens  wrote:
>>> 
>>> This sounds good George.
>>> 
>>> Do you need any support from the community to bring this into affect... in 
>>> the form of endorsement on this list, policy proposal (happy to do one).
>>> 
>>> Let us know.
>>> 
>>> 
>>> ...Skeeve
>>> 
>>> Skeeve Stevens - Senior IP Broker
>>> v4Now - an eintellego Networks service
>>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
>>> <http://www.v4now.com/>
>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
>>> facebook.com/v4now <http://facebook.com/v4now> ;  
>>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
>>> <http://linkedin.com/in/skeeve>
>>> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
>>> www.theispguy.com <http://www.theispguy.com/> ; Keybase: 
>>> https://keybase.io/skeeve <https://keybase.io/skeeve>
>>> 
>>> IP Address Brokering - Introducing sellers and buyers
>>> 
>>> On Wed, Sep 16, 2015 at 8:07 AM, George Kuo >> <mailto:geo...@apnic.net>> wrote:
>>> Hi Owen,
>>> 
>>> 
>>> On 15/09/2015 3:36 am, Owen DeLong wrote:
>>> 
>>> On Sep 14, 2015, at 01:59 , Masato Yamanishi >> <mailto:myama...@gmail.com>
>>> <mailto:myama...@gmail.com <mailto:myama...@gmail.com>>> wrote:
>>> 
>>> Dear Colleagues,
>>> 
>>> In Jakarta, Geoff Huston presented the status of our IPv4 resources,
>>> in particular about exhaustion and transfer,
>>> and some participants asked to summarize and post it to the list for
>>> further discussion.
>>> 
>>> Following is Chairs' summary of the presentation and discussion.
>>> 
>>> 1. Status of APNIC Final /8 pool (103/8)
>>> - Will run out ~4-5 years
>>> 
>>> I think this is an appropriate time frame for runout of this pool as it
>>> will be at least that long before new entrants are not in need of some
>>> way to communicate with the legacy IPv4 internet.
>>> 
>>> 2. Status of IANA Recovered pool (non-103)
>>> - Will run out in next 7 months+
>>> - IANA may allocate additional space in every 6 months
>>> - This pool will repeatedly ‘run-out’ as IANA delegates more space
>>> and it is distributed by APNIC
>>> - May need policy to deal with temporary exhaustion of the non-103 pool
>>>  -> Close the door when exhausted or create the waiting list and
>>> put further applications to there?
>>> 
>>> I really don’t care what we do here. What would be the defa

Re: [sig-policy] The status of APNIC's IPv4 resources

[Owen DeLong]

I fully support the plan George described.

If George states that policy is useful in pursuing that plan, I say we pass a 
policy that codifies the plan.

Otherwise, I say let’s focus our efforts on IPv6 and let IPv4 disintegrate as 
it will.

Owen

> On Sep 15, 2015, at 15:10 , Skeeve Stevens  wrote:
> 
> This sounds good George.
> 
> Do you need any support from the community to bring this into affect... in 
> the form of endorsement on this list, policy proposal (happy to do one).
> 
> Let us know.
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
> <http://www.v4now.com/>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
> facebook.com/v4now <http://facebook.com/v4now> ;  
> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
> <http://linkedin.com/in/skeeve>
> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
> www.theispguy.com <http://www.theispguy.com/> ; Keybase: 
> https://keybase.io/skeeve <https://keybase.io/skeeve>
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On Wed, Sep 16, 2015 at 8:07 AM, George Kuo  <mailto:geo...@apnic.net>> wrote:
> Hi Owen,
> 
> 
> On 15/09/2015 3:36 am, Owen DeLong wrote:
> 
> On Sep 14, 2015, at 01:59 , Masato Yamanishi  <mailto:myama...@gmail.com>
> <mailto:myama...@gmail.com <mailto:myama...@gmail.com>>> wrote:
> 
> Dear Colleagues,
> 
> In Jakarta, Geoff Huston presented the status of our IPv4 resources,
> in particular about exhaustion and transfer,
> and some participants asked to summarize and post it to the list for
> further discussion.
> 
> Following is Chairs' summary of the presentation and discussion.
> 
> 1. Status of APNIC Final /8 pool (103/8)
>- Will run out ~4-5 years
> 
> I think this is an appropriate time frame for runout of this pool as it
> will be at least that long before new entrants are not in need of some
> way to communicate with the legacy IPv4 internet.
> 
> 2. Status of IANA Recovered pool (non-103)
>- Will run out in next 7 months+
>- IANA may allocate additional space in every 6 months
>- This pool will repeatedly ‘run-out’ as IANA delegates more space
> and it is distributed by APNIC
>- May need policy to deal with temporary exhaustion of the non-103 pool
>  -> Close the door when exhausted or create the waiting list and
> put further applications to there?
> 
> I really don’t care what we do here. What would be the default action if
> no policy change is enacted? Can we get clarification from staff on that?
> Absent that being a particularly bad outcome (unlikely), I say let’s not
> focus on rearranging the IPv4 deck chairs any further.
> 
> 
> There is no policy which addresses this issue however APNIC staff have 
> discussed this and propose the following approach:
> 
> When requests from this pool are approved but cannot be fulfilled they will 
> be added to a waitlist.  When additional resources are added to the pool, 
> they will be allocated to wait-listed requests (in order) until the pool is 
> consumed or the waitlist is cleared.  We will continue in this way until 
> there is a policy which directs otherwise.
> 
> We believe this is fairer than rejecting requests which cannot be fulfilled, 
> and then having to deal with a flood of new requests when we announce 
> availability of additional resources (in particular because the timing of 
> that announcement will strongly influence who can take advantage of it).
> 
> Feedback and discussion on this approach would be welcome of course.
> 
> Thanks.
> 
> 
> George
> 
> 
> 3. Some address spaces in 103/8 were transferred within 12months since
> initial allocation
>- There is no policy to prohibit it while the Secretariat asks in
> review process
> 
> Closing the door after the horses have left the barn is likely
> pointless. The community specifically chose to exclude this concern from
> the transfer policy during its development (it’s not like it was not
> discussed), so I say let’s spend this energy getting IPv6 deployed
> rather than rearranging the IPv4 deck chairs any further.
> 
> Owen
> 
> 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
> http://mailman.apnic.net/mailman/listinfo/sig-policy 
> <http://mailman.apnic.net/mailman/listinfo/sig

Re: [sig-policy] The status of APNIC's IPv4 resources

[Owen DeLong]

Note, I said “at least”.

However, i don’t think string it out further is any more justified because the 
only way to do that is to deny the legitimate needs of new organizations today 
for the sake of new organizations later.

I cannot make a case for doing that.

Owen

> On Sep 15, 2015, at 03:45 , Masato Yamanishi  wrote:
> 
> Owen and All,
> 
> > I think this is an appropriate time frame for runout of this pool as it 
> > will be at least that long before new entrants are not > in need of some 
> > way to communicate with the legacy IPv4 internet.
> 
> In 2010, I was told that the transition would be end in 5 years.
> In 2000…… Where are we right now?
> I bet my 5 cents that we just started long long way.
> 
> Regards,
> Masato Yamanishi
> 
> 
> 2015-09-15 2:36 GMT+09:00 Owen DeLong  <mailto:o...@delong.com>>:
> 
>> On Sep 14, 2015, at 01:59 , Masato Yamanishi > <mailto:myama...@gmail.com>> wrote:
>> 
>> Dear Colleagues,
>> 
>> In Jakarta, Geoff Huston presented the status of our IPv4 resources, in 
>> particular about exhaustion and transfer,
>> and some participants asked to summarize and post it to the list for further 
>> discussion.
>> 
>> Following is Chairs' summary of the presentation and discussion.
>> 
>> 1. Status of APNIC Final /8 pool (103/8)
>>- Will run out ~4-5 years
> 
> I think this is an appropriate time frame for runout of this pool as it will 
> be at least that long before new entrants are not in need of some way to 
> communicate with the legacy IPv4 internet.
> 
>> 2. Status of IANA Recovered pool (non-103)
>>- Will run out in next 7 months+
>>- IANA may allocate additional space in every 6 months
>>- This pool will repeatedly ‘run-out’ as IANA delegates more space and it 
>> is distributed by APNIC
>>- May need policy to deal with temporary exhaustion of the non-103 pool
>>  -> Close the door when exhausted or create the waiting list and put 
>> further applications to there?
> 
> I really don’t care what we do here. What would be the default action if no 
> policy change is enacted? Can we get clarification from staff on that?
> Absent that being a particularly bad outcome (unlikely), I say let’s not 
> focus on rearranging the IPv4 deck chairs any further.
> 
>> 3. Some address spaces in 103/8 were transferred within 12months since 
>> initial allocation
>>- There is no policy to prohibit it while the Secretariat asks in review 
>> process
> 
> Closing the door after the horses have left the barn is likely pointless. The 
> community specifically chose to exclude this concern from the transfer policy 
> during its development (it’s not like it was not discussed), so I say let’s 
> spend this energy getting IPv6 deployed rather than rearranging the IPv4 deck 
> chairs any further.
> 
> Owen
> 
> 

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] The status of APNIC's IPv4 resources

[Owen DeLong]

> On Sep 14, 2015, at 01:59 , Masato Yamanishi  wrote:
> 
> Dear Colleagues,
> 
> In Jakarta, Geoff Huston presented the status of our IPv4 resources, in 
> particular about exhaustion and transfer,
> and some participants asked to summarize and post it to the list for further 
> discussion.
> 
> Following is Chairs' summary of the presentation and discussion.
> 
> 1. Status of APNIC Final /8 pool (103/8)
>- Will run out ~4-5 years

I think this is an appropriate time frame for runout of this pool as it will be 
at least that long before new entrants are not in need of some way to 
communicate with the legacy IPv4 internet.

> 2. Status of IANA Recovered pool (non-103)
>- Will run out in next 7 months+
>- IANA may allocate additional space in every 6 months
>- This pool will repeatedly ‘run-out’ as IANA delegates more space and it 
> is distributed by APNIC
>- May need policy to deal with temporary exhaustion of the non-103 pool
>  -> Close the door when exhausted or create the waiting list and put 
> further applications to there?

I really don’t care what we do here. What would be the default action if no 
policy change is enacted? Can we get clarification from staff on that?
Absent that being a particularly bad outcome (unlikely), I say let’s not focus 
on rearranging the IPv4 deck chairs any further.

> 3. Some address spaces in 103/8 were transferred within 12months since 
> initial allocation
>- There is no policy to prohibit it while the Secretariat asks in review 
> process

Closing the door after the horses have left the barn is likely pointless. The 
community specifically chose to exclude this concern from the transfer policy 
during its development (it’s not like it was not discussed), so I say let’s 
spend this energy getting IPv6 deployed rather than rearranging the IPv4 deck 
chairs any further.

Owen

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Final Comment Period for prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

I still oppose the policy due to lack of inclusion of the possibility of a 
non-multi-homed
need based on a unique routing policy.

Owen

> On Sep 12, 2015, at 23:33 , Jahangir Hossain  wrote:
> 
> I support this proposal by adding multi-homed to be optional but organization 
> should share their future plan of multi-homing to get ASN.
> 
>  
> 
> 
> On Sat, Sep 12, 2015 at 9:27 PM, Masato Yamanishi  > wrote:
> Dear colleagues
> 
> Version 3 of prop-114: Modification in the ASN eligibility criteria,
> reached consensus at the APNIC 40 Open Policy Meeting and later at the
> APNIC Member Meeting (AMM).
> 
> 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.
> 
> At the end of this period the Policy SIG Chairs will evaluate comments
> made and determine if the consensus reached at APNIC 40 still holds. The
> Chairs may extend the Comment Period to a maximum of eight (8) weeks to
> allow further discussion.
> 
> If consensus holds, the Chair of the Policy SIG will ask the Executive
> Council to endorse the proposal for implementation.
> 
>- Send all comments and questions to: 
>- Deadline for comments:  23:59 (UTC +10) Sunday, 11 October 2015
> 
> 
> 
> Proposal details
> 
> 
> This is a proposal changes the criteria for AS number requests from
> end-user organizations considering multihoming.
> 
> Proposal details, including the full text of the proposal, history, and
> links to the APNIC 40 meeting archive, are available at:
> 
>  http://www.apnic.net/policy/proposals/prop-114 
> 
> 
> Regards
> 
> Masato and Sumon
> 
> ---
> 
> prop-114-v003: Modification in the ASN eligibility criteria
> 
> ---
> 
> Proposer:  Aftab Siddiqui
>aftab.siddi...@gmail.com 
> 
>Skeeve Stevens
>ske...@eintellegonetworks.com 
> 
> 
> 
> 1. Problem statement
> 
> 
>The current ASN assignment policy states two eligibility criteria and
>that both criteria should be fulfilled in order to obtain an ASN. The
>policy seems to imply that both requirements i.e. multi-homing and
>clearly defined single routing policy must be met simultaneously,
>this has created much confusion in interpreting the policy.
> 
>As a result organizations have either provided incorrect information
>to get the ASN or barred themselves from applying where they still
>have a valid justification for obtaining an ASN.
> 
> 
> 2. Objective of policy change
> -
> 
>In order to make the policy guidelines simpler we are proposing to
>modify the text describing the eligibility criteria for ASN
>assignment by providing alternate criteria to obtaining an ASN.
> 
> 
> 3. Situation in other regions
> -
> 
> ARIN:
> It is not mandatory but optional to be multi-homed in order get ASN
> 
> RIPE:
> Policy to remove multi-homing requirement is currently in discussion
> and the current phase ends 12 February 2015 (awaiting Chair decision)
> Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 
> 
> 
> LACNIC:
> Only inter-connect is mandatory not multi-homing
> 
> AFRINIC:
> It is mandatory to be multi-homed in order to get ASN.
> 
> 
> 4. Proposed policy solution
> ---
> 
> An organisation is eligible for an ASN assignment if:
> 
> - they are currently multi-homed, OR
> 
> - have previous allocated provider independent address space by
>   APNIC, AND intend to multi-home in the future
> 
> 
> 5. Advantages / Disadvantages
> -
> 
> Advantages:
> 
> By adding the additional criteria of Guidelines managed by APNIC
> Secretariat, this would enable the Secretariat to make decisions
> based on common or rare use cases, but that may still be a valid
> request.
> 
> Disadvantages:
> 
> It may be perceived that this policy would enable members to obtain
> ASN’s more easily, and in return cause faster consumption of ASN’s
> in the region.  Given the relative ease of obtaining an ASN with
> ‘work around’ methods, we do not perceive this will actually have
> any effect.
> 
> 
> 6. Impact on resource holders
> -
> 
> No impact on existing resource holders.
> 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net 
> http://mailman.apnic.

Re: [sig-policy] Prop-115 returned to author for further consideration

[Owen DeLong]

I do not support the proposal.

Contorting policy around the abomination that is CGN instead of recognizing 
that no amount of policy or other contortion will preserve usability in IPv4 
and just getting on with the business of making IPv6 deployment ubiquitous is 
counterproductive for the internet as a whole and for each and every individual 
subjected to these ridiculous and dysfunctional hacks.

NAT was bad enough. NAT on top of NAT and so-called “Carrier Grade” NAT and all 
of these other stupid net tricks are in desperate need of deprecation.

Owen

> On Sep 13, 2015, at 01:59 , Jahangir Hossain  wrote:
> 
> Hi ,
> 
> Actually i'm also thinking why this is important ? or why we are trying to 
> mapping port with addressing specially in IPv4? I think their are so many 
> reasons not support this proposal specially by considering technical 
> feasibility and scalability . 
> 
> Just one question for my personal understanding to author like; How to define 
> the best route within ISP routing table if HomeA and Home B announce same 
> prefix ?  
> 
> 192.0.2.24/32  1-256 is for HomeA
>  192.0.2.24/32  257-511 is for HomeB
> 
> 
> On Sun, Sep 13, 2015 at 1:28 PM, Andrew Yager  > wrote:
> I do not support this proposal, and consider that such data is largely 
> irrelevant, likely to be prone to inaccuracies and technically infeasible to 
> manage on an ongoing basis or practically implement the filtering described 
> in the proposal.
> 
> If individual providers which to disclose such information in the remarks 
> field in their data then I see no issue with them continuing to do so.
> 
> Andrew
> 
> On 13 September 2015 at 01:15, Masato Yamanishi  > wrote:
> Dear colleagues
> 
> Version 3 of prop-115: Registration of detailed assignment information
> in whois DB, did not reach consensus at the APNIC 40 Open
> Policy Meeting.
> 
> The Policy SIG Chair requested the Secretariat conduct further research
> into the problem statement and returned the proposal to the authors for
> further consideration.
> 
> Proposal details
> 
> 
> This proposal seeks to require LIRs to register accurate filtering
> information, such as IPv4 port-range information and IPv6 assignment
> prefix size.
> 
> Proposal details, including the full text of the proposal, history, and
> links to the APNIC 40 meeting archive, are available at:
> 
>  http://www.apnic.net/policy/proposals/prop-115 
> 
> 
> Regards
> 
> Masato and Sumon
> 
> 
> 
> 
> prop-115-v003: Registration of detailed assignment information in
>whois DB
> 
> 
> Proposer:   Ruri Hiromi
> hir...@inetcore.com 
> 
> Tomohiro Fujisaki
> fujis...@syce.net 
> 
> 
> 1. Problem statement
> 
> 
> Recently, there are some cases need to get IP address assignment
> information in more detail to specify user IP address.
> 
> Without this information, operators cannot filter out specific
> address range, and it might lead to 'over-filter' (i.e. filtering
> whole ISP's address range).
> 
> For example:
> 
> 1) 'Port' range information in IPv4
> 
>ISPs are using 'CGN' or other kinds of IPv4 address sharing
>technology with assignment of IP address and specified port
>range to their users.
> 
>In this case, port information is necessary to specify one user.
> 
>ex) 192.0.2.24/32  1-256 is for HomeA
>192.0.2.24/32  257-511 is for HomeB
> 
>or 192.0.2.0/24  1-65536 is shared address of 
> ISP-X
>minimum size is /32
> 
> 2) address assignment size information in IPv6
> 
>The IPv6 address assignment size may be different from ISP and
>its service estimation. Address assignment prefix size will be
>necessary.
> 
>ex) 2001:db8:1::0/56 is for HomeA
>2001:db8:1:1::0/48 is for HomeB
> 
>or 2001:db8:1::/36's minimum size is /56
> 
> 
> 2. Objective of policy change
> -
> 
> Lots of operators look a record when harmful behavior coming to
> their network to identify its IP address confirming it can be
> filtered or not.
> 
> The goal is providing more specific information to support these
> actions.
> 
> 
> 3. Situation in other regions
> -
> 
> No same regulation/discussion can be seen in other regions.
> 
> 
> 4. Proposed policy solution
> ---
> 
> Provide accurate filtering information generated from whois DB.
> 
> For IPv4, propose t

Re: [sig-policy] prop-114: Modification in the ASN eligibility criteria to be discussed at APNIC 40

[Owen DeLong]

> On Aug 7, 2015, at 02:34 , Masato Yamanishi  wrote:
> 
> Dear SIG members
> 
> ## It is NOT new version, just a reminder that this proposal will be 
> discussed at APNIC 40 
> 
> Version 3 of this proposal was posted to the mailing list during
> APNIC 39. The proposal did not reach consensus and discussion will
> continue at APNIC 40.
> 
> 
> Information about earlier versions is available from:
> 
> https://www.apnic.net/policy/proposals/prop-114 
> 
> 
> 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,
> 
> Masato
> 
> 
> 
> ---
> 
> prop-114-v003: Modification in the ASN eligibility criteria
> 
> ---
> 
> Proposer:  Aftab Siddiqui
>aftab.siddi...@gmail.com 
> 
>Skeeve Stevens
>ske...@eintellegonetworks.com 
> 
> 
> 
> 1. Problem statement
> 
> 
>The current ASN assignment policy states two eligibility criteria and
>that both criteria should be fulfilled in order to obtain an ASN. The
>policy seems to imply that both requirements i.e. multi-homing and
>clearly defined single routing policy must be met simultaneously,
>this has created much confusion in interpreting the policy.
> 
>As a result organizations have either provided incorrect information
>to get the ASN or barred themselves from applying where they still
>have a valid justification for obtaining an ASN.
> 
> 
> 2. Objective of policy change
> -
> 
>In order to make the policy guidelines simpler we are proposing to
>modify the text describing the eligibility criteria for ASN
>assignment by providing alternate criteria to obtaining an ASN.
> 
> 
> 3. Situation in other regions
> -
> 
> ARIN:
> It is not mandatory but optional to be multi-homed in order get ASN

This is misleading.

In ARIN you must meet one of the two criteria:
Multihome
Unique Routing Policy

So it is optional to be multi-homed _IF_ you have a unique routing policy.

> 
> RIPE:
> Policy to remove multi-homing requirement is currently in discussion
> and the current phase ends 12 February 2015 (awaiting Chair decision)
> Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 
> 
> 
> LACNIC:
> Only inter-connect is mandatory not multi-homing
> 
> AFRINIC:
> It is mandatory to be multi-homed in order to get ASN.
> 
> 
> 4. Proposed policy solution
> ---
> 
> An organisation is eligible for an ASN assignment if:
> 
> - they are currently multi-homed, OR
> 
> - have previous allocated provider independent address space by
>   APNIC, AND intend to multi-home in the future
> 

I support this as written, though I would recommend adding:

…, OR
- have a unique routing policy

Examples where Unique Routing Policy may be necessary include things like
transit marketplaces where you may select only a single provider for transit 
and may
not peer with more than one provider at any given time, but you still have a 
unique
routing policy and are (potentially) changing providers more frequently than 
could
be rationally facilitated without BGP and an ASN.

> 
> 5. Advantages / Disadvantages
> -
> 
> Advantages:
> 
> By adding the additional criteria of Guidelines managed by APNIC
> Secretariat, this would enable the Secretariat to make decisions
> based on common or rare use cases, but that may still be a valid
> request.
> 
> Disadvantages:
> 
> It may be perceived that this policy would enable members to obtain
> ASN¹s more easily, and in return cause faster consumption of ASN¹s
> in the region.  Given the relative ease of obtaining an ASN with
> Œwork around¹ methods, we do not perceive this will actually have
> any effect.
> 
> 
> 6. Impact on resource holders
> -
> 
> No impact on existing resource holders.
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Idea for 1.2.3.0/24

[Owen DeLong]

> On May 22, 2015, at 20:42 , Michel Py  
> wrote:
> 
>> David Conrad wrote :
>> In my (early) experience at APNIC, there was significant interest in 
>> "vanity" IP addresses,
>> to the point where folks created multiple companies in order to get 
>> particular addresses
>> when APNIC was allocating address blocks in a predictable sequential fashion.
> 
> +1
> 
> It has not changed much either : FACE:B00C  :P
> Come on guys, back in the Novell days we were already in that game claiming 
> FEED BABE BEEF and F00D and CAFE on IPX networks.
> 
> Michel.
> 
> 


I’ll point out that face:b00c is _NOT_ a vanity address. The full address in 
question is: 2a03:2880:2130:cf05:face:b00c::1 which is
a perfectly normal prefix assignment from RIPE-NCC regisetered as 
2a03:2880::/32 to Facebook Irleand.

Facebook could have created that same /64 within any /32 they were issued 
anywhere, so it’s not a great example.

As to David’s argument… It doesn’t counter mine. I said I can only think of a 
few reasons. David brought up one of the few I could think of.

I don’t doubt that there are several companies that might have those same 
reasons for wanting to do so, but there are a pretty limited number of reasons.

I don’t know whether or not Google payed anything extra to Level 3 to get that 
particular /24 (8.8.8.0/24) or it’s companion 8.8.4.0/24 or not. If they did, 
I’m betting it wasn’t a whole lot.

Do you have any examples of a beneficial purpose for which a company would be 
likely to outbid the nefarious purposes for such an address in an open auction? 
I’m betting running a free public nameserver isn’t going to cut it.

Owen

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Idea for 1.2.3.0/24

[Owen DeLong]

I can only think of a few reasons a company would want to spend any amount of 
money for a vanity IP address.

I can think of fewer reasons that such a company would do so for one with such 
a large background radiation problem.

Of those, the ones that would carry the most monetary benefit to the company in 
question are also the ones which are most likely to be considered abusive by at 
least some members of the internet community, myself included.

For example, harvesting the background radiation for information that can be 
used for business or nefarious purposes (where nefarious is likely more 
profitable and even business is likely still abusive).

Since an auction is, by definition, won by the highest bidder, it stands to 
reason that the logical conclusion of David’s proposal would be to hand this 
block over to the company with the strongest economic motivation for using it.

Owen

> On May 22, 2015, at 10:21 , Paul Wilson  wrote:
> 
> 
> 
> On 23 May 2015, at 2:13 am, Owen DeLong  wrote:
> 
>> Paul,
>> 
>> I find it interesting amid calls for “don’t rearrange the deck chairs” that 
>> you single out my message as the one attempting to shut the conversation 
>> down.
>> 
>> I’m perfectly willing to tolerate whatever discussions people want to have.
> 
> My apologies Owen, I didn’t mean to single you out.  I was merely responding 
> within what I thought was a thread of conversation (but sticking to the 
> original subject: line).
> 
> Thanks for your reply.  I’m interested to understand what you feel would be 
> the “harm” done by David’s proposal.
> 
> Paul.
> 
> 
>> 
>> As for the value of a memorable address such as 1.2.3.4 or 1.2.3.*/24, meh. 
>> there is no history of address policy based on memorable or attractive 
>> choices of numbers throughout the useful life of IPv4. As such, it’s hard 
>> for me to get behind any such policy now that IPv4 is (hopefully) into its 
>> winding down towards deprecation days.
>> 
>> We can discuss it as much as people want to discuss it. I would never 
>> presume to attempt to shut down discussion. However, In terms of the best 
>> policy overall, I still believe my original statement stands. It’s just a 
>> /24. It has lots of noise on it which might be useful for some research 
>> purposes. Most of the exploitations I can think of for it by a company that 
>> would bid for it at auction are, frankly, not very good for most of the 
>> users of the internet.
>> 
>> So… I oppose auctioning it off as I think this would do more harm than good.
>> I think its value as a prefix for valid use is very limited due to its 
>> background noise level.
>> 
>> As such, I stand by my original statement… Use it for whatever research 
>> value it has, then put it out to pasture with the rest of this antiquated 
>> 32-bit address space.
>> 
>> Owen
>> 
>>> On May 22, 2015, at 08:34 , Paul Wilson  wrote:
>>> 
>>> My understanding is that this is not about “just a single /24” but about 
>>> this particular /24, which is a memorable address and may be useful for 
>>> that reason.
>>> 
>>> If it is useful (for some undetermined purpose) then its use may extend 
>>> through the entire remaining life of IPv4 on the Internet, not just the 
>>> “life” of remaining IPv4 address pools.
>>> 
>>> As a general comment, I would observe that while IPv4 exists on the 
>>> Internet, and certainly while it is still a sort of essential part of the 
>>> infrastructure (to say the least), we might tolerate discussions about IPv4 
>>> address space, rather than trying to shut them down.
>>> 
>>> Paul
>>> 
>>> 
>>> 
>>> Paul Wilson, Director-General, APNICd...@apnic.net
>>> http://www.apnic.net@apnicdg
>>> 
>>> 
>>> 
>>> On 22 May 2015, at 8:48 am, Owen DeLong  wrote:
>>> 
>>>> We’re talking about a single /24.
>>>> 
>>>> Use it for whatever research value it has and then put it out to pasture 
>>>> along with the rest of this antiquated addressing.
>>>> 
>>>> My $0.02.
>>>> 
>>>> Owen
>>>> 
>>>>> On May 21, 2015, at 12:45 , David Huberman  
>>>>> wrote:
>>>>> 
>>>>> Dean,
>>>>> 
>>>>> Thank you for your excellent reply.
>>>>> 
>>>>> I am all for working to

Re: [sig-policy] Idea for 1.2.3.0/24

[Owen DeLong]

Paul,

I find it interesting amid calls for “don’t rearrange the deck chairs” that you 
single out my message as the one attempting to shut the conversation down.

I’m perfectly willing to tolerate whatever discussions people want to have.

As for the value of a memorable address such as 1.2.3.4 or 1.2.3.*/24, meh. 
there is no history of address policy based on memorable or attractive choices 
of numbers throughout the useful life of IPv4. As such, it’s hard for me to get 
behind any such policy now that IPv4 is (hopefully) into its winding down 
towards deprecation days.

We can discuss it as much as people want to discuss it. I would never presume 
to attempt to shut down discussion. However, In terms of the best policy 
overall, I still believe my original statement stands. It’s just a /24. It has 
lots of noise on it which might be useful for some research purposes. Most of 
the exploitations I can think of for it by a company that would bid for it at 
auction are, frankly, not very good for most of the users of the internet.

So… I oppose auctioning it off as I think this would do more harm than good.
I think its value as a prefix for valid use is very limited due to its 
background noise level.

As such, I stand by my original statement… Use it for whatever research value 
it has, then put it out to pasture with the rest of this antiquated 32-bit 
address space.

Owen

> On May 22, 2015, at 08:34 , Paul Wilson  wrote:
> 
> My understanding is that this is not about “just a single /24” but about this 
> particular /24, which is a memorable address and may be useful for that 
> reason.
> 
> If it is useful (for some undetermined purpose) then its use may extend 
> through the entire remaining life of IPv4 on the Internet, not just the 
> “life” of remaining IPv4 address pools.
> 
> As a general comment, I would observe that while IPv4 exists on the Internet, 
> and certainly while it is still a sort of essential part of the 
> infrastructure (to say the least), we might tolerate discussions about IPv4 
> address space, rather than trying to shut them down.
> 
> Paul
> 
> 
> 
> Paul Wilson, Director-General, APNICd...@apnic.net
> http://www.apnic.net    @apnicdg
> 
> 
> 
> On 22 May 2015, at 8:48 am, Owen DeLong  wrote:
> 
>> We’re talking about a single /24.
>> 
>> Use it for whatever research value it has and then put it out to pasture 
>> along with the rest of this antiquated addressing.
>> 
>> My $0.02.
>> 
>> Owen
>> 
>>> On May 21, 2015, at 12:45 , David Huberman  
>>> wrote:
>>> 
>>> Dean,
>>> 
>>> Thank you for your excellent reply.
>>> 
>>> I am all for working together to identify a way to get 1.2.3.0/24 into the 
>>> hands of a network operator who can do good things with it.  The prefix is 
>>> trapped in APNIC right now with nowhere to go, and it’s time to set it free.
>>> 
>>> More ideas everyone!  We can have a great discussion about it, here and in 
>>> Jakarta.
>>> 
>>> /david
>>> 
>>> 
>>> 
>>> From: sig-policy-boun...@lists.apnic.net 
>>> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
>>> Sent: Thursday, May 21, 2015 12:41 PM
>>> To: sig-policy@lists.apnic.net
>>> Subject: [sig-policy] Fwd: Idea for 1.2.3.0/24
>>> 
>>> Oops wrong button :)
>>> 
>>> -- Forwarded message --
>>> From: Dean Pemberton 
>>> Date: Friday, 22 May 2015
>>> Subject: [sig-policy] Idea for 1.2.3.0/24
>>> To: David Huberman 
>>> 
>>> 
>>> Hi David, Everyone
>>> 
>>> If APNIC were to just sell this off then there is no saying that it won't 
>>> just appear in some large providers NAT pool. 
>>> 
>>> I've just visited some providers who wanted address space so much they 
>>> would probably bid for this just to have 1.2.3.4 as a flag to wave and the 
>>> rest of the /24 just sits in their CGN. That would be terrible for anyone 
>>> whose sessions were associated with these addresses. 
>>> 
>>> I won't elaborate here but there are even potential security issues related 
>>> with a malicious actor being able to redirect this about of traffic. 
>>> 
>>> Any of these would be a net loss to the Internet community.  
>>> 
>>> So how can we turn this into a net win?
>>> 
>>> I'm not that concerned about the money. Good things can be done with 

Re: [sig-policy] Idea for 1.2.3.0/24

[Owen DeLong]

We’re talking about a single /24.

Use it for whatever research value it has and then put it out to pasture along 
with the rest of this antiquated addressing.

My $0.02.

Owen

> On May 21, 2015, at 12:45 , David Huberman  
> wrote:
> 
> Dean, <>
>  
> Thank you for your excellent reply.
>  
> I am all for working together to identify a way to get 1.2.3.0/24 into the 
> hands of a network operator who can do good things with it.  The prefix is 
> trapped in APNIC right now with nowhere to go, and it’s time to set it free.
>  
> More ideas everyone!  We can have a great discussion about it, here and in 
> Jakarta.
>  
> /david
>  
>  
>  
> From: sig-policy-boun...@lists.apnic.net 
> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
> Sent: Thursday, May 21, 2015 12:41 PM
> To: sig-policy@lists.apnic.net
> Subject: [sig-policy] Fwd: Idea for 1.2.3.0/24
>  
> Oops wrong button :)
> 
> -- Forwarded message --
> From: Dean Pemberton mailto:d...@internetnz.net.nz>>
> Date: Friday, 22 May 2015
> Subject: [sig-policy] Idea for 1.2.3.0/24 
> To: David Huberman  >
> 
> 
> Hi David, Everyone
>  
> If APNIC were to just sell this off then there is no saying that it won't 
> just appear in some large providers NAT pool. 
>  
> I've just visited some providers who wanted address space so much they would 
> probably bid for this just to have 1.2.3.4 as a flag to wave and the rest of 
> the /24 just sits in their CGN. That would be terrible for anyone whose 
> sessions were associated with these addresses. 
>  
> I won't elaborate here but there are even potential security issues related 
> with a malicious actor being able to redirect this about of traffic. 
>  
> Any of these would be a net loss to the Internet community.  
>  
> So how can we turn this into a net win?
>  
> I'm not that concerned about the money. Good things can be done with auction 
> proceeds, but good ideas can come from people without money too. 
>  
> For example what if an individual has a great idea to use 1.2.3.4 for the 
> common good but would never have an ability to win an auction?  They might 
> also have no ability to purchase infrastructure to make the idea happen. 
>  
> Nat Morris for eg runs a great any cast DNS service helping lots of people 
> but I'm pretty sure his wife and dog would notice him going up against large 
> corps in an auction. 
>  
> What about this. 
>  
> We take suggestions for the best 'public good' use of 1.2.3.4. 
> For each of the ideas, let the community show support "a thumbs up/down" if 
> you will. Also for each of them allow organisations to pitch to deliver it. 
>  
> Market it as recycling trash even :)
>  
> This way the good idea can come from anyone in any part of the world as long 
> as it benefits all internet users. And large corporations can still get some 
> exposure by offering to make it happen. 
>  
> Imagine the photoshoot. Smart up-and-coming engineer from an LDC alongside a 
> large multinational helping APNIC to make a difference to us all. 
>  
> Thoughts?
>  
> 
> 
> On Friday, 22 May 2015, David Huberman > 
> wrote:
> Hello Policy SIG,
>  
> I have an idea for 1.2.3.0/24  I would like to share with 
> you before submitting a policy proposal.
>  
> Prop-109 properly directed APNIC to use 1.0.0.0/24  and 
> 1.1.1.0/24  for research purposes.  That leaves one more 
> significant prefix to deal with:1.2.3.0/24 .  It is 
> significant because it contains the IP address 1.2.3.4.
>  
> 1.2.3.4 is a desirable IP address.  It can be used in all sorts of very 
> interesting applications.  It also receives an enormous amount of “junk” 
> traffic every day, so it requires a fairly hefty infrastructure just to start 
> routing it.  
> 
> My idea is that APNIC should make this prefix available to all parties who 
> want it. To decide who gets it, I propose an AUCTION where all proceeds go to 
> a charitable endeavor (perhaps a future APNIC Foundation).   As the potential 
> author of such a proposal, and as the IP address manager at Microsoft 
> Corporation, I will guarantee that neither I nor my company will participate 
> in any way in such an auction.  This proposal is not to benefit me or my 
> company.  It is to give the prefix out to a network operator who wants it, in 
> return for money given to charity.
>  
> This is a new idea, and is not fully thought out.  So I wanted to post it, 
> get some reactions, and improve the idea.  (Or abandon it if people do not 
> like it.)
>  
> Thank you.
>  
> David
>  
> David R Huberman
> Principal, Global IP Addressing
> Microsoft Corporation
>  
> 
> 
> -- 
> --
> Dean Pemberton
> 
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz <>
> 
> To promote the Internet's benefits and uses, and protect its potential.
> 
> 
> 
> -- 
> --
> Dean Pemberton

Re: [sig-policy] Updated Text - Prop-114v003

[Owen DeLong]

I think this is an improvement, but I can support either way.

Owen

> On Mar 4, 2015, at 21:54 , Sanjeev Gupta  wrote:
> 
> 
> On Thu, Mar 5, 2015 at 12:50 PM, Skeeve Stevens  > wrote:
> 4. Proposed policy solution
> ---
> 
> An organisation is eligible for an ASN assignment if:
> 
>  - they are currently multi-homed OR 
> 
>  - you have been previous allocated provider independent address space by 
> APNIC AND
> 
>  - intend to multi-home in the future
> 
> May I suggest a change?
> 
> 
> An organisation is eligible for an ASN assignment if:
> 
>  - they are currently multi-homed OR 
> 
>  - you are currently allocated provider independent address space by 
> APNIC AND intend to multi-home in the future
> 
> The first change is to remove those who are moving to NIRs, or other RIRs.  
> They should apply for resources from their current Registery.
> 
> The second change is to clarify that the "AND" in #3 applies to #2, not #1 OR 
> #2.
> 
> -- 
> Sanjeev Gupta
> +65 98551208   http://sg.linkedin.com/in/ghane 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Updated Text - Prop-114v003

[Owen DeLong]

That’s text I can support.

Owen

> On Mar 4, 2015, at 21:27 , Gaurab Raj Upadhaya  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I support this.
> 
> - -gaurab
> 
> 
> On 3/5/15 4:50 AM, Skeeve Stevens wrote:
>> In this text, the suggested guidelines have been removed to be
>> replaced with:
>> 
>> " - you have been previous allocated provider independent address 
>> space by APNIC AND
>> 
>> 
>> - intend to multi-home in the future
>> 
>> "
>> 
>> 
>> This policy can be reviewed on an annual basis for any impact on
>> the number of allocations of ASN and if there has been any
>> detrimental effect.
>> 
>> 
>> ==
>> 
>> ---
>> 
>> prop-114-v003: Modification in the ASN eligibility criteria
>> 
>> ---
>> 
>> 
>> Proposer:  Aftab Siddiqui
>> 
>> aftab.siddi...@gmail.com  
>> >
>> 
>> 
>> Skeeve Stevens
>> 
>> ske...@eintellegonetworks.com  
>> >
>> 
>> 
>> 
>> 1. Problem statement
>> 
>> 
>> 
>> 
>> The current ASN assignment policy states two eligibility criteria
>> and that both criteria should be fulfilled in order to obtain an
>> ASN. The policy seems to imply that both requirements i.e.
>> multi-homing and clearly defined single routing policy must be met
>> simultaneously, this has created much confusion in interpreting the
>> policy.
>> 
>> 
>> As a result organizations have either provided incorrect
>> information to get the ASN or barred themselves from applying where
>> they still have a valid justification for obtaining an ASN.
>> 
>> 
>> 
>> 2. Objective of policy change
>> 
>> -
>> 
>> 
>> In order to make the policy guidelines simpler we are proposing to 
>> modify the text describing the eligibility criteria for ASN
>> assignment by providing alternate criteria to obtaining an ASN.
>> 
>> 
>> 
>> 3. Situation in other regions
>> 
>> -
>> 
>> 
>> ARIN:
>> 
>> It is not mandatory but optional to be multi-homed in order get
>> ASN
>> 
>> 
>> RIPE:
>> 
>> Policy to remove multi-homing requirement is currently in
>> discussion and the current phase ends 12 February 2015 (awaiting
>> Chair decision)
>> 
>> Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 
>> 
>> 
>> 
>> LACNIC:
>> 
>> Only inter-connect is mandatory not multi-homing
>> 
>> 
>> AFRINIC:
>> 
>> It is mandatory to be multi-homed in order to get ASN.
>> 
>> 
>> 
>> 4. Proposed policy solution
>> 
>> ---
>> 
>> 
>> An organisation is eligible for an ASN assignment if:
>> 
>> 
>> - they are currently multi-homed OR
>> 
>> 
>> - you have been previous allocated provider independent address 
>> space by APNIC AND
>> 
>> 
>> - intend to multi-home in the future
>> 
>> 
>> 
>> 
>> 5. Advantages / Disadvantages
>> 
>> -
>> 
>> 
>> Advantages:
>> 
>> 
>> By adding the additional criteria of Guidelines managed by APNIC 
>> Secretariat, this would enable the Secretariat to make decisions
>> based on common or rare use cases, but that may still be a valid
>> request.
>> 
>> 
>> Disadvantages:
>> 
>> 
>> It may be perceived that this policy would enable members to
>> obtain ASN’s more easily, and in return cause faster consumption of
>> ASN’s in the region.  Given the relative ease of obtaining an ASN
>> with ‘work around’ methods, we do not perceive this will actually
>> have any effect.
>> 
>> 
>> 
>> 6. Impact on resource holders
>> 
>> -
>> 
>> 
>> No impact on existing resource holders.
>> 
>> 
>> 
>> 7. References
>> 
>> -
>> 
>> 
>> 
>> ==
>> 
>> ...Skeeve
>> 
>> *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego
>> Networks service ske...@v4now.com  
>> > ;
>> www.v4now.com  > >
>> 
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve 
>> 
>> 
>> facebook.com/v4now  > > ;
>> > >linkedin.com/in/skeeve 
>>  
>> >
>> 
>> twitter.com/theispguy  
>> > ; blog:
>> www.theispguy.com  > >
>> 
>> 
>> IP Address Brokering - Introducing sellers and buyers
>> 
>> 
>> *  sig-policy:  APNIC

Re: [sig-policy] Updated Text - Prop-113v003

[Owen DeLong]

I support this as written.

Owen

> On Mar 4, 2015, at 20:50 , Skeeve Stevens  wrote:
> 
> The only addition to this text was the clarification of demonstrated need.  
> It is not being removed and will remain in place as below.
> 
> "Organizations requesting a delegation under these terms must demonstrate 
> that they are able to use 25% of the requested addresses immediately and 50% 
> within one year."
> 
> =
> 
> prop-113-v003: Modification in the IPv4 eligibility criteria
> 
> 
> Proposer:  Aftab Siddiqui
>aftab.siddi...@gmail.com 
>Skeeve Stevens
>ske...@eintellegonetworks.com 
> 
> 
> 1. Problem statement
> 
> 
> The current APNIC IPv4 delegation policy defines multiple eligibility 
> criteria and applicants must meet one criteria to be eligible to receive IPv4 
> resources. One of the criteria dictates that “an organization is eligible if 
> it is currently multi-homed with provider-based addresses, or demonstrates a 
> plan to multi-home within one month” (section 3.3).
> 
> The policy seems to imply that multi-homing is mandatory even if there is no 
> use case for the applicant to be multi-homed or even when there is only one 
> upstream provider available, this has created much confusion in interpreting 
> this policy.
> 
> As a result organizations have either tempted to provide incorrect or 
> fabricated multi-homing information to get the IPv4 resources or barred 
> themselves from applying.
> 
> 
> 2. Objective of policy change
> -
> 
> In order to make the policy guidelines simpler we are proposing to modify the 
> text of section 3.3.
> 
> 
> 3. Situation in other regions
> -
> 
> ARIN:
> There is no multi-homing requirement
> 
> RIPE:
> There is no multi-homing requirement.
> 
> LACNIC:
> Applicant can either have multi-homing requirement or interconnect.
> 
> AFRINIC:
> There is no multi-homing requirement.
> 
> 
> 4. Proposed policy solution
> ---
> 
> 
> 
> Section 3.3: Criteria for small delegations
> 
> An organization is eligible if:
> 
> it is currently multi-homed OR
> 
> currently utilising provider (ISP) assignment of at least a /24, AND intends 
> to be multi-homed OR
> 
> intends to be multi-homed
> 
> AND
> 
> advertise the prefixes within 6 months
> 
> Organizations requesting a delegation under these terms must demonstrate that 
> they are able to use 25% of the requested addresses immediately and 50% 
> within one year.
> 
> 5. Advantages / Disadvantages
> -
> 
> Advantages:
> 
> Simplifies the process of applying for IPv4 address space for small 
> delegations and delays the immediate requirement for multi-homing as 
> determined to be appropriate within the timeframe as detailed in Section 3.3.
> 
> 
> Disadvantages:
> 
> There is no known disadvantage of this proposal.
> 
> 
> 6. Impact on resource holders
> -
> 
> No impact on existing resource holders.
> 
> 
> 7. References
> -
> 
> 
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com  ; www.v4now.com 
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
> facebook.com/v4now  ;  
> linkedin.com/in/skeeve 
> 
> twitter.com/theispguy  ; blog: 
> www.theispguy.com 
> 
> IP Address Brokering - Introducing sellers and buyers
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Mar 4, 2015, at 18:31 , Gaurab Raj Upadhaya  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 3/5/15 2:13 AM, Skeeve Stevens wrote:
> 
>> So, if I wanted to put a connection online in Singapore, and only 
>> connected to one upstream, but also connect to Megaport, or
>> Pacnets PEN - or to Megaports MLPA IX - which is state based - or
>> other fabric, then I could need an ASN, and the routing policy
>> would be unique to that location.  Rinse and repeat for other
>> locations.
>> 
> what prevents you from using the same ASN ?

Exactly.

At the point where you bring up the second site, just peer it with the previous 
site and it is multihomed. There’s no reason not to run a GRE or other tunnel 
between the sites and peer them.

Owen

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

I don’t see any rational use case for a second or third ASN where it wouldn’t 
be peering with at least 2 ASNs.

If you can present one, then I could be convinced to reconsider.

Owen

> On Mar 4, 2015, at 16:46 , Skeeve Stevens  wrote:
> 
> Owen,
> 
> That is almost, but not quite ok.
> 
> There may be cases where you have the same reason to do this for a second or 
> third ASN.
> 
> Say I need one for an isolated network in HK, or NZ, or KH with a completely 
> separate routing policy?
> 
> The same criteria should apply for the first and 10th?
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
> <http://www.v4now.com/>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
> facebook.com/v4now <http://facebook.com/v4now> ;  
> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
> <http://linkedin.com/in/skeeve>
> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
> www.theispguy.com <http://www.theispguy.com/>
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On Thu, Mar 5, 2015 at 9:30 AM, Owen DeLong  <mailto:o...@delong.com>> wrote:
> I don’t feel the need for every use case to be set in stone, but I do think 
> that there are better ways to address this.
> 
> Is there any reason that adding the following to the existing policy would be 
> unacceptable to you?
> 
> …
> or an organization which has received an assignment or allocation from APNIC 
> and has not previously obtained an ASN may obtain one ASN upon request for 
> purposes of setting up peering for their network with one or more other other 
> autonomous systems.
> 
> 
> Why would that not suffice?
> 
> Owen
> 
>> On Mar 4, 2015, at 15:47 , Skeeve Stevens > <mailto:ske...@v4now.com>> wrote:
>> 
>> Owen,
>> 
>> It just feels like nitpicking and moving chairs around.  I actually trust 
>> the Secretariat to do the right thing when allocating resources.  We're also 
>> talking about a resource where there are over 4.1 billion ASN's still 
>> available... not that it should be a justification to wastage, but it is 
>> useful for context.  
>> 
>> The APNIC stats are:
>> 
>>  How many ASN - % of Membership
>> no ASN
>> 34.06%
>> 1
>> 56.59%
>> 2
>> 5.55%
>> 3
>> 1.78%
>> 4
>> 0.77%
>> 5
>> 0.35%
>> 6
>> 0.28%
>> 7
>> 0.15%
>> 8
>> 0.04%
>> 10
>> 0.13%
>> more than 10
>> 0.31%
>>  
>> I'm unsure why you guys want to see each and every use-case set in stone.  I 
>> don't want to have to come back and do amendments picking on a word here or 
>> there because there has been an innovation in the way networks are operated.
>> 
>> 
>> I fully support the idea that this isn't a free-for-all.. but we need some 
>> flexibility in the community.
>> 
>> 
>> ...Skeeve
>> 
>> Skeeve Stevens - Senior IP Broker
>> v4Now - an eintellego Networks service
>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
>> <http://www.v4now.com/>
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
>> facebook.com/v4now <http://facebook.com/v4now> ;  
>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
>> <http://linkedin.com/in/skeeve>
>> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
>> www.theispguy.com <http://www.theispguy.com/>
>> 
>> IP Address Brokering - Introducing sellers and buyers
>> 
>> On Thu, Mar 5, 2015 at 8:33 AM, Owen DeLong > <mailto:o...@delong.com>> wrote:
>> If said standard pre-existing procedure were subject to the PDP, I’d be fine 
>> with that.
>> 
>> However, that’s not what the wording implies. In the case of the IPv6 
>> policy, I think this is less than desirable, but it’s not on the table in 
>> this discussion.
>> 
>> Certainly if someone proposed removing that wording from the IPv6 policy, I 
>> would support such a proposal.
>> 
>> Owen
>> 
>>> On Mar 4, 2015, at 14:58 , Skeeve Stevens >> <mailto:ske...@v4now.com>> wrote:
>>> 
>>> Do we just move the 'proposed draft guidelines' to cases under 3.3?
>>> 
>>> We were trying to be flexible for future use cases without going through 
>>> this painful process for every future valid use case tha

Re: [sig-policy] New version of prop-113: Modification in the IPv4 eligibility criteria

[Owen DeLong]

Simply advertising a network doesn’t mean you need the addresses or that you’re 
actually using them in an operational network.

It just means you typed in a BGP anchor statement.

Owen

> On Mar 4, 2015, at 16:44 , Skeeve Stevens  wrote:
> 
> How do you see needs basis going away in this wording?
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
> <http://www.v4now.com/>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
> facebook.com/v4now <http://facebook.com/v4now> ;  
> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
> <http://linkedin.com/in/skeeve>
> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
> www.theispguy.com <http://www.theispguy.com/>
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On Thu, Mar 5, 2015 at 9:31 AM, Owen DeLong  <mailto:o...@delong.com>> wrote:
> +1… I’m with Dean… Still opposed.
> 
> Let’s keep needs basis in place, please. I’m all for removing the requirement 
> to multihome, but not the requirement to actually need the addresses for an 
> operational network.
> 
> Owen
> 
>> On Mar 4, 2015, at 16:09 , Dean Pemberton > <mailto:d...@internetnz.net.nz>> wrote:
>> 
>> Just to clarify. 
>> 
>> This still looks to remove needs based allocation and shift that to an 
>> "ability to advertise". 
>> 
>> Am I missing something here?
>> 
>> On Thursday, 5 March 2015, Masato Yamanishi > <mailto:myama...@gmail.com>> wrote:
>> Dear SIG members
>> 
>> A new version of the proposal “prop-113: Modification in the IPv4 
>> eligibility criteria" has been sent to the Policy SIG for review.
>> 
>> Information about earlier versions is available from:
>> 
>> http://www.apnic.net/policy/proposals/prop-113 
>> <http://www.apnic.net/policy/proposals/prop-113>
>> 
>> 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,
>> 
>> Masato
>> 
>> 
>> 
>> 
>> --
>> prop-113-v002: Modification in the IPv4 eligibility criteria
>> -
>> 
>> Proposer:   Aftab Siddiqui
>>   aftab.siddi...@gmail.com <>
>> 
>>   Skeeve Stevens
>>   ske...@eintellegonetworks.com <>
>> 
>> 
>> 1. Problem statement
>> -
>> 
>> The current APNIC IPv4 delegation policy defines multiple
>> eligibility criteria and applicants must meet one criteria to be
>> eligible to receive IPv4 resources. One of the criteria dictates
>> that “an organization is eligible if it is currently multi-homed
>> with provider-based addresses, or demonstrates a plan to multi-home
>> within one month” (section 3.3).
>> 
>> The policy seems to imply that multi-homing is mandatory even if
>> there is no use case for the applicant to be multi-homed or even
>> when there is only one upstream provider available, this has created
>> much confusion in interpreting this policy.
>> 
>> As a result organizations have either tempted to provide incorrect
>> or fabricated multi-homing information to get the IPv4 resources or
>> barred themselves from applying.
>> 
>> 
>> 2. Objective of policy change
>> --
>> 
>> In order to make the policy guidelines simpler we are proposing to
>> modify the text of section 3.3.
>> 
>> 
>> 3. Situation in other regions
>> 
>> 
>> ARIN:
>> There is no multi-homing requirement
>> 
>> RIPE:
>> There is no multi-homing requirement.
>> 
>> LACNIC:
>> Applicant can either have multi-homing requirement or interconnect.
>> 
>> AFRINIC:
>> There is no multi-homing requirement.
>> 
>> 
>> 4. Proposed policy solution
>> 
>> 
>> Section 3.3: Criteria for small deleg

Re: [sig-policy] New version of prop-113: Modification in the IPv4 eligibility criteria

[Owen DeLong]

+1… I’m with Dean… Still opposed.

Let’s keep needs basis in place, please. I’m all for removing the requirement 
to multihome, but not the requirement to actually need the addresses for an 
operational network.

Owen

> On Mar 4, 2015, at 16:09 , Dean Pemberton  wrote:
> 
> Just to clarify. 
> 
> This still looks to remove needs based allocation and shift that to an 
> "ability to advertise". 
> 
> Am I missing something here?
> 
> On Thursday, 5 March 2015, Masato Yamanishi  > wrote:
> Dear SIG members
> 
> A new version of the proposal “prop-113: Modification in the IPv4 
> eligibility criteria" has been sent to the Policy SIG for review.
> 
> Information about earlier versions is available from:
> 
> http://www.apnic.net/policy/proposals/prop-113 
> 
> 
> 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,
> 
> Masato
> 
> 
> 
> 
> --
> prop-113-v002: Modification in the IPv4 eligibility criteria
> -
> 
> Proposer:   Aftab Siddiqui
>   aftab.siddi...@gmail.com <>
> 
>   Skeeve Stevens
>   ske...@eintellegonetworks.com <>
> 
> 
> 1. Problem statement
> -
> 
> The current APNIC IPv4 delegation policy defines multiple
> eligibility criteria and applicants must meet one criteria to be
> eligible to receive IPv4 resources. One of the criteria dictates
> that “an organization is eligible if it is currently multi-homed
> with provider-based addresses, or demonstrates a plan to multi-home
> within one month” (section 3.3).
> 
> The policy seems to imply that multi-homing is mandatory even if
> there is no use case for the applicant to be multi-homed or even
> when there is only one upstream provider available, this has created
> much confusion in interpreting this policy.
> 
> As a result organizations have either tempted to provide incorrect
> or fabricated multi-homing information to get the IPv4 resources or
> barred themselves from applying.
> 
> 
> 2. Objective of policy change
> --
> 
> In order to make the policy guidelines simpler we are proposing to
> modify the text of section 3.3.
> 
> 
> 3. Situation in other regions
> 
> 
> ARIN:
> There is no multi-homing requirement
> 
> RIPE:
> There is no multi-homing requirement.
> 
> LACNIC:
> Applicant can either have multi-homing requirement or interconnect.
> 
> AFRINIC:
> There is no multi-homing requirement.
> 
> 
> 4. Proposed policy solution
> 
> 
> Section 3.3: Criteria for small delegations
> 
> An organization is eligible if:
> 
> - it is currently multi-homed 
> 
> OR,
> 
> - currently utilising provider (ISP) assignment of at least a /24,
>   
> AND 
> 
> - intends to be multi-homed 
>   
> OR,
> 
> - intends to be multi-homed
> 
> AND
> 
> - advertise the prefixes within 6 months
> 
> 
> 
> 5. Advantages / Disadvantages
> --
> 
> Advantages:
> 
> Simplifies the process of applying for IPv4 address space for small
> delegations and delays the immediate requirement for multi-homing as
> determined to be appropriate within the timeframe as detailed in
> Section 3.3.
> 
> Disadvantages:
> 
> There is no known disadvantage of this proposal.
> 
> 
> 6. Impact on resource holders
> -
> 
> No impact on existing resource holders.
> 
> 
> 
> -- 
> --
> Dean Pemberton
> 
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz 
> 
> To promote the Internet's benefits and uses, and protect its potential.
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net 
> http://mailman.apnic.net/mailman/listinfo/sig-policy 
> 
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

I don’t feel the need for every use case to be set in stone, but I do think 
that there are better ways to address this.

Is there any reason that adding the following to the existing policy would be 
unacceptable to you?

…
or an organization which has received an assignment or allocation from APNIC 
and has not previously obtained an ASN may obtain one ASN upon request for 
purposes of setting up peering for their network with one or more other other 
autonomous systems.


Why would that not suffice?

Owen

> On Mar 4, 2015, at 15:47 , Skeeve Stevens  wrote:
> 
> Owen,
> 
> It just feels like nitpicking and moving chairs around.  I actually trust the 
> Secretariat to do the right thing when allocating resources.  We're also 
> talking about a resource where there are over 4.1 billion ASN's still 
> available... not that it should be a justification to wastage, but it is 
> useful for context.  
> 
> The APNIC stats are:
> 
>  How many ASN - % of Membership
> no ASN
> 34.06%
> 1
> 56.59%
> 2
> 5.55%
> 3
> 1.78%
> 4
> 0.77%
> 5
> 0.35%
> 6
> 0.28%
> 7
> 0.15%
> 8
> 0.04%
> 10
> 0.13%
> more than 10
> 0.31%
>  
> I'm unsure why you guys want to see each and every use-case set in stone.  I 
> don't want to have to come back and do amendments picking on a word here or 
> there because there has been an innovation in the way networks are operated.
> 
> 
> I fully support the idea that this isn't a free-for-all.. but we need some 
> flexibility in the community.
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
> <http://www.v4now.com/>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
> facebook.com/v4now <http://facebook.com/v4now> ;  
> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
> <http://linkedin.com/in/skeeve>
> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
> www.theispguy.com <http://www.theispguy.com/>
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On Thu, Mar 5, 2015 at 8:33 AM, Owen DeLong  <mailto:o...@delong.com>> wrote:
> If said standard pre-existing procedure were subject to the PDP, I’d be fine 
> with that.
> 
> However, that’s not what the wording implies. In the case of the IPv6 policy, 
> I think this is less than desirable, but it’s not on the table in this 
> discussion.
> 
> Certainly if someone proposed removing that wording from the IPv6 policy, I 
> would support such a proposal.
> 
> Owen
> 
>> On Mar 4, 2015, at 14:58 , Skeeve Stevens > <mailto:ske...@v4now.com>> wrote:
>> 
>> Do we just move the 'proposed draft guidelines' to cases under 3.3?
>> 
>> We were trying to be flexible for future use cases without going through 
>> this painful process for every future valid use case that comes up in future.
>> 
>> This is an established process where for subsequent IPv6 allocations:
>> 
>> === http://www.apnic.net/policy/ipv6-address-policy#5.3.2 
>> <http://www.apnic.net/policy/ipv6-address-policy#5.3.2> 
>> 
>> 5.3.2 Alternative allocation criteria
>> 
>> Alternatively, a subsequent allocation may be provided where an organization 
>> (ISP/LIR) can demonstrate a valid reason for requiring the subsequent 
>> allocation. For guidelines on what will be considered a valid technical or 
>> other reason, see “APNIC guidelines for IPv6 allocation and assignment 
>> requests”.
>> 
>>http://www.apnic.net/ipv6-guidelines 
>> <http://www.apnic.net/ipv6-guidelines>
>> ===
>> 
>> Why isn't a standard pre-existing procedure acceptable to you?
>> 
>> 
>> ...Skeeve
>> 
>> Skeeve Stevens - Senior IP Broker
>> v4Now - an eintellego Networks service
>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
>> <http://www.v4now.com/>
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
>> facebook.com/v4now <http://facebook.com/v4now> ;  
>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
>> <http://linkedin.com/in/skeeve>
>> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
>> www.theispguy.com <http://www.theispguy.com/>
>> 
>> IP Address Brokering - Introducing sellers and buyers
>> 
>> On Thu, Mar 5, 2015 at 3:11 AM, Owen DeLong > <mailto:o...@delong.com>> wrote:
>> Opposed as written.
>> 
>> Vague wording which bas

Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

If said standard pre-existing procedure were subject to the PDP, I’d be fine 
with that.

However, that’s not what the wording implies. In the case of the IPv6 policy, I 
think this is less than desirable, but it’s not on the table in this discussion.

Certainly if someone proposed removing that wording from the IPv6 policy, I 
would support such a proposal.

Owen

> On Mar 4, 2015, at 14:58 , Skeeve Stevens  wrote:
> 
> Do we just move the 'proposed draft guidelines' to cases under 3.3?
> 
> We were trying to be flexible for future use cases without going through this 
> painful process for every future valid use case that comes up in future.
> 
> This is an established process where for subsequent IPv6 allocations:
> 
> === http://www.apnic.net/policy/ipv6-address-policy#5.3.2 
> <http://www.apnic.net/policy/ipv6-address-policy#5.3.2> 
> 
> 5.3.2 Alternative allocation criteria
> 
> Alternatively, a subsequent allocation may be provided where an organization 
> (ISP/LIR) can demonstrate a valid reason for requiring the subsequent 
> allocation. For guidelines on what will be considered a valid technical or 
> other reason, see “APNIC guidelines for IPv6 allocation and assignment 
> requests”.
> 
>http://www.apnic.net/ipv6-guidelines <http://www.apnic.net/ipv6-guidelines>
> ===
> 
> Why isn't a standard pre-existing procedure acceptable to you?
> 
> 
> ...Skeeve
> 
> Skeeve Stevens - Senior IP Broker
> v4Now - an eintellego Networks service
> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
> <http://www.v4now.com/>
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
> facebook.com/v4now <http://facebook.com/v4now> ;  
> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
> <http://linkedin.com/in/skeeve>
> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
> www.theispguy.com <http://www.theispguy.com/>
> 
> IP Address Brokering - Introducing sellers and buyers
> 
> On Thu, Mar 5, 2015 at 3:11 AM, Owen DeLong  <mailto:o...@delong.com>> wrote:
> Opposed as written.
> 
> Vague wording which basically says that the secretariat can decide policy on 
> a case-by-case
> basis is antithetical to an informed multi-stakeholder community consensus 
> policy development
> process.
> 
> Owen
> 
>> On Mar 4, 2015, at 00:02 , Masato Yamanishi > <mailto:myama...@gmail.com>> wrote:
>> 
>> Dear SIG members
>> 
>> A new version of the proposal “prop-114: Modification in the ASN 
>> eligibility criteria" has been sent to the Policy SIG for review.
>> 
>> Information about earlier versions is available from:
>> 
>> http://www.apnic.net/policy/proposals/prop-114 
>> <http://www.apnic.net/policy/proposals/prop-114>
>> 
>> 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,
>> 
>> Masato
>> 
>> 
>> 
>> --
>> prop-114-v002: Modification in the ASN eligibility criteria
>> --
>> 
>> Proposer: Aftab Siddiqui
>> aftab.siddi...@gmail.com 
>> <mailto:aftab.siddi...@gmail.com>
>> 
>>Skeeve Stevens
>>ske...@eintellegonetworks.com 
>> <mailto:ske...@eintellegonetworks.com>
>> 
>> 
>> 1. Problem statement
>> -
>> 
>> The current ASN assignment policy states two eligibility criteria
>> and that both criteria should be fulfilled in order to obtain an
>> ASN. The policy seems to imply that both requirements i.e.
>> multi-homing and clearly defined single routing policy must be met
>> simultaneously, this has created much confusion in interpreting the
>> policy.
>> 
>> As a result organizations have either provided incorrect information
>> to get the ASN or barred themselves from applying where they still
>> have a valid justification for obtaining an ASN.
>> 
>> 
>> 2. Objective of policy change
>> --
>> 
>> In order to make the policy guidelines simpler we are proposing to
>> modify the text desc

Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

Opposed as written.

Vague wording which basically says that the secretariat can decide policy on a 
case-by-case
basis is antithetical to an informed multi-stakeholder community consensus 
policy development
process.

Owen

> On Mar 4, 2015, at 00:02 , Masato Yamanishi  wrote:
> 
> Dear SIG members
> 
> A new version of the proposal “prop-114: Modification in the ASN 
> eligibility criteria" has been sent to the Policy SIG for review.
> 
> Information about earlier versions is available from:
> 
> http://www.apnic.net/policy/proposals/prop-114 
> 
> 
> 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,
> 
> Masato
> 
> 
> 
> --
> prop-114-v002: Modification in the ASN eligibility criteria
> --
> 
> Proposer: Aftab Siddiqui
> aftab.siddi...@gmail.com 
> 
>Skeeve Stevens
>ske...@eintellegonetworks.com 
> 
> 
> 
> 1. Problem statement
> -
> 
> The current ASN assignment policy states two eligibility criteria
> and that both criteria should be fulfilled in order to obtain an
> ASN. The policy seems to imply that both requirements i.e.
> multi-homing and clearly defined single routing policy must be met
> simultaneously, this has created much confusion in interpreting the
> policy.
> 
> As a result organizations have either provided incorrect information
> to get the ASN or barred themselves from applying where they still
> have a valid justification for obtaining an ASN.
> 
> 
> 2. Objective of policy change
> --
> 
> In order to make the policy guidelines simpler we are proposing to
> modify the text describing the eligibility criteria for ASN
> assignment by providing alternate criteria to obtaining an ASN.
> 
> 
> 3. Situation in other regions
> 
> 
> ARIN:
> It is not mandatory but optional to be multi-homed in order get ASN
> 
> RIPE:
> Policy to remove multi-homing requirement is currently in discussion
> and the current phase ends 12 February 2015 (awaiting Chair 
> decision)
> 
> Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 
> 
> 
> LACNIC:
> Only inter-connect is mandatory not multi-homing
> 
> AFRINIC:
> It is mandatory to be multi-homed in order to get ASN.
> 
> 
> 4. Proposed policy solution
> ---
> 
> An organization is eligible for an ASN assignment if:
> 
>  - they are currently multi-homed OR
> 
>  - meet one of the other criteria in the guidelines managed by the 
>APNIC Secretariat
> 
> 
> 5. Advantages / Disadvantages
> -
> 
> Advantages:
> 
> By adding the additional criteria of Guidelines managed by APNIC
> Secretariat, this would enable the Secretariat to make decisions
> based on common or rare use cases, but that may still be a valid
> request.
> 
> Disadvantages:
> 
> It may be perceived that this policy would enable members to obtain
> ASN’s more easily, and in return cause faster consumption of ASN’s
> in the region.  Given the relative ease of obtaining an ASN with
> ‘work around’ methods, we do not perceive this will actually have
> any effect.
> 
> 
> 
> 6. Impact on resource holders
> ---
> 
> No impact on existing resource holders.
> 
> 
> 
> Proposed Draft Guidelines
> (to be created as a numbered document by APNIC)
> 
> 
> The below are example of guidelines that could be considered for
> alternate needs justification.
> 
> The intention to multi-home in the future
> 
> The applicant is participating in elastic fabrics where the 
> requirements to connect to ‘on demand’ service providers may require
> ASN/BGP connectivity
> 
> Regional limitation of obtaining multi-homing connectivity in the
> ‘immediate’ term, but want to design their networks for this capability
> 
> Have a single unique routing policy different to their upstream, but yet
> are single-homed
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy ma

Re: [sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB

[Owen DeLong]

I simply don’t see this as at all likely to have the desired effect.

When ISPs put an abuse block in, it’s a very high-overhead thing to do. 
Generally,
in order to maximize the probability that the problem will get resolved at the 
source,
while minimizing the odds of having to play whack-a-mole, it’s done on broad 
strokes
regardless of the detail of information available.

There’s already a remarks section where you can put whatever you want. If you’re
hoping that will reduce how people filter your network, go for it. I doubt it 
will have
much effect.

Other than using the remarks field, an additional field would in fact, be 
necessary.

I oppose the proposal as written.

Owen

> On Mar 2, 2015, at 18:23 , Ruri Hiromi  wrote:
> 
> Hello Owen and list,
> 
> Thanks for your interest to our proposal.
> 
> I don't cost much for implementing in execution of the proposal such
> making additional filed or other.
> 
> But some operators actually see the whois DB and IRR DB to confirm the
> attack vector with its IP address. When set filter by IP address it is
> important to check the assignment range if they do not want to filter
> whole range of ISP's allocated address.
> 
> I also do not want to focus on CGNs, it is a sample case for the
> detailed information.
> 
> In addition, if there is another solution to work with issue, I will
> reconsider the proposal. I think using IRR is the one solution.
> 
> But in order to start discussing about what is good solution where we
> can get detailed information about assignment of address, I thought
> whois DB is possible one to choose.
> 
> Regards,
> 
> On 2015/02/25 2:11, Owen DeLong wrote:
>> I don’t believe the proposal offers enough benefit to be worth what
>> implementation would likely
>> cost.
>> 
>> First, I am sincerely hoping that CGN is an extremely temporary
>> situation. I’m not sure
>> it should be worth the effort to recode the registry to support it.
>> 
>> Second, I’m wondering if there’s any real advantage to having this level
>> of detail on
>> residential subscribers that don’t even get full addresses, since we
>> don’t really tend
>> to have it for single-address subscribers now.
>> 
>> IMHO, best to just let each ISP keep this information for themselves as
>> the relevant contact
>> for abuse and such is usually the ISP and not the residential user anyway.
>> 
>> Owen
>> 
>>> On Feb 23, 2015, at 10:53 , Masato Yamanishi >> <mailto:myama...@gmail.com <mailto:myama...@gmail.com>>> wrote:
>>> 
>>> Dear Colleagues,
>>> 
>>> And, here is prop-115. No comment has not been made for this proposal.
>>> 
>>> If reached consensus, it may needs significant change for whois database.
>>> I just reviewed implementation impact assessment by the Secretariat,
>>> and it says it might take more than 6 months.
>>> I think same thing will happen for whois database of each NIRs.
>>> And if your company have a system linked with APNIC/NIR whois
>>> database, it will be impacted also.
>>> 
>>> As Chair, I'm always very neutral for each proposal, including prop-115.
>>> However, I would like to emphasis prop-115 should be discussed more
>>> widely as it has wide impact.
>>> It is very appreciated if you will express your views.
>>> 
>>> Regards,
>>> Masato Yamanishi, Policy SIG Chair (Acting) 
>>> 
>>> 
>>> 2015-02-04 14:52 GMT-06:00 Masato Yamanishi >> <mailto:myama...@gmail.com>
>>> <mailto:myama...@gmail.com <mailto:myama...@gmail.com>>>:
>>> 
>>>Dear SIG members
>>> 
>>>The Problem statement "Registration of detailed assignment information
>>>in whois DB" has been assigned a Policy Proposal number following the
>>>submission of a new version sent to the Policy SIG for consideration.
>>> 
>>>The proposal, "prop-115-v001: Registration of detailed assignment
>>>information in whois DB" now includes an objective and proposed
>>>solution.
>>> 
>>>Information about this and earlier versions is available from:
>>> 
>>>http://www.apnic.net/policy/proposals/prop-115 
>>> <http://www.apnic.net/policy/proposals/prop-115>
>>> 
>>>You are encouraged 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 com

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Feb 27, 2015, at 01:43 , Izumi Okutani  wrote:
> 
> On 2015/02/27 17:58, Usman Latif wrote:
>> I think organisations that have obtained portable address ranges from RIRs 
>> should have the liberty to use public ASNs from day one (if they want to) 
>> regardless of whether they are single homed or multihomed.
>> 
> 
> OK, that's an interesting approach.
> 
> What is the reason for this? Would be curious to hear from other
> operators as well, on what issues it may cause if you are a single homed
> portable assignment holder and cannot receive a global ASN.

I can see a few reasons.

1.  The difficulty of renumbering from a private ASN is proportional to the 
number of links,
not the number of ASNs. Ergo, someone who is single homed, but plans to 
become
multihomed at some unspecified date in the future may, indeed, have 
good reason for
wanting to do so with a public ASN.

2.  I see very little harm in adopting such a policy, so long as it is 
limited to one ASN per 
organization.

3.  If you have multiple links to a provider with diverse topology, it is 
desirable to be able
to use a routing protocol in order to prevent black-holing traffic 
across down links, etc.
The only routing protocol any sane ISP would run with an unrelated 
third party is
BGP. BGP requires an ASN. See above for why a public ASN may be more 
desirable
under this circumstance than a private one.

As to the references to RFC-1930, I think they are anachronistic at this point.

RFC-1930 was written before 32-bit ASNs were available and with a strong eye to 
the
coming shortage of 16-bit ASNs. While I agree that even the 32-bit pool of ASNs 
is finite,
I don’t think we’re going to cause a shortage of them by allowing single-homed 
organizations
with PI space who plan to multihome at an unspecified future time to receive 
one.

As such, I believe such a policy would do no harm and provide benefit to some 
members
of the community. If it were proposed, I would support it.

Owen

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Feb 26, 2015, at 22:16 , Shen Zhi  wrote:
> 
> Good point, getting greater operator participation in the policy processes is
> important. APRICOT and APNIC having joint meeting is one of the good 
> ways to bring more operators to APNIC policy discussion. I noticed on the 
> Policy SIG session @APNIC 39, there will be some short background 
> instroductions
> by APNIC staff (could be someone from the community who is familiar with the 
> policy history in future) before the proposal discussion, I think it's a very 
> good 
> way to faciliate the new comers to understand and join the discussion.
> 
> I'm thinking if we set part of or whole Policy SIG session on the same days 
> when APRICOT or APCERT sessions are running, say Tuesday, or Wednesday, will 
> it help that more operators attend the policy discussions?

That depends. If it’s a parallel track to something operators would consider 
more interesting,
then probably not.

If it’s _THE_ track at that time, then it might work, or, it might turn into 
shopping time, etc.

As near as I can tell, the problem is less one of accessibility than interest.

Owen

> 
> 
> Cheers,
> Jessica Shen
> 
> 
> 
>> -邮件原件-
>> 发件人: sig-policy-boun...@lists.apnic.net
>> [mailto:sig-policy-boun...@lists.apnic.net] 代表 Owen DeLong
>> 发送时间: 2015年2月27日 4:42
>> 收件人: Mark Tinka
>> 抄送: sig-policy@lists.apnic.net
>> 主题: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the
>> ASN eligibility criteria
>> 
>> In theory, this is why each RIR has a public policy process open to any who
>> choose to participate.
>> 
>> The fact that operator participation in the process is limited (voluntarily 
>> by
>> the operators themselves) continues to cause problems for operators. This
>> not only affects RIRs, but also the IETF, ICANN, and other multi-stakeholder
>> fora covering various aspects of internet governance and development.
>> 
>> If you have a suggestion for getting greater operator participation in these
>> processes, I’m all ears.
>> 
>> Owen
>> 
>>> On Feb 25, 2015, at 5:27 PM, Mark Tinka 
>> wrote:
>>> 
>>> While I tend to agree that the current draft policy in its form needs
>>> more work, I empathize with the long-held concern of detachment
>>> between the RIR and network operations. This is a well-documented
>>> issue that affects several other policies within various RIR
>>> communities, and not just this one nor APNIC. Take assigned prefix
>>> length and what operators filter against as an example.
>>> 
>>> Globally, perhaps we would do well to find way to make RIR operations
>>> and policy design reflect the practical day-to-day changes taking
>>> place within operator networks, or at the very least, make a provision
>>> for them that sufficiently covers what the future may throw up.
>>> 
>>> I don't think any of us have the answers now, but it starts from
>> somewhere.
>>> 
>>> Mark.
>>> *  sig-policy:  APNIC SIG on resource management policy
>> *
>>> ___
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>> 
>> *  sig-policy:  APNIC SIG on resource management policy
>> *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
> 

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Requirements for Subsequent ASN Requests

[Owen DeLong]

I’m not opposed to qualifying some cases where private AS may also work, 
because in those cases, frankly, I think most organizations will either use a 
private AS rather than go to the trouble of applying, or, they may have a good 
reason (future plans, etc.) for wanting to get a public AS and not have to 
re-run all their peering sessions later.

Owen

> On Feb 26, 2015, at 13:40 , Masato Yamanishi  wrote:
> 
> Owen,
> 
> I don't want to discuss too much details since I'm acting chair,
> but I'm afraid that "unique routing policy" is vague and it may qualify some 
> usecases that private AS may also work.
> So, what is the definition or understanding for "unique routing policy" in 
> ARIN?
> 
> Masato Yamanishi
> 
> Feb 26, 2015 3:14 PM、Owen DeLong mailto:o...@delong.com>> 
> のメッセージ:
> 
>> Yes, I was well aware of that. Is there anything you believe to be incorrect 
>> in my comments as a result? Otherwise, I’m not sure what you are getting at.
>> 
>> I believe a unique routing policy or multiple peers is sufficient 
>> justification.
>> 
>> Absent that, I believe that an entity which qualifies for PI and intends to 
>> multihome later should legitimately be able to obtain an ASN to simplify 
>> their build-out in anticipation of later multihoming. 
>> 
>> This last part, is, IMHO, the only change that should be contemplated vs. 
>> the current existing policy.
>> 
>> Owen
>> 
>>> On Feb 26, 2015, at 9:45 AM, Masato Yamanishi >> <mailto:myama...@gmail.com>> wrote:
>>> 
>>> Owen and Usman,
>>> 
>>> In following comments, did you consider we are discussing "public" AS 
>>> numbers?
>>> Since we are discussing "public" AS, we should have some kind of 
>>> justifications why it should be globally unique.
>>> 
>>> Regards,
>>> Masato
>>> 
>>> 
>>> 2015-02-25 18:39 GMT-06:00 Owen DeLong >> <mailto:o...@delong.com>>:
>>> Usman, since an AS is defined as “A collection of prefixes with a common 
>>> routing policy”, what would you use one for if not to connect to other 
>>> autonomous systems? If you are connecting to a single other autonomous 
>>> system, then, arguably it is impossible for your prefixes to have a 
>>> distinct routing policy and you are, therefore, part of that other AS. If 
>>> you are connecting to multiple other autonomous systems, then, you are, by 
>>> definition multihomed.
>>> 
>>> If you have some better way to manage this, I’m all ears.
>>> 
>>> Owen
>>> 
>>>> On Feb 25, 2015, at 16:26 , Usman Latif >>> <mailto:osma...@yahoo.com>> wrote:
>>>> 
>>>> ASN is an identifier for an autonomous system - so theoretically speaking, 
>>>> an ASN should have no dependency on multihoming or single homing
>>>> However, what we need is a better way to regulate assignment of ASNs so 
>>>> their allocation doesn't become wasteful..
>>>> 
>>>> Regards,
>>>> Usman
>>>> 
>>>> 
>>>> On 26 Feb 2015, at 11:16 am, Skeeve Stevens >>> <mailto:ske...@v4now.com>> wrote:
>>>> 
>>>>> Hi Secretariat,
>>>>> 
>>>>> I would like to understand the policy/secretariats view on the 
>>>>> justification/requirements of subsequent ASN resource requests.
>>>>> 
>>>>> 
>>>>> 
>>>>> ...Skeeve
>>>>> 
>>>>> Skeeve Stevens - Senior IP Broker
>>>>> v4Now - an eintellego Networks service
>>>>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
>>>>> <http://www.v4now.com/>
>>>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 
>>>>>  ; skype://skeeve <>
>>>>> facebook.com/v4now <http://facebook.com/v4now> ;  
>>>>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
>>>>> <http://linkedin.com/in/skeeve>
>>>>> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
>>>>> www.theispguy.com <http://www.theispguy.com/>
>>>>> 
>>>>> IP Address Brokering - Introducing sellers and buyers
>>>>> *  sig-policy:  APNIC SIG on resource management policy   
>>>>> *
>>>>> ___
>>>>> sig-poli

Re: [sig-policy] Requirements for Subsequent ASN Requests

[Owen DeLong]

Yes, I was well aware of that. Is there anything you believe to be incorrect in 
my comments as a result? Otherwise, I’m not sure what you are getting at.

I believe a unique routing policy or multiple peers is sufficient justification.

Absent that, I believe that an entity which qualifies for PI and intends to 
multihome later should legitimately be able to obtain an ASN to simplify their 
build-out in anticipation of later multihoming. 

This last part, is, IMHO, the only change that should be contemplated vs. the 
current existing policy.

Owen

> On Feb 26, 2015, at 9:45 AM, Masato Yamanishi  wrote:
> 
> Owen and Usman,
> 
> In following comments, did you consider we are discussing "public" AS numbers?
> Since we are discussing "public" AS, we should have some kind of 
> justifications why it should be globally unique.
> 
> Regards,
> Masato
> 
> 
> 2015-02-25 18:39 GMT-06:00 Owen DeLong  <mailto:o...@delong.com>>:
> Usman, since an AS is defined as “A collection of prefixes with a common 
> routing policy”, what would you use one for if not to connect to other 
> autonomous systems? If you are connecting to a single other autonomous 
> system, then, arguably it is impossible for your prefixes to have a distinct 
> routing policy and you are, therefore, part of that other AS. If you are 
> connecting to multiple other autonomous systems, then, you are, by definition 
> multihomed.
> 
> If you have some better way to manage this, I’m all ears.
> 
> Owen
> 
>> On Feb 25, 2015, at 16:26 , Usman Latif > <mailto:osma...@yahoo.com>> wrote:
>> 
>> ASN is an identifier for an autonomous system - so theoretically speaking, 
>> an ASN should have no dependency on multihoming or single homing
>> However, what we need is a better way to regulate assignment of ASNs so 
>> their allocation doesn't become wasteful..
>> 
>> Regards,
>> Usman
>> 
>> 
>> On 26 Feb 2015, at 11:16 am, Skeeve Stevens > <mailto:ske...@v4now.com>> wrote:
>> 
>>> Hi Secretariat,
>>> 
>>> I would like to understand the policy/secretariats view on the 
>>> justification/requirements of subsequent ASN resource requests.
>>> 
>>> 
>>> 
>>> ...Skeeve
>>> 
>>> Skeeve Stevens - Senior IP Broker
>>> v4Now - an eintellego Networks service
>>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com 
>>> <http://www.v4now.com/>
>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 
>>>  ; skype://skeeve <>
>>> facebook.com/v4now <http://facebook.com/v4now> ;  
>>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve 
>>> <http://linkedin.com/in/skeeve>
>>> twitter.com/theispguy <http://twitter.com/theispguy> ; blog: 
>>> www.theispguy.com <http://www.theispguy.com/>
>>> 
>>> IP Address Brokering - Introducing sellers and buyers
>>> *  sig-policy:  APNIC SIG on resource management policy 
>>>   *
>>> ___
>>> sig-policy mailing list
>>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy 
>>> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
>> *  sig-policy:  APNIC SIG on resource management policy  
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
>> http://mailman.apnic.net/mailman/listinfo/sig-policy 
>> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
> 
> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net>
> http://mailman.apnic.net/mailman/listinfo/sig-policy 
> <http://mailman.apnic.net/mailman/listinfo/sig-policy>
> 
> 

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

In theory, this is why each RIR has a public policy process open to any who 
choose to participate.

The fact that operator participation in the process is limited (voluntarily by 
the operators themselves) continues to cause problems for operators. This not 
only affects RIRs, but also the IETF, ICANN, and other multi-stakeholder fora 
covering various aspects of internet governance and development.

If you have a suggestion for getting greater operator participation in these 
processes, I’m all ears.

Owen

> On Feb 25, 2015, at 5:27 PM, Mark Tinka  wrote:
> 
> While I tend to agree that the current draft policy in its form needs
> more work, I empathize with the long-held concern of detachment between
> the RIR and network operations. This is a well-documented issue that
> affects several other policies within various RIR communities, and not
> just this one nor APNIC. Take assigned prefix length and what operators
> filter against as an example.
> 
> Globally, perhaps we would do well to find way to make RIR operations
> and policy design reflect the practical day-to-day changes taking place
> within operator networks, or at the very least, make a provision for
> them that sufficiently covers what the future may throw up.
> 
> I don't think any of us have the answers now, but it starts from somewhere.
> 
> Mark.
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

Re: [sig-policy] Requirements for Subsequent ASN Requests

[Owen DeLong]

Usman, since an AS is defined as “A collection of prefixes with a common 
routing policy”, what would you use one for if not to connect to other 
autonomous systems? If you are connecting to a single other autonomous system, 
then, arguably it is impossible for your prefixes to have a distinct routing 
policy and you are, therefore, part of that other AS. If you are connecting to 
multiple other autonomous systems, then, you are, by definition multihomed.

If you have some better way to manage this, I’m all ears.

Owen

> On Feb 25, 2015, at 16:26 , Usman Latif  wrote:
> 
> ASN is an identifier for an autonomous system - so theoretically speaking, an 
> ASN should have no dependency on multihoming or single homing
> However, what we need is a better way to regulate assignment of ASNs so their 
> allocation doesn't become wasteful..
> 
> Regards,
> Usman
> 
> 
> On 26 Feb 2015, at 11:16 am, Skeeve Stevens  > wrote:
> 
>> Hi Secretariat,
>> 
>> I would like to understand the policy/secretariats view on the 
>> justification/requirements of subsequent ASN resource requests.
>> 
>> 
>> 
>> ...Skeeve
>> 
>> Skeeve Stevens - Senior IP Broker
>> v4Now - an eintellego Networks service
>> ske...@v4now.com  ; www.v4now.com 
>> 
>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <>
>> facebook.com/v4now  ;  
>> linkedin.com/in/skeeve 
>> 
>> twitter.com/theispguy  ; blog: 
>> www.theispguy.com 
>> 
>> IP Address Brokering - Introducing sellers and buyers
>> *  sig-policy:  APNIC SIG on resource management policy  
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net 
>> http://mailman.apnic.net/mailman/listinfo/sig-policy 
>> 
> *  sig-policy:  APNIC SIG on resource management policy   
> *
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy