Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
My reading of the policy proposal is that it aims to allow people who received allocations under the legacy allocation scheme to expand their address space in a contiguous fashion without having to shift out of their existing address space. Maybe I'm being dense but how are the restricted from doing this under the current policy framework? They can extend up to a /29 today if they have the need. If they need more then they get two block or renumber. Thats the current framework, this policy doesn't really change that as far as I can tell. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB
Yeah I think this is a bit of a radical proposal to accept at present. I'm not convinced we should be supporting CGN in this way, nor am I a fan of seeing more and more information make it into Whois which might not be the best place. I would like to hear more from Hiromi-san about the problem statement and how this might be solved, but I'm not at all sure I would support the current proposal. Would it be possible to withdraw the proposal and use the scheduled time during the Policy Sig for an informational session to allow Hiromi-san to present to the community the problem here? 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 6:11 AM, Owen DeLong o...@delong.com wrote: I don’t believe the proposal offers enough benefit to be worth what implementation would likely cost. First, I am sincerely hoping that CGN is an extremely temporary situation. I’m not sure it should be worth the effort to recode the registry to support it. Second, I’m wondering if there’s any real advantage to having this level of detail on residential subscribers that don’t even get full addresses, since we don’t really tend to have it for single-address subscribers now. IMHO, best to just let each ISP keep this information for themselves as the relevant contact for abuse and such is usually the ISP and not the residential user anyway. Owen On Feb 23, 2015, at 10:53 , Masato Yamanishi myama...@gmail.com wrote: Dear Colleagues, And, here is prop-115. No comment has not been made for this proposal. If reached consensus, it may needs significant change for whois database. I just reviewed implementation impact assessment by the Secretariat, and it says it might take more than 6 months. I think same thing will happen for whois database of each NIRs. And if your company have a system linked with APNIC/NIR whois database, it will be impacted also. As Chair, I'm always very neutral for each proposal, including prop-115. However, I would like to emphasis prop-115 should be discussed more widely as it has wide impact. It is very appreciated if you will express your views. Regards, Masato Yamanishi, Policy SIG Chair (Acting) 2015-02-04 14:52 GMT-06:00 Masato Yamanishi myama...@gmail.com: Dear SIG members The Problem statement Registration of detailed assignment information in whois DB has been assigned a Policy Proposal number following the submission of a new version sent to the Policy SIG for consideration. The proposal, prop-115-v001: Registration of detailed assignment information in whois DB now includes an objective and proposed solution. Information about this and earlier versions is available from: http://www.apnic.net/policy/proposals/prop-115 You are encouraged you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Regards, Masato prop-115-v001: Registration of detailed assignment information in whois DB Proposer: Ruri Hiromi hir...@inetcore.com Tomohiro Fujisaki fujis...@syce.net 1. Problem statement Recently, there are some cases need to get IP address assignment information in more detail to specify user IP address. With out this information, operators cannot filter out specific address range, and it might lead to 'over-filter' (i.e. filtering whole ISP's address range). For example: 1) 'Port' range information in IPv4 ISPs are using 'CGN' or other kinds of IPv4 address sharing technology with assignment of IP address and specified port range to their users. In this case, port information is necessary to specify one user. ex) 192.0.2.24/32 1-256 is for HomeA 192.0.2.24/32 257-511 is for HomeB or 192.0.2.0/24 1-65536 is shared address of ISP-X minimum size is /32 2) address assignment size information in IPv6 The IPv6 address assignment size may be different from ISP to ISP, and address ranges in one ISP. Address assignment prefix size will be necessary. ex) 2001:db8:1::0/56 is for HomeA 2001:db8:1:1::0/48 is for HomeB or 2001:db8:1::/36's minimum size is /56 2. Objective of policy change - Lots of operators look a record
Re: [sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB
I look forward to hearing more from the author. At present I do not support this proposal. On Wednesday, 25 February 2015, Masato Yamanishi myama...@gmail.com wrote: Dean, I totally agree that we should focus on the problem statement itself in Fukuoka since this problem statement has something new concept for Policy SIG and Fukuoka will be first meeting. However, I don't think this proposal needs to be withdrawn to focus on the problem statement in Fukuoka. Certainly, in past meeting, we made it clear that we can discuss problem statement only presentation first, but that is optional. Regards, Masato 2015-02-24 14:41 GMT-06:00 Dean Pemberton d...@internetnz.net.nz javascript:_e(%7B%7D,'cvml','d...@internetnz.net.nz');: Yeah I think this is a bit of a radical proposal to accept at present. I'm not convinced we should be supporting CGN in this way, nor am I a fan of seeing more and more information make it into Whois which might not be the best place. I would like to hear more from Hiromi-san about the problem statement and how this might be solved, but I'm not at all sure I would support the current proposal. Would it be possible to withdraw the proposal and use the scheduled time during the Policy Sig for an informational session to allow Hiromi-san to present to the community the problem here? 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 Wed, Feb 25, 2015 at 6:11 AM, Owen DeLong o...@delong.com javascript:_e(%7B%7D,'cvml','o...@delong.com'); wrote: I don’t believe the proposal offers enough benefit to be worth what implementation would likely cost. First, I am sincerely hoping that CGN is an extremely temporary situation. I’m not sure it should be worth the effort to recode the registry to support it. Second, I’m wondering if there’s any real advantage to having this level of detail on residential subscribers that don’t even get full addresses, since we don’t really tend to have it for single-address subscribers now. IMHO, best to just let each ISP keep this information for themselves as the relevant contact for abuse and such is usually the ISP and not the residential user anyway. Owen On Feb 23, 2015, at 10:53 , Masato Yamanishi myama...@gmail.com javascript:_e(%7B%7D,'cvml','myama...@gmail.com'); wrote: Dear Colleagues, And, here is prop-115. No comment has not been made for this proposal. If reached consensus, it may needs significant change for whois database. I just reviewed implementation impact assessment by the Secretariat, and it says it might take more than 6 months. I think same thing will happen for whois database of each NIRs. And if your company have a system linked with APNIC/NIR whois database, it will be impacted also. As Chair, I'm always very neutral for each proposal, including prop-115. However, I would like to emphasis prop-115 should be discussed more widely as it has wide impact. It is very appreciated if you will express your views. Regards, Masato Yamanishi, Policy SIG Chair (Acting) 2015-02-04 14:52 GMT-06:00 Masato Yamanishi myama...@gmail.com javascript:_e(%7B%7D,'cvml','myama...@gmail.com');: Dear SIG members The Problem statement Registration of detailed assignment information in whois DB has been assigned a Policy Proposal number following the submission of a new version sent to the Policy SIG for consideration. The proposal, prop-115-v001: Registration of detailed assignment information in whois DB now includes an objective and proposed solution. Information about this and earlier versions is available from: http://www.apnic.net/policy/proposals/prop-115 You are encouraged you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Regards, Masato prop-115-v001: Registration of detailed assignment information in whois DB Proposer: Ruri Hiromi hir...@inetcore.com javascript:_e(%7B%7D,'cvml','hir...@inetcore.com'); Tomohiro Fujisaki fujis...@syce.net javascript:_e(%7B%7D,'cvml','fujis...@syce.net'); 1. Problem statement Recently, there are some cases need to get IP address assignment
Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
On 25 February 2015 at 07:13, Dean Pemberton d...@internetnz.net.nz wrote: +1 to most of what Dean says. My point is that if you need more than a /32, then you should be able to get a /28 rather than having to make a /[29..31] work. It's my understanding that current policy allows just that. If you need a /28 then APNIC will be able to allocate you one. It might not be an extension of your existing allocation if you were one of the early adopters (limited to a /29 boundary), but this policy doesn't provide anything new. All it proposes is that anyone in the position of having an allocation from: 2001:0200::/23 2001:0c00::/23 2001:0e00::/23 2001:4400::/23 Can request their allocation be extended to a /29 without any further justification needed. Owen opposes this as it wouldn't support allocation on a byte boundary (/28). That is never going to be possible for allocations within this block as they were initially allocated too close together. I oppose this on the grounds that it violates needs based allocation guidelines AND non byte boundary allocation for IPv6. So you would support it if it only violated one of those two concerns? A way forward that I would support is: 1. Have the hostmasters confirm that a member with an allocation in this block could, if justified, receive an allocation up to a /29 by extending their current allocation. 2. Have the hostmasters confirm that a member with an allocation in this block could, if justified, swap the allocation for one allocated from a different block where the /29 restriction on growth did not apply. 3. Withdraw this proposal. My reading of the policy proposal is that it aims to allow people who received allocations under the legacy allocation scheme to expand their address space in a contiguous fashion without having to shift out of their existing address space. Given that the address space between the legacy /32s is completely wasted at present, I don't see an issue with removing the justification requirements in this specific case (it's been mentioned that we're setting a dangerous precedent - I'd argue that leaving the space wasted if we have a technically feasible way to make better utilisation of it is a more dangerous precedent). I do not see an issue with this, given the specific limitations which are documented in the proposal. We have to accept that (short of handing everyone with a legacy allocation a new allocation based on today's allocation policy and forcing them to move over to it, handing back their legacy allocation - and I believe that the fact that this proposal is even being considered means we'd not go down that path) we will never resolve the requirement for contiguous address space within the legacy allocation ranges without allowing non-byte allocations. So, in my mind, the issue comes down to Do we want to allow allocation on non byte boundaries [in a limited sense, only within the legacy allocation policy blocks] in order to allow us to better utilise what is currently wasted space, and provide a non-disruptive allocation expansion capability for those who's only crime was to ask for their allocation when the policy was different to what it is now? In the end, I believe that we do want to do this. And thus, in the absence of an alternative policy proposal which resolves the issues this one does, I support this proposal. * 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
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 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
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. 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. 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. 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. 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. 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.) 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. 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) Dean * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB
Dean, I totally agree that we should focus on the problem statement itself in Fukuoka since this problem statement has something new concept for Policy SIG and Fukuoka will be first meeting. However, I don't think this proposal needs to be withdrawn to focus on the problem statement in Fukuoka. Certainly, in past meeting, we made it clear that we can discuss problem statement only presentation first, but that is optional. Regards, Masato 2015-02-24 14:41 GMT-06:00 Dean Pemberton d...@internetnz.net.nz: Yeah I think this is a bit of a radical proposal to accept at present. I'm not convinced we should be supporting CGN in this way, nor am I a fan of seeing more and more information make it into Whois which might not be the best place. I would like to hear more from Hiromi-san about the problem statement and how this might be solved, but I'm not at all sure I would support the current proposal. Would it be possible to withdraw the proposal and use the scheduled time during the Policy Sig for an informational session to allow Hiromi-san to present to the community the problem here? 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 6:11 AM, Owen DeLong o...@delong.com wrote: I don’t believe the proposal offers enough benefit to be worth what implementation would likely cost. First, I am sincerely hoping that CGN is an extremely temporary situation. I’m not sure it should be worth the effort to recode the registry to support it. Second, I’m wondering if there’s any real advantage to having this level of detail on residential subscribers that don’t even get full addresses, since we don’t really tend to have it for single-address subscribers now. IMHO, best to just let each ISP keep this information for themselves as the relevant contact for abuse and such is usually the ISP and not the residential user anyway. Owen On Feb 23, 2015, at 10:53 , Masato Yamanishi myama...@gmail.com wrote: Dear Colleagues, And, here is prop-115. No comment has not been made for this proposal. If reached consensus, it may needs significant change for whois database. I just reviewed implementation impact assessment by the Secretariat, and it says it might take more than 6 months. I think same thing will happen for whois database of each NIRs. And if your company have a system linked with APNIC/NIR whois database, it will be impacted also. As Chair, I'm always very neutral for each proposal, including prop-115. However, I would like to emphasis prop-115 should be discussed more widely as it has wide impact. It is very appreciated if you will express your views. Regards, Masato Yamanishi, Policy SIG Chair (Acting) 2015-02-04 14:52 GMT-06:00 Masato Yamanishi myama...@gmail.com: Dear SIG members The Problem statement Registration of detailed assignment information in whois DB has been assigned a Policy Proposal number following the submission of a new version sent to the Policy SIG for consideration. The proposal, prop-115-v001: Registration of detailed assignment information in whois DB now includes an objective and proposed solution. Information about this and earlier versions is available from: http://www.apnic.net/policy/proposals/prop-115 You are encouraged you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Regards, Masato prop-115-v001: Registration of detailed assignment information in whois DB Proposer: Ruri Hiromi hir...@inetcore.com Tomohiro Fujisaki fujis...@syce.net 1. Problem statement Recently, there are some cases need to get IP address assignment information in more detail to specify user IP address. With out this information, operators cannot filter out specific address range, and it might lead to 'over-filter' (i.e. filtering whole ISP's address range). For example: 1) 'Port' range information in IPv4 ISPs are using 'CGN' or other kinds of IPv4 address sharing technology with assignment of IP address and specified port range to their users. In this case, port information is necessary to specify one user.
Re: [sig-policy] [New Policy Proposal] prop-113: Modification in the IPv4 eligibility criteria
Actually, after seeing the clarifications provided to Dean, I now oppose this proposal as written. Owen On Feb 23, 2015, at 10:21 , Masato Yamanishi myama...@gmail.com wrote: Dear Colleagues, Regarding prop-113, I saw 3 very simple support and 1 clarification without any negative comment. Isn't there any concern or negative comment? Dean Can you express your view after clarification? Aflab and Skeeve If prop-113 will reach consensus but prop-114 will not, is it acceptable initial approach to implement only prop-113? Or, these are inseparable policies? Regards, Masato Yamanishi, Policy SIG Chair (Acting) 2015-02-03 22:18 GMT-06:00 Sanjeev Gupta sanj...@dcs1.biz mailto:sanj...@dcs1.biz: On Wed, Feb 4, 2015 at 1:56 AM, Masato Yamanishi myama...@gmail.com mailto:myama...@gmail.com wrote: The proposal prop-113: Modification in the IPv4 eligibility criteria has been sent to the Policy SIG for review. Support. -- Sanjeev Gupta +65 98551208 tel:%2B65%2098551208 http://sg.linkedin.com/in/ghane http://sg.linkedin.com/in/ghane * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net mailto:sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas. It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies. Regards, 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 7:25 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: Thanks Guangliang for the update, 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. So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future? 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
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. I do not support the proposal -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan g...@apnic.net wrote: Hi Dean and All, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. Best regards, Guangliang = -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong o...@delong.com wrote: On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nz wrote: On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.com wrote: Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this. This is not true. You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation. I don't agree (Damn and we were getting on so well this year =) ). I would argue that the situation you describe above DOES constitute multihoming. I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR. Clarification from APNIC staff on the exact behavior from APNIC could render this moot. However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”. If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy. What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”. I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help. Agreed. While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective. I really want to find out what those multi-homing requirements are. I suspect that they amount to BGP connections to two or more other ASNs In which case I think we can go back to agreeing. As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.). I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity. I can see your point, but taking a smaller simpler approach is only valid once you have agreed on the larger more strategic direction. I don't believe that we have had those conversations. I find 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On 25 February 2015 at 17:06, Dean Pemberton d...@internetnz.net.nz wrote: Great - Thanks for that. As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114. I do not support the proposal I concur with Dean - I don't see a requirement for this proposal, given the clarification of existing policy which has been provided, and thus do not support the proposal. * 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
All, I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree) Currently they all have to commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others. Would we the proposal be acceptable if we reworded the proposal to say something on the lines of ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²? This would cover the use case without opening the floodgates. Thoughts? Raf On 25/2/15 2:33 pm, Dean Pemberton d...@internetnz.net.nz wrote: Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas. It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies. Regards, 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 7:25 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: Thanks Guangliang for the update, 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. So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future? 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
To me, relaxing these rules is less about lying - although is easy, but it is to do with flexibility. I understand the routing policy wont be different that an upstream without being multi-homed, but it does curtail the convenience of being able to add these things easily. Lets say I was a company with a /23 and upstream into Telstra Only. If I had my own ASN and was announcing to Telstra, then at any time I could add another ISP, IXP, direct peering without having to go apply for an ASN, reconfigure my network to bring the announcement in-house, etc. I also might want to maintain a single provider, but be able to migrate easily to another provider without having to rely on the providers to do the right thing while changing announcements between them. I think this policy has VERY valid applications for many smaller entities to be able to have an ASN without having to be multi-homed either initially, or maintain that multi-homing. As Randy used to say - Why do you have the right to tell me how to manage my network? If I want to be multi-homed, or change my mind and not be, it is none of your damn business. I think this policy change reflects the changing way for businesses to get online since APNIC has run out of IP's, and are often charging significant amounts of money - so people are going to APNIC directly - which they are entitled to do. And being flexible and being able to change their circumstances is a more common thing nowadays. If you want, suggest charging for ASN's... but don't tell networks how they should be connected at any time. Btw... I am happy for this to apply ONLY to ASN4 and not ASN2. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Wed, Feb 25, 2015 at 3:33 PM, Dean Pemberton d...@internetnz.net.nz wrote: Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas. It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies. Regards, 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 7:25 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: Thanks Guangliang for the update, 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. So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future? 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Agreed... Aftabs use case is one of many... the others I just posted about. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Wed, Feb 25, 2015 at 3:47 PM, Raphael Ho raphael...@ap.equinix.com wrote: All, I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree) Currently they all have to commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others. Would we the proposal be acceptable if we reworded the proposal to say something on the lines of ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²? This would cover the use case without opening the floodgates. Thoughts? Raf On 25/2/15 2:33 pm, Dean Pemberton d...@internetnz.net.nz wrote: Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas. It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies. Regards, 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 7:25 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: Thanks Guangliang for the update, 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. So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future? 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
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) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan g...@apnic.net wrote: Hi Dean and All, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. Best regards, Guangliang = -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong o...@delong.com wrote: On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nz wrote: On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.com wrote: Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this. This is not true. You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation. I don't agree (Damn and we were getting on so well this year =) ). I would argue that the situation you describe above DOES constitute multihoming. I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR. Clarification from APNIC staff on the exact behavior from APNIC could render this moot. However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”. If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy. What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”. I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help. Agreed. While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective. I really want to find out what those multi-homing requirements are. I suspect that they amount to BGP connections to two or more other ASNs In which case I think we can go back to agreeing. As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.). I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity. I can see your point, but taking a
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Thanks Guangliang for the update, 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. So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future? 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
I¹m with Dean on both counts. My opinion is, if you are buying a single homed transit + peering, you are multihoming. However, if you are sub-allocated addresses from your upstream (non portable) + peering, you are doing something undesirable (in my personal opinion. Yours personal opinion may vary) I think if you have a portable address block, and have demonstrated need for an ASN (hint: just say peering), then you should be able to get one or more (hint: just say discontiguous network) - which is not very different from the current policy. On 25/2/15 5:02 am, Dean Pemberton d...@internetnz.net.nz wrote: 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 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
