Re: [sig-policy] IANA Recovered Space
Dear Aftab, I can confirm these are the IPv4 ranges APNIC received from IANA recovered pool in 2018. Kind regards, Guangliang Pan (Benny) Registration Services Manager, APNIC Email: g...@apnic.net<mailto:g...@apnic.net> Phone: +61 7 3858 3188 From: sig-policy-boun...@lists.apnic.net On Behalf Of Aftab Siddiqui Sent: Sunday, 24 February 2019 12:53 PM To: mailman_SIG-policy Subject: [sig-policy] IANA Recovered Space Dear APNIC Secretariat, Can you please confirm if this is what APNIC got from IANA recovered pool in 2018. 160.238.0.0/24<http://160.238.0.0/24> APNIC 2018-03 192.26.110.0/24<http://192.26.110.0/24> APNIC 2018-03 192.75.137.0/24<http://192.75.137.0/24> APNIC 2018-03 192.135.99.0/24<http://192.135.99.0/24> APNIC 2018-03 192.145.228.0/23<http://192.145.228.0/23> APNIC 2018-03 192.156.144.0/24<http://192.156.144.0/24> APNIC 2018-03 192.156.220.0/24<http://192.156.220.0/24> APNIC 2018-03 192.197.113.0/24<http://192.197.113.0/24> APNIC 2018-09 199.212.57.0/24<http://199.212.57.0/24> APNIC 2018-09 204.52.191.0/24<http://204.52.191.0/24> APNIC 2018-09 192.51.188.0/24<http://192.51.188.0/24> APNIC 2018-09 Regards, 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
Re: [sig-policy] Information Required for new policy proposal
Dear Rajesh, APNIC started making delegations from its final 103/8 IPv4 pool on 18 April 2011. So far, APNIC have delegated 45001 /24s (68.67%) of the final 103/8 pool. As of this date, 20535 /24s (33.13%) still remaining in the final 103/8 pool to be delegated. APNIC delegated the first IPv6 block on 13 August 1999. As of this date, 3887 (57.77%) APNIC direct members have received IPv6 delegations. 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 - From: sig-policy-boun...@lists.apnic.net <sig-policy-boun...@lists.apnic.net> On Behalf Of Rajesh Panwala Sent: Monday, 19 March 2018 7:26 PM To: mailman_SIG-policy <sig-pol...@apnic.net> Subject: [sig-policy] Information Required for new policy proposal Dear APNIC Team, Request you to provide following instruction, to create a policy proposal , as discussed during last policy meeting at Kathmandu. 1. Since when APNIC is allocating IPs from last 103/8 pool ? 2. How many /24 blocks are already allocated. 3. When did APNIC started allocating IPv6 blocks ? 4. How many member organizations have already got allocation ? This may help us in drafting a proposal. Thanking you in anticipation. Regards, Rajesh Panwala For Smartlink Solutions Pvt. Ltd. +91-9227886001. * 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-123-v001: Modify 103/8 IPv4 transfer policy
; >>> https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt >>> >>> --- >>> >>> prop-123-v001: Modify 103/8 IPv4 transfer policy >>> >>> --- >>> >>> Proposer:Alex Yang >>> yang...@126.com >>> >>> >>> 1. Problem statement >>> --- >>> >>> Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses >>> in the final /8 block reached consensus at the APNIC 44 AMM on 14 >>> Sep 2017. Since that APNIC has stopped all the IPv4 transfers from >>> 103/8 block if the delegation date is less than 5 years. >>> >>> However, some of the 103/8 ranges were delegated before 14 Sep 2017. >>> Those resources should not be subjected to 5 years restriction. The >>> community was not aware of the restriction when they received those >>> resources, some of the resources have been transferred or planning >>> to transfer. If APNIC is not allow those transfers to be registered, >>> there will be underground transfers. This will cause incorrect APNIC >>> Whois data. >>> >>> >>> 2. Objective of policy change >>> --- >>> >>> To keep the APNIC Whois data correct. >>> >>> >>> 3. Situation in other regions >>> --- >>> >>> No such situation in other regions. >>> >>> >>> 4. Proposed policy solution >>> --- >>> >>> ?Prohibit transfer IPv4 addresses under final /8 address block >>> (103/8) which have not passed five years after its allocation/assignment? >>> should only apply to those ranges were delegated from APNIC since 14 >>> Sep 2017. >>> >>> >>> 5. Advantages / Disadvantages >>> --- >>> >>> Advantages: >>> >>> - Allow APNIC to register those 103/8 transfers to keep the APNIC >>> Whois data correct. >>> >>> >>> Disadvantages: >>> >>> None. >>> >>> >>> 6. Impact on resource holders >>> --- >>> >>> Resource holders are allowed to transfer 103/8 ranges if the >>> resources were delegated before 14 Sep 2017. >>> >>> >>> >>> 7. References >>> --- >>> >>> >>> * 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 >> > > -- next part -- An HTML attachment was scrubbed... URL: <http://mailman.apnic.net/mailing-lists/sig-policy/attachments/20180129/13c4 1d4f/attachment.html> -- Message: 2 Date: Mon, 29 Jan 2018 13:12:33 +0500 From: "Yasir Shamim, Muhammad" <yasir.sha...@cyber.net.pk> To: <sig-policy@lists.apnic.net> Subject: [sig-policy] sig-policy Digest, Vol 164, Issue 7 Message-ID: <01fc01d398d8$eb05a550$c110eff0$@cyber.net.pk> Content-Type: text/plain; charset="US-ASCII" Hi APNIC Secretariat How many transfers will be affected by prop-116-v006, since 14th Sep 2017 ? Regards Muhammad Yasir Shamim -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of sig-policy-requ...@lists.apnic.net Sent: Monday, January 29, 2018 11:44 AM To: sig-policy@lists.apnic.net Subject: sig-policy Digest, Vol 164, Issue 7 Send sig-policy mailing list submissions to sig-policy@lists.apnic.net To subscribe or unsubscribe via the World Wide Web, visit https://mailman.apnic.net/mailman/listinfo/sig-policy or, via email, send a message with subject or body 'help' to sig-policy-requ...@lists.apnic.net You can reach the perso
Re: [sig-policy] prop-118-v001: No need policy in APNIC region
Hi David, Thanks for your clarifications. See you at the APNIC 43 soon. Best regards, Guangliang == From: David Hilario [mailto:d.hila...@laruscloudservice.net] Sent: Tuesday, 21 February 2017 5:30 PM To: Guangliang Pan Cc: sig-pol...@apnic.net Subject: Re: [sig-policy] prop-118-v001: No need policy in APNIC region 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<tel:+852%202988%208918> m: +359 89 764 1784<tel:+359%2089%20764%201784> f: +852 29888068<tel:+852%202988%208068> a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR w: laruscloudservice.net/uk<http://laruscloudservice.net/uk> e: d.hila...@laruscloudservice.net<mailto:d.hila...@outsideheaven.com> On 21 February 2017 at 05:38, Guangliang Pan <g...@apnic.net<mailto:g...@apnic.net>> 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<mailto:g...@apnic.net> SIP: g...@voip.apnic.net<mailto:g...@voip.apnic.net> Phone: +61 7 3858 3188<tel:+61%207%203858%203188> http://www.apnic.net - * You can now call APNIC Helpdesk for free using Skype. For more information visit: www.apnic.net/helpdesk<http://www.apnic.net/helpdesk> From: sig-policy-boun...@lists.apnic.net<mailto:sig-policy-boun...@lists.apnic.net> [mailto:sig-policy-boun...@lists.apnic.net<mailto:sig-policy-boun...@lists.apnic.net>] On Behalf Of David Hilario Sent: Friday, 17 February 2017 12:17 AM To: sig-pol...@apnic.net<mailto:sig-pol...@apnic.net> Subject: Re: [sig-policy] prop-118-v001: No need policy in APNIC region Dear list, We are only a few days away from the meeting in Saigon. There has been no opposition to the policy, but only very little support as well. As the proposer of this policy I would like to know if there is interest in streamlining the policy a bit in order to make transfers between two regions more compatible, it is really more of a small patch the way I see it. Any opposition to it is very much welcome too, only the "positive" sides were really investigated and I would gladly hear any opposition to it as well as any support. David Hilario IP Manager Larus Cloud Service Limited p: +852 29888918<tel:+852%202988%208918> m: +359 89 764 1784<tel:+359%2089%20764%201784> f: +852 29888068<tel:+852%202988%208068> a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR w: laruscloudservice.net/uk<http://laruscloudservice.net/uk> e: d.hila...@laruscloudservice.net<mailto:d.hila...@outsideheaven.com> * 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] Requirements for Subsequent ASN Requests
Hi Skeeve, I don’t think the current policy mention about subsequent ASN assignment. Every ASN assignment is requested to meet the multihoming requirement. For additional ASN requests, the requestors have to provide justification to show that their new AS is independent to their existing AS. They should have different routing policies and announce different IP address ranges. Best regards, Guangliang = From: Skeeve Stevens [mailto:ske...@v4now.com] Sent: Thursday, 26 February 2015 10:16 AM To: sig-policy@lists.apnic.net Cc: Guangliang Pan Subject: Requirements for Subsequent ASN Requests 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.commailto:ske...@v4now.com ; www.v4now.comhttp://www.v4now.com/ Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4nowhttp://facebook.com/v4now ; linkedin.com/in/skeevehttp://linkedin.com/in/skeeve twitter.com/theispguyhttp://twitter.com/theispguy ; blog: www.theispguy.comhttp://www.theispguy.com/ [Image removed by sender.] IP Address Brokering - Introducing sellers and buyers * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Hi Dean, If they meet the policy requirement and no payment requested, they normally will receive an ASN in the next working day. Thanks, Guangliang On 25 Feb 2015, at 6:36 pm, Dean Pemberton d...@internetnz.net.nz wrote: Thanks for that Guangliang. Thats really helped to clarify the position here. Another question. Whats the normal time lag between a member applying for an ASN (assuming that all the information is present and correct) and it being allocated? 1 day? 1 week? 1 month? I'm trying to gauge if it really takes longer to apply for an ASN than it does to arrange and configure a BGP peering session. Thanks Dean -- 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Hi Gaurab, If they can provide 2 peer ASNs in their application, based on the policy they can receive an ASN assignment. Regards, Guangliang On 25 Feb 2015, at 6:10 pm, Gaurab Raj Upadhaya gau...@lahai.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guangliang, can you clarify these questions for me. If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ? - -gaurab On 2/25/15 4:05 AM, Guangliang Pan 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 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Hi Skeeve, I don't think we have a policy to reclaim those AS Numbers. Regards, Guangliang On 25 Feb 2015, at 7:57 pm, Skeeve Stevens ske...@v4now.commailto:ske...@v4now.com wrote: Guangliang, What are the rules about someone with a ASN, later de-multi-homing? ...Skeeve Skeeve Stevens - Senior IP Broker v4Now - an eintellego Networks service ske...@v4now.commailto:ske...@v4now.com ; www.v4now.comhttp://www.v4now.com/ Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4nowhttp://facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeevehttp://linkedin.com/in/skeeve twitter.com/theispguyhttp://twitter.com/theispguy ; blog: www.theispguy.comhttp://www.theispguy.com/ [http://eintellegonetworks.com/logos/v4now-web05.png] IP Address Brokering - Introducing sellers and buyers On Wed, Feb 25, 2015 at 6:53 PM, Guangliang Pan g...@apnic.netmailto:g...@apnic.net wrote: Hi Gaurab, If they can provide 2 peer ASNs in their application, based on the policy they can receive an ASN assignment. Regards, Guangliang On 25 Feb 2015, at 6:10 pm, Gaurab Raj Upadhaya gau...@lahai.commailto:gau...@lahai.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guangliang, can you clarify these questions for me. If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ? - -gaurab On 2/25/15 4:05 AM, Guangliang Pan 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.netmailto:sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.netmailto: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.netmailto: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.nzmailto: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.commailto:o...@delong.com wrote: On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nzmailto:d...@internetnz.net.nz wrote: On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.commailto: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
