Re: [sig-policy] prop-110v001: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
> I have issues with the RPKI portion. It creates additional burden on > APNIC to support non-member entities, which I do not support. As a fee > paying member, this whole idea of supporting the 46K ASNs currently > visible on the Internet doesn't scale and I'd find it a waste of fee > paying member resources. Thank you for your feedback Gaurab, as an fee-paying member as well as a member of the EC you have a unique insight here. You bring up a very important concern above. It is certainly not the intent of this proposal to create an unreasonable burden on APNIC. It is difficult however for the membership as a whole to ascertain this burden is in fact unreasonable without being authorised to view any information around the costs associated with its implementation. While it is an important issue that you raise, unfortunately the magnitude of the importance depends on the magnitude of the marginal cost associated with the creation of an additional RPKI ROA. If this cost is $100 per record then as you say, this could open APNIC up to a cost of $4,600,000. I'm sure everyone would agree that that was unreasonable. If on the other hand the marginal cost of creation and maintenance is 1 cent per record then this cost is only $450, well within the realms of the other 'public good' work performed by APNIC for the benefit of non-member entities.Release of the cost implications may cause a number of outcomes for this proposal, it may prove to be a cost that members would be happy for the EC to accept, it may cause the RPKI portion of this proposal to be removed, it may also cause a different RPKI trust anchor with a lower cost model to be suggested. Sanjaya, Gaurab has bought to light an important issue which is central to this proposal. Could I request information regarding the marginal cost of creation of an additional RPKI ROA to an existing allocation be made public to the list. I appreciate that exact figures may be difficult to obtain given the tight time constraints, to make this easier, an upper and lower bound on this cost would also be fine Once again, thanks for bringing up this issue Gaurab. Regards, 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] prop-110v001: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
I would be happy to look at an extension to the proposal to cover "Any service with local-only significance within the autonomous system". -- 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 Mon, Jan 27, 2014 at 5:41 PM, Raphael Ho wrote: > I think as long as nobody is announcing this out to the general Internet, > this is an interesting proposal. If the prefix is allowed out on the > public Internet uncontrolled then I have a problem with potential DNS > hijacking and other issues (and I agree with Mr Hannigan that¹s where IETF > needs to come in) > > Assuming that the members agree that the prefix would not be internet > reachable, do we want expand the scope of the proposal to ³Any service > with local-only significance within the autonomous system², and not limit > the use? I can see some other interesting uses that would not require > global routability, but need slightly more flexibility/reachability than > the usual RFC1918 space. > > > > On 27/1/14 12:26 pm, "Hannigan, Martin" wrote: > >> >> >>That and isn't the IETF the right venue to carve out a specific from a >>/8? This is in effect global policy, isn't it? >> >> >>On Jan 25, 2014, at 8:24 PM, Randy Bush wrote: >> >>> and why won't this leak and make confusion? >>> >>> randy >>> * 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] prop-110v001: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Thank you for the reply. I can see how the process weight could vastly change the cost of implementation. To that end to co-authors have a proposed solution. Upon careful consideration of the underlying reasoning behind this proposal, the RPKI section may not be required. It does not make sense to attempt to protect this prefix from hijacking when by it's very nature it's available for non-exclusive use. We will remove the references RPKI and send an updated draft as soon as possible. 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 5, 2014 at 11:04 AM, Sanjaya Sanjaya wrote: > Hi Dean and all, > > My apologies for the delayed reply. > > On the cost of extending the RPKI system to cover the need of this proposal, > it really depends on the degree of automation desired in managing the > registration of this particular block. A fully automated process will not > cost much at all. Any manual oversight of the process will likely increase > the cost significantly. Any idea how heavy/lightweight the registration > process should be? > > Regards, > Sanjaya > >> Sanjaya, Gaurab has bought to light an important issue which is >> central to this proposal. Could I request information regarding the >> marginal cost of creation of an additional RPKI ROA to an existing >> allocation be made public to the list. I appreciate that exact >> figures may be difficult to obtain given the tight time constraints, >> to make this easier, an upper and lower bound on this cost would also >> be fine >> >> Once again, thanks for bringing up this issue Gaurab. >> >> >> >> Regards, >> >> 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 * 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-110v001: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Good morning Masato. After consideration the co-authors feel that RPKI is an unnecessary addition and reference to it as a requirement will be removed in a subsequent draft. It is essential that any barrier to entry or perception of exclusivity or licensing for the use of this prefix be removed. Regards Dean On Thursday, February 6, 2014, Masato Yamanishi wrote: > Dear SIG members, > > Can you go back to original point which is whether the RPKI section is > needed for prop-110 or not? > IMO, it is quite important point to consider this proposal. > > Also, please note that APNIC policy SIG is not a place to debate between > regions. > > Rgs, > Masato (Matt) Yamanishi > > > > > On 14/02/04 16:16, "Randy Bush" > wrote: > > >> I did not intend the normative SHOULD that you are implying, if you > >> prefer s/should/"MAY WISH TO" and see RFC 6919. > > > >actually, i suggest the manner i deal with the arin policy, i do not > >post to the list, period. [ and, my $dayjob is in the arin region. ] > > > >the world was tired of americans telling everyone else what to do even > >before snowden. > > > >randy > >* 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. * 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-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Hi Mike, I like David's way of handling the issue that you raise. By saying that "... it is acceptable to filter this prefix at an administrative boundary, if an operator desires. Further, it should be made clear it is not acceptable to advertise this prefix to the Global Internet." I'm interested in your comment here regarding the IXP situation. Would 1.2.3.4 being advertised onto an IXP by a willing participant be something that you'd see a problem with? It would certainly be possible to place wording into the policy which places an expectation that operators should filter this at their AS boundary. I'm interested in whether people think this would unreasonably restrict the benefit of some fo the use cases of this prefix. 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 14, 2014 at 10:54 AM, Mike Jager wrote: >> 4. Proposed policy solution >> --- >> >>This proposal recommends that the APNIC community agree to assign >>1.2.3.0/24 to the APNIC Secretariat for use in the context of locally >>scoped infrastructure support for DNS resolvers. >> >>At some future point there is nothing restricting an RFC being >>written to include this prefix into the special-purpose IPv4 >>registry. However, at this time it is considered sufficient for the >>APNIC community to designate this prefix to be managed as a common >>anycast address for locally scoped infrastructure support for DNS >>resolvers. > > In an off-list discussion, a question was raised as to what the intended > definition of "locally scoped" is. My interpretation is that advertising > 1.2.3.0/24 across an AS boundary would not be a wise thing to do, but I > appreciate that authors may have a different view. > > One specific example of this related to what behaviour one might expect from > an IXP's route servers. Obviously operational decisions are up to each > network, but are we expecting that 1.2.3.0/24 might be exchanged between > ASes, or that it would become another martian prefix? > > Cheers > -Mike > * 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] IP Leasing BoF at APRICOT 2014
Good Morning all, There will be a BoF on the subject of IP address leasing at the APRICOT 2014 meeting on Tuesday, 25th Feb 2014 at 17:30 - 19:00 in the Grand Caymans room on Level 10. I will be chairing this BoF and I'd like to invite all interested parties to attend. While the concept of IP address leasing is not new, and has been the primary model for ISP sub-delegation to its customers, there is an assumption that some level of operational control is retained by the ISP. There is an expectation that the registry data reflects an operational hierarchy that makes it possible for people to look up 'parent' blocks and use the contact information at that level to resolve operational issues at a lower level network block. This model and assumptions may no longer be valid in the IPv4 exhaustion state we're currently in. Addresses may be leased out with no operational service or control attached to it. How should the registry reflect this reality, to maintain its important role in facilitating operational trouble shooting? Policy-wise, should lessors be allowed to accumulate address space, using leasing demands as 'demonstrated need' in getting more IP addresses transferred to them? Voice your opinion in a healthy debate in this BoF, held to gauge the community's sentiment on these important issues. Regards, 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] IP Leasing BoF at APRICOT 2014
I've just been advised that due to popular demand, this session will now be streamed live. Please ensure that if you would like to watch the stream or participate that you register before hand. There is a registration link on the top of the Programme page https://2014.apricot.net/program See you all there. Dean On Fri, Feb 21, 2014 at 1:31 PM, Dean Pemberton wrote: > Good Morning all, > > There will be a BoF on the subject of IP address leasing at the > APRICOT 2014 meeting on Tuesday, 25th Feb 2014 at 17:30 - 19:00 in the > Grand Caymans room on Level 10. > > I will be chairing this BoF and I'd like to invite all interested > parties to attend. > > While the concept of IP address leasing is not new, and has been the > primary model for ISP sub-delegation to its customers, there is an > assumption that some level of operational control is retained by the > ISP. There is an expectation that the registry data reflects an > operational hierarchy that makes it possible for people to look up > 'parent' blocks and use the contact information at that level to > resolve operational issues at a lower level network block. > > This model and assumptions may no longer be valid in the IPv4 > exhaustion state we're currently in. Addresses may be leased out with > no operational service or control attached to it. How should the > registry reflect this reality, to maintain its important role in > facilitating operational trouble shooting? Policy-wise, should lessors > be allowed to accumulate address space, using leasing demands as > 'demonstrated need' in getting more IP addresses transferred to them? > > Voice your opinion in a healthy debate in this BoF, held to gauge the > community's sentiment on these important issues. > > > Regards, > > Dean -- Regards, 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] [apnic-transfers] IP Leasing BoF at APRICOT 2014
All the information is in the APRICOT Programme referenced here. https://2014.apricot.net/program#session/66948 On Fri, Feb 21, 2014 at 3:48 PM, Skeeve Stevens < ske...@eintellegonetworks.com> wrote: > Sweet. Can I get some timezone information for this event please. > > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > ske...@eintellegonetworks.com ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> > linkedin.com/in/skeeve > > twitter.com/theispguy ; blog: www.theispguy.com > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > > On Fri, Feb 21, 2014 at 1:33 PM, Dean Pemberton wrote: > >> I've just been advised that due to popular demand, this session will >> now be streamed live. >> >> Please ensure that if you would like to watch the stream or >> participate that you register before hand. >> >> There is a registration link on the top of the Programme page >> https://2014.apricot.net/program >> >> >> See you all there. >> >> Dean >> >> On Fri, Feb 21, 2014 at 1:31 PM, Dean Pemberton >> wrote: >> > Good Morning all, >> > >> > There will be a BoF on the subject of IP address leasing at the >> > APRICOT 2014 meeting on Tuesday, 25th Feb 2014 at 17:30 - 19:00 in the >> > Grand Caymans room on Level 10. >> > >> > I will be chairing this BoF and I'd like to invite all interested >> > parties to attend. >> > >> > While the concept of IP address leasing is not new, and has been the >> > primary model for ISP sub-delegation to its customers, there is an >> > assumption that some level of operational control is retained by the >> > ISP. There is an expectation that the registry data reflects an >> > operational hierarchy that makes it possible for people to look up >> > 'parent' blocks and use the contact information at that level to >> > resolve operational issues at a lower level network block. >> > >> > This model and assumptions may no longer be valid in the IPv4 >> > exhaustion state we're currently in. Addresses may be leased out with >> > no operational service or control attached to it. How should the >> > registry reflect this reality, to maintain its important role in >> > facilitating operational trouble shooting? Policy-wise, should lessors >> > be allowed to accumulate address space, using leasing demands as >> > 'demonstrated need' in getting more IP addresses transferred to them? >> > >> > Voice your opinion in a healthy debate in this BoF, held to gauge the >> > community's sentiment on these important issues. >> > >> > >> > Regards, >> > >> > Dean >> >> >> >> -- >> Regards, >> >> Dean >> >> ___ >> apnic-transfers mailing list >> apnic-transf...@apnic.net >> http://mailman.apnic.net/mailman/listinfo/apnic-transfers >> > > -- Regards, 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] Policy Regarding Transfers of Legacy Space
I believe this situation was covered in the ip leasing bof yesterday. On Wednesday, February 26, 2014, Skeeve Stevens < ske...@eintellegonetworks.com> wrote: > Helpful Owen ;-) > > I agree... the question was... Is there actually any policy surrounding > people who aren't members holding Legacy or Non-Members? > > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > ske...@eintellegonetworks.com > ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> > linkedin.com/in/skeeve > > twitter.com/theispguy ; blog: www.theispguy.com > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud - Consulting - IPv4 Brokering > > > On Wed, Feb 26, 2014 at 9:18 AM, Owen DeLong > > > wrote: > >> Legacy should be different. >> >> Owen >> >> >> On Feb 25, 2014, at 14:07, Skeeve Stevens >> > >> wrote: >> >> Hi All, >> >> I've been contacted by a holder of some small (not relevant) legacy space >> who was inquiring about selling it. >> >> But, they are not an APNIC member (or a Non-Member). >> >> Referring to: >> http://www.apnic.net/publications/media-library/documents/membership/non-member-fees#Historical >> under >> 1.4, it talks about receiving transfers, but not making transfers. >> >> Any thoughts? >> >> ...Skeeve >> >> *Skeeve Stevens - *eintellego Networks Pty Ltd >> ske...@eintellegonetworks.com >> ; www.eintellegonetworks.com >> >> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >> >> facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> >> linkedin.com/in/skeeve >> >> twitter.com/theispguy ; blog: www.theispguy.com >> >> >> The Experts Who The Experts Call >> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering >> >> * 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. * 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] Timezone conversion for remote participation
> :( I got timezones mixed up. > > > ...Skeeve > Thats a shame Skeeve, timezones can be hard if you're not used to working with them. I'd hate for other remote participants to be caught by the simple error you encountered. Luckily there is a handy webpage which does accurate conversion. http://www.timeanddate.com/worldclock/converter.html You can put in your timezone and the one you're interested in and it will do the conversion for you. No need for guess work. Here is an example for Skeeve which converts time in Kuala Lumpur (as shown on the APRICOT 2014 programme) into his local time in Sydney. http://www.timeanddate.com/worldclock/converted.html?iso=20140225T00&p1=122&p2=240 There is even a "Meeting Planner" which will show you all the times for the whole day. No longer is there an excuse to miss a meeting. http://www.timeanddate.com/worldclock/meeting.html Here is another example for Skeeve showing how Kuala Lumpur and Sydney time matches up for today. http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140226&p1=122&p2=240 I hope this helps all remote APRICOT participants and I look forward to seeing more remote participation. 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. * 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-111 Request-based expansion of IPv6 default allocation size
As mentioned in the Policy-SIG. I would like to see a proposal that looked to discuss and possibly extend the list of justifications available for members when requesting prefixes (such as Traffic Engineering). I encourage the proposer of prop-111 to look at authoring such a proposal for discussion by the community. Regards 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 14, 2014 at 12:29 PM, Andy Linton wrote: > > Dear SIG members > > A new version of the proposal "prop-111 Request-based expansion of IPv6 > default allocation size" has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-111 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose 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, > > Andy and Masato > > > -- > prop-111-v002 Request-based expansion of IPv6 default allocation size > -- > > Author: Tomohiro Fujisaki > fujis...@syce.net > > > 1. Problem statement > > >IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 >address allocation and assignment policy"[1]. It's better to >expand this minimum allocation size up to /29 (/32 - /29) since: > >- Before sparse allocation mechanism implemented in late 2006, /29 > was reserved for all /32 allocations by sequential allocation > method made from those old /23 blocks. These reserved blocks > might be kept unused in the future. > >- Sparse allocation mechanism was implemented in late 2006 with a > /12 allocation from the IANA. Under the sparse allocation > mechanism, there is no reservation size defined, and the space > between allocations continues to change, depending on the > remaining free pool available in APNIC. > > However, the "APNIC guidelines for IPv6 allocation and > assignment requests"[2] stated: > > "In accordance with APNIC's "IPv6 address allocation and > assignment policy", where possible, subsequent delegations to the > same resource holder are made from an adjacent address block by > growing the delegation into the free space remaining, unless > disaggregated ranges are requested for multiple discrete > networks." > > So, it is expected that allocation up to /29 is guaranteed for > consistency with allocations above. Based on the current > situation, contiguous allocation of /29 can still be accommodated > even under the sparse allocation mechanism (Current /32 > allocations from the /12 block can grow up to /24 at this stage). > >- For traffic control purpose, some LIRs announce address blocks > longer than /32 (e.g. /35). However, some ISPs may set filters to > block address size longer than /32 since some filtering > guidelines recommend to filter longer prefix than /32([3][4]). If > LIRs have multiple /32, they can announce these blocks and its > reachability will be better than longer prefix. > >- If an LIR needs address blocks larger than /32, LIRs may tend to > announce as a single prefix if a /29 is allocated initially at > once. i.e., total number of announced prefixes in case 1 may be > smaller than in case 2. > > case 1: > The LIR obtains /29 at the beginning of IPv6 network construction. > > case 2: > The LIR obtains /32, and /31, /30 additionally with the subsequent > allocation mechanism. > > 2. Objective of policy change > - >This proposal modifies the eligibility for an organization to >receive an initial IPv6 allocation up to a /29 (/32 - /29) by >request basis. > > > 3. Situation in other regions > - > >RIPE-NCC: >The policy "Extension of IPv6 /32 to /29 on a per-allocation vs >per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get >up to /29 by default. > > > 4. Proposed policy solution > > >- Change the text to "5.2.2 Minimum initial allocation size" of > current policy document as below: > > Organizations that meet the ini
Re: [sig-policy] Returned to SIG: prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
After consideration of all the factors highlighted on the mailing list and in person at both the OPM and AMM, the authors do not wish to proceed with this proposal. Regards, Dean On Tuesday, March 4, 2014, Masato Yamanishi wrote: > Geoff and Dean, > > As next step, can you share your thought as the authors whether continue > the discussion or withdraw this proposal? > > Rgs, > Masato > > > > 2014-03-03 5:27 GMT-08:00 Masato Yamanishi > > >: > > Dear colleagues > > Version 2 of prop-110: Designate 1.2.3.0/24 as Anycast to support DNS > Infrastructure, reached consensus at the APNIC 37 Policy SIG, but did > not reach consensus at the APNIC 37 Member Meeting. > > Therefore, this proposal is being returned to the authors and the Policy > SIG mailing list for further consideration. > > > Proposal details > > > The objective of this proposal is to permit the use 1.2.3.0/24 as > anycast addresses to be used in context of scoped routing to support the > deployment of DNS resolvers. > > Proposal details including the full text of the proposal, history, and > links to mailing list discussions are available at: > >http://www.apnic.net/policy/proposals/prop-110 > > Regards > > Masato > > > > > prop-110v002: Designate 1.2.3.0/24 as Anycast to support DNS > Infrastructure > > > > Proposers: Dean Pemberton, d...@internetnz.net.nz > Geoff Huston, g...@apnic.net > > > 1. Problem statement > > >Network 1 (1.0.0.0/8) was allocated to APNIC by the IANA on 19 >January 2010. In line with standard practice APNIC's Resource Quality >Assurance activities determined that 95% of the address space would >be suitable for delegation as it was found to be relatively free of >unwanted traffic [1]. > >Testing, conducted by APNIC R&D found that certain blocks within >Network 1 attract significant amounts of unwanted traffic, primarily >due to its unauthorised use as private address space [2]. > >Analysis revealed that, prior to any delegations being made from the >block, 1.0.0.0/8 attracted an average of 140Mbps - 160Mbps of >unsolicited incoming traffic as a continuous sustained traffic level, >with peak bursts of over 800Mbps. > >The analysis highlighted individual addresses such as 1.2.3.4 with >its covering /24 (identified as 1.2.3.0/24) remain in APNIC >quarantine and it is believed they will not be suitable for normal >address distribution. > >The proposal proposes the use of 1.2.3.0/24 in a context of locally >scoped infrastructure support for DNS resolvers. > > 2. Objective of policy change > - > >As the addresses attract extremely high levels of unsolicited >incoming traffic, the block has been withheld from allocation and >periodically checked to determine if the incoming traffic profile has >altered. None has been observed to date. After four years, it now >seems unlikely there will ever be any change in the incoming traffic >profile. > >The objective of this proposal is to permit the use 1.2.3.0/24 as a >anycast addresses to be used in context of scoped routing to support >the deployment of DNS resolvers. It is > > > > > -- > Masato Yamanishi > SVP, Network Engineering > Japan Telecom America > Tel: +1-213-623-0797 ext.106 > -- -- 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] Consensus Measurement
And even if today's chairs are able to use it as a single input into their decision making process, I think that it maybe too tempting a fall back for future chairs. I'm unconvinced as well. -- 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, May 21, 2014 at 6:04 PM, Randy Bush wrote: >> My concern is e-consensus system may be more easily confused as an >> electric voting. > > i strongly agree with this concern. > > i suspect that we are a bunch of engineers trying to use technology to > compensate for not being sensitive to our membership/audience. boys and > their toys, is the american idiom. > > randy > * 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 version of prop-111: Request-based expansion of IPv6 default allocation size
Good morning, Would the author like to highlight what the changes in version 003 of this proposal are? How does this differ to the version which failed to gain consensus at the previous OPM? How do these changes address the concerns raised at the previous OPM? Kind 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 Fri, Aug 1, 2014 at 6:42 AM, Masato Yamanishi wrote: > Dear SIG members > > A new version of the proposal “prop-111: Request-based expansion of IPv6 > default allocation size has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-111 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Andy and Masato > > > -- > prop-111-v003 Request-based expansion of IPv6 default allocation size > -- > > Author: Tomohiro Fujisaki > fujis...@syce.net > > > 1. Problem statement > > > IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 > address allocation and assignment policy"[1]. It's better to > expand this minimum allocation size up to /29 (/32 - /29) since: > > - Before sparse allocation mechanism implemented in late 2006, /29 > was reserved for all /32 allocations by sequential allocation > method made from those old /23 blocks. These reserved blocks > might be kept unused in the future. > > - Sparse allocation mechanism was implemented in late 2006 with a > /12 allocation from the IANA. Under the sparse allocation > mechanism, there is no reservation size defined, and the space > between allocations continues to change, depending on the > remaining free pool available in APNIC. > > However, the "APNIC guidelines for IPv6 allocation and > assignment requests"[2] stated: > > "In accordance with APNIC's "IPv6 address allocation and > assignment policy", where possible, subsequent delegations to the > same resource holder are made from an adjacent address block by > growing the delegation into the free space remaining, unless > disaggregated ranges are requested for multiple discrete > networks." > > So, it is expected that allocation up to /29 is guaranteed for > consistency with allocations above. Based on the current > situation, contiguous allocation of /29 can still be accommodated > even under the sparse allocation mechanism (Current /32 > allocations from the /12 block can grow up to /24 at this stage). > > - After amended HD Ratio (0.94) and base calculation size (/56) was > introduced (prop-031 and prop-033), to obtain address blocks larger > than /32 and to request additional address blocks became harder > especially for small and middle size ISPs. > > - For traffic control purpose, some LIRs announce address blocks > longer than /32 (e.g. /35). However, some ISPs may set filters to > block address size longer than /32 since some filtering > guidelines recommend to filter longer prefix than /32([3][4]). If > LIRs have multiple /32, they can announce these blocks and its > reachability will be better than longer prefix. > > - If an LIR needs address blocks larger than /32, LIRs may tend to > announce as a single prefix if a /29 is allocated initially at > once. i.e., total number of announced prefixes in case 1 may be > smaller than in case 2. > > case 1: > The LIR obtains /29 at the beginning of IPv6 network construction. > > case 2: > The LIR obtains /32, and /31, /30 additionally with the subsequent > allocation mechanism. > > 2. Objective of policy change > - > > This proposal modifies the eligibility for an organization to > receive or extend an IPv6 address space up to a /29 (/32 -/29) by > explaining how the extended space up to /29 will be used. > > > 3. Situation in other regions > - > > RIPE-NCC: > The policy "Extension of IPv6 /32 to /29 on a per-allocation vs > per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can get > up to /29 by default. > > > 4. Proposed policy solution > > > - Change the text to "5.2.2 Minimum initial allocation s
Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
> > > I support using /28 , and then /24 , etc, rather than /29 or /27 or > whatever. I know this is inefficient, and realise that 50 years from now, > it will be seen as stupid and wasteful. But 50 years from now, they are > unlikely to care how APNIC handled allocations. > > The statement above is very worrying to me. I travel the globe assisting developing economies to realise their potential through the use of the Internet. Whenever I talk about IPv6 and the size of the address space, someone will always say words to the effect of: "Phew, this means we will never run out ever again..." I reply with "Throughout history, humanity has proved itself an expert at two skills; being short-sighted and wasteful in equal measure" Some of the largest IP resourcing arguments we have had as an APNIC community, and indeed a global Internet community, have sprung from the adoption of mindsets similar to the one presented above. We have all heard the lament of economies who feel justifiable disadvantaged by being late to the Internet revolution. Economies who now have to make do with a thousand or so IP address per member while looking at economies who came before them and were allocated as many as was convenient at the time. The Internet is for everyone, and those of us assisting the people building and promoting it today have an obligation to ensure that it's available not only for today's users, but also the generations of users who will come in the future. InternetNZ strongly believes that policy making bodies such as the one we are all contributing to here should operate as true servants of the Internet community, rather than a mind-set that they know what's best and enforcing those views onto the masses. Mandating what seem like arbitrary decisions about sub-netting on hex-charater boundaries may been like it has very little to no impact, but the difference between a /29 and a /28 is 633,825,300,114,114,700,748,351,602,688 usable IPv6 addresses. There will always be a balance to achieve between resource conservation and ease of network deployment, but it is just that, a balance. Allocating unnecessary IP address space so that it is easier for humans to type into networking equipment is not striking the right balance point. I do not wish to give support or otherwise to prop-111 at this time, I will wait to hear oral submissions at the OPM, what I would encourage however is that in making a decision to support prop-111, members consider what is best for the billions of people in the Internet Community that we all serve, rather than what is easiest for a small minority to type or read on a screen. 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. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
That's one of my concerns Elvis... If we accept the argument that we'll only allocate on hex-char boundaries, then it means that we're wasting more and more addresses as time goes by. We'll be having this discussion in a little while about /24s rather than /27s then it will be /20s rather than.. I once had someone swear that they would never use the 'letters' in the IPv6 address because it made the addresses look 'strange'. They ended up wasting over a third of their address space. What is being suggested here is almost as crazy. 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 Thu, Sep 18, 2014 at 9:07 AM, Elvis Velea wrote: > Hi Owen and Mike, > > can you explain why /28 and not /29? > > Why waste so much and use only nibble boundaries? What would you accept if > someone needs more than a /28, allocation of a /24? > > Kind regards, > Elvis > > > On 18/09/14 06:24, HENDERSON MIKE, MR wrote: > > Just for the avoidance of any doubt, I completely agree with Owen's position > on this matter. > > > > To reiterate: > > · I can accept that sparse allocations already made on /29 > boundaries can be expanded to fill the entire /29, if there is no room to > expand them to a /28. > > · I do not agree that any new/ 29 allocations should be made, the > next size above /32 should be /28 > > > > > > Regards > > > > > > Mike > > > > -Original Message- > From: sig-policy-boun...@lists.apnic.net > [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong > Sent: Thursday, 18 September 2014 6:16 a.m. > To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)" > Cc: sig-policy@lists.apnic.net > Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 > default allocation size > > > > Yes, I still feel it misses my point completely. > > > > I have no problem with expanding the existing reservations which are bounded > at /29 to /29. > > > > I don’t want to see us move the default allocation in the sparse allocation > world to larger than /32. Larger than /32 should require additional > justification for those blocks. > > > > Further, I don’t want to see us creating a default at a non-nibble boundary. > For organizations that show need for larger than a /32, I would support a > default of /28, but will continue to oppose a default expansion to /29. > > > > Owen > > > > On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) > wrote: > > > >> > >> Hi, > >> > >> Thank you so much for your comments. > >> > >> Here, just I would like to confirm, > >> > >> | 1.unrestricted issuance of /29s to every >> organization regardless of needs. > >> > >> I've added some texts that LIRs would like to to obtain a additional > >> block larger than /32 need to demonstrate their needs in version 3 > >> (prop-111-v003). > >> > >>> From the mail I sent on 1st August: > >> | > >> | I submitted revised version of: > >> | “prop-111: Request-based expansion of IPv6 default allocation size" > >> | > >> | At the last policy sig discussion, I got concern about address > >> | allocation without any constraint, and some criteria should be added > >> | to expand the block size. > >> | > >> | In this revised proposal, I added the requirement to demonstrate > >> | need for both initial and subsequent allocations to reflect such >> opinions. > >> | > >> | For initial allocation: > >> | > The organizations > >> | > can receive up to /29 by providing utilization information of the >> whole > >> | > address space. > >> | > >> | For subsequent allocation: > >> | > LIRs that hold one or more IPv6 allocations are able to request > >> | > extension of each of these allocations up to a /29 without >> meeting > >> | > the utilization rate for subsequent allocation by explaining > >> | > how the whole address space will be used. > >> > >> # The wording is slightly different from latest (v004) version. > >> > >> Do you think corrent text is not enough? > >> > >> Yours Sincerely, > >> -- > >> Tomohiro Fujisaki > >> * sig-policy: APNIC SIG on resource manag
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
I am familiar with Owen’s arguments, and he and I have agreed to disagree in the past many times. -- 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 Thu, Sep 18, 2014 at 9:35 AM, Owen DeLong wrote: > Absolutely… That is current policy in the ARIN region and it is working > well. > > The reality is that the amount saved by doing non-nibble boundary > allocations is insignificant compared to the likely increase in human > factors related errors induced and other varieties of inconvenience (RPKI > difficulties, DNSSEC difficulties, etc.) > > In reality, there are probably well under 1,000,000 organizations that could > justify more than a /28 (i.e. a /24) world wide. Probably at most a few > million ISPs that would be able to justify more than a /32 (i.e. a /28, > serving more than 50,000 customers), I think we’re fine. > > If it turns out I’m wrong and we burn through 2000::/3 this way in less than > 50 years, than I will happily admit it and help anyone who is interested > draft more restrictive policies for the remaining untouched ~3/4 of IPv6 > address space. > > So far, we haven’t even managed to polish off a /12 in any region. > > Owen > > On Sep 17, 2014, at 4:07 PM, Elvis Velea wrote: > > Hi Owen and Mike, > > can you explain why /28 and not /29? > > Why waste so much and use only nibble boundaries? What would you accept if > someone needs more than a /28, allocation of a /24? > > Kind regards, > Elvis > > On 18/09/14 06:24, HENDERSON MIKE, MR wrote: > > Just for the avoidance of any doubt, I completely agree with Owen's position > on this matter. > > To reiterate: > · I can accept that sparse allocations already made on /29 > boundaries can be expanded to fill the entire /29, if there is no room to > expand them to a /28. > · I do not agree that any new/ 29 allocations should be made, the > next size above /32 should be /28 > > > Regards > > > Mike > > -Original Message- > From: sig-policy-boun...@lists.apnic.net > [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Owen DeLong > Sent: Thursday, 18 September 2014 6:16 a.m. > To: "(Tomohiro -INSTALLER- Fujisaki/藤崎 智宏)" > Cc: sig-policy@lists.apnic.net > Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 > default allocation size > > Yes, I still feel it misses my point completely. > > I have no problem with expanding the existing reservations which are bounded > at /29 to /29. > > I don’t want to see us move the default allocation in the sparse allocation > world to larger than /32. Larger than /32 should require additional > justification for those blocks. > > Further, I don’t want to see us creating a default at a non-nibble boundary. > For organizations that show need for larger than a /32, I would support a > default of /28, but will continue to oppose a default expansion to /29. > > Owen > > On Sep 16, 2014, at 6:59 PM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) > wrote: > >> >> Hi, >> >> Thank you so much for your comments. >> >> Here, just I would like to confirm, >> >> | 1.unrestricted issuance of /29s to every >> organization regardless of needs. >> >> I've added some texts that LIRs would like to to obtain a additional >> block larger than /32 need to demonstrate their needs in version 3 >> (prop-111-v003). >> >>> From the mail I sent on 1st August: >> | >> | I submitted revised version of: >> | “prop-111: Request-based expansion of IPv6 default allocation size" >> | >> | At the last policy sig discussion, I got concern about address >> | allocation without any constraint, and some criteria should be added >> | to expand the block size. >> | >> | In this revised proposal, I added the requirement to demonstrate >> | need for both initial and subsequent allocations to reflect such >> opinions. >> | >> | For initial allocation: >> | > The organizations >> | > can receive up to /29 by providing utilization information of the >> whole >> | > address space. >> | >> | For subsequent allocation: >> | > LIRs that hold one or more IPv6 allocations are able to request >> | > extension of each of these allocations up to a /29 without >> meeting >> | > the utilization rate for subsequent allocation by explaining >> | > how the whole address space will be used. >> >> # The wording is slightly di
Re: [sig-policy] Resignation as Policy SIG chair
As the list knows by now, Owen and I don't always see eye to eye, but on this we are agreed. I'd like to go further however... It would be easy to assume that Randy's considerable contributions to the global Internet community are all in the past. This however could not be further from the truth. Randy continues to be actively involved in a great number of projects which provide direct benefit to current and future users of the Internet. I have the pleasure of working with Randy on a number of these projects and the thing they all have in common is that Randy doesn't feel the need to place himself in the spotlight. In fact quite the opposite; Randy would never want his profile to be higher than that of the organisation he is assisting. This assistance spans the gamut from ensuring individuals from underrepresented groups can access mentoring, training and knowledge transfer opportunities to designing and deploying Internet infrastructure projects which assist entire economies to benefit from increased Internet access. Suffice to say that in contrast to the statement that Randy is negative, pessimistic, sour and arrogant. I have witnessed his work in projects where he continues to show positivity, optimism, enthusiasm and humility. Do not judge a person by a single act, but by the balanced sum of their actions. If Randy chooses not to spend his time and efforts within the APNIC community then that is both his choice, and this community's loss. Regards Dean On Sun, Sep 21, 2014 at 6:34 AM, Owen DeLong wrote: > Skeeve. > > First: +1 to what you have said below, except. > > In the past (rapidly becoming the distant past), Randy provided a lot of > service to this and several other internet communities. He was a talented > engineer and helped to solve many problems. There was a time when his > commitment to the community matched his arrogance, pessimism, and hostility. > Sadly, it seems that all that is left is the arrogance, pessimism, and > hostility. > > I was never Randy's greatest fan and he was certainly never mine. However, I > do think it is important to recognize the contributions he has made, in > spite of his best efforts to obscure them behind his current behavior. > > Owen > > On Sep 20, 2014, at 04:20 , Masato Yamanishi > wrote: > > Dear Andy and SIG members, > > I'm very sorry to hear your resignation, but I would like to express our > appreciation for your service, in particular for last 3 years as Policy SIG > Chair and NRO NC, on behalf of the community. > > SIG members> > Please join me in thanking Andy for his great chairmanship and excellent > cooperation work. > > Masato Yamanishi > Policy SIG co-chair > > Sep 19, 2014 10:18 PM、Andy Linton のメッセージ: > > I've decided to stand down as chair of the APNIC Policy SIG. I'm doing this > for a number of reasons which I'll go into in this mail. I was not able to > attend APNIC38 as I am currently in the UK but to be honest even if I'd been > in New Zealand I'm not sure that I would have made the trip to Brisbane. > > Several meetings ago Randy Bush put a proposal in front of the Policy SIG > suggesting that the time had come to abandon the making of policy in the > current form. I chaired the session that discussed this matter. We had a > session which ended in confusion and acrimony and the debate ended at that > point. > > I will say that while Randy and I disagreed over the mechanism of how to > disband/radically change the current process, I am in full support of the > core idea proposed in prop-103. I believe the current process is failing the > community and it should be wound up and replaced with some other mechanism. > > At APNIC38, my colleague Masato Yamanashi was returned unopposed as co-chair > and I am confident that he will handle the role of Chair until the meeting > in Fukuoka next February where the community can decide if they want to > continue with the current mechanism or not. My resignation now will give > plenty of time for any debate on this. > > I believe that we are now at the stage where we are having a face to face > meeting of the Policy SIG mainly to validate the legitimacy of having a > meeting of APNIC every six months. There's little of substance that couldn't > be discussed on line and there are very few people taking part in debate on > address policy because there is really very little to discuss. > > I believe that APNIC's job is and should continue to be a registry with a > lightweight structure. I believe APNIC has changed into a quasi political > body that spends vast amounts of time and money travelling to Internet > Governance meetings where they meet other similar entities and they all tell > each other what a fabulous job they're doing of governing the Internet. > > You may agree with them doing that - that's fine. I don't and I think it's > time for me to step aside and let them get on with it. You could say I > should stay and help to try to fix things but I simply don't have the time >
Re: [sig-policy] [New Policy Proposal] prop-113: Modification in the IPv4 eligibility criteria
Could I ask that the APNIC hostmasters to comment on the following: Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to? In other words had the current policy in the eyes of the host masters ever been a barrier to entry? I'll also be asking the same question of the other similar policy. On Wednesday, 4 February 2015, Masato Yamanishi wrote: > Dear SIG members > > The proposal "prop-113: Modification in the IPv4 eligibility criteria" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, > Japan on Thursday, 5 March 2015. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > > Information about this proposal is available at: > > > http://www.apnic.net/policy/proposals/prop-113 > > Regards > > Masato > > > > > prop-113-v001: Modification in the IPv4 eligibility criteria > > > Proposer: Aftab Siddiqui > aftab.siddi...@gmail.com > > > Skeeve Stevens > ske...@eintellegonetworks.com > > > > 1. Problem statement > > The current APNIC IPv4 delegation policy defines multiple > eligibility criteria and applicant must meet one to be eligible to > receive IPv4 resources. One of the criteria dictates that “an > organization is eligible if it is currently multi-homed with > provider-based addresses, or demonstrates a plan to multi-home > within one month” (section 3.3). > > The policy seems to imply that multi-homing is mandatory even if > there is no use case for the applicant to be multi-homed or even > when there is only one upstream provider available, this has created > much confusion in interpreting this policy. > > As a result organizations have either tempted to provide incorrect > or fabricated multi-homing information to get the IPv4 resources or > barred themselves from applying. > > > 2. Objective of policy change > - > > In order to make the policy guidelines simpler we are proposing to > modify the text of section 3.3. > > > 3. Situation in other regions > - > > ARIN: > There is no multi-homing requirement > > RIPE: > There is no multi-homing requirement. > > LACNIC: > Applicant can either have multi-homing requirement or interconnect. > > AFRINIC: > There is no multi-homing requirement. > > > 4. Proposed policy solution > --- > > Section 3.3: Criteria for small delegations > An organization is eligible if it is currently multi-homed or > inter-connected with provider (ISP)-based addresses, or demonstrates > a plan to advertise the prefixes within 3 months. > > > 5. Advantages / Disadvantages > - > > Advantages: > > Removing the mandatory multi-homing requirement from the policy will > make sure that organizations are not tempted to provide wrong or > fabricated multi-homing information in order to fulfil the criteria > of eligibility. > > Disadvantages: > > There is no known disadvantage of this proposal. > > > 6. Impact on resource holders > - > > No impact on existing resource holders. > > > 7. References > - > -- -- 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
Could I ask that the APNIC hostmasters to comment on the following: Have you ever been made aware of a situation where due of the current wording of the relevant clauses in the policy, a member or potential member has not made a resource application where they would otherwise have been able to? In other words has the current policy in the eyes of the host masters ever been a barrier to entry? On Wednesday, 4 February 2015, Masato Yamanishi wrote: > Dear SIG members > > The proposal "prop-114: Modification in the ASN eligibility criteria" > has been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka, > Japan on Thursday, 5 March 2015. > > We invite you to review and comment on the proposal on the mailing list > before the meeting. > > The comment period on the mailing list before an APNIC meeting is an > important part of the policy development process. We encourage you to > express your views on the proposal: > > - Do you support or oppose this proposal? > - Does this proposal solve a problem you are experiencing? If so, > tell the community about your situation. > - Do you see any disadvantages in this proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more > effective? > > > Information about this proposal is available at: > > http://www.apnic.net/policy/proposals/prop-114 > > > Regards, > > Masato > > > > > > --- > prop-114-v001: Modification in the ASN eligibility criteria > --- > > Proposer: Aftab Siddiqui > aftab.siddi...@gmail.com > > > Skeeve Stevens > ske...@eintellegonetworks.com > > > > 1. Problem statement > > > The current ASN assignment policy dictates two eligibility criteria > and both should be fulfilled in order to get an ASN. The policy > seems to imply that both requirements i.e. multi-homing and clearly > defined single routing policy must be met simultaneously, this has > created much confusion in interpreting the policy. > > As a result organizations have either provided incorrect information > to get the ASN or barred themselves from applying. > > > 2. Objective of policy change > - > > In order to make the policy guidelines simpler we are proposing to > modify the text describing the eligibility criteria for ASN > assignment by removing multi-homing requirement for the organization. > > > 3. Situation in other regions > - > > ARIN: > It is not mandatory but optional to be multi-homed in order get ASN > > RIPE: > Policy to remove multi-homing requirement is currently in discussion > and the current phase ends 12 February 2015 > Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 > > LACNIC: > only inter-connect is mandatory not multi-homing > > AFRINIC: > It is mandatory to be multi-homed in order to get ASN. > > > 4. Proposed policy solution > --- > > An organization is eligible for an ASN assignment if it: > - Is planning to use it within next 6 months > > > 5. Advantages / Disadvantages > - > > Advantages: > > Removing the mandatory multi-homing requirement from the policy will > make sure that organizations are not tempted to provide wrong > information in order to fulfil the criteria of eligibility. > > Disadvantages: > > No disadvantage. > > > 6. Impact on resource holders > - > > No impact on existing resource holders. > > > 7. References > - > > -- -- 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-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
e this will lead to inefficient utilization of > IPv6 space since LIRs can obtain huge address size unnecessarily. > However, this will not happen because larger address size needs > higher cost to maintain that address block. > > > 6. Impact on resource holders > - > > NIRs must implement this policy if it is implemented by APNIC. > > > 7. References > - > > [1] IPv6 address allocation and assignment policy > http://www.apnic.net/policy/ipv6-address-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 > > > The information contained in this Internet Email message is intended for > the addressee only and may contain privileged information, but not > necessarily the official views or opinions of the New Zealand Defence > Force. If you are not the intended recipient you must not use, disclose, > copy or > distribute this message or the information in it. If you have received > this message in error, please Email or telephone the sender immediately. > -- -- 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
Changing or removing the rules is not the way to address people submitting invalid or misleading information. Also I doubt that the hostmasters would be 'aware' of a case. If they were then the question would be why did they approve the resource application. On Wednesday, 4 February 2015, Aftab Siddiqui wrote: > Hi Dean, > Thanks for raising the question. > > Could I ask that the APNIC hostmasters to comment on the following: >> >> Have you ever been made aware of a situation where due of the current >> wording of the relevant clauses in the policy, a member or potential member >> has not made a resource application where they would otherwise have been >> able to? >> > > Would like to add something here to the question, "have you even been made > aware of a situation where applicant provided wrong or fake multi-homing > information just to meet the criteria?" > > >> In other words has the current policy in the eyes of the host masters >> ever been a barrier to entry? >> >> Very valid point. > > > Regards, > > Aftab A. Siddiqui > > > -- -- 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
So it doesn't look like there is a problem here. The hostmasters are clear about the current policy, they explain it to people who contact them. Am I missing something? I'm not at all in favour of policy for policy sake. What's the problem statement here? On Thursday, 5 February 2015, George Kuo wrote: > Hello Dean, > > We are not aware of any potential members who may have decided not to > apply for IPv4 addresses or AS numbers based on how they have interpreted > the policy wording. > > However, we explain the policy criteria to any potential members who do > contact APNIC, and those who are not multihoming do not qualify for An IPv4 > or ASN assignment based on the current policy. > > Currently, we don't keep a record of these unsuccessful requests, but > we can begin to keep records in the future if this information is > required. > > George K > > On 4/02/2015 5:13 am, Dean Pemberton wrote: > >> Could I ask that the APNIC hostmasters to comment on the following: >> >> Have you ever been made aware of a situation where due of the current >> wording of the relevant clauses in the policy, a member or potential >> member has not made a resource application where they would otherwise >> have been able to? >> >> In other words has the current policy in the eyes of the host masters >> ever been a barrier to entry? >> >> >> >> >> On Wednesday, 4 February 2015, Masato Yamanishi > <mailto:myama...@gmail.com>> wrote: >> >> Dear SIG members >> >> The proposal "prop-114: Modification in the ASN eligibility criteria" >> has been sent to the Policy SIG for review. >> >> It will be presented at the Open Policy Meeting at APNIC 39 in >> Fukuoka, >> Japan on Thursday, 5 March 2015. >> >> We invite you to review and comment on the proposal on the mailing >> list >> before the meeting. >> >> The comment period on the mailing list before an APNIC meeting is an >> important part of the policy development process. We encourage you to >> express your views on the proposal: >> >> - Do you support or oppose this proposal? >> - Does this proposal solve a problem you are experiencing? If >> so, >>tell the community about your situation. >> - Do you see any disadvantages in this proposal? >> - Is there anything in the proposal that is not clear? >> - What changes could be made to this proposal to make it more >>effective? >> >> >> Information about this proposal is available at: >> >> http://www.apnic.net/policy/proposals/prop-114 >> >> >> Regards, >> >> Masato >> >> >> >> >> >> --- >> prop-114-v001: Modification in the ASN eligibility criteria >> --- >> >> Proposer: Aftab Siddiqui >> aftab.siddi...@gmail.com >> >> >>Skeeve Stevens >> ske...@eintellegonetworks.com >> >> >> >> 1. Problem statement >> >> >> The current ASN assignment policy dictates two eligibility >> criteria >> and both should be fulfilled in order to get an ASN. The policy >> seems to imply that both requirements i.e. multi-homing and >> clearly >> defined single routing policy must be met simultaneously, this >> has >> created much confusion in interpreting the policy. >> >> As a result organizations have either provided incorrect >> information >> to get the ASN or barred themselves from applying. >> >> >> 2. Objective of policy change >> - >> >> In order to make the policy guidelines simpler we are proposing >> to >> modify the text describing the eligibility criteria for ASN >> assignment by removing multi-homing requirement for the >> organization. >> >> >> 3. Situation in other regions >> - >> >> ARIN: >> It is not mandatory but optional to be multi-homed in order get >> ASN >> >> RIPE: >> Policy to remove multi-homing requirement is currently in >> discussion >> and the current phase ends 12 Fe
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
You're right that it's just one data point. I'd encourage anyone with any further information to present it. At the moment I'm not seeing the requirement here. On Friday, 6 February 2015, Owen DeLong wrote: > I don't think your conclusion is supported by the statement from > hostmaster... > > "We don't know of anyone who hasn't reached out to us" doesn't mean that > nobody has reached out to them... It means that they are unaware. > > Asking the hostmasters about this issue in the way you did is akin to > walking into a room full of people and saying "Everyone who is not here, > please raise your hand" and concluding from the lack of raised hands that > everyone is present. > > Owen > > > > > On Feb 4, 2015, at 8:09 PM, Dean Pemberton > wrote: > > So it doesn't look like there is a problem here. > > The hostmasters are clear about the current policy, they explain it to > people who contact them. > > Am I missing something? I'm not at all in favour of policy for policy > sake. > > What's the problem statement here? > > On Thursday, 5 February 2015, George Kuo > wrote: > >> Hello Dean, >> >> We are not aware of any potential members who may have decided not to >> apply for IPv4 addresses or AS numbers based on how they have interpreted >> the policy wording. >> >> However, we explain the policy criteria to any potential members who do >> contact APNIC, and those who are not multihoming do not qualify for An IPv4 >> or ASN assignment based on the current policy. >> >> Currently, we don't keep a record of these unsuccessful requests, but >> we can begin to keep records in the future if this information is >> required. >> >> George K >> >> On 4/02/2015 5:13 am, Dean Pemberton wrote: >> >>> Could I ask that the APNIC hostmasters to comment on the following: >>> >>> Have you ever been made aware of a situation where due of the current >>> wording of the relevant clauses in the policy, a member or potential >>> member has not made a resource application where they would otherwise >>> have been able to? >>> >>> In other words has the current policy in the eyes of the host masters >>> ever been a barrier to entry? >>> >>> >>> >>> >>> On Wednesday, 4 February 2015, Masato Yamanishi >> <mailto:myama...@gmail.com>> wrote: >>> >>> Dear SIG members >>> >>> The proposal "prop-114: Modification in the ASN eligibility criteria" >>> has been sent to the Policy SIG for review. >>> >>> It will be presented at the Open Policy Meeting at APNIC 39 in >>> Fukuoka, >>> Japan on Thursday, 5 March 2015. >>> >>> We invite you to review and comment on the proposal on the mailing >>> list >>> before the meeting. >>> >>> The comment period on the mailing list before an APNIC meeting is an >>> important part of the policy development process. We encourage you to >>> express your views on the proposal: >>> >>> - Do you support or oppose this proposal? >>> - Does this proposal solve a problem you are experiencing? If >>> so, >>>tell the community about your situation. >>> - Do you see any disadvantages in this proposal? >>> - Is there anything in the proposal that is not clear? >>> - What changes could be made to this proposal to make it more >>>effective? >>> >>> >>> Information about this proposal is available at: >>> >>> http://www.apnic.net/policy/proposals/prop-114 >>> >>> >>> Regards, >>> >>> Masato >>> >>> >>> >>> >>> >>> --- >>> prop-114-v001: Modification in the ASN eligibility criteria >>> --- >>> >>> Proposer: Aftab Siddiqui >>> aftab.siddi...@gmail.com >>> >>> >>>Skeeve Stevens >>> ske...@eintellegonetworks.com >>> >>> >>> >>> 1. Problem statement >>> >>> >>> The current ASN assignment policy dictates two eligibility >>> criteria >>>
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Rather than being a laughing matter this proposal seeks to hand out ASNs with no more justification than "I want one". Can the authors explain why they feel radical change to existing policy is required? On Friday, 6 February 2015, Skeeve Stevens wrote: > hahahahahahahahahah > > "...to walking into a room full of people and saying "Everyone who is not > here, please raise your hand" and concluding from the lack of raised hands > that everyone is present." > > This made my morning. > > > ...Skeeve > > *Skeeve Stevens - Senior IP Broker* > *v4Now - *an eintellego Networks service > ske...@v4now.com ; > www.v4now.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/v4now ; <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 6, 2015 at 12:57 AM, Owen DeLong > wrote: > >> I don't think your conclusion is supported by the statement from >> hostmaster... >> >> "We don't know of anyone who hasn't reached out to us" doesn't mean that >> nobody has reached out to them... It means that they are unaware. >> >> Asking the hostmasters about this issue in the way you did is akin to >> walking into a room full of people and saying "Everyone who is not here, >> please raise your hand" and concluding from the lack of raised hands that >> everyone is present. >> >> Owen >> >> >> >> >> On Feb 4, 2015, at 8:09 PM, Dean Pemberton > > wrote: >> >> So it doesn't look like there is a problem here. >> >> The hostmasters are clear about the current policy, they explain it to >> people who contact them. >> >> Am I missing something? I'm not at all in favour of policy for policy >> sake. >> >> What's the problem statement here? >> >> On Thursday, 5 February 2015, George Kuo > > wrote: >> >>> Hello Dean, >>> >>> We are not aware of any potential members who may have decided not to >>> apply for IPv4 addresses or AS numbers based on how they have interpreted >>> the policy wording. >>> >>> However, we explain the policy criteria to any potential members who do >>> contact APNIC, and those who are not multihoming do not qualify for An IPv4 >>> or ASN assignment based on the current policy. >>> >>> Currently, we don't keep a record of these unsuccessful requests, but >>> we can begin to keep records in the future if this information is >>> required. >>> >>> George K >>> >>> On 4/02/2015 5:13 am, Dean Pemberton wrote: >>> >>>> Could I ask that the APNIC hostmasters to comment on the following: >>>> >>>> Have you ever been made aware of a situation where due of the current >>>> wording of the relevant clauses in the policy, a member or potential >>>> member has not made a resource application where they would otherwise >>>> have been able to? >>>> >>>> In other words has the current policy in the eyes of the host masters >>>> ever been a barrier to entry? >>>> >>>> >>>> >>>> >>>> On Wednesday, 4 February 2015, Masato Yamanishi >>> <mailto:myama...@gmail.com>> wrote: >>>> >>>> Dear SIG members >>>> >>>> The proposal "prop-114: Modification in the ASN eligibility >>>> criteria" >>>> has been sent to the Policy SIG for review. >>>> >>>> It will be presented at the Open Policy Meeting at APNIC 39 in >>>> Fukuoka, >>>> Japan on Thursday, 5 March 2015. >>>> >>>> We invite you to review and comment on the proposal on the mailing >>>> list >>>> before the meeting. >>>> >>>> The comment period on the mailing list before an APNIC meeting is an >>>> important part of the policy development process. We encourage you >>>> to >>>> express your views on the proposal: >>>> >>>> - Do you support or oppose this proposal? >>>> - Does this proposal solve a problem you are experiencing? If >>>> so, >>>>tell the community about your situation. >>>> - Do you see any disadvantages in this propo
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
There is a version of this that I would support, this isn't it. On Sunday, 8 February 2015, Owen DeLong wrote: > I do agree with Dean that this proposal in its current state is too > radical, but I do support relaxing the requirements to multi home _or_ > unique routing policy would be an improvement that addresses the issue > raised in the problem statement. > > Owen > > > > > On Feb 5, 2015, at 12:07, Skeeve Stevens > wrote: > > hahahahahahahahahah > > "...to walking into a room full of people and saying "Everyone who is not > here, please raise your hand" and concluding from the lack of raised hands > that everyone is present." > > This made my morning. > > > ...Skeeve > > *Skeeve Stevens - Senior IP Broker* > *v4Now - *an eintellego Networks service > ske...@v4now.com ; > www.v4now.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/v4now ; <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 6, 2015 at 12:57 AM, Owen DeLong > wrote: > >> I don't think your conclusion is supported by the statement from >> hostmaster... >> >> "We don't know of anyone who hasn't reached out to us" doesn't mean that >> nobody has reached out to them... It means that they are unaware. >> >> Asking the hostmasters about this issue in the way you did is akin to >> walking into a room full of people and saying "Everyone who is not here, >> please raise your hand" and concluding from the lack of raised hands that >> everyone is present. >> >> Owen >> >> >> >> >> On Feb 4, 2015, at 8:09 PM, Dean Pemberton > > wrote: >> >> So it doesn't look like there is a problem here. >> >> The hostmasters are clear about the current policy, they explain it to >> people who contact them. >> >> Am I missing something? I'm not at all in favour of policy for policy >> sake. >> >> What's the problem statement here? >> >> On Thursday, 5 February 2015, George Kuo > > wrote: >> >>> Hello Dean, >>> >>> We are not aware of any potential members who may have decided not to >>> apply for IPv4 addresses or AS numbers based on how they have interpreted >>> the policy wording. >>> >>> However, we explain the policy criteria to any potential members who do >>> contact APNIC, and those who are not multihoming do not qualify for An IPv4 >>> or ASN assignment based on the current policy. >>> >>> Currently, we don't keep a record of these unsuccessful requests, but >>> we can begin to keep records in the future if this information is >>> required. >>> >>> George K >>> >>> On 4/02/2015 5:13 am, Dean Pemberton wrote: >>> >>>> Could I ask that the APNIC hostmasters to comment on the following: >>>> >>>> Have you ever been made aware of a situation where due of the current >>>> wording of the relevant clauses in the policy, a member or potential >>>> member has not made a resource application where they would otherwise >>>> have been able to? >>>> >>>> In other words has the current policy in the eyes of the host masters >>>> ever been a barrier to entry? >>>> >>>> >>>> >>>> >>>> On Wednesday, 4 February 2015, Masato Yamanishi >>> <mailto:myama...@gmail.com>> wrote: >>>> >>>> Dear SIG members >>>> >>>> The proposal "prop-114: Modification in the ASN eligibility >>>> criteria" >>>> has been sent to the Policy SIG for review. >>>> >>>> It will be presented at the Open Policy Meeting at APNIC 39 in >>>> Fukuoka, >>>> Japan on Thursday, 5 March 2015. >>>> >>>> We invite you to review and comment on the proposal on the mailing >>>> list >>>> before the meeting. >>>> >>>> The comment period on the mailing list before an APNIC meeting is an >>>> important part of the policy development process. We encourage you >>>> to >>>> express your views on the proposal: >>>> >>>> - Do you support or oppose this proposal? >>>> - Does th
Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
On Tue, Feb 24, 2015 at 7:13 AM, Masato Yamanishi wrote: > Q1. Is the benefit larger than the concern or not? What benefit? I'm not seeing one here. As far as I can see there is nothing stopping an LIR with one of these historical allocations (a /32 for example) coming back to APNIC, requesting more address space, demonstrating need, and being allocated that additional space. What this proposal seems to be advocating is that each of the LIRs be 'gifted' up to a /29 without having to demonstrate any need what so ever. I oppose this policy on those grounds alone. If the policy were to place a needs based assessment on the LIR, then the proposal would not be required at all and we would be able to proceed under the rules we have today. > Q2. Does the alternative solution proposed by Owen resolve this problem > also? > Owen's solution is available to people today. eg, If I have a /32 and I want to grow this to a /28 but there is only a /29 possible under the allocation models, then I can request a /28 from a different block and renumber into it, returning the /32. I believe people have been doing similar things in the IPv4 world for a while. In it's current form the policy is either not required (members can get additional allocations if required), or a dangerous precident (removal of needs based allocation for IPv6). I do not support this proposal in it's current form. 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 Policy Proposal] prop-113: Modification in the IPv4 eligibility criteria
This proposal seems to advocates two things: The removal of any requirement for organisations to be multihomed The removal of any needs based allocation for IPv4 address allocation. The proposed wording states: Section 3.3: Criteria for small delegations An organization is eligible if it is currently multi-homed or inter-connected with provider (ISP)-based addresses, or demonstrates a plan to advertise the prefixes within 3 months. Can the authors clarify that their intended state is one where an LIR is only required to demonstrate a plan to advertise the addresses rather than demonstrate an actual need for them? 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 Tue, Feb 24, 2015 at 7:21 AM, Masato Yamanishi 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 : >> >> >> On Wed, Feb 4, 2015 at 1:56 AM, Masato Yamanishi >> 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 http://sg.linkedin.com/in/ghane >> >> * 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
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. Secondly, In considering this policy proposal in conjunction with prop-113, I am increasingly doubtful that there is anything for me to support here. I suspect what is happening here is that these proposals (113 and 114) are conjoined and rather than significantly lowering the bar with regard to allocation of IPv4 resources, they seek removal of the bar altogether. There are players within the community who will significantly benefit from a policy framework with a reduced multi-homing and demonstrated needs requirement, but those entities are not necessarily the end LIRs. What these two proposals seek to do is remove all barriers to obtaining IPv4 addresses and ASNs. One of the major problems here is that the authors seek to do this one 'cut' at a time. Almost in an attempt to avoid waking the tiger which is ARIN's requirement for needs based allocation, or having the APNIC community discussion around 'needs based' allocation for IPv4 resources. I would like to see us stop the subterfuge here. I would like to see both of these policies withdrawn and prop-116 "Removal of all barriers to allocation of IPv4 and ASN resources" put forward for debate. It is only in that way that the true ramifications/impacts of these smaller policies can be realised and discussed by the community. Forcing us to debate this clause by clause is a waste of community time and effort. I strongly oppose this policy as it is currently written. 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 Tue, Feb 24, 2015 at 7:38 AM, Masato Yamanishi wrote: > Dear Colleagues, > > Regarding prop-114, discussion points are; > > 1. Whether completely taking away multi-home requirement or relaxing it by > adding "or unique routing policy" > as Owen proposed and ARIN doing. > > http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00015.html > > http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00044.html > > 2. Whether we will relax it for only 4-byte AS or 2-byte also. > (Please note that we are running out 2-byte AS and it might speed it > up) > > It is very appreciated if you will express your views for these points, > and also show another points if you have. > > Regards, > Masato > > > 2015-02-07 19:25 GMT-06:00 Skeeve Stevens : > > Dean, >> >> Pleas enlighten us on what version you would support. >> >> >> ...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 Sun, Feb 8, 2015 at 11:49 AM, Dean Pemberton >> wrote: >> >>> There is a version of this that I would support, this isn't it. >>> >>> >>> >>> On Sunday, 8 February 2015, Owen DeLong wrote: >>> >>>> I do agree with Dean that this proposal in its current state is too >>>> radical, but I do support relaxing the requirements to multi home _or_ >>>> unique routing policy would be an improvement that addresses the issue >>>> raised in the problem statement. >>>> >>>> Owen >>>> >>>> >>>> >>>> >>>> On Feb 5, 2015, at 12:07, Skeeve Stevens wrote: >>>> >>>> hahahahahahahahahah >>>> >>>> "...to walking into a room full of people and saying "Everyone who is >>>> not here, please raise your hand" and concluding from the lack of raised >>>> hands that everyone is present." >>>> >>>> This made my morning. >>>> >>>> >>>> ...Skeeve >>>> >>>> *Skeeve Stevens - Senior IP Broker* >>>> *v4Now - *an eintellego Networks service >>>> ske...@v4now.com ; www.v4now.com >>>> >>>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >>>> >>>> facebook.com/v4now ; <http://twitter.com/networkceoau> >>>> linkedin.com/in/skeeve >>>> >&
Re: [sig-policy] [New Policy Proposal] prop-113: Modification in the IPv4 eligibility criteria
-- 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 Tue, Feb 24, 2015 at 7:47 PM, Aftab Siddiqui wrote: >> The removal of any needs based allocation for IPv4 address allocation. > > Not exactly. > Yes exactly - you go on to say just that below. > I don't see any reason to force LIR to provide justification that how they > will use the prefixes with in 3 months or an year and now we are not talking > about /18s /17s any more. This statement clearly shows that you are in favour of, and that this policy effectively removes demonstrated need from IPv4 allocations. 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 Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]
> > +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. 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. * 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 Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 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
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 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 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 : >> >> 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 ca
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 wrote: > >> On Feb 24, 2015, at 12:38 , Dean Pemberton wrote: >> >> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 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 i
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 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 >: > >> 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 > > 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 > > 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 > >: >> >> >> >> 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
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 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 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 wrote: >> >>> On Feb 24, 2015, at 12:38 , Dean Pemberton wrote: >>> >>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 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,
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 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
Nope - Your other email didn't provide any reasons which weren't covered by Philips answer. If you have a peering session to two or more ASNs you are multihomed and you qualify. If you only peer with one ASN then you can do this with a private ASN. If you want to make a change and move from a single peer to more than one then you get quickly get an ASN. You can even get them in advance of a planned network change as seen in the current policy snippet below "An organization will also be eligible if it can demonstrate that it will meet the above criteria upon receiving an ASN (or within a reasonably short time thereafter)." No need to change policy. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:09 PM, Skeeve Stevens wrote: > Please see my other email Phil.. there is very valid reasons for this > policy change. > > > ...Skeeve > > *Skeeve Stevens - Senior IP Broker* > *v4Now - *an eintellego Networks service > 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 4:25 PM, Philip Smith wrote: > >> Dean Pemberton wrote on 25/02/2015 15:06 : >> > Great - Thanks for that. >> > >> > As far as I can tell this covers all possible use cases I can see. >> > I do not believe that there is a need for prop-114. >> >> Same, I simply don't understand what problem is trying to be solved here. >> >> If an organisation is connected to only one other organisation, there is >> no need for an ASN. If these two orgs want to use BGP, that's a private >> matter, and is what private ASNs are for - and there are now around 1 >> billion of those. >> >> If an organisation needs to connect to at least two other ASNs, then >> they qualify under the APNIC definition which Guanliang shared. >> >> philip >> -- >> >> > >> > I do not support the proposal >> > >> > >> > -- >> > Dean Pemberton >> > >> > Technical Policy Advisor >> > InternetNZ >> > +64 21 920 363 (mob) >> > 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 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 wrote: >> >>> >> >>>> On Feb 24, 2015, at 12:38 , Dean Pemberton >> wrot
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Thanks for that Guangliang. Thats really helped to clarify the position here. Another question. Whats the normal time lag between a member applying for an ASN (assuming that all the information is present and correct) and it being allocated? 1 day? 1 week? 1 month? I'm trying to gauge if it really takes longer to apply for an ASN than it does to arrange and configure a BGP peering session. Thanks Dean -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan 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 wrote: >> >>> On Feb 24, 2015, at 12:38 , Dean Pemberton wrote: >>> >>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Thanks Guangliang, That's what I hoped the answer would be and it's great to see that the hostmasters are able to turn these around so quickly. My summary here after all we have discussed is that under the current policy, if there is an operational need (connecting to more than one ASN or to an IXP) for a member to have an ASN, they can apply a short time in advance and generally receive an ASN the next working day. There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok with that. Dean -- 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 10:36 PM, Guangliang Pan wrote: > Hi Dean, > > If they meet the policy requirement and no payment requested, they normally > will receive an ASN in the next working day. > > Thanks, > Guangliang > >> On 25 Feb 2015, at 6:36 pm, "Dean Pemberton" wrote: >> >> Thanks for that Guangliang. Thats really helped to clarify the position >> here. >> >> Another question. >> Whats the normal time lag between a member applying for an ASN >> (assuming that all the information is present and correct) and it >> being allocated? >> >> 1 day? >> 1 week? >> 1 month? >> >> I'm trying to gauge if it really takes longer to apply for an ASN than >> it does to arrange and configure a BGP peering session. >> >> Thanks >> Dean >> -- >> Dean Pemberton >> >> Technical Policy Advisor >> InternetNZ >> +64 21 920 363 (mob) >> d...@internetnz.net.nz >> >> To promote the Internet's benefits and uses, and protect its potential. >> >> >>> On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan 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 wrote: >>>> >>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton wrote: >>>>> >>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Actually the RFC makes this clear.
There is clear guidance within RFC1930 for this which is marked as "BEST
CURRENT PRACTICE". Please someone let me know if I've missed an
obsolescence here.
All of the situations you are talking about are described as "rare and
should almost never happen". If you believe that the RFC is wrong and no
longer constitutes best practice, then engage in the IETF community and try
and fix this at the source rather than using RIR policy to justify a
departure from documented current best practice.
5.1 Sample Cases
*Single-homed site, single prefix
A separate AS is not needed; the prefix should be placed in an
AS of the provider. The site's prefix has exactly the same rout-
ing policy as the other customers of the site's service
provider, and there is no need to make any distinction in rout-
ing information.
This idea may at first seem slightly alien to some, but it high-
lights the clear distinction in the use of the AS number as a
representation of routing policy as opposed to some form of
administrative use.
In some situations, a single site, or piece of a site, may find
it necessary to have a policy different from that of its
provider, or the rest of the site. In such an instance, a sepa-
rate AS must be created for the affected prefixes. This situa-
tion is rare and should almost never happen. Very few stub sites
require different routing policies than their parents. Because
the AS is the unit of policy, however, this sometimes occurs.
*Single-homed site, multiple prefixes
Again, a separate AS is not needed; the prefixes should be
placed in an AS of the site's provider.
*Multi-homed site
Here multi-homed is taken to mean a prefix or group of prefixes
which connects to more than one service provider (i.e. more than
one AS with its own routing policy). It does not mean a network
multi-homed running an IGP for the purposes of resilience.
An AS is required; the site's prefixes should be part of a
single AS, distinct from the ASes of its service providers.
This allows the customer the ability to have a different repre-
sentation of policy and preference among the different service
providers.
This is ALMOST THE ONLY case where a network operator should
create its own AS number. In this case, the site should ensure
that it has the necessary facilities to run appropriate routing
protocols, such as BGP4.
--
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 Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens wrote:
> Owen,
>
> But who determines 'if they need one' ? Them, or you (plural)?
>
> I believe they should be able to determine that they need one and be able
> to get one based on that decision - not told how they should be doing their
> upstream connectivity at any particular time.
>
>
> ...Skeeve
>
> *Skeeve Stevens - Senior IP Broker*
> *v4Now - *an eintellego Networks service
> ske...@v4now.com ; 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 Thu, Feb 26, 2015 at 8:03 AM, Owen DeLong wrote:
>
>>
>> > On Feb 24, 2015, at 22:47 , Raphael Ho
>> wrote:
>> >
>> > All,
>> >
>> > I¹m having an offline discussion with Aftab, basically the issue he¹s
>> > trying to address is that new ISPs in small countries/cities may not
>> meet
>> > the day 1 requirements for an ASN, but however should be eligible since
>> > they will require an ASN to peer/multihome at some point in the future
>> > (which I do agree)
>>
>> What is the disadvantage for them to get the ASN later, when they
>> actually need it?
>>
>> > Currently they all have to "commit fraud² in order to get an ASN, and I
>> > guess some religion takes that more seriously than others.
>>
>> They only have to commit fraud if they are determined to get an ASN
>> before they need one.
>>
>> > Would we the proposal be acceptable if we reworded the proposal to say
>> > something on the lines of
>> >
>> > ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible
>> > for as ASN²?
>>
>> I think “an ASN” rather than “a
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens wrote: > > > I'm asking that the policy reflect an operators choice to decide how they > manage their networks should they choose to do it that way. > > > I believe we've entered the point of diminishing returns here. It has been shown multiple times in this thread that there is no barrier to getting an ASN if one is required under the current policy. This fact has been supported by the current hostmasters. Operators currently have the freedom to choose how to manage their networks, they can choose to get an ASN anytime they need one for operational purposes. There is no change in policy required. I strongly oppose this policy as written. * 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
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 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
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. 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. -- 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 7:10 PM, Skeeve Stevens 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 ; <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 > 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 >> 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Here's a quote from an even OLDER RFC which hasn't stood the test of time. - Large organizations like banks and retail chains are switching to TCP/IP for their internal communication. Large numbers of local workstations like cash registers, money machines, and equipment at clerical positions rarely need to have such connectivity. Thing is though that we haven't tossed out the rest of RFC1918 just because some of it didn't age well. -- 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 7:19 PM, Aftab Siddiqui wrote: > On a side note.. Since RFC1930 has already been quoted couple of times here > as the Best Current Practice even valid today.. > > an excerpt > > "BGP (Border Gateway Protocol, the current de facto standard for inter-AS > routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, > which the Internet is expected to adopt when BGP becomes obsolete; see > [IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI, or > Routing Domain Identifier." > > > > > Regards, > > Aftab A. Siddiqui > > On Fri, Feb 27, 2015 at 10:43 AM, Dean Pemberton > 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 >> 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
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 > 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 ; <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 > 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 >> > > 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 > > -- -- 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
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 wrote: > > > On Feb 27, 2015, at 01:43 , Izumi Okutani > 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 > -- -- 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
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 wrote: > Owen, > > What do you mean by 'If it’s _THE_ track at that time'? > > Jessica Shen > > > > -原始邮件- > > 发件人: "Owen DeLong" > > > 发送时间: 2015-02-28 05:33:59 (星期六) > > 收件人: "Shen Zhi" > > > 抄送: "Mark Tinka" >, > 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 > > 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 > > > >> 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. * 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
Nope - you almost had me, but now you've lost me again, well done. 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. 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" 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. -- 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 8:03 AM, David Farmer wrote: > On 2/27/15 16:05 , Dean Pemberton wrote: >> >> 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. > > > 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. > > If someone gets an ASN, and uses it, when they get PI, they will have a much > easier time porting to a new provider, or better yet, becoming multi-homed > and/or participating in an IX in the future. > > So, don't force them to get an ASN, just don't force then wait until they > multi-home their PI either. > >> Any additional ASN requested by a member must conform to existing policy. > > > The exact wording of the current policy may or may not be right for the > situation, but that is the basic idea. Also, you should still be able to > get an ASN to do PA multi-homing, if you are multi-homing with a cut-out > from an upstream provider. > >> Is this where we're at? Change the proposal and see where we get to. > > > Yes, please. > >> 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. > > > That's silly, your APNIC Member number should just be your credit card > number. :) > > > -- > > 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
That's what we strive for. Something for everyone :) On Saturday, 28 February 2015, Skeeve Stevens 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 > 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 wrote: >> >>> Owen, >>> >>> What do you mean by 'If it’s _THE_ track at that time'? >>> >>> Jessica Shen >>> >>> >>> > -原始邮件- >>> > 发件人: "Owen DeLong" >>> > 发送时间: 2015-02-28 05:33:59 (星期六) >>> > 收件人: "Shen Zhi" >>> > 抄送: "Mark Tinka" , 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 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 >>> > >> 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 >>> >
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 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] [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 wrote: > On 2/27/15 17:41 , Dean Pemberton wrote: >> >> On Sat, Feb 28, 2015 at 8:03 AM, David Farmer 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 Version of prop-115-v001: Registration of detailed assignment information in whois DB
I am currently neither in favour or opposed to this proposal, but I would like to ask for a point of clarification... Is the author suggesting that new fields in the whois be added to allow this funtionality? It would seem that this is something which operators could choose to implement today using the 'remarks' field as they do for BGP community information as shown below. $ whois -h rr.Level3.net as702 % RIPEdb(3.0.0a13) with ISI RPSL extensions aut-num: AS702 as-name: AS702 descr: Verizon Business EMEA - Commercial IP service provider in Europe admin-c: DUMY-RIPE tech-c:DUMY-RIPE remarks: -- Verizon Business filters out inbound prefixes longer than /24. We also filter any networks within AS702:RS-INBOUND-FILTER. -- VzBi uses the following communities with its customers: 702:80Set Local Pref 80 within AS702 702:120 Set Local Pref 120 within AS702 702:20Announce only to VzBi AS'es and VzBi customers 702:30Keep within Europe, don't announce to other VzBi AS's 702:1 Prepend AS702 once at edges of VzBi to Peers 702:2 Prepend AS702 twice at edges of VzBi to Peers 702:3 Prepend AS702 thrice at edges of VzBi to Peers -- Advanced communities for customers 702:7020 Do not announce to AS702 peers with a scope of National but advertise to Global Peers, European Peers and VzBi customers. 702:7001 Prepend AS702 once at edges of VzBi to AS702 peers with a scope of National. 702:7002 Prepend AS702 twice at edges of VzBi to AS702 peers with a scope of National. 702:7003 Prepend AS702 thrice at edges of VzBi to AS702 peers with a scope of National. 702:8020 Do not announce to AS702 peers with a scope of European but advertise to Global Peers, National Peers and VzBi customers. 702:8001 Prepend AS702 once at edges of VzBi to AS702 peers with a scope of European. 702:8002 Prepend AS702 twice at edges of VzBi to AS702 peers with a scope of European. 702:8003 Prepend AS702 thrice at edges of VzBi to AS702 peers with a scope of European. -- Additional details of the VzBi communities are located at: http://www.verizonbusiness.com/uk/customer/bgp/ -- Details of VzBi's peering policy and how to get in touch with VzBi regarding peering policy matters can be found at: http://www.verizonbusiness.com/uunet/peering/ -- remarks: remarks: * THIS OBJECT IS MODIFIED remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * To view the original object, please query the RIPE Database at: remarks: * http://www.ripe.net/whois remarks: mnt-by:WCOM-EMEA-RICE-MNT changed: unr...@ripe.net 20000101 source:RIPE -- 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 Thu, Feb 5, 2015 at 5:52 AM, Masato Yamanishi wrote: > 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
Re: [sig-policy] Policy SIG session schedule
I agree. Thats why I was in favour of abandoning the AMM consensus. Unfortunately the policy failed. -- 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 Tue, Mar 3, 2015 at 6:25 PM, Izumi Okutani wrote: > Great to know this Philip. > > We had simliar issue last year, where we discussed about the proposal on > reserving a space for DNS anycast, and due to parallel session, some > operators could not attend. It got rediscussed at the AMM and the > consensus at Policy SIG got reverted. I think it's not efficient that > consensus decisions needs to be rediscussed due to parallel sessions and > not everyone could participate at Policy SIG. > > I provided input to an APNIC staff after the session last year and would > like to raise this again. > > > Thanks, > Izumi > > > > On 2015/03/02 12:07, Philip Smith wrote: >> FWIW, a few years ago we did have at least two APRICOTs where there was >> nothing in parallel with the Thursday Policy SIG. It meant that the >> technical/ops part of the conference finished on Wednesday. APRICOT 2009 >> was one example - for reference. (And tech/ops people left on Wednesday >> night.) >> >> But we reverted to putting regular conference content in parallel with >> the Policy SIG following requests and feedback for that. >> >> And yes, if there is clear desire from the Policy SIG to be standalone, >> the APRICOT PC will pay very close attention to that desire. :-) >> >> philip >> -- >> >> >> Skeeve Stevens wrote on 2/03/2015 12:04 : >>> OK... so a year in the future... that should easily be dealt with by >>> talking to the Apricot Program Committee... as it is a very reasonable >>> and obvious thing to do. >>> >>> Is it possible for this meeting? Competing event for Policy means there >>> will be little reason to entice people to come . >>> >>> >>> ...Skeeve >>> >>> *Skeeve Stevens - Senior IP Broker* >>> *v4Now - *an eintellego Networks service >>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com >>> <http://www.v4now.com/> >>> >>> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve >>> >>> facebook.com/v4now >>> <http://facebook.com/v4now> ; >>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve >>> <http://linkedin.com/in/skeeve> >>> >>> twitter.com/theispguy <http://twitter.com/theispguy> ; >>> blog: www.theispguy.com <http://www.theispguy.com/> >>> >>> >>> IP Address Brokering - Introducing sellers and buyers >>> >>> On Mon, Mar 2, 2015 at 11:58 AM, Masato Yamanishi >> <mailto:myama...@gmail.com>> wrote: >>> >>> Skeeve, >>> >>> Unfortunately, I don't think we can change the schedule in this >>> meeting. >>> I'm asking about future meetings. >>> >>> Regards, >>> Masato >>> >>> 2015-03-01 18:46 GMT-08:00 Skeeve Stevens >> <mailto:ske...@v4now.com>>: >>> >>> Masato-san, >>> >>> Are you suggesting that we are able to change either Policy or >>> Lightening talks for this event? I would love to go to both. >>> >>> I think this is only really a problem at Apricot events, not >>> APNIC events. >>> >>> >>> ...Skeeve >>> >>> *Skeeve Stevens - Senior IP Broker* >>> *v4Now - *an eintellego Networks service >>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com >>> <http://www.v4now.com/> >>> >>> Phone: 1300 239 038; Cell +61 (0)414 753 383 >>> ; skype://skeeve >>> >>> facebook.com/v4now >>> <http://facebook.com/v4now> ; >>> <http://twitter.com/networkceoau>linkedin.com/in/skeeve >>> <http://linkedin.com/in/skeeve> >>> >>> twitter.com/theispguy <http://twitter.com/theispguy> ; >>> blog: www.theispguy.com <http://www.theispguy.com/> >>> >>> >>> IP Address Brokering - Introducing sellers and buyers >>> >>> On Mon, Mar 2, 2015 at 11:18 AM, Masato Yamanishi >>> mailto:myama...@gma
Re: [sig-policy] Policy SIG session schedule
The Policy-SIG is also open to anyone where as the consensus at the AMM is members only. It also seemed like it gave people a time to get additional input/feedback between the Policy-SIG and the AMM. -- 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, Mar 4, 2015 at 11:36 AM, Aftab Siddiqui wrote: > What I can recall, the objection was more members join AMM rather > Policy-SIG therefore the consensus at Policy-SIG is not actual consensus of > the members at the event. I hope secretariat can suggest what other issues > were registered. > > Regards, > > Aftab A. Siddiqui > > On Wed, Mar 4, 2015 at 7:31 AM, Skeeve Stevens wrote: > >> Let's try again? What were the objections last time? >> >> >> ...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, Mar 4, 2015 at 11:29 AM, Dean Pemberton >> wrote: >> >>> I agree. Thats why I was in favour of abandoning the AMM consensus. >>> Unfortunately the policy failed. >>> -- >>> 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 Tue, Mar 3, 2015 at 6:25 PM, Izumi Okutani wrote: >>> > Great to know this Philip. >>> > >>> > We had simliar issue last year, where we discussed about the proposal >>> on >>> > reserving a space for DNS anycast, and due to parallel session, some >>> > operators could not attend. It got rediscussed at the AMM and the >>> > consensus at Policy SIG got reverted. I think it's not efficient that >>> > consensus decisions needs to be rediscussed due to parallel sessions >>> and >>> > not everyone could participate at Policy SIG. >>> > >>> > I provided input to an APNIC staff after the session last year and >>> would >>> > like to raise this again. >>> > >>> > >>> > Thanks, >>> > Izumi >>> > >>> > >>> > >>> > On 2015/03/02 12:07, Philip Smith wrote: >>> >> FWIW, a few years ago we did have at least two APRICOTs where there >>> was >>> >> nothing in parallel with the Thursday Policy SIG. It meant that the >>> >> technical/ops part of the conference finished on Wednesday. APRICOT >>> 2009 >>> >> was one example - for reference. (And tech/ops people left on >>> Wednesday >>> >> night.) >>> >> >>> >> But we reverted to putting regular conference content in parallel with >>> >> the Policy SIG following requests and feedback for that. >>> >> >>> >> And yes, if there is clear desire from the Policy SIG to be >>> standalone, >>> >> the APRICOT PC will pay very close attention to that desire. :-) >>> >> >>> >> philip >>> >> -- >>> >> >>> >> >>> >> Skeeve Stevens wrote on 2/03/2015 12:04 : >>> >>> OK... so a year in the future... that should easily be dealt with >>> by >>> >>> talking to the Apricot Program Committee... as it is a very >>> reasonable >>> >>> and obvious thing to do. >>> >>> >>> >>> Is it possible for this meeting? Competing event for Policy means >>> there >>> >>> will be little reason to entice people to come . >>> >>> >>> >>> >>> >>> ...Skeeve >>> >>> >>> >>> *Skeeve Stevens - Senior IP Broker* >>> >>> *v4Now - *an eintellego Networks service >>> >>> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com >>> >>> <http://www.v4now.com/> >>> >>> >>> >>> Phone: 1300 239 038; Cell +61 (0)414 753 383
Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria
I agree with Owen here. I oppose as written. On Thursday, 5 March 2015, Owen DeLong wrote: > Opposed as written. > > Vague wording which basically says that the secretariat can decide policy > on a case-by-case > basis is antithetical to an informed multi-stakeholder community consensus > policy development > process. > > Owen > > On Mar 4, 2015, at 00:02 , Masato Yamanishi > wrote: > > Dear SIG members > > A new version of the proposal “prop-114: Modification in the ASN > eligibility criteria" has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-114 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Masato > > > > -- > prop-114-v002: Modification in the ASN eligibility criteria > -- > > Proposer: Aftab Siddiqui > aftab.siddi...@gmail.com > > >Skeeve Stevens >ske...@eintellegonetworks.com > > > > 1. Problem statement > - > > The current ASN assignment policy states two eligibility criteria > and that both criteria should be fulfilled in order to obtain an > ASN. The policy seems to imply that both requirements i.e. > multi-homing and clearly defined single routing policy must be met > simultaneously, this has created much confusion in interpreting the > policy. > > As a result organizations have either provided incorrect information > to get the ASN or barred themselves from applying where they still > have a valid justification for obtaining an ASN. > > > 2. Objective of policy change > -- > > In order to make the policy guidelines simpler we are proposing to > modify the text describing the eligibility criteria for ASN > assignment by providing alternate criteria to obtaining an ASN. > > > 3. Situation in other regions > > > ARIN: > It is not mandatory but optional to be multi-homed in order get ASN > > RIPE: > Policy to remove multi-homing requirement is currently in discussion > and the current phase ends 12 February 2015 (awaiting Chair > decision) > > Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 > > LACNIC: > Only inter-connect is mandatory not multi-homing > > AFRINIC: > It is mandatory to be multi-homed in order to get ASN. > > > 4. Proposed policy solution > --- > > An organization is eligible for an ASN assignment if: > > - they are currently multi-homed OR > > - meet one of the other criteria in the guidelines managed by the >APNIC Secretariat > > > 5. Advantages / Disadvantages > - > > Advantages: > > By adding the additional criteria of Guidelines managed by APNIC > Secretariat, this would enable the Secretariat to make decisions > based on common or rare use cases, but that may still be a valid > request. > > Disadvantages: > > It may be perceived that this policy would enable members to obtain > ASN’s more easily, and in return cause faster consumption of ASN’s > in the region. Given the relative ease of obtaining an ASN with > ‘work around’ methods, we do not perceive this will actually have > any effect. > > > > 6. Impact on resource holders > --- > > No impact on existing resource holders. > > > > Proposed Draft Guidelines > (to be created as a numbered document by APNIC) > > > The below are example of guidelines that could be considered for > alternate needs justification. > > The intention to multi-home in the future > > The applicant is participating in elastic fabrics where the > requirements to connect to ‘on demand’ service providers may require > ASN/BGP connectivity > > Regional limitation of obtaining multi-homing connectivity in the > ‘imme
Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria
d policy solution >> --- >> >> An organization is eligible for an ASN assignment if: >> >> - they are currently multi-homed OR >> >> - meet one of the other criteria in the guidelines managed by the >>APNIC Secretariat >> >> >> 5. Advantages / Disadvantages >> - >> >> Advantages: >> >> By adding the additional criteria of Guidelines managed by APNIC >> Secretariat, this would enable the Secretariat to make decisions >> based on common or rare use cases, but that may still be a valid >> request. >> >> Disadvantages: >> >> It may be perceived that this policy would enable members to obtain >> ASN’s more easily, and in return cause faster consumption of ASN’s >> in the region. Given the relative ease of obtaining an ASN with >> ‘work around’ methods, we do not perceive this will actually have >> any effect. >> >> >> >> 6. Impact on resource holders >> --- >> >> No impact on existing resource holders. >> >> >> >> Proposed Draft Guidelines >> (to be created as a numbered document by APNIC) >> >> >> The below are example of guidelines that could be considered for >> alternate needs justification. >> >> The intention to multi-home in the future >> >> The applicant is participating in elastic fabrics where the >> requirements to connect to ‘on demand’ service providers may require >> ASN/BGP connectivity >> >> Regional limitation of obtaining multi-homing connectivity in the >> ‘immediate’ term, but want to design their networks for this >> capability >> >> Have a single unique routing policy different to their upstream, but >> yet >> are single-homed >> >> * sig-policy: APNIC SIG on resource management policy >> * >> ___ >> sig-policy mailing list >> sig-policy@lists.apnic.net >> >> http://mailman.apnic.net/mailman/listinfo/sig-policy >> >> >> >> * sig-policy: APNIC SIG 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. * 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-113: Modification in the IPv4 eligibility criteria
Just to clarify. This still looks to remove needs based allocation and shift that to an "ability to advertise". Am I missing something here? On Thursday, 5 March 2015, Masato Yamanishi wrote: > Dear SIG members > > A new version of the proposal “prop-113: Modification in the IPv4 > eligibility criteria" has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > http://www.apnic.net/policy/proposals/prop-113 > > You are encouraged to express your views on the proposal: > > - Do you support or oppose the proposal? > - Is there anything in the proposal that is not clear? > - What changes could be made to this proposal to make it more effective? > > Please find the text of the proposal below. > > Kind Regards, > > Masato > > > > > -- > prop-113-v002: Modification in the IPv4 eligibility criteria > - > > Proposer: Aftab Siddiqui > aftab.siddi...@gmail.com > > > Skeeve Stevens > ske...@eintellegonetworks.com > > > > 1. Problem statement > - > > The current APNIC IPv4 delegation policy defines multiple > eligibility criteria and applicants must meet one criteria to be > eligible to receive IPv4 resources. One of the criteria dictates > that “an organization is eligible if it is currently multi-homed > with provider-based addresses, or demonstrates a plan to multi-home > within one month” (section 3.3). > > The policy seems to imply that multi-homing is mandatory even if > there is no use case for the applicant to be multi-homed or even > when there is only one upstream provider available, this has created > much confusion in interpreting this policy. > > As a result organizations have either tempted to provide incorrect > or fabricated multi-homing information to get the IPv4 resources or > barred themselves from applying. > > > 2. Objective of policy change > -- > > In order to make the policy guidelines simpler we are proposing to > modify the text of section 3.3. > > > 3. Situation in other regions > > > ARIN: > There is no multi-homing requirement > > RIPE: > There is no multi-homing requirement. > > LACNIC: > Applicant can either have multi-homing requirement or interconnect. > > AFRINIC: > There is no multi-homing requirement. > > > 4. Proposed policy solution > > > Section 3.3: Criteria for small delegations > > An organization is eligible if: > > - it is currently multi-homed > > OR, > > - currently utilising provider (ISP) assignment of at least a /24, > > AND > > - intends to be multi-homed > > OR, > > - intends to be multi-homed > > AND > > - advertise the prefixes within 6 months > > > > 5. Advantages / Disadvantages > -- > > Advantages: > > Simplifies the process of applying for IPv4 address space for small > delegations and delays the immediate requirement for multi-homing as > determined to be appropriate within the timeframe as detailed in > Section 3.3. > > Disadvantages: > > There is no known disadvantage of this proposal. > > > 6. Impact on resource holders > - > > No impact on existing resource holders. > > -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz 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 version of prop-114: Modification in the ASN eligibility criteria
> >>> A new version of the proposal “prop-114: Modification in the ASN >>> eligibility criteria" has been sent to the Policy SIG for review. >>> >>> Information about earlier versions is available from: >>> >>> http://www.apnic.net/policy/proposals/prop-114 >>> >>> You are encouraged to express your views on the proposal: >>> >>> - Do you support or oppose the proposal? >>> - Is there anything in the proposal that is not clear? >>> - What changes could be made to this proposal to make it more effective? >>> >>> Please find the text of the proposal below. >>> >>> Kind Regards, >>> >>> Masato >>> >>> >>> >>> >>> -- >>> prop-114-v002: Modification in the ASN eligibility criteria >>> >>> -- >>> >>> Proposer: Aftab Siddiqui >>> aftab.siddi...@gmail.com >>> >>> >>>Skeeve Stevens >>>ske...@eintellegonetworks.com >>> >>> >>> >>> 1. Problem statement >>> - >>> >>> The current ASN assignment policy states two eligibility criteria >>> and that both criteria should be fulfilled in order to obtain an >>> ASN. The policy seems to imply that both requirements i.e. >>> multi-homing and clearly defined single routing policy must be met >>> simultaneously, this has created much confusion in interpreting the >>> policy. >>> >>> As a result organizations have either provided incorrect information >>> to get the ASN or barred themselves from applying where they still >>> have a valid justification for obtaining an ASN. >>> >>> >>> 2. Objective of policy change >>> -- >>> >>> In order to make the policy guidelines simpler we are proposing to >>> modify the text describing the eligibility criteria for ASN >>> assignment by providing alternate criteria to obtaining an ASN. >>> >>> >>> 3. Situation in other regions >>> >>> >>> ARIN: >>> It is not mandatory but optional to be multi-homed in order get ASN >>> >>> RIPE: >>> Policy to remove multi-homing requirement is currently in discussion >>> and the current phase ends 12 February 2015 (awaiting Chair >>> decision) >>> >>> Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 >>> >>> LACNIC: >>> Only inter-connect is mandatory not multi-homing >>> >>> AFRINIC: >>> It is mandatory to be multi-homed in order to get ASN. >>> >>> >>> 4. Proposed policy solution >>> --- >>> >>> An organization is eligible for an ASN assignment if: >>> >>> - they are currently multi-homed OR >>> >>> - meet one of the other criteria in the guidelines managed by the >>>APNIC Secretariat >>> >>> >>> 5. Advantages / Disadvantages >>> - >>> >>> Advantages: >>> >>> By adding the additional criteria of Guidelines managed by APNIC >>> Secretariat, this would enable the Secretariat to make decisions >>> based on common or rare use cases, but that may still be a valid >>> request. >>> >>> Disadvantages: >>> >>> It may be perceived that this policy would enable members to obtain >>> ASN’s more easily, and in return cause faster consumption of ASN’s >>> in the region. Given the relative ease of obtaining an ASN with >>> ‘work around’ methods, we do not perceive this will actually have >>> any effect. >>> >>> >>> >>> 6. Impact on resource holders >>> --- >>> >>> No impact on existing resource holders. >>> >>> >>> >>> Proposed Draft Guidelines >>> (to be created as a numbered document by APNIC) >>> >>> >>> The below are example of guidelines that could be considered for >>> alternate needs justification. >>> >>> The intention to multi-home in the future >>> >>> The applicant is participating in elastic fabrics where the >>> requirements to connect to ‘on demand’ service providers may require >>> ASN/BGP connectivity >>> >>> Regional limitation of obtaining multi-homing connectivity in the >>> ‘immediate’ term, but want to design their networks for this >>> capability >>> >>> Have a single unique routing policy different to their upstream, but >>> yet >>> are single-homed >>> >>> * sig-policy: APNIC SIG on resource management policy >>> * >>> ___ >>> sig-policy mailing list >>> sig-policy@lists.apnic.net >>> >>> http://mailman.apnic.net/mailman/listinfo/sig-policy >>> >>> >>> >>> * sig-policy: APNIC SIG 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. * 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] Fwd: Idea for 1.2.3.0/24
Oops wrong button :) -- Forwarded message -- From: *Dean Pemberton* Date: Friday, 22 May 2015 Subject: [sig-policy] Idea for 1.2.3.0/24 To: David Huberman Hi David, Everyone If APNIC were to just sell this off then there is no saying that it won't just appear in some large providers NAT pool. I've just visited some providers who wanted address space so much they would probably bid for this just to have 1.2.3.4 as a flag to wave and the rest of the /24 just sits in their CGN. That would be terrible for anyone whose sessions were associated with these addresses. I won't elaborate here but there are even potential security issues related with a malicious actor being able to redirect this about of traffic. Any of these would be a net loss to the Internet community. So how can we turn this into a net win? I'm not that concerned about the money. Good things can be done with auction proceeds, but good ideas can come from people without money too. For example what if an individual has a great idea to use 1.2.3.4 for the common good but would never have an ability to win an auction? They might also have no ability to purchase infrastructure to make the idea happen. Nat Morris for eg runs a great any cast DNS service helping lots of people but I'm pretty sure his wife and dog would notice him going up against large corps in an auction. What about this. We take suggestions for the best 'public good' use of 1.2.3.4. For each of the ideas, let the community show support "a thumbs up/down" if you will. Also for each of them allow organisations to pitch to deliver it. Market it as recycling trash even :) This way the good idea can come from anyone in any part of the world as long as it benefits all internet users. And large corporations can still get some exposure by offering to make it happen. Imagine the photoshoot. Smart up-and-coming engineer from an LDC alongside a large multinational helping APNIC to make a difference to us all. Thoughts? On Friday, 22 May 2015, David Huberman > wrote: > Hello Policy SIG, > > > > I have an idea for 1.2.3.0/24 I would like to share with you before > submitting a policy proposal. > > > > Prop-109 properly directed APNIC to use 1.0.0.0/24 and 1.1.1.0/24 for > research purposes. That leaves one more significant prefix to deal with: > 1.2.3.0/24. It is significant because it contains the IP address 1.2.3.4. > > > > 1.2.3.4 is a desirable IP address. It can be used in all sorts of very > interesting applications. It also receives an enormous amount of “junk” > traffic every day, so it requires a fairly hefty infrastructure just to > start routing it. > > > My idea is that APNIC should make this prefix available to all parties who > want it. To decide who gets it, I propose an AUCTION where all proceeds go > to a charitable endeavor (perhaps a future APNIC Foundation). As the > potential author of such a proposal, and as the IP address manager at > Microsoft Corporation, I will guarantee that neither I nor my company will > participate in any way in such an auction. This proposal is not to benefit > me or my company. It is to give the prefix out to a network operator who > wants it, in return for money given to charity. > > > > This is a new idea, and is not fully thought out. So I wanted to post it, > get some reactions, and improve the idea. (Or abandon it if people do not > like it.) > > > > Thank you. > > > > David > > > > *David R Huberman* > Principal, Global IP Addressing > > Microsoft Corporation > > > -- -- 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. -- -- 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] Idea for 1.2.3.0/24
No worries. I'm less worried about the use of this prefix than its use 'for good'. We do have to remember that this prefix is the IP equivalent of 256 barrels of radioactive waste. Toxic to all who touch them. I'm sure Geoff can give the exact Geiger counter measurements :) I'm in favour of finding a use for this prefix, but we have a duty of care to ensure that end users are not harmed. Supporting someone who can reuse toxic waste to fight cancer... Great Idea! Selling it to the highest bidder to use as a cheap house paint additive... Not such a great idea. Even if you donate the money to charity. Thanks for bringing this topic up David, now we just have to find the right thing to support. Ideas? Dean On Friday, 22 May 2015, David Huberman wrote: > Dean, > > > > Thank you for your excellent reply. > > > > I am all for working together to identify a way to get 1.2.3.0/24 into > the hands of a network operator who can do good things with it. The prefix > is trapped in APNIC right now with nowhere to go, and it’s time to set it > free. > > > > More ideas everyone! We can have a great discussion about it, here and in > Jakarta. > > > > /david > > > > > * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] An interesting policy question
Good Morning, InternetNZ, as the host of APRICOT 2016 would like to take this opportunity to reiterate that it seeks to support the APNIC Policy SIG session during APRICOT 2016 to be an environment where everyone can have their point of view heard in a safe environment. To this end InternetNZ, in association with the APIA board, have worked to develop the following Code of Conduct / Anti-harrassment Policy which will be in place for the entire APRICOT 2016 summit. We look forward to ensuring that everyone has a great time. See you all in Auckland! Regards Dean - APRICOT Code of Conduct/ Anti-harassment Policy We value your being at APRICOT 2016 and want everyone to feel safe and included! APRICOT is dedicated to providing a harassment-free conference experience for everyone, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, nationality, age or religion. We do not tolerate harassment of conference participants in any form. Conference participants violating these rules may be sanctioned or expelled from the conference without a refund at the discretion of the conference organizers. Harassment includes, but is not limited to: Deliberate intimidation or stalking Harassing photography or recording Sustained disruption of talks or other events Inappropriate physical contact Unwelcome sexual attention Verbal comments that reinforce social structures of domination related to gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, nationality, age, religion. Advocating for, or encouraging, any of the above behaviour. Sexual images in public spaces If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact a member of APRICOT’s staff immediately. APRICOT staff will be happy to help participants contact venue security or NZ Police, provide escorts, or otherwise assist those experiencing harassment to feel safe for the duration of APRICOT. We expect participants to follow these rules at all APRICOT venues and related social events. This includes all online/digital spaces. If you have any questions, don't understand some of the policy or would like to discuss this policy please contact any member of APRICOT staff who would be happy to discuss arrange for someone to discuss it with you. -- * 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-115 revised.
Fujisaki-San. Thank you for this updated submission. I would like to address one point you make in your email. You seem to be suggesting that this proposal is not yet complete and the authors are in fact seeking community feedback at this time. "At this time, in the next sig meeting, we would like to discuss more about the methods and find a conclusion." While this is understandable, I believe that there are some aspects of this situation which need to be addressed. a) if there is an acknowledgement by the authors that the proposal is as yet incomplete, then it should be withdrawn and an 'informational' session held at the policy sig in its place. b) there may be a feeling by the authors that a proposal is the only mechanism available to them. They may feel that the community provides inadequate feedback unless there is a proposal being discussed. I have some sympathy for this point of view, but I believe that it sets a dangerous precedent where proposals are brought to the community where a more informal method of engagement would be more appropriate. c) InternetNZ has a number of policy principles which guide its response to issues. One of them is: "Internet governance should be determined by open, multi-stakeholder processes." Even with the advances in Policy SIG remote participation, care must be taken before points discussed at the policy sig meeting could be claimed to be supported by a multi-stakeholder process. If for example we find ourselves at a Policy SIG meeting making substantive changes to a policy before calling for consensus, it could be argued that this excludes a significant proportion of the Internet community who may be effected by these changes. Ensuring that policy wording is essentially complete, and presented to the mailing list by the time the meeting starts ensures that the largest possible community has had an opportunity for engagement and therefore can be considered a true multi-stakeholder process. Therefore I suggest the following ways forward 1) If the authors feel that the proposal will not be complete by the time of the Policy SIG meeting, that the proposal be reframed as an Informational Session for community discussion during the meeting or 2) That the authors lead an open discussion of the methods on the mailing list with a view to presenting a single finished version before the Policy SIG meeting. This will ensure that substantive changes are not required during the meeting. If such a version is not ready, then as per 1) it should be changed to an Informational Session. Kind Regards Dean Pemberton On Wednesday, 10 February 2016, 藤崎智宏 wrote: > Dear all, > > We've posted new version of prop-115, and it will appear on the web soon. > > Main modification points are: > - remove IPv4 text > - propose several methods to register and distribute IPv6 assignment >information (thank you for your suggestion in the previous sig meeting) > > Authors discussed about methods, but could not reach a decision which to > be used. At this time, in the next sig meeting, we would like to discuss > more > about the methods and find a conclusion. > > We appreciate if you give us any comments or suggestions. > > Yours Sincerely, > -- > Ruri Hiromi > Tomohiro Fujisaki > * 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
