Nope - Your other email didn't provide any reasons which weren't covered by Philips answer.

If you have a peering session to two or more ASNs you are multihomed and you qualify.
If you only peer with one ASN then you can do this with a private ASN.
If you want to make a change and move from a single peer to more than one then you get quickly get an ASN.  
You can even get them in advance of a planned network change as seen in the current policy snippet below

"An organization will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN (or within a reasonably short time thereafter)."

No need to change policy.



--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
dean@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.

On Wed, Feb 25, 2015 at 9:09 PM, Skeeve Stevens <skeeve@v4now.com> wrote:
Please see my other email Phil.. there is very valid reasons for this policy change.


...Skeeve

Skeeve Stevens - Senior IP Broker
v4Now - an eintellego Networks service
IP Address Brokering - Introducing sellers and buyers

On Wed, Feb 25, 2015 at 4:25 PM, Philip Smith <pfsinoz@gmail.com> wrote:
Dean Pemberton wrote on 25/02/2015 15:06 :
> 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.

Same, I simply don't understand what problem is trying to be solved here.

If an organisation is connected to only one other organisation, there is
no need for an ASN. If these two orgs want to use BGP, that's a private
matter, and is what private ASNs are for - and there are now around 1
billion of those.

If an organisation needs to connect to at least two other ASNs, then
they qualify under the APNIC definition which Guanliang shared.

philip
--

>
> I do not support the proposal
>
>
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> dean@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 <gpan@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-bounces@lists.apnic.net [mailto:sig-policy-bounces@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)
>> dean@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 <owen@delong.com> wrote:
>>>
>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton <dean@internetnz.net.nz> wrote:
>>>>
>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong <owen@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 that in general, the larger the group you are attempting to discuss strategy with, the smaller the chunks necessary for a useful outcome.
>>>
>>> YMMV.
>>>
>>>> We are seeing small proposals purporting to talk about multihoming,
>>>> but what they are in essence talking about is the much larger topic
>>>> of the removal of demonstrated need (as Aftab's clarification in the
>>>> other thread confirms beyond doubt.)
>>>
>>> Upon which clarification, you will notice that I switched to outright opposition to that policy. Frankly, you caught a subtlety in the language that I missed where I interpreted the proposal to still require justified need rather than mere announcement, but a careful re-read and the subsequent clarification of intent made it clear that I had erred.
>>>
>>> Further, note that I have always opposed this proposal as written, but offered as an alternative a much smaller change which I felt met the intent stated by the proposer without the radical consequences you and I both seem to agree are undesirable.
>>>
>>>> There is danger in the death by a thousand cuts.  Many times you
>>>> can't see the unintended consequences until you are already down the
>>>> track of smaller simpler policy changes.
>>>
>>> I really don’t think that is a risk in this case.
>>>
>>>> As we are in Japan I offer a haiku:
>>>>
>>>> A frog in water
>>>> doesn’t feel it boil in time.
>>>> Do not be that frog.
>>>>
>>>> (http://en.wikipedia.org/wiki/Boiling_frog)
>>>
>>> I wish I could be at the meeting, but, alas, I’m here in the US looking on from afar.
>>>
>>> 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
> *              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