[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 

[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=05%7C02%7C%7C96c320a0c7bb4e6a778008dbfc501ddd%7C127d8d0d7ccf473dab096e44ad752ded%7C0%7C0%7C638381193266052234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=wHJMNZRDt48kdnbwDKs2Sc2uGR9ZleDC7IY2kAaAwXQ%3D=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 broadly in 
>> any 

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

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

[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 

[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 

[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 

[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 

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 
> 

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

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 

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 moving “rout

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 valid ROA fro

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

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

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 

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 

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 

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

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 “invalid”, 
>&

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 address block n

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 

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

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

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

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 

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

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 
> <skeeve+sigpol...@eintellegonetworks.asia> 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 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” 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, 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 <o...@delong.com 
> <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 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 transfer block 
> into parent’s holdings.
>   4.  Lather, rinse, repeat.
> 
> Owen
> 
>> On Jan 31, 2018, at 08:47 , Skeeve Stevens 
>> <skeeve+sigpol...@eintellegonetworks.asia 
>> <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 <g...@apnic.net 
>> <mailto:g...@apnic.net>> wrote:
>> Hi Aftab,
>> 
>>  
>> 
>> The number of M 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

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 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 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 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 >
> Cc: Sanjeev Gupta >; 
> mailman_SIG-policy >
> Subject: Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy 
> [SECURITY=UNCLASSIFIED]
> 
>  
> 
> Hi Guangliang,
> 
> How many M 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 >
> 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 98551208    http://sg.linkedin.com/in/ghane 
> 
>  
> 
> On Mon, Jan 29, 2018 at 4:16 AM, Henderson Mike, Mr 
> > 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 

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

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

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 <o...@delong.com 
> <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 <ske...@v4now.com 
>>> <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 <h...@anytimechinese.com 
>>> <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 <pwil...@apnic.net> 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 <ske...@v4now.com> 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 <geo...@apnic.net 
>>> <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 <myama...@gmail.com 
>>> <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 t

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 

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 

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 pwil...@apnic.net 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 o...@delong.com 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 david.huber...@microsoft.com 
 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 d...@internetnz.net.nz
 Date: Friday, 22 May 2015
 Subject: [sig-policy] Idea for 1.2.3.0/24
 To: David Huberman david.huber...@microsoft.com
 
 
 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

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 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 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 
 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 mailing list
 sig-policy@lists.apnic.net
 http://mailman.apnic.net/mailman/listinfo/sig-policy

*  sig-policy:  APNIC SIG 

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 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 myama...@gmail.com 
 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 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 mailto: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 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 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 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/networkceoaulinkedin.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 o...@delong.com 
 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 ske...@v4now.com 
 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/networkceoaulinkedin.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 o...@delong.com 
 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 myama...@gmail.com 
 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

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 ske...@v4now.com 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/networkceoaulinkedin.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 o...@delong.com 
 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 d...@internetnz.net.nz 
 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 myama...@gmail.com 
 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 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

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 shen...@cnnic.cn 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 mark.ti...@seacom.mu
 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] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

 On Feb 27, 2015, at 01:43 , Izumi Okutani iz...@nic.ad.jp 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]

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 mark.ti...@seacom.mu 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]

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 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 o...@delong.com 
 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 osma...@yahoo.com 
 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 ske...@v4now.com 
 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 
 tel:%2B61%20%280%29414%20753%20383 ; skype://skeeve 
 facebook.com/v4now http://facebook.com/v4now ;  
 http://twitter.com/networkceoaulinkedin.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] 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 myama...@gmail.com 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 o...@delong.com 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 myama...@gmail.com 
 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 o...@delong.com 
 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 osma...@yahoo.com 
 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 ske...@v4now.com 
 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 
 tel:%2B61%20%280%29414%20753%20383 ; skype://skeeve 
 facebook.com/v4now http://facebook.com/v4now ;  
 http://twitter.com/networkceoaulinkedin.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]

 On Feb 25, 2015, at 00:32 , Skeeve Stevens ske...@v4now.com wrote:
 
 Sorry Dean, I don't agree with you.
 
 You guys are trying to tell people how to run their networks, and that they 
 aren't allowed to pre-emptively design their connectivity to allow for 
 changing to multi-homing, or away from it, without going through a change in 
 network configuration.
 
 That might be easy for you, but that is simply your opinion on how things 
 should be done... not a reason why others shouldn't be allowed to do it the 
 way they want to.
 
 If a member has a portable range, they should be entitled to - with no 
 restrictions - a ASN number to be able to BE as portable as they want to.

Even if I agreed with what you have said above, and I do not, this last 
statement bears no resemblence to the policy you have proposed.

If you want to propose a policy that matches your last sentence, I would not 
oppose that, so long as any additional ASNs had to be issued under the current 
multihome requirement.

However, your proposal doesn’t say someone who has PI space is entitled to 1 
ASN. It says anyone who wants one is entitled to as many ASNs as they want.

That’s simply a bad idea.

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 25, 2015, at 15:10 , David Farmer far...@umn.edu wrote:
 
 On 2/25/15 15:44 , Dean Pemberton wrote:
 ...
 There is essentially no barrier to entry here.  If a site needs an ASN
 they are able to receive one.  If they want one 'just in case', then
 that is against current policy and I'm ok with that.
 
 Dean
 
 From a policy perspective there is no barrier to entry.
 
 However, from an operational perspective, I see it a little differently; 
 having deployed my network using a private ASN, I then need to migrate to a 
 new unique registry assigned ASN.  Which you are saying I can't have until 
 I've grown to the point were I need to multi-home or connect to an IX.  If 
 I'm a small network, this may not be a big hardship.  But if you connect to a 
 single provider in multiple cities you could build a fairly extensive network 
 that would not qualify for a registry assigned ASN until you got a second 
 provider or connected to an IX, at which point the transition to the new ASN 
 could be rather complicated.

That’s actually not the case.

The case is until you choose to multihome or connect to an IX. You can choose 
to do that with a pretty small network. My home is multihomed, for example.

Any network with an IPv4 upstream can get an IPv6 tunnel from HE, turn on BGP, 
and poof, they are sufficiently multihomed for the APNIC definition. HE has 
several tunnel servers in the APNIC region to support this.

Changing ASNs on peering sessions actually isn’t very hard. There’s a brief 
period where you have inconsistent origin, but otherwise, it’s mostly one line 
of config change on each of your border routers. Even if you’ve got a hundred 
peering sessions, it’s something that can be done in a day or two with a 
cooperative provider. It might take a few weeks with some of the less 
responsive providers.

However, while I’m not trying to tell anyone how to run their network, I think 
we can agree that it is pretty foolhearty to get much beyond 2 or 3 peering 
sessions without mixing in some provider diversity. Further, if you want to 
plan ahead and deploy an ASN early, turning up an HE tunnel to do that is 
pretty easy. Unless HE is your only upstream for IPv4, you’re all set at that 
point.

 I'm not sure that justifies obliterating the current policy, but there is at 
 least an operational barrier to entry in some situations.  I think maybe a 
 compromise would be to allow a network of a certain size to obtain an ASN 
 regardless of having a unique routing policy, being multi-homed, or connected 
 to an IX.

I don’t think size is relevant. As I said, I wouldn’t oppose a policy 
modification that in addition to the current mechanisms, allowed for anyone 
with a PI allocation or assignment to obtain a single ASN without question.

 A network of 1 or 2 routers probably doesn't justify an ASN unless it is 
 multi-homed or connected to an IX.  A network of 100 routers probably 
 justifies an ASN regardless.  Then the question becomes, where to draw the 
 line.

I’m having trouble envisioning who would build a network with 100 border 
routers (only the border routers really count in this case) without connecting 
to more than one upstream. This smells like looking for a corner case to 
justify a solution looking for a problem statement.


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] 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 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 ske...@v4now.com 
 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/networkceoaulinkedin.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
 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]

 On Feb 24, 2015, at 22:46 , Skeeve Stevens ske...@v4now.com wrote:
 
 To me, relaxing these rules is less about lying - although is easy, but it is 
 to do with flexibility.
 
 I understand the routing policy wont be different that an upstream without 
 being multi-homed, but it does curtail the convenience of being able to add 
 these things easily.
 
 Lets say I was a company with a /23 and upstream into Telstra Only.  If I had 
 my own ASN and was announcing to Telstra, then at any time I could add 
 another ISP, IXP, direct peering without having to go apply for an ASN, 
 reconfigure my network to bring the announcement in-house, etc. 

No you can’t… You just have already done it instead of doing it when you get 
ready to actually multihome.

It’s all the same effort, just a difference in when you have to apply said 
effort.

 I also might want to maintain a single provider, but be able to migrate 
 easily to another provider without having to rely on the providers to do the 
 right thing while changing announcements between them.

This has some validity, but if you have an overlap period, you’re multihomed 
during the overlap and eligible for an ASN as a result.

 I think this policy has VERY valid applications for many smaller entities to 
 be able to have an ASN without having to be multi-homed either initially, or 
 maintain that multi-homing.

I don’t believe you lose your ASN if you stop multihoming.

 As Randy used to say - Why do you have the right to tell me how to manage my 
 network?  If I want to be multi-homed, or change my mind and not be, it is 
 none of your damn business.

That’s true. But nobody is trying to tell you that. I don’t believe the APNIC 
policy calls for reclaiming ASNs from entities that are no longer multihomed. 
It merely prevents issuing ASNs to entities that are not multihomed.

The only possible case I can see where this might be useful would be the case 
of two uplinks to the same ASN that are sufficiently topologically diverse as 
to make it desirable to do route injection for better failover capabilities.

 I think this policy change reflects the changing way for businesses to get 
 online since APNIC has run out of IP's, and are often charging significant 
 amounts of money - so people are going to APNIC directly - which they are 
 entitled to do.  And being flexible and being able to change their 
 circumstances is a more common thing nowadays.

No, this policy change turns APNIC into an ASN pez dispenser which is an 
undesirable state.

You don’t need an ASN to use provider independent addresses, so the rest of the 
paragraph is a red herring.

The flexibility exists. It’s just a question of when one does the work to turn 
on BGP and get an ASN. I see no reason the community should hand out ASNs to 
anyone who thinks they might want one for some possible use at some possible 
time in some possible future.

 If you want, suggest charging for ASN's... but don't tell networks how they 
 should be connected at any time.

Nobody is telling anyone how they should be connected. This is about resource 
management of a community resource pool, not about dictating operational 
practice. You can do everything you have said you want to do with your network 
under the existing policy.  You just can’t get an ASN until you actually need 
one. Imagine where we’d be if we had handed out all the IPv4 space to anyone 
who thought they might need some someday?

 Btw... I am happy for this to apply ONLY to ASN4 and not ASN2.

There are no more ASN4s than there are IPv4 addresses.

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]

 Policy Advisor
 InternetNZ
 +64 21 920 363 (mob)
 d...@internetnz.net.nz mailto:d...@internetnz.net.nz
 
 To promote the Internet's benefits and uses, and protect its potential.
 
 On Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens ske...@v4now.com 
 mailto:ske...@v4now.com wrote:
 Owen,
 
 But who determines 'if they need one' ?  Them, or you (plural)?
 
 I believe they should be able to determine that they need one and be able to 
 get one based on that decision - not told how they should be doing their 
 upstream connectivity at any particular time.
 
 
 ...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 
 tel:%2B61%20%280%29414%20753%20383 ; skype://skeeve 
 facebook.com/v4now http://facebook.com/v4now ;  
 http://twitter.com/networkceoaulinkedin.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, Feb 26, 2015 at 8:03 AM, Owen DeLong o...@delong.com 
 mailto:o...@delong.com wrote:
 
  On Feb 24, 2015, at 22:47 , Raphael Ho raphael...@ap.equinix.com 
  mailto:raphael...@ap.equinix.com wrote:
 
  All,
 
  I¹m having an offline discussion with Aftab, basically the issue he¹s
  trying to address is that new ISPs in small countries/cities may not meet
  the day 1 requirements for an ASN, but however should be eligible since
  they will require an ASN to peer/multihome at some point in the future
  (which I do agree)
 
 What is the disadvantage for them to get the ASN later, when they actually 
 need it?
 
  Currently they all have to commit fraud² in order to get an ASN, and I
  guess some religion takes that more seriously than others.
 
 They only have to commit fraud if they are determined to get an ASN before 
 they need one.
 
  Would we the proposal be acceptable if we reworded the proposal to say
  something on the lines of
 
  ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible
  for as ASN²?
 
 I think “an ASN” rather than “as ASN”, but I’d need to better understand why 
 they need one
 ahead of time. What’s wrong with getting the ASN when you need it?
 
 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-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]

 On Feb 24, 2015, at 22:06 , Dean Pemberton d...@internetnz.net.nz wrote:
 
 Great - Thanks for that.
 
 As far as I can tell this covers all possible use cases I can see.
 I do not believe that there is a need for prop-114.
 

Agreed… However, it does allow one to basically get ASNs no matter what, since 
all one needs to do is cobble up 3 distinct sites and ask for an ASN for each 
site and then peer the sites with each other.

Owen

 I do not support the proposal
 
 
 --
 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.
 
 
 On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan g...@apnic.net wrote:
 Hi Dean and All,
 
 According to the current APNIC ASN policy document, the definition of 
 multihomed is as below.
 
 http://www.apnic.net/policy/asn-policy#3.4
 
 3.4 Multihomed
 
 A multi-homed AS is one which is connected to more than one other AS. An AS 
 also qualifies as multihomed if it is connected to a public Internet 
 Exchange Point.
 
 In the ASN request form, you will be asked to provide the estimate ASN 
 implementation date, two peer AS numbers and their contact details. It is 
 also acceptable if your network only connect to an IXP.
 
 Best regards,
 
 Guangliang
 =
 
 -Original Message-
 From: sig-policy-boun...@lists.apnic.net 
 [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
 Sent: Wednesday, 25 February 2015 7:02 AM
 To: Owen DeLong
 Cc: sig-policy@lists.apnic.net
 Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in 
 the ASN eligibility criteria
 
 Looks like a clarification on the definition of multi-homing from the 
 secretariat is what we need before being able to proceed here.
 
 
 --
 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.
 
 
 On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong o...@delong.com wrote:
 
 On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nz wrote:
 
 On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.com wrote:
 Firstly I agree with Randy here.  If you're not multi-homed then your 
 routing policy can not be 'unique' from your single upstream.  You may 
 wish it was, but you have no way to enforce this.
 
 This is not true.
 
 You can be single homed to a single upstream, but, have other peering 
 relationships with other non-upstream ASNs which are also not 
 down-stream. These relationships may not be sufficiently visible to 
 convince APNIC that one is multihomed, even though technically it is a 
 multihomed situation.
 
 
 I don't agree (Damn and we were getting on so well this year  =) ).
 
 I would argue that the situation you describe above DOES constitute 
 multihoming.
 
 I agree, but it may not necessarily constitute “multihoming” in a manner 
 that is recognized or accepted by the RIR.
 
 Clarification from APNIC staff on the exact behavior from APNIC could 
 render this moot.
 
 However, I have past experience where RIRs have rejected peerings with 
 related entities and/or private ASNs of third parties as not constituting 
 valid “multihoming” whereupon I had to resort to “a unique routing policy”.
 
 
 If an LIR were connected to an upstream ISP but also wanted to
 participate at an IXP I would consider them to be multihomed and
 covered under existing APNIC policy.
 
 What if they only connected to the IXP with a single connection? I’ve also 
 encountered situations where this is considered “not multihomed” and to be 
 a “unique routing policy”.
 
 
 I couldn't find the strict definition on the APNIC pages as to what
 the hostmasters considered multihoming to be, but if one of them can
 point us to it then it might help.
 
 Agreed.
 
 
 
 While I oppose that (and thus completely oppose the other proposal), as 
 stated above, I think there are legitimate reasons to allow ASN issuance 
 in some cases for organizations that may not meet the multi-homing 
 requirement from an APNIC perspective.
 
 I really want to find out what those multi-homing requirements are.
 I suspect that they amount to BGP connections to two or more other
 ASNs
 In which case I think we can go back to agreeing.
 
 As long as it’s not more specific than that (for example, two or more 
 public ASNs or via distinct circuits, etc.).
 
 
 
 
 I think it is more a case that smaller and simpler policy proposals that 
 seek to change a single aspect of policy are more likely to succeed or 
 fail on their merits, where large complex omnibus proposals have a 
 substantial history of failing on community misunderstanding or general 
 avoidance of complexity.
 
 I can see your point, but taking a smaller simpler approach is only
 valid once you have agreed on the larger more strategic direction.  I
 don't believe that we have had those conversations.
 
 I find

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

[Owen DeLong]

 On Feb 24, 2015, at 22:47 , Raphael Ho raphael...@ap.equinix.com wrote:
 
 All,
 
 I¹m having an offline discussion with Aftab, basically the issue he¹s
 trying to address is that new ISPs in small countries/cities may not meet
 the day 1 requirements for an ASN, but however should be eligible since
 they will require an ASN to peer/multihome at some point in the future
 (which I do agree)

What is the disadvantage for them to get the ASN later, when they actually need 
it?

 Currently they all have to commit fraud² in order to get an ASN, and I
 guess some religion takes that more seriously than others.

They only have to commit fraud if they are determined to get an ASN before they 
need one.

 Would we the proposal be acceptable if we reworded the proposal to say
 something on the lines of
 
 ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible
 for as ASN²?

I think “an ASN” rather than “as ASN”, but I’d need to better understand why 
they need one
ahead of time. What’s wrong with getting the ASN when you need 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-113: Modification in the IPv4 eligibility criteria

[Owen DeLong]

Actually, after seeing the clarifications provided to Dean, I now oppose this 
proposal as written.

Owen

 On Feb 23, 2015, at 10:21 , Masato Yamanishi myama...@gmail.com wrote:
 
 Dear Colleagues,
 
 Regarding prop-113, I saw 3 very simple support and 1 clarification without 
 any negative comment.
 Isn't there any concern or negative comment?
 
 Dean
 Can you express your view after clarification?
 
 Aflab and Skeeve
 If prop-113 will reach consensus but prop-114 will not, is it acceptable 
 initial approach to implement only prop-113?
 Or, these are inseparable policies?
 
 Regards,
 Masato Yamanishi, Policy SIG Chair (Acting)
 
 
 2015-02-03 22:18 GMT-06:00 Sanjeev Gupta sanj...@dcs1.biz 
 mailto:sanj...@dcs1.biz:
 
 On Wed, Feb 4, 2015 at 1:56 AM, Masato Yamanishi myama...@gmail.com 
 mailto:myama...@gmail.com wrote:
 
 The proposal prop-113: Modification in the IPv4 eligibility criteria
 has been sent to the Policy SIG for review.
 
 Support.
 
 -- 
 Sanjeev Gupta
 +65 98551208 tel:%2B65%2098551208   http://sg.linkedin.com/in/ghane 
 http://sg.linkedin.com/in/ghane
 
 *  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

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

I do agree with Dean that this proposal in its current state is too radical, 
but I do support relaxing the requirements to multi home _or_ unique routing 
policy would be an improvement that addresses the issue raised in the problem 
statement. 

Owen




 On Feb 5, 2015, at 12:07, Skeeve Stevens ske...@v4now.com wrote:
 
 hahahahahahahahahah
 
 ...to walking into a room full of people and saying Everyone who is not 
 here, please raise your hand and concluding from the lack of raised hands 
 that everyone is present.
 
 This made my morning.
 
 
 ...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
 
 On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong o...@delong.com wrote:
 I don't think your conclusion is supported by the statement from 
 hostmaster...
 
 We don't know of anyone who hasn't reached out to us doesn't mean that 
 nobody has reached out to them... It means that they are unaware.
 
 Asking the hostmasters about this issue in the way you did is akin to 
 walking into a room full of people and saying Everyone who is not here, 
 please raise your hand and concluding from the lack of raised hands that 
 everyone is present.
 
 Owen
 
 
 
 
 On Feb 4, 2015, at 8:09 PM, Dean Pemberton d...@internetnz.net.nz wrote:
 
 So it doesn't look like there is a problem here. 
 
 The hostmasters are clear about the current policy, they explain it to 
 people who contact them. 
 
 Am I missing something?  I'm not at all in favour of policy for policy 
 sake. 
 
 What's the problem statement here?
 
 On Thursday, 5 February 2015, George Kuo geo...@apnic.net wrote:
 Hello Dean,
 
 We are not aware of any potential members who may have decided not to 
 apply for IPv4 addresses or AS numbers based on how they have interpreted 
 the policy wording.
 
 However, we explain the policy criteria to any potential members who do 
 contact APNIC, and those who are not multihoming do not qualify for An 
 IPv4 or ASN assignment based on the current policy.
 
 Currently, we don't keep a record of these unsuccessful requests, but
 we can begin to keep records in the future if this information is
 required.
 
 George K
 
 On 4/02/2015 5:13 am, Dean Pemberton wrote:
 Could I ask that the APNIC hostmasters to comment on the following:
 
 Have you ever been made aware of a situation where due of the current
 wording of the relevant clauses in the policy, a member or potential
 member has not made a resource application where they would otherwise
 have been able to?
 
 In other words has the current policy in the eyes of the host masters
 ever been a barrier to entry?
 
 
 
 
 On Wednesday, 4 February 2015, Masato Yamanishi myama...@gmail.com
 mailto:myama...@gmail.com wrote:
 
 Dear SIG members
 
 The proposal prop-114: Modification in the ASN eligibility criteria
 has been sent to the Policy SIG for review.
 
 It  will be presented at the Open Policy Meeting at APNIC 39 in 
 Fukuoka,
 Japan on Thursday, 5 March 2015.
 
 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-114
 
 
 Regards,
 
 Masato
 
 
 
 
 
 ---
 prop-114-v001: Modification in the ASN eligibility criteria
 ---
 
 Proposer: Aftab Siddiqui
 aftab.siddi...@gmail.com
 javascript:_e(%7B%7D,'cvml','aftab.siddi...@gmail.com');
 
Skeeve Stevens
 ske...@eintellegonetworks.com
 javascript:_e(%7B%7D,'cvml','ske...@eintellegonetworks.com');
 
 
 1. Problem statement
 
 
  The current ASN assignment policy dictates two eligibility 
 criteria
  and both should be fulfilled in order to get 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

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

[Owen DeLong]

I don't think your conclusion is supported by the statement from hostmaster...

We don't know of anyone who hasn't reached out to us doesn't mean that nobody 
has reached out to them... It means that they are unaware.

Asking the hostmasters about this issue in the way you did is akin to walking 
into a room full of people and saying Everyone who is not here, please raise 
your hand and concluding from the lack of raised hands that everyone is 
present.

Owen




 On Feb 4, 2015, at 8:09 PM, Dean Pemberton d...@internetnz.net.nz wrote:
 
 So it doesn't look like there is a problem here. 
 
 The hostmasters are clear about the current policy, they explain it to people 
 who contact them. 
 
 Am I missing something?  I'm not at all in favour of policy for policy sake. 
 
 What's the problem statement here?
 
 On Thursday, 5 February 2015, George Kuo geo...@apnic.net wrote:
 Hello Dean,
 
 We are not aware of any potential members who may have decided not to apply 
 for IPv4 addresses or AS numbers based on how they have interpreted the 
 policy wording.
 
 However, we explain the policy criteria to any potential members who do 
 contact APNIC, and those who are not multihoming do not qualify for An IPv4 
 or ASN assignment based on the current policy.
 
 Currently, we don't keep a record of these unsuccessful requests, but
 we can begin to keep records in the future if this information is
 required.
 
 George K
 
 On 4/02/2015 5:13 am, Dean Pemberton wrote:
 Could I ask that the APNIC hostmasters to comment on the following:
 
 Have you ever been made aware of a situation where due of the current
 wording of the relevant clauses in the policy, a member or potential
 member has not made a resource application where they would otherwise
 have been able to?
 
 In other words has the current policy in the eyes of the host masters
 ever been a barrier to entry?
 
 
 
 
 On Wednesday, 4 February 2015, Masato Yamanishi myama...@gmail.com
 mailto:myama...@gmail.com wrote:
 
 Dear SIG members
 
 The proposal prop-114: Modification in the ASN eligibility criteria
 has been sent to the Policy SIG for review.
 
 It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
 Japan on Thursday, 5 March 2015.
 
 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-114
 
 
 Regards,
 
 Masato
 
 
 
 
 
 ---
 prop-114-v001: Modification in the ASN eligibility criteria
 ---
 
 Proposer: Aftab Siddiqui
 aftab.siddi...@gmail.com
 javascript:_e(%7B%7D,'cvml','aftab.siddi...@gmail.com');
 
Skeeve Stevens
 ske...@eintellegonetworks.com
 javascript:_e(%7B%7D,'cvml','ske...@eintellegonetworks.com');
 
 
 1. Problem statement
 
 
  The current ASN assignment policy dictates two eligibility criteria
  and both should be fulfilled in order to get 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.
 
 
 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 removing multi-homing requirement for the
 organization.
 
 
 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
  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 

Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

[Owen DeLong]

 On Feb 3, 2015, at 7:47 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) 
 fujis...@syce.net wrote:
 
 
 Hi Owen, Mike,
 
 Thank you for your comments.
 
 I'm the author of prop-112.
 
 The purpose of this policy proposal is not to align the boundary but
 to utilize unused space. Up to /29 is reserved for each /32 in the
 legacy space.

I understood that from the beginning.

I oppose that purpose.

I would support policy that provided nibble-aligned boundaries.

I hope this is sufficiently clear.

 
 | From: sig-policy-boun...@lists.apnic.net 
 [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong
 | Sent: Wednesday, 4 February 2015 4:05 p.m.
 | To: Masato Yamanishi
 | Cc: sig-policy@lists.apnic.net
 | Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand 
 expansion of IPv6 address allocation size in legacy IPv6 space
 | 
 | I will again oppose this as written. I would much rather see policy deliver 
 nibble-boundary based allocations.
 | 
 | I would rather see such organizations issued new /28s than expand these 
 /32s into /29s.
 
 And renumbering will be necessary for this expansion, and the
 legacy space folders have used their address space for a long time,
 it might be difficult.

No, I am not proposing that anyone be required to renumber. I am proposing 
giving them a second prefix, requesting that they not make any new assignments 
in the old prefix and that when or if it dies of attrition, the old prefix be 
returned.

 Technically, I also think nibble boundary is reasonable, but that
 should be considered in other proposal.

Then I oppose this proposal as written. I made a proposal for nibble 
boundaries, but it was rejected, largely due to misunderstandings and some 
difficulties with power during the meeting where I was presenting the proposal 
remotely.

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-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

[Owen DeLong]

 On Feb 3, 2015, at 8:12 PM, Robert Hudson hud...@gmail.com wrote:
 
 On 4 February 2015 at 14:54, Dean Pemberton d...@internetnz.net.nz 
 mailto:d...@internetnz.net.nz wrote:
 There are a number of things that concern me about this proposal. 
 
 1) it doesn't appear to support needs based allocation
 2) it doesn't support allocation on nibble boundaries which operators have 
 said repeatedly is a major issue. 
 
 As I read it...
 
 The proposal addresses only organisations who already have /32 allocations in 
 the legacy IPv6 block (the IP ranges this includes are defined in the 
 proposal).  The allocation policy in the legacy block was effectively to 
 carve out a /29, but then only provide the applicant with a /32 out of this 
 /29 - meaning the gap between the /29 and the /32 remains un-allocated.

That is correct. However, rather than expanding this swamp, I would support 
issuing additional /28s to these organizations and draining the early 
allocation swamp through attrition.

 Prop-112 simply proposes that the owner of one of these /32 allocations can, 
 if the require it, request to fill out the /29 which is allocated to them 
 in the back-end, so that they end up with a contiguous block of IP address 
 space.  It is not possible to stretch this to a nibble boundary (/28), 
 because the next allocation in the legacy IPv6 block could/would overlap this.

Correct, hence my suggestion that they simply be issued new /28s.

 The proposal does NOT impact /32 allocations that were made since the newer 
 policy of sparse allocation was introduced.  Those are left to be dealt with 
 under the existing rules.
 
 If the proposal is not accepted, the gap between /32 and /29 is wasted for 
 every allocation within the legacy IPv6 block.  This wastes 30,064,771,072 
 /64 networks, unless a policy is proposed and approved to somehow use this 
 address space in another fashion.

Note there are actually multiple blocks as pointed out. Forever is a very long 
time.

The better solution, which does not waste all of them forever, is to allocate 
new /28s to those organizations that need more than a /32 ask that they not 
make any new allocations or assignments within the original /32, and return the 
/32 when or if they ever vacate it through attrition.

For organizations that are lucky enough to have the correct neighbor vacate 
their /32, their prefix could, then, be expanded to a /28 without issue.

Even with this policy, most of that space will remain wasted anyway, it will 
just be wasted in a different place where it can never be used for a different 
purpose.

 I'm happy to be corrected on any of this.  But if my understanding is 
 correct, the benefits of this proposal vastly outweigh any negatives, and I 
 believe SAGE-AU will be supporting it.

They do not, actually. While 30,064,771,072 sounds like a lot of /64s, the 
simple reality is that when you’re handing them out to end-users 65,536 at a 
time and to ISPs 4,294,967,296 at a time (minimum), it’s really not so many. 
When you consider that RIRs are given more than 1024 times that amount of space 
each time they apply to IANA and that no RIR has even come close to needing a 
second /12 from IANA so far, I think it is better to hold that particular space 
in reserve until its current mess is cleaned up through attrition, even if that 
never happens.

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-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

[Owen DeLong]

 On Feb 3, 2015, at 8:12 PM, Robert Hudson hud...@gmail.com 
 mailto:hud...@gmail.com wrote:
 
 On 4 February 2015 at 14:54, Dean Pemberton d...@internetnz.net.nz 
 mailto:d...@internetnz.net.nz wrote:
 There are a number of things that concern me about this proposal. 
 
 1) it doesn't appear to support needs based allocation
 2) it doesn't support allocation on nibble boundaries which operators have 
 said repeatedly is a major issue. 
 
 As I read it...
 
 The proposal addresses only organisations who already have /32 allocations in 
 the legacy IPv6 block (the IP ranges this includes are defined in the 
 proposal).  The allocation policy in the legacy block was effectively to 
 carve out a /29, but then only provide the applicant with a /32 out of this 
 /29 - meaning the gap between the /29 and the /32 remains un-allocated.

That is correct. However, rather than expanding this swamp, I would support 
issuing additional /28s to these organizations and draining the early 
allocation swamp through attrition.

 Prop-112 simply proposes that the owner of one of these /32 allocations can, 
 if the require it, request to fill out the /29 which is allocated to them 
 in the back-end, so that they end up with a contiguous block of IP address 
 space.  It is not possible to stretch this to a nibble boundary (/28), 
 because the next allocation in the legacy IPv6 block could/would overlap this.

Correct, hence my suggestion that they simply be issued new /28s.

 The proposal does NOT impact /32 allocations that were made since the newer 
 policy of sparse allocation was introduced.  Those are left to be dealt with 
 under the existing rules.
 
 If the proposal is not accepted, the gap between /32 and /29 is wasted for 
 every allocation within the legacy IPv6 block.  This wastes 30,064,771,072 
 /64 networks, unless a policy is proposed and approved to somehow use this 
 address space in another fashion.

Note there are actually multiple blocks as pointed out. Forever is a very long 
time.

The better solution, which does not waste all of them forever, is to allocate 
new /28s to those organizations that need more than a /32 ask that they not 
make any new allocations or assignments within the original /32, and return the 
/32 when or if they ever vacate it through attrition.

For organizations that are lucky enough to have the correct neighbor vacate 
their /32, their prefix could, then, be expanded to a /28 without issue.

Even with this policy, most of that space will remain wasted anyway, it will 
just be wasted in a different place where it can never be used for a different 
purpose.

 I'm happy to be corrected on any of this.  But if my understanding is 
 correct, the benefits of this proposal vastly outweigh any negatives, and I 
 believe SAGE-AU will be supporting it.

They do not, actually. While 30,064,771,072 sounds like a lot of /64s, the 
simple reality is that when you’re handing them out to end-users 65,536 at a 
time and to ISPs 4,294,967,296 at a time (minimum), it’s really not so many. 
When you consider that RIRs are given more than 1024 times that amount of space 
each time they apply to IANA and that no RIR has even come close to needing a 
second /12 from IANA so far, I think it is better to hold that particular space 
in reserve until its current mess is cleaned up through attrition, even if that 
never happens.

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] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

[Owen DeLong]

On Sep 17, 2014, at 7:23 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) 
fujis...@syce.net wrote:

 
 Hi Skeeve,
 
 Thank you for your comment!
 
 From: Skeeve Stevens ske...@v4now.com
 Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
 default allocation size (SECURITY=UNCLASSIFIED)
 Date: Thu, 18 Sep 2014 12:02:43 +1000
 
 | So... balancing the two.. I support increasing the standard large
 | allocation to a /28.
 
 I have two concerns. I'm sorry for repeating these.
 
 1. LIRs in legacy space, who has been tackling IPv6 deployment from
   the early stage could not expand their address space to /28. I
   think it's not fair.

LIRs in such a position should be given the following choices:

1.  Expand to a /29 and stay where they are.
2.  Receive a new /28 with no requirement to return their existing 
/32, but a polite request that they do so if
it later becomes vacant and encouragement not to allocate new 
things within the /32.

In this way, I think it can be made perfectly fair.

 2. If we employ 'nibble boundary' allocation for technical reasons,
   the additional subsequent allocation should be /24, /20, and so on.
   It might be meaningless if only first allocation aligns.  To do
   that, I think we need difference proposal since there will be so
   big changes in our policy.

Yes… I agree that this should be done. I would have no problem with that being 
addressed in a separate policy proposal.

 And one more, ARIN implements totally different address allocation
 scheme, which discussed also in our APNIC region as prop-098. I'm not
 sure but nibble boundary allocation scheme will be suitable under that
 policy.

Unfortunately, that discussion was seriously hampered by technical difficulties 
and the author’s inability to be present at the meeting for the discussion. One 
person characterized the proposal as an attempt to tell network operators how 
to run their networks which was completely untrue. It was, as is your proposal, 
an effort to make it easier for operators that wanted to get larger allocations 
(within reason).

Owen

 
 Yours Sincerely,
 --
 Tomohiro Fujisaki
 
 
 From: Skeeve Stevens ske...@v4now.com
 Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 
 default allocation size (SECURITY=UNCLASSIFIED)
 Date: Thu, 18 Sep 2014 12:02:43 +1000
 
 | Elvis,
 | 
 | Owens position has been quite simply explained.
 | 
 | He does NOT oppose the increase in the size of the allocation just just
 | wants it done more cleanly.
 | 
 | Deans argument is that this will potentially waste additional space.
 | 
 | I see, and actually agree with both positions...   I like to conserve
 | address space, but Owens point is very valid... even if 1 million
 | organisations took a /28, it would still make minimal impact on the address
 | space over a significant period.
 | 
 | But, planning for the future is something we should keep in our mind...
 | but, not at the detriment of todays operations.
 | 
 | His point of the number of name servers for reverse delegation for a /29
 | being 8 and a /28 being 1 is quite a compelling reason to increase the
 | default 'larger' allocation to /28.
 | 
 | So... balancing the two.. I support increasing the standard large
 | allocation to a /28.
 | 
 | 
 | ...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 ;  http://twitter.com/networkceoau
 | linkedin.com/in/skeeve
 | 
 | twitter.com/theispguy ; blog: www.theispguy.com
 | 
 | 
 | IP Address Brokering - Introducing sellers and buyers
 | 
 | On 18 September 2014 09:59, Elvis Velea el...@velea.eu wrote:
 | 
 |   Hi Owen,
 | 
 |  what has ARIN to do with the policy in APNIC?
 |  I could also justify my arguments by saying that the RIPE policy allows up
 |  to a /29 per member.. and that policy works very well as well.
 | 
 |  Let's not use other regions' policies to justify disapproval of this
 |  policy proposal. Especially when both ARIN and RIPE have different 
 policies
 |  that work very well.
 | 
 |  I would like to ask you to explain what kind of errors/difficulties may
 |  induce the allocation of a /29 (instead of a /28) in regards to RPKI and
 |  DNSSSEC. I do not really understand that part (sorry, I am not very
 |  technical). If it's fat-fingering you are talking about, that can happen
 |  regardless of the size of the allocation.
 | 
 |  I find it surprising that you oppose to a policy proposal that would allow
 |  members of APNIC to use more IPv6 addresses just because the policy does
 |  not say 'more than more' (/28s instead of /29s).
 | 
 |  cheers,
 |  elvis
 | 
 |  On 18/09/14 09:35, Owen DeLong wrote:
 | 
 |  Absolutely… That is current policy in the ARIN region and it is working
 |  well.
 | 
 |   The reality is that the amount saved by doing non

Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]

[Owen DeLong]

On Sep 3, 2014, at 2:12 PM, Masato Yamanishi myama...@japan-telecom.com wrote:

 Hi Mike,
 
 Thank you for you comment and let me clarify your one point.
 
 On 2014/09/02 16:07, HENDERSON MICHAEL, MR michael.hender...@nzdf.mil.nz 
 wrote:
 
 I do not favour IPv6 allocations on “non-nibble” boundaries, I believe that 
 allocations ought to be made on “nibble” (i.e. 4-bit) boundaries. On that 
 basis, the next allocation larger than /32 would be /28, not /29.
 Address masking and calculation on /29 boundaries will in my view be quite 
 nasty, and the size of the IPv6 address space is sufficiently large that we 
 need not, and therefore should not, impose such inconveniences on ourselves.
  
 Hence, in my IPv6 allocation world, a resource holder who has a demonstrated 
 need (for whatever value of ‘need’ seems appropriate) for address space 
 larger than /32, should be allocated a /28.
 If they are ‘growing’ an existing /32, then the new /28 would very 
 preferably be one that includes the currently-allocated /28.
  
  
 However, I understand the current situation is that the ‘legacy’ IPv6 
 address allocation was for smaller allocations within blocks on /29 
 boundaries, if I read the Proposition correctly.
 As a special case only, I would support the allocation of these ‘legacy /29’ 
 blocks. The provisos being that firstly they do fall into this ‘legacy’ 
 category, and that secondly it is not possible (owing to allocation to a 
 third party) to allocate a /28 to the relevant resource holder
  
  
 
 
 But this proposal is NOT ONLY for the special case.
 Every organizations, which are new comers, “legacy” IPv6 space holder, and 
 existing IPv6 space holder with sparse allocation mechanism,
 will be eligible for /29 by providing necessary information as shown in Sec.4.

Which I believe is a flaw in the proposal.

 
 So, can you share your preference for current proposed text as it is?

I do not support the proposal as written. I would support it if /28s were 
issued whenever possible and /29s were only issued in cases where the existing 
assignment or allocation cannot be expanded to at least /28.

Owen

 
 4. Proposed policy solution
 
 
 - Change the text to 5.2.2 Minimum initial allocation size of
 current policy document as below:
 
 Organizations that meet the initial allocation criteria are
 eligible to receive an initial allocation of /32. The organizations
 can receive up to /29 by providing utilization information of the whole
 address space.
 
 - Add following text in the policy document:
 
 for Existing IPv6 address space holders
 
 LIRs that hold one or more IPv6 allocations are able to request
 extension of each of these allocations up to a /29 without meeting
 the utilization rate for subsequent allocation by explaining
 how the whole address space will be used.
 
 Rgs,
 Masato
 *  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] Returned to SIG: prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure

[Owen DeLong]

On Mar 5, 2014, at 00:09 , Sanjeev Gupta sanj...@dcs1.biz wrote:

 
 On Wed, Mar 5, 2014 at 5:33 AM, Masato Yamanishi myama...@japan-telecom.com 
 wrote:
 Is there anyone who want to continue this proposal?
 
 I read the Transcript, and saw the comment made on the inadvisability of 
 1.2.3.4/24 being used as a DNS resolver.  I am not sure that this concern is 
 either new enough, or severe enough, to substantially cause the proposal to 
 be dropped.
 
 To quote the Transcript:
 
 Yoshinobu Matsuzaki (IIJ): Let me clarify
 
 why I oppose to the prop-110, because
 
 it's creating a new security risk.  Once
 
 the broadband router is set with default
 
 setting, that DNS reserve the 1.2.3.4, if
 
 there's no DNS server maintained by ISP,
 
 probably it's query to the DNS server in
 
 the Internet, and sometimes it's
 
 maintained by good guy, but sometimes it
 
 could be maintained by bad boy.  Right?
 
 
 
 I see two scenarios which might lead to to this objection: (Yamanishi-san, 
 please forward this email to mazz if he is not on this list.  I hope I am not 
 misunderstanding his objections.)
 Consumer Router manufacturers might start hardcode-ing 1.2.3.4 as the default 
 DNS resolver, and this may be someone outside the ISP's network.  I 
 appreciate that this may happen, and I have seen similar things happen re: 
 NTP servers.  I do not, however, think this is either going to be likely, or 
 widespread.  At least in S E Asia, I have not seen any Home Routers with even 
 Google's PDNS hardcoded into them.  As such, I do not think D-Link or Linksys 
 (as an example) is likely to ship devices with 1.2.3.4 as the default.  The 
 support costs for D-Link if this does not work would be prohibitive.
 Second, the Home Device could be re-sold, with 1.2.3.4 as the DNS setup, and 
 the new owner would be unknowingly be using it.  I consider this extremely 
 unlikely to happen accidentally.  The new owner would (unless he had exactly 
 the same ISP and setup) need to review settings, perhaps a factory default.  
 And if he had the same ISP and setup as the previous owner, then there would 
 be no additional danger anyway.
 As such, I am not saying that a bad network operator could not announce 
 1.2.3.4, and wait for people to use him.  I am saying that this is not an 
 additional danger, many people already use 8.8.8.8. and 4.4.2.2, for example, 
 or OpenDNS.  
 
1.2.3.4 is very different from 8.8.8.8 and 4.4.2.2, etc. In the case of the 
former, random advertisements leaking from whoever are expected and normal. 
They should be blocked, but the concept of should in the global routing table 
is an amusing one at best. In the latter case, the routes are expected to come 
from known origin ASNs and a misalignment would be rapidly and easily detected, 
especially one for malicious intent or fraudulent purposes.
 And any person deciding to announce 1.2.3.0/24 to the open network, would 
 have to face a massive traffic storm anyway.  prop-109 by Geoff Huston 
 mentions the traffic flowing to certain easily-remembered ranges.  Assuming 
 that 1.2.3.0/24 gets even 50Mbps of traffic if I announce it to the Internet, 
 that is till still an expensive pipe, and probably not worth it on the 
 off-chance that a random user will use it and allow evil me to redirect him 
 to the particular bank that he is a member of, and which I am forging a 
 website for.
 
Never underestimate the willingness of a malefactor to subject hosts he 
controls (but probably doesn't own) or even hosts he doesn't necessarily 
control to vast quantities of traffic.

 To summarize, there is no ADDITIONAL danger, and there are some advantages to 
 this proposal.  I would like work on this proposal to continue, and see if we 
 can address the concerns raised at the APNIC Meeting.

There are no advantages to this proposal and substantial danger, actually. I 
support dropping 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] Policy documentation feedback requested

[Owen DeLong]

On Feb 17, 2014, at 5:29 PM, Adam Gosling a...@apnic.net wrote:

 Hello Owen
 
 That makes me think of another option I haven’t listed.
 
 We could take the structure outlined in option 4 and put them all in one 
 document. That way we would have all the definitions, goals, and principles 
 information at the beginning of the document and then have three sections 
 IPv4, IPv6, and ASNs.
 

That sounds excellent.

 One of the concerns with option 2 was the way Section 6 swaps back and forth 
 between the three resource types.
 

Agreed.

 So I present Option 5 structure below. It would achieve the goal of one 
 policy document with all its advantages, but keep the various resource policy 
 criteria quite distinct. 

Yes, this.

FWIW, I think this is merely a coincidence, but it is rather convenient that in 
the ARIN NRPM, IPv4 policy is in section 4 and IPv6 policy is in section 6. 
IIRC, Section 5 is ASN policy.

It would certainly be helpful to some of us who work with multiple policy 
frameworks if an effort to harmonize section ordering and numbering to the 
extent possible were made.

Owen

 
 
 ---
 OPTION 5: One Policy Document
 ---
 
 Section 1: Policy Environment
 -
 1.1. Introduction
  Scope of Policy
  Distribution Hierarchy
 1.2. Definitions
  All definitions
 1.3. Policy framework
  Goals  Principles
 1.4. Resource License
  Validity, renewal, recovery
 1.5. Resource Management
  APNIC pool management
  Historical resources
  LIR responsibilities
 1.6. General requirements for requests
 1.7. Resource Transfers
  Intra-Regional transfers IPv4  ASNs
  Inter-RIR transfers IPv4  ASNs
  Historical resources
  Mergers, acquisitions
 1.8. Experimental allocations
 
 
 Section 2: IPv4 Policy
 --
 2.1. IPv4 Resource requests
  Criteria for initial IPv4 delegations
  Criteria for subsequent IPv4 delegations
 2.2. Resource Transfers
  Intra-Regional IPv4 transfers
  Inter-RIR IPv4 transfers
  Historical resources
  Mergers, acquisitions
 
 
 Section 3: IPv6 Policy
 --
 3.1. IPv6 Resource requests
  Criteria for initial IPv6 delegations
  Criteria for subsequent IPv6 allocations
  Criteria for initial IPv6 assignments
  Criteria for subsequent IPv6 assignments
 3.2. Resource Transfers
  Mergers, acquisitions
 3.3. Appendix A : HD-Ratio
 
 
 Section 4: ASN Policy
 -
 4.1. ASN Resource requests
  Criteria for ASN delegations
 4.2. Resource Transfers
  Intra-Regional ASN transfers
  Inter-RIR ASN transfers
  Mergers, acquisitions
 
 
 
 
 
 
 -- 
 Adam Gosling
 Senior Policy Specialist   email: a...@apnic.net
 APNIC  sip:  a...@voip.apnic.net
 http://www.apnic.net   phone:+61 7 3858 3100
 
  * Sent by email to save paper. Print only if necessary.
 
 On 18/02/2014 12:26 am, Owen DeLong o...@delong.com wrote:
 
 I support option 2.
 
 It is hard enough trying to follow the regional policy differences as an 
 international network.
 At least being able to find each regions policies in a single document would 
 be a monumental
 improvement.
 
 Owen
 
 On Feb 16, 2014, at 21:33 , Adam Gosling a...@apnic.net wrote:
 
 Dear Colleagues
 
 Many of you may recall that the APNIC Secretariat has been working
 toward a restructure of the policy documents that govern the management
 of resources in the region.
 
 Last March, I circulated a draft document that merged all seven policy
 documents into one policy manual. The email containing the links to
 those drafts is available here:
 
 http://mailman.apnic.net/mailing-lists/sig-policy/archive/2013/03/msg2.html
 
 Since then I have had some feedback that some may find a different 
 approach easier. Accordingly, I have identified below, a series of four
 options. These range from no change - maintain the seven separate 
 documents, to keeping three or four documents.
 
 To give a sense of what this might look like, I've pasted a likely Table
 of Contents for each policy according to the structure of each option.
 
 I can discuss this in more detail at APNIC 37, but the idea is to either
 put all policies together in one policy manual, or to maintain separate
 IPv4, IPv6, and AS number documents.
 
 I look forward to feedback and opinions from community members, either
 on this list, or at the meeting.
 
 Kind Regards,
 
 Adam
 
 
 -- 
 Adam Gosling
 Senior Policy Specialist   email: a...@apnic.net
 APNIC  sip:  a...@voip.apnic.net
 http://www.apnic.net   phone:+61 7 3858 3100
 
  * Sent by email to save paper. Print only if necessary