Re: [sig-policy] Prop-114: Modification in the ASN eligibility criteria - explanation.
What he said... Mark. On 28/Feb/15 05:25, David Huberman wrote: Hello, [Please pardon the top posting. I am on a mobile device.] Regarding your sentence: Any subsequent allocations [of an AS number] would fall under the same criteria, plus the extra burden of justification by the secretariat to justify additional ASNs. I humbly request the draft policy authors, the working group community, and the APNIC staff to think carefully about how such policy language will be written, and how such a policy would be implemented. My experiences have taught me that the answer to the question, why do you need an additional AS number? is not easily captured in either policy language or RIR procedures. Why? Because networks are not all built the same. In well-known situations, there are both regulatory and market-based forces which sometimes back network operators into engineering designs which lack polish. Secondly, network architects like to apply creative solutions to complex situations. What this means in the real world of network operations is that just because you would design Network X to use one AS number doesn't mean I designed it that way; my solution calls for two or three AS numbers. And this is important because the RIR (in both its AS number policies and its internal procedures for reviewing requests) needs to recognize that when a network operator states he needs an additional AS number, he probably does. Most importantly, the RIR staff should not be put in a position to have to fully understand a network architecture and be required to adjudicate its worthiness for an additional AS number. Thank you for any consideration you can give to this matter, and I look forward to our discussions this week in Fukuoka. David R Huberman Microsoft Corporation Principal, Global IP Addressing *From:* sig-policy-boun...@lists.apnic.net sig-policy-boun...@lists.apnic.net on behalf of Skeeve Stevens ske...@v4now.com *Sent:* Friday, February 27, 2015 5:45:12 PM *Cc:* sig-policy@lists.apnic.net *Subject:* [sig-policy] Prop-114: Modification in the ASN eligibility criteria - explanation. Hi all, Having read (most of) the feedback, Aftab and I will be putting a new version out probably either late Sunday or Early Monday. I am at Haneda Airport flying to Fukuoka now and Aftab arrives in Tokyo and I believe will be arriving tomorrow morning. Once we've had time to confer, we will issue new wording. The object of this policy is to remove the need to be multi-homed to get your */initial/* ASN. It is not designed to hand out ASN's like candy, not provide them to people who have no intention of multi-homing. It is designed for those who wish to announce their portable ranges via their own ASN using whatever routing policy they determine to be appropriate for the operation of their network, but removing the requirement to be immediately multi-homed, but having the intention to multi-home at some point (the timeframe should not be mandated) - whether that be permanently or not is not relevant. Any subsequent allocations would fall under the same criteria, plus the extra burden of justification by the secretariat to justify additional ASN's. The wording will be based around the above. The cases for this policy are numerous and the reasons Aftab and I are doing this together is to address several of them. - Entities not meeting the multi-homing criteria due to economic circumstances, regional access, etc. - Smaller entities, such as businesses with portable address space that would like more control and flexibility over how they announce their networks, and plan for multi-homing either as a future facility or for cloud/elastic on demand purposes. The major use case from my perspective is: - Due to IP runout (ISPs having less and charging more), and some requirements for being portable, I am assisting *many* businesses become APNIC members and their own address space. Many of these initially are not multi-homed, but are planning to in the short period as they consider the elastic infrastructure available to them over new initiatives like Megaport and others - where layer 2, BGP to many 'service' providers is the new way of doing business. I did a presentation on Megaport and Elastic X-Connect Fabrics at the last APNIC in Brisbane for those who saw it. In Australia (and I am sure other places too), there is the new concept of opportunistic capacity - being able to buy transit on an as-needs basis for any determined time period... 1 week, 1 day, even hourly. An operator might be single homed, but may wish to bring on elastic/On Demand transit capacity for short periods of time - at which point the would be multi-homed, but then disconnect and then be single-homed again. Here is a news article about this offering:
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
HI Dean, here's the finding. Mind you I spoke mostly to existing members. we should probably ask prospective members too. - Not all ISP provides (or those who do only do so very selectively) BGP connection service - Lack of carrier neutral IXPs in some economies - Limited networking knowledge and skills Cheers, Sanjaya -Original Message- From: Dean Pemberton [mailto:d...@internetnz.net.nz] Sent: Saturday, 28 February 2015 10:57 AM To: Sanjaya Sanjaya Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Thanks Sanjaya The last slide asks some questions. What were the answers from the audiences you were presenting to? -- 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 Sat, Feb 28, 2015 at 9:02 AM, Sanjaya Sanjaya sanj...@apnic.net wrote: Hi all, I'm neither for nor against the proposal. As an additional information I'd like to share a presentation that I made early last year about ASNs in the Asia Pacific region, when I visited a few operators in China. While it highlighted the relatively low use of ASNs in AP region compared to Europe and North America, it didn't put blame on allocation policy. But could or should the policy help? I don't know. It's up to the community to decide. We've had a very good discussion so far. Thanks! Cheers, Sanjaya --- Deputy Director General, APNIC * 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] Prop-114: Modification in the ASN eligibility criteria - explanation.
Hello, [Please pardon the top posting. I am on a mobile device.] Regarding your sentence: Any subsequent allocations [of an AS number] would fall under the same criteria, plus the extra burden of justification by the secretariat to justify additional ASNs. I humbly request the draft policy authors, the working group community, and the APNIC staff to think carefully about how such policy language will be written, and how such a policy would be implemented. My experiences have taught me that the answer to the question, why do you need an additional AS number? is not easily captured in either policy language or RIR procedures. Why? Because networks are not all built the same. In well-known situations, there are both regulatory and market-based forces which sometimes back network operators into engineering designs which lack polish. Secondly, network architects like to apply creative solutions to complex situations. What this means in the real world of network operations is that just because you would design Network X to use one AS number doesn't mean I designed it that way; my solution calls for two or three AS numbers. And this is important because the RIR (in both its AS number policies and its internal procedures for reviewing requests) needs to recognize that when a network operator states he needs an additional AS number, he probably does. Most importantly, the RIR staff should not be put in a position to have to fully understand a network architecture and be required to adjudicate its worthiness for an additional AS number. Thank you for any consideration you can give to this matter, and I look forward to our discussions this week in Fukuoka. David R Huberman Microsoft Corporation Principal, Global IP Addressing From: sig-policy-boun...@lists.apnic.net sig-policy-boun...@lists.apnic.net on behalf of Skeeve Stevens ske...@v4now.com Sent: Friday, February 27, 2015 5:45:12 PM Cc: sig-policy@lists.apnic.net Subject: [sig-policy] Prop-114: Modification in the ASN eligibility criteria - explanation. Hi all, Having read (most of) the feedback, Aftab and I will be putting a new version out probably either late Sunday or Early Monday. I am at Haneda Airport flying to Fukuoka now and Aftab arrives in Tokyo and I believe will be arriving tomorrow morning. Once we've had time to confer, we will issue new wording. The object of this policy is to remove the need to be multi-homed to get your initial ASN. It is not designed to hand out ASN's like candy, not provide them to people who have no intention of multi-homing. It is designed for those who wish to announce their portable ranges via their own ASN using whatever routing policy they determine to be appropriate for the operation of their network, but removing the requirement to be immediately multi-homed, but having the intention to multi-home at some point (the timeframe should not be mandated) - whether that be permanently or not is not relevant. Any subsequent allocations would fall under the same criteria, plus the extra burden of justification by the secretariat to justify additional ASN's. The wording will be based around the above. The cases for this policy are numerous and the reasons Aftab and I are doing this together is to address several of them. - Entities not meeting the multi-homing criteria due to economic circumstances, regional access, etc. - Smaller entities, such as businesses with portable address space that would like more control and flexibility over how they announce their networks, and plan for multi-homing either as a future facility or for cloud/elastic on demand purposes. The major use case from my perspective is: - Due to IP runout (ISPs having less and charging more), and some requirements for being portable, I am assisting many businesses become APNIC members and their own address space. Many of these initially are not multi-homed, but are planning to in the short period as they consider the elastic infrastructure available to them over new initiatives like Megaport and others - where layer 2, BGP to many 'service' providers is the new way of doing business. I did a presentation on Megaport and Elastic X-Connect Fabrics at the last APNIC in Brisbane for those who saw it. In Australia (and I am sure other places too), there is the new concept of opportunistic capacity - being able to buy transit on an as-needs basis for any determined time period... 1 week, 1 day, even hourly. An operator might be single homed, but may wish to bring on elastic/On Demand transit capacity for short periods of time - at which point the would be multi-homed, but then disconnect and then be single-homed again. Here is a news article about this offering: http://www.itwire.com/business-it-news/networking/65730-intabank-partners-with-megaport Megaport is across Australia ,Singapore, Hong Kong, New Zealand and heading for the US and Europe - as well as
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On 28/Feb/15 03:08, David Farmer wrote: If you only look at it through the lens of the current multi-homing requirement for an ASN then you don't need it, it is totally anticipatory and only a future need, but that is self-fulfilling. I'm suggesting that multi-homing is too narrow of a definition of need for an ASN. The PI assignment and what every justified that should also equally justify the need for ASN assignment. The PI assignment was intended to be portable, also assigning an ASN simply is intended to facilitate that portability. I'm saying that the need for portability is also a need for an ASN, if you look beyond multi-homing. True, PI is meant to be portable, which is fine for IPv6 because we have a lot of address space. But don't you worry that you will blow through 4.2 billion ASN's soon if PI allocation policy evolves to become liberal that 4.2 billion PI allocations become a reality? 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On 28/Feb/15 03:56, Sanjaya Sanjaya wrote: HI Dean, here's the finding. Mind you I spoke mostly to existing members. we should probably ask prospective members too. - Not all ISP provides (or those who do only do so very selectively) BGP connection service - Lack of carrier neutral IXPs in some economies - Limited networking knowledge and skills All of which are normal states of the Internet. 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On Feb 27, 2015, at 00:22, Dean Pemberton d...@internetnz.net.nz wrote: I'm sure Skeeve also thinks that organisations should be able to get all the IP addresses they might ever need all on day one. I'm sure he even knows a company who could arrange that for them. Well our IPv4 policies are explicitly designed to not provide all the IPv4 addresses an organization needs. Where as with IPv6 that is at least possible, maybe not forever, but there is a goal of 5 to 10 years or more for an initial allocation. Lets see where the community thinks this should go. It still sounds like unlimited ASNs for anyone who thinks they might like to have them. Great business for anyone clipping the ticket on the transaction. Now that we that have 4 billion ASNs, maybe we should reexamine our policy goals for ASNs, at least compared to when we only had 65 thousand ASNs. If we are willing to give an organization a routing slot with IPv4 or IPv6 PA or PI address block, why wouldn't we be willing to give them a ASN too? I would want them to provide additional justification why they need a second ASN, but the mere fact we gave then a PA or PI address block is probably sufficient justification for their first ASN. The reverse is also probably also true, if we are NOT willing to give them a routing slot, we probably should NOT be willing to give them an ASN either, at least without additional justification like multi-homing. -- 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. -- === David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 === * 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
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
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
So a maybe someday ASN? So anyone who has PI space and doesn't already have an ASN gets allocated one regardless of need. Any new member who gets PI space gets an ASN allocated as a matter of course. Any additional ASN requested by a member must conform to existing policy. Is this where we're at? Change the proposal and see where we get to. Why not make it your APNIC membership number and be done with it :). That lowers the barrier even further and means that people wouldn't need assistance applying for them. On Saturday, 28 February 2015, Owen DeLong o...@delong.com wrote: On Feb 27, 2015, at 01:43 , Izumi Okutani iz...@nic.ad.jp javascript:; 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 javascript:; http://mailman.apnic.net/mailman/listinfo/sig-policy -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
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. Also, a lot of times organisations get more than one Internet link (for redundancy etc) from the same provider so theoretically they are not multihomed as they use the same provider. I am not sure if the current proposal allows for assignment of a public ASN for the above situation? If not, then this should be brought into scope because controlling traffic and AS-loops using private ASNs becomes challenging for organisations that have single-homed-but-multiple-links-to-same-provider-scenarios Regards, Usman On 27 Feb 2015, at 5:10 pm, Skeeve Stevens ske...@v4now.com wrote: This is where the big different in philosophy is. I want to be able to choose to get an ASN and ready my network to be multi-homed - 'at some point' Dean says do it with private ASN and then reconfigure your network when you are ready. Frankly, I still think this is telling me how to plan the building of my networks - and telling me when I should do the work. ...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 27, 2015 at 2:43 PM, Dean Pemberton d...@internetnz.net.nz wrote: It did say immediate future. I would say that it seems reasonable that if you're claiming that you're going to multihome in the immediate future that you would know the ASNs with whom you were going to peer. If it was more of a Well at some point we might want to multihome, then you might not know the ASN. But in those situations RFC1930 says that you should be using a private AS until such time as you are closer to peering. 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 Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: Hi Guangliang, The option b is acceptable. b. If an applicant can demonstrate a plan to be multihomed in immediate future, it is not a must they are physically multihomed at the time of submitting a request But even then applicant has to provide the details of those ASN with whom they may or may not multhome in future. right? Regards, Aftab A. Siddiqui * 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
How so? If not, then this should be brought into scope because controlling traffic and AS-loops using private ASNs becomes challenging for organisations that have single-homed-but-multiple-links-to-same-provider-scenarios Regards, Usman On 27 Feb 2015, at 5:10 pm, Skeeve Stevens ske...@v4now.com javascript:_e(%7B%7D,'cvml','ske...@v4now.com'); wrote: This is where the big different in philosophy is. I want to be able to choose to get an ASN and ready my network to be multi-homed - 'at some point' Dean says do it with private ASN and then reconfigure your network when you are ready. Frankly, I still think this is telling me how to plan the building of my networks - and telling me when I should do the work. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.com javascript:_e(%7B%7D,'cvml','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 Fri, Feb 27, 2015 at 2:43 PM, Dean Pemberton d...@internetnz.net.nz javascript:_e(%7B%7D,'cvml','d...@internetnz.net.nz'); wrote: It did say immediate future. I would say that it seems reasonable that if you're claiming that you're going to multihome in the immediate future that you would know the ASNs with whom you were going to peer. If it was more of a Well at some point we might want to multihome, then you might not know the ASN. But in those situations RFC1930 says that you should be using a private AS until such time as you are closer to peering. Dean -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz javascript:_e(%7B%7D,'cvml','d...@internetnz.net.nz'); To promote the Internet's benefits and uses, and protect its potential. On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui aftab.siddi...@gmail.com javascript:_e(%7B%7D,'cvml','aftab.siddi...@gmail.com'); wrote: Hi Guangliang, The option b is acceptable. b. If an applicant can demonstrate a plan to be multihomed in immediate future, it is not a must they are physically multihomed at the time of submitting a request But even then applicant has to provide the details of those ASN with whom they may or may not multhome in future. right? Regards, Aftab A. Siddiqui * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','sig-policy@lists.apnic.net'); http://mailman.apnic.net/mailman/listinfo/sig-policy -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On 2015/02/27 18:16, Mark Tinka wrote: On 27/Feb/15 10: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. Also, a lot of times organisations get more than one Internet link (for redundancy etc) from the same provider so theoretically they are not multihomed as they use the same provider. BGP does not concern itself with how many links it is running over. Networks on the Internet have no idea how many links exist between you and your service provider(s). All they see is the NLRI your network purports to originate. So really, being multi-homed has little bearing on how many links you have to one or more providers, but rather with how many different providers you share your routing policy with. In BGP's mind (and in the classic definition of multi-homing as our community understands it today), you could have 100x links to the same ISP, but to the world, you still appear to be behind a single ISP, not behind 100x links. Indeed. If we look at the definition of multihoming on APNIC Guangliang have shared on this mailing list, it doesn't specify how many links and it defines criteria based on ASNs. 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. Izumi * 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
That was bad planning :(. I was thinking of doing a lightening, but policy is more important. ...Skeeve On Saturday, February 28, 2015, Dean Pemberton d...@internetnz.net.nz wrote: We have the first policy sig session on at the same time as the Lightning talks on Thursday. It will be interesting to see which attracts more operators. On Saturday, 28 February 2015, Jessica Shen shen...@cnnic.cn javascript:_e(%7B%7D,'cvml','shen...@cnnic.cn'); wrote: Owen, What do you mean by 'If it’s _THE_ track at that time'? Jessica Shen -原始邮件- 发件人: Owen DeLong o...@delong.com 发送时间: 2015-02-28 05:33:59 (星期六) 收件人: Shen Zhi shen...@cnnic.cn 抄送: Mark Tinka mark.ti...@seacom.mu, sig-policy@lists.apnic.net 主题: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria 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 -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz javascript:_e(%7B%7D,'cvml','d...@internetnz.net.nz'); To promote the Internet's benefits and uses, and protect its potential. -- ...Skeeve (from an iPhone 6 Plus) * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
That's what we strive for. Something for everyone :) On Saturday, 28 February 2015, Skeeve Stevens ske...@eintellegonetworks.com wrote: That was bad planning :(. I was thinking of doing a lightening, but policy is more important. ...Skeeve On Saturday, February 28, 2015, Dean Pemberton d...@internetnz.net.nz javascript:_e(%7B%7D,'cvml','d...@internetnz.net.nz'); wrote: We have the first policy sig session on at the same time as the Lightning talks on Thursday. It will be interesting to see which attracts more operators. On Saturday, 28 February 2015, Jessica Shen shen...@cnnic.cn wrote: Owen, What do you mean by 'If it’s _THE_ track at that time'? Jessica Shen -原始邮件- 发件人: Owen DeLong o...@delong.com 发送时间: 2015-02-28 05:33:59 (星期六) 收件人: Shen Zhi shen...@cnnic.cn 抄送: Mark Tinka mark.ti...@seacom.mu, sig-policy@lists.apnic.net 主题: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria 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 -- -- 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. -- ...Skeeve (from an iPhone 6 Plus) -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On 28/Feb/15 02:02, Sanjaya Sanjaya wrote: Hi all, I'm neither for nor against the proposal. As an additional information I'd like to share a presentation that I made early last year about ASNs in the Asia Pacific region, when I visited a few operators in China. While it highlighted the relatively low use of ASNs in AP region compared to Europe and North America, it didn't put blame on allocation policy. But could or should the policy help? I don't know. It's up to the community to decide. We've had a very good discussion so far. Thanks! I think this highlights the issue in question - there need not be any linear relationship between IP addressing and ASN routing. Service providers (and end users) simply care about being online. The biggest issue around that is how devices can be uniquely addressed on the Internet, more so for China given how many they are as a populace, and how many IPv4 addresses are (not) left for them to chew on. If a service provider can fix their most pressing issue, which is a lack of IP addresses, that might rate higher in priority than needing an ASN if they do not necessarily have a need to define their routing policy separate from their ISP's or the rest of the Internet. My concern with issuing an ASN to anyone that obtains PI space is that PI space can be obtained both by service providers and non-service providers. Are we saying that a mom-and-pop shop that qualifies for PI should also get an ASN? If, for some reason, technology suggests that every mobile phone needs PI space because we've got tons of it in IPv6, and RIR policy is updated to cover such use-cases, suddenly, 4.2 billion ASN's does not seem like a lot anymore. I suppose the issue here is that as many billions as the resources are, they are still finite. We do not know what might increase their rate of take-up in the future, but if history is anything to go by, the opportunity is always there. So allocating ASN's just because is something I do not support, as an up coming enterprise that needs IPv6 PI space may not have a need to advertise their routing policy to the Internet, because they are a simple shop who rely on their ISP for all their routing. 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
In addition, to clariry, I didn't mean making APRICOT and Policy SIG sessions parallel, but sequential on the same day(s). For example, when operators finish a APOPS session, they can join the Policy session in the next time spot; and when finish the Policy session, they can join another APOPS session. Jessica Shen -原始邮件- 发件人: Owen DeLong o...@delong.com 发送时间: 2015-02-28 05:33:59 (星期六) 收件人: Shen Zhi shen...@cnnic.cn 抄送: Mark Tinka mark.ti...@seacom.mu, sig-policy@lists.apnic.net 主题: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria 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
On 2/27/15 17:41 , Dean Pemberton wrote: On Sat, Feb 28, 2015 at 8:03 AM, David Farmer far...@umn.edu wrote: Don't allocated one if they don't want one. But if they want one, and they already have PI, or getting new PI, then why say no? And its not regardless of need, more accurately in anticipation of future need. Nope - you almost had me, but now you've lost me again, well done. Sorry, let me try one more time. What you are suggesting *IS* regardless of need, and thats what I think people are missing. If you are not required to demonstrate need to get something, then it is allocated regardless of need. I realise this might seem semantic, but policy is all about semantics. On this we agree. This 'anticipation of future need' stuff is at best ethereal and at worst a fallacy. Lets not forget that there is an almost zero barrier to entry with regard to ASN allocation should the member require one. I just don't subscribe to this I may one day require one so give it to me now If you only look at it through the lens of the current multi-homing requirement for an ASN then you don't need it, it is totally anticipatory and only a future need, but that is self-fulfilling. I'm suggesting that multi-homing is too narrow of a definition of need for an ASN. The PI assignment and what every justified that should also equally justify the need for ASN assignment. The PI assignment was intended to be portable, also assigning an ASN simply is intended to facilitate that portability. I'm saying that the need for portability is also a need for an ASN, if you look beyond multi-homing. It's the same as saying I don't require an IPv6 allocation today, but I anticipate that at some point I'll need a /10. Just give it all to me now so that I don't have to make difficult design decisions later. If everyone gets one then I can live with that. What I can't live with is opening up a can of worms with a I might one day need something so please allocate it now. It's a dangerous slippery slope.Today ASNs, Tomorrow IPv4, next day IPv6. It's not that I only might need it, in my opinion it is fundamentally necessary to fulfill the portability of the PI assignment. No need to move the assignment within the routing system, no need for portability and no need for an ASN. But, if you make a PI assignment without allowing me an ASN you've limited its portability and the useability for its intended purpose. Making a PI assignment implies to me, it can be picked up and moved within the routing system, assigning an ASN is needed to facilitate that movement. However, looked at through the lens of multi-homing, portability itself is only a future need. You have to look beyond multi-homing, not abandon the idea of need, to understand what I'm trying say. But, I probably only dug the whole deeper. :) So, I'll stop now. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 * 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
So it's back to what I said originally. You're claiming that an ASN is required in order to be a fully fledged member of the PI utilising community. You're also claiming that an ASN isn't an operational element anymore, that it's more like a license to be able to use PI space to it's fullest extend. If it is true, then the only sensible way forward is to allocate them as you become a community member. So we're back to Become an APNIC member, get an ASN Is that really what people are saying and is it really a sensible thing 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 Sat, Feb 28, 2015 at 10:08 AM, David Farmer far...@umn.edu wrote: On 2/27/15 17:41 , Dean Pemberton wrote: On Sat, Feb 28, 2015 at 8:03 AM, David Farmer far...@umn.edu wrote: Don't allocated one if they don't want one. But if they want one, and they already have PI, or getting new PI, then why say no? And its not regardless of need, more accurately in anticipation of future need. Nope - you almost had me, but now you've lost me again, well done. Sorry, let me try one more time. What you are suggesting *IS* regardless of need, and thats what I think people are missing. If you are not required to demonstrate need to get something, then it is allocated regardless of need. I realise this might seem semantic, but policy is all about semantics. On this we agree. This 'anticipation of future need' stuff is at best ethereal and at worst a fallacy. Lets not forget that there is an almost zero barrier to entry with regard to ASN allocation should the member require one. I just don't subscribe to this I may one day require one so give it to me now If you only look at it through the lens of the current multi-homing requirement for an ASN then you don't need it, it is totally anticipatory and only a future need, but that is self-fulfilling. I'm suggesting that multi-homing is too narrow of a definition of need for an ASN. The PI assignment and what every justified that should also equally justify the need for ASN assignment. The PI assignment was intended to be portable, also assigning an ASN simply is intended to facilitate that portability. I'm saying that the need for portability is also a need for an ASN, if you look beyond multi-homing. It's the same as saying I don't require an IPv6 allocation today, but I anticipate that at some point I'll need a /10. Just give it all to me now so that I don't have to make difficult design decisions later. If everyone gets one then I can live with that. What I can't live with is opening up a can of worms with a I might one day need something so please allocate it now. It's a dangerous slippery slope.Today ASNs, Tomorrow IPv4, next day IPv6. It's not that I only might need it, in my opinion it is fundamentally necessary to fulfill the portability of the PI assignment. No need to move the assignment within the routing system, no need for portability and no need for an ASN. But, if you make a PI assignment without allowing me an ASN you've limited its portability and the useability for its intended purpose. Making a PI assignment implies to me, it can be picked up and moved within the routing system, assigning an ASN is needed to facilitate that movement. However, looked at through the lens of multi-homing, portability itself is only a future need. You have to look beyond multi-homing, not abandon the idea of need, to understand what I'm trying say. But, I probably only dug the whole deeper. :) So, I'll stop now. -- David Farmer Email: far...@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 * 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
On 27/Feb/15 11:43, Izumi Okutani wrote: 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. My experience with downstreams who have needed address space without the need for an ASN is so they can have independence from their provider's address space, but do not necessarily have the skill-set or budget to run an autonomous system. So I do not think that it is necessarily wise to tie IP address resources to ASN resources in this way, by default. It is a valid operational approach for networks that require the address space - but not the autonomous system routing - to have their upstreams run their address space behind the upstreams ASN. As an operator running network across Africa, Europe and south Asia, we see and handle these use-cases all the time. In my experience, most customers in this scenario are more concerned with address space than routing. 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
We have the first policy sig session on at the same time as the Lightning talks on Thursday. It will be interesting to see which attracts more operators. On Saturday, 28 February 2015, Jessica Shen shen...@cnnic.cn wrote: Owen, What do you mean by 'If it’s _THE_ track at that time'? Jessica Shen -原始邮件- 发件人: Owen DeLong o...@delong.com javascript:; 发送时间: 2015-02-28 05:33:59 (星期六) 收件人: Shen Zhi shen...@cnnic.cn javascript:; 抄送: Mark Tinka mark.ti...@seacom.mu javascript:;, sig-policy@lists.apnic.net javascript:; 主题: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria On Feb 26, 2015, at 22:16 , Shen Zhi shen...@cnnic.cn javascript:; 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 javascript:; [mailto:sig-policy-boun...@lists.apnic.net javascript:;] 代表 Owen DeLong 发送时间: 2015年2月27日 4:42 收件人: Mark Tinka 抄送: sig-policy@lists.apnic.net javascript:; 主题: 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 javascript:; 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 javascript:; 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 javascript:; 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 javascript:; http://mailman.apnic.net/mailman/listinfo/sig-policy -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
