Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]
With these statistics, I fail to see the problem that was being addressed as opposed to the problem is now causes by limiting the way people do their business. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Thu, Feb 1, 2018 at 7:29 PM, Guangliang Pan <g...@apnic.net> wrote: > Hello Owen, > > > > There is 1.86% of the delegations from 103/8 block have been transferred > by M Out of that, only 5 ranges transferred more than once. > > > > There are 152 members acquired 103/8 ranges via M transfers. It is 1% of > the total membership (includes members under NIRs). Out of that, 123 > members received one range, 16 members received two ranges and 13 members > received more two ranges. > > > > Kind regards, > > Guangliang > > == > > > > > > > > *From:* Owen DeLong [mailto:o...@delong.com] > *Sent:* Thursday, 1 February 2018 3:00 AM > *To:* Skeeve Stevens <skeeve+sigpol...@eintellegonetworks.asia> > *Cc:* Guangliang Pan <g...@apnic.net>; mailman_SIG-policy < > sig-pol...@apnic.net> > *Subject:* Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer > policy [SECURITY=UNCLASSIFIED] > > > > I would argue that 257 probably represents a significant fraction of the > distributed portion of 103/8. > > > > I would be interested if staff can answer what percentage of the issued > 103/8 resources have been subject > > to one or more M transfers since issuance. I’d be especially interested > in the number instances where > > the same entity has “acquired” more than entity that holds 103/8 block(s). > > > > I am concerned that there could be an emerging pattern of: > > > > 1. Stand up shell entity > > 2. Subscribe shell entity to APNIC and obtain > 103/8 block. > > 3. Merge shell entity into parent entity and M > transfer block into parent’s holdings. > > 4. Lather, rinse, repeat. > > > > Owen > > > > On Jan 31, 2018, at 08:47 , Skeeve Stevens <skeeve+sigpolicy@ > eintellegonetworks.asia> wrote: > > > > This number is so small in the scheme of things it should NOT have been > enshrined in policy. > > > > ...Skeeve > > > > *Skeeve Stevens - Founder & The Architect* - eintellego Networks > (Cambodia) Pte Ltd. > > Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia > > Cell +61 (0)414 753 383 ; Skype: skeeve > > Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; > Twitter: eintellego <https://twitter.com/eintellego> > > LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile > <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve > > > > Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises > > > > On Tue, Jan 30, 2018 at 1:11 PM, Guangliang Pan <g...@apnic.net> wrote: > > Hi Aftab, > > > > The number of M transfers involved 103/8 address block from 15 April > 2011 to 14 Sep 2017 is 257. > > > > Kind regards, > > Guangliang > > == > > > > *From:* Aftab Siddiqui [mailto:aftab.siddi...@gmail.com] > *Sent:* Monday, 29 January 2018 8:49 PM > *To:* Guangliang Pan <g...@apnic.net> > *Cc:* Sanjeev Gupta <sanj...@dcs1.biz>; mailman_SIG-policy < > sig-pol...@apnic.net> > *Subject:* Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer > policy [SECURITY=UNCLASSIFIED] > > > > Hi Guangliang, > > How many M were processed for 103/8 address block from 15 April 2011 to > 14 Sep 2017. > > > > On Mon, 29 Jan 2018 at 06:43 Guangliang Pan <g...@apnic.net> wrote: > > Hi Sanjeev, > > > > The number of delegations from 103/8 pool since 29 Jan 2013 (Five years > count back from today) to 14 Sep 2017 is 10868. These are the delegations > are not allowed to transfer as of today according to prop-116-v006. > > > > Kind regards, > > Guangliang > > = > > > > > > *From:* sig-policy-boun...@lists.apnic.net [mailto:sig-policy
Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]
Owen, Of course, there is the possibility (probability) of this, but that would be stupid as the costs of maintaining companies would exceed CGN or other methods to alleviate the need. The issue here is that APNIC needs to be satisfied it is a real M, which should not be that hard to do. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Thu, Feb 1, 2018 at 4:00 AM, Owen DeLong <o...@delong.com> wrote: > I would argue that 257 probably represents a significant fraction of the > distributed portion of 103/8. > > I would be interested if staff can answer what percentage of the issued > 103/8 resources have been subject > to one or more M transfers since issuance. I’d be especially interested > in the number instances where > the same entity has “acquired” more than entity that holds 103/8 block(s). > > I am concerned that there could be an emerging pattern of: > > 1. Stand up shell entity > 2. Subscribe shell entity to APNIC and obtain 103/8 block. > 3. Merge shell entity into parent entity and M transfer block into > parent’s holdings. > 4. Lather, rinse, repeat. > > Owen > > On Jan 31, 2018, at 08:47 , Skeeve Stevens <skeeve+sigpolicy@ > eintellegonetworks.asia> wrote: > > This number is so small in the scheme of things it should NOT have been > enshrined in policy. > > > ...Skeeve > > *Skeeve Stevens - Founder & The Architect* - eintellego Networks > (Cambodia) Pte Ltd. > Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia > Cell +61 (0)414 753 383 ; Skype: skeeve > Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; > Twitter: eintellego <https://twitter.com/eintellego> > LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile > <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve > > Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises > > On Tue, Jan 30, 2018 at 1:11 PM, Guangliang Pan <g...@apnic.net> wrote: > >> Hi Aftab, >> >> >> >> The number of M transfers involved 103/8 address block from 15 April >> 2011 to 14 Sep 2017 is 257. >> >> >> >> Kind regards, >> >> Guangliang >> >> == >> >> >> >> *From:* Aftab Siddiqui [mailto:aftab.siddi...@gmail.com] >> *Sent:* Monday, 29 January 2018 8:49 PM >> *To:* Guangliang Pan <g...@apnic.net> >> *Cc:* Sanjeev Gupta <sanj...@dcs1.biz>; mailman_SIG-policy < >> sig-pol...@apnic.net> >> *Subject:* Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer >> policy [SECURITY=UNCLASSIFIED] >> >> >> >> Hi Guangliang, >> >> How many M were processed for 103/8 address block from 15 April 2011 to >> 14 Sep 2017. >> >> >> >> On Mon, 29 Jan 2018 at 06:43 Guangliang Pan <g...@apnic.net> wrote: >> >> Hi Sanjeev, >> >> >> >> The number of delegations from 103/8 pool since 29 Jan 2013 (Five years >> count back from today) to 14 Sep 2017 is 10868. These are the delegations >> are not allowed to transfer as of today according to prop-116-v006. >> >> >> >> Kind regards, >> >> Guangliang >> >> = >> >> >> >> >> >> *From:* sig-policy-boun...@lists.apnic.net [mailto:sig-policy-bounces@lis >> ts.apnic.net] *On Behalf Of *Sanjeev Gupta >> *Sent:* Monday, 29 January 2018 3:34 PM >> *To:* Henderson Mike, Mr <michael.hender...@nzdf.mil.nz> >> *Cc:* mailman_SIG-policy <sig-pol...@apnic.net> >> *Subject:* Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer >> policy [SECURITY=UNCLASSIFIED] >> >> >> >> Hi, >> >> >> >> I see this as more of a "do not make policy retroactively". People who >> "bought" an "asset" in good faith should not be told it is worth different >> now. >> >> >> >> I am amenable to changing the cut-off date in Prop-123 to the date it was >> sent to the Policy SIG, as that might have given warning to people the >> rules were
Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]
I have multiple clients who are going through M of smaller ISPs and now have resources they need to use but can't combine them under their membership and have to maintain a legal company just to hold the resources. This could cost a couple of thousand dollars per year in Australia for ASIC fees, Annual Tax Returns and Accountant Fees. I am considering advising clients to let the companies die, keep records of an internal transfer of assets (resources), and point lawyers at APNIC if they do not update the registry records. In an M there is no need to justify the use of resources as they are already using them and will continue to do so under the original (whatever that is) justification. It is not the right of APNIC to interfere with a business lawfully carrying on its operations and I think the courts will agree. APNIC is a registry operator and record keeper. They are already drifting from their chartered purpose too much in my opinion and should be put back in their place. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Tue, Jan 30, 2018 at 9:08 PM, andrew khoo <andrew.k...@as136019.net> wrote: > we will vote to support this policy. > > as a practical example, the organisation i work for will be affected by > this policy. > > the organisation (a mobile MVNO) acquired a business in 2016 with a /22 > from the 103/8 range with the intention of offering fixed line services. > > we are seeking to merge the purchased entity's /22 into our APNIC account. > > if we do not do this, the details in APNIC whois for the purchased entity > will soon be no longer valid. > > > > > On Tue, Jan 30, 2018 at 1:11 PM, Guangliang Pan <g...@apnic.net> wrote: > >> Hi Aftab, >> >> >> >> The number of M transfers involved 103/8 address block from 15 April >> 2011 to 14 Sep 2017 is 257. >> >> >> >> Kind regards, >> >> Guangliang >> >> == >> >> >> >> *From:* Aftab Siddiqui [mailto:aftab.siddi...@gmail.com] >> *Sent:* Monday, 29 January 2018 8:49 PM >> *To:* Guangliang Pan <g...@apnic.net> >> *Cc:* Sanjeev Gupta <sanj...@dcs1.biz>; mailman_SIG-policy < >> sig-pol...@apnic.net> >> >> *Subject:* Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer >> policy [SECURITY=UNCLASSIFIED] >> >> >> >> Hi Guangliang, >> >> How many M were processed for 103/8 address block from 15 April 2011 to >> 14 Sep 2017. >> >> >> >> On Mon, 29 Jan 2018 at 06:43 Guangliang Pan <g...@apnic.net> wrote: >> >> Hi Sanjeev, >> >> >> >> The number of delegations from 103/8 pool since 29 Jan 2013 (Five years >> count back from today) to 14 Sep 2017 is 10868. These are the delegations >> are not allowed to transfer as of today according to prop-116-v006. >> >> >> >> Kind regards, >> >> Guangliang >> >> = >> >> >> >> >> >> *From:* sig-policy-boun...@lists.apnic.net [mailto:sig-policy-bounces@lis >> ts.apnic.net] *On Behalf Of *Sanjeev Gupta >> *Sent:* Monday, 29 January 2018 3:34 PM >> *To:* Henderson Mike, Mr <michael.hender...@nzdf.mil.nz> >> *Cc:* mailman_SIG-policy <sig-pol...@apnic.net> >> *Subject:* Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer >> policy [SECURITY=UNCLASSIFIED] >> >> >> >> Hi, >> >> >> >> I see this as more of a "do not make policy retroactively". People who >> "bought" an "asset" in good faith should not be told it is worth different >> now. >> >> >> >> I am amenable to changing the cut-off date in Prop-123 to the date it was >> sent to the Policy SIG, as that might have given warning to people the >> rules were changing. >> >> >> >> APNIC Secretariat, how many transfers will be affected by Prop-123? >> >> >> >> >> -- >> Sanjeev Gupta >> +65 98551208 <+65%209855%201208> http://sg.linkedin.com/in/ghane >> >> >> >> On Mon, Jan 29, 2018 at 4:16 AM, Henderson Mike, Mr < >
Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]
This number is so small in the scheme of things it should NOT have been enshrined in policy. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Tue, Jan 30, 2018 at 1:11 PM, Guangliang Pan <g...@apnic.net> wrote: > Hi Aftab, > > > > The number of M transfers involved 103/8 address block from 15 April > 2011 to 14 Sep 2017 is 257. > > > > Kind regards, > > Guangliang > > == > > > > *From:* Aftab Siddiqui [mailto:aftab.siddi...@gmail.com] > *Sent:* Monday, 29 January 2018 8:49 PM > *To:* Guangliang Pan <g...@apnic.net> > *Cc:* Sanjeev Gupta <sanj...@dcs1.biz>; mailman_SIG-policy < > sig-pol...@apnic.net> > *Subject:* Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer > policy [SECURITY=UNCLASSIFIED] > > > > Hi Guangliang, > > How many M were processed for 103/8 address block from 15 April 2011 to > 14 Sep 2017. > > > > On Mon, 29 Jan 2018 at 06:43 Guangliang Pan <g...@apnic.net> wrote: > > Hi Sanjeev, > > > > The number of delegations from 103/8 pool since 29 Jan 2013 (Five years > count back from today) to 14 Sep 2017 is 10868. These are the delegations > are not allowed to transfer as of today according to prop-116-v006. > > > > Kind regards, > > Guangliang > > = > > > > > > *From:* sig-policy-boun...@lists.apnic.net [mailto:sig-policy-bounces@ > lists.apnic.net] *On Behalf Of *Sanjeev Gupta > *Sent:* Monday, 29 January 2018 3:34 PM > *To:* Henderson Mike, Mr <michael.hender...@nzdf.mil.nz> > *Cc:* mailman_SIG-policy <sig-pol...@apnic.net> > *Subject:* Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer > policy [SECURITY=UNCLASSIFIED] > > > > Hi, > > > > I see this as more of a "do not make policy retroactively". People who > "bought" an "asset" in good faith should not be told it is worth different > now. > > > > I am amenable to changing the cut-off date in Prop-123 to the date it was > sent to the Policy SIG, as that might have given warning to people the > rules were changing. > > > > APNIC Secretariat, how many transfers will be affected by Prop-123? > > > > > -- > Sanjeev Gupta > +65 98551208 <+65%209855%201208> http://sg.linkedin.com/in/ghane > > > > On Mon, Jan 29, 2018 at 4:16 AM, Henderson Mike, Mr < > michael.hender...@nzdf.mil.nz> wrote: > > Not supported > > > > The proposal should in my opinion be amended to read: > > ___ > > Disadvantages: > > > > None Completely negates the purpose of prop-116-v006: Prohibit to transfer > IPv4 addresses in > > the final /8 block. > > ___ > > > > > > Regards > > > > > > *Mike* > > > > *From:* sig-policy-boun...@lists.apnic.net [mailto:sig-policy-bounces@ > lists.apnic.net] *On Behalf Of *Bertrand Cherrier > *Sent:* Friday, 26 January 2018 4:28 p.m. > *To:* sig-pol...@apnic.net > *Subject:* [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy > > > > Dear SIG members, > > The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has > been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 45 in > Kathmandu, Nepal on Tuesday, 27 February 2018. > > 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-123 > > Regards > > Sumon, Bertr
Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
I agree, but there needs to be some protection for APNIC on the resources left. But I think the APNIC EC can probably decide on the best way to evaluate this themselves. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Mon, Jan 29, 2018 at 7:03 PM, Rajesh Panwala <raj...@smartlinkindia.com> wrote: > Dear Team, > > My submission is " All M cases should be excluded from denying the > transfer." > > As M is routine business activity, there is no point barring transfer. > > regards, > > Rajesh Panwala > For Smartlink Solutions Pvt. Ltd. > +91-9227886001 > > On Mon, Jan 29, 2018 at 12:04 PM, Sanjeev Gupta <sanj...@dcs1.biz> wrote: > >> Rajesh, the issue will be that the Secretariat has to be given a clear >> definition of "genuine". It is unfair to them to expect that they >> administer a rule which is not well defined. >> >> Putting a date makes life clear (not better, but clear). >> >> >> -- >> Sanjeev Gupta >> +65 98551208 http://sg.linkedin.com/in/ghane >> >> On Mon, Jan 29, 2018 at 1:52 PM, Rajesh Panwala < >> raj...@smartlinkindia.com> wrote: >> >>> I partially support the policy. For genuine M cases , there should not >>> be any restriction on transfer of resources. M activities are part and >>> parcel of routine business and no one knows when will it take place. >>> >>> regards, >>> >>> Rajesh Panwala >>> For Smartlink Solutions Pvt. Ltd. >>> +91-9227886001 <+91%2092278%2086001> >>> >>> On Fri, Jan 26, 2018 at 8:57 AM, Bertrand Cherrier < >>> b.cherr...@micrologic.nc> wrote: >>> >>>> Dear SIG members, >>>> >>>> The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has >>>> been sent to the Policy SIG for review. >>>> >>>> It will be presented at the Open Policy Meeting at APNIC 45 in >>>> Kathmandu, Nepal on Tuesday, 27 February 2018. >>>> >>>> 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-123 >>>> >>>> Regards >>>> >>>> Sumon, Bertrand, Ching-Heng >>>> APNIC Policy SIG Chairs >>>> >>>> https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt >>>> >>>> --- >>>> >>>> prop-123-v001: Modify 103/8 IPv4 transfer policy >>>> >>>> --- >>>> >>>> Proposer:Alex Yang >>>> yang...@126.com >>>> >>>> >>>> 1. Problem statement >>>> --- >>>> >>>> Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in >>>> the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep >>>> 2017. Since that APNIC has stopped all the IPv4 transfers from 103/8 >>>> block if the delegation date is less than 5 years. >>>> >>>> However, some of the 103/8 ranges were delegated before 14 Sep 2017. >>>> Those resources should not b
Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
So define it better. This could be undertaken by the EC outside the scope of policy IMHO. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Mon, Jan 29, 2018 at 5:34 PM, Sanjeev Gupta <sanj...@dcs1.biz> wrote: > Rajesh, the issue will be that the Secretariat has to be given a clear > definition of "genuine". It is unfair to them to expect that they > administer a rule which is not well defined. > > Putting a date makes life clear (not better, but clear). > > > -- > Sanjeev Gupta > +65 98551208 http://sg.linkedin.com/in/ghane > > On Mon, Jan 29, 2018 at 1:52 PM, Rajesh Panwala <raj...@smartlinkindia.com > > wrote: > >> I partially support the policy. For genuine M cases , there should not >> be any restriction on transfer of resources. M activities are part and >> parcel of routine business and no one knows when will it take place. >> >> regards, >> >> Rajesh Panwala >> For Smartlink Solutions Pvt. Ltd. >> +91-9227886001 <+91%2092278%2086001> >> >> On Fri, Jan 26, 2018 at 8:57 AM, Bertrand Cherrier < >> b.cherr...@micrologic.nc> wrote: >> >>> Dear SIG members, >>> >>> The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has >>> been sent to the Policy SIG for review. >>> >>> It will be presented at the Open Policy Meeting at APNIC 45 in >>> Kathmandu, Nepal on Tuesday, 27 February 2018. >>> >>> 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-123 >>> >>> Regards >>> >>> Sumon, Bertrand, Ching-Heng >>> APNIC Policy SIG Chairs >>> >>> https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt >>> >>> --- >>> >>> prop-123-v001: Modify 103/8 IPv4 transfer policy >>> >>> --- >>> >>> Proposer:Alex Yang >>> yang...@126.com >>> >>> >>> 1. Problem statement >>> --- >>> >>> Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in >>> the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep >>> 2017. Since that APNIC has stopped all the IPv4 transfers from 103/8 >>> block if the delegation date is less than 5 years. >>> >>> However, some of the 103/8 ranges were delegated before 14 Sep 2017. >>> Those resources should not be subjected to 5 years restriction. The >>> community was not aware of the restriction when they received those >>> resources, some of the resources have been transferred or planning to >>> transfer. If APNIC is not allow those transfers to be registered, >>> there will be underground transfers. This will cause incorrect APNIC >>> Whois data. >>> >>> >>> 2. Objective of policy change >>> --- >>> >>> To keep the APNIC Whois data correct. >>> >>> >>> 3. Situation in other regions >>> --- >>> >>> No such situation in other regions. >>> >
Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
Agreed. I do agree that there needs to be some protections to avoid abuse of the last /8 resources, but, there seems to be a policy failure elsewhere in APNIC in relation to the evaluation of M which is allowing abusive transactions to occur. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Mon, Jan 29, 2018 at 4:52 PM, Rajesh Panwala <raj...@smartlinkindia.com> wrote: > I partially support the policy. For genuine M cases , there should not > be any restriction on transfer of resources. M activities are part and > parcel of routine business and no one knows when will it take place. > > regards, > > Rajesh Panwala > For Smartlink Solutions Pvt. Ltd. > +91-9227886001 > > On Fri, Jan 26, 2018 at 8:57 AM, Bertrand Cherrier < > b.cherr...@micrologic.nc> wrote: > >> Dear SIG members, >> >> The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has >> been sent to the Policy SIG for review. >> >> It will be presented at the Open Policy Meeting at APNIC 45 in >> Kathmandu, Nepal on Tuesday, 27 February 2018. >> >> 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-123 >> >> Regards >> >> Sumon, Bertrand, Ching-Heng >> APNIC Policy SIG Chairs >> >> https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt >> >> --- >> >> prop-123-v001: Modify 103/8 IPv4 transfer policy >> >> --- >> >> Proposer:Alex Yang >> yang...@126.com >> >> >> 1. Problem statement >> --- >> >> Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in >> the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep >> 2017. Since that APNIC has stopped all the IPv4 transfers from 103/8 >> block if the delegation date is less than 5 years. >> >> However, some of the 103/8 ranges were delegated before 14 Sep 2017. >> Those resources should not be subjected to 5 years restriction. The >> community was not aware of the restriction when they received those >> resources, some of the resources have been transferred or planning to >> transfer. If APNIC is not allow those transfers to be registered, >> there will be underground transfers. This will cause incorrect APNIC >> Whois data. >> >> >> 2. Objective of policy change >> --- >> >> To keep the APNIC Whois data correct. >> >> >> 3. Situation in other regions >> --- >> >> No such situation in other regions. >> >> >> 4. Proposed policy solution >> --- >> >> “Prohibit transfer IPv4 addresses under final /8 address block (103/8) >> which have not passed five years after its allocation/assignment” >> should only apply to those ranges were delegated from APNIC since 14 >> Sep 2017. >> >> >> 5. Advantages / Disadvantages >> --- >> >> Advantages: >> >> - Allow APNIC to register those 103/8 transfers to keep the APNIC >> Whois data correct. >> >> >> Disadvantage
Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy
I very much support this policy. A policy should not be retrospectively applied otherwise anything any of us may do or plan to do can be considered guaranteed, and I would see a case for requesting APNIC to return funds for any services provided that have been negated by policy changes. I also very much object to the 5 year period that snuck in at the last APNIC meeting. I was happy with 2 years, but 5 years is unreasonable. I was going to make a submission to change this back to 2 years, but unfortunately, work got in the way and I did not get the submission in on time. Next meeting maybe. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Fri, Jan 26, 2018 at 2:27 PM, Bertrand Cherrier <b.cherr...@micrologic.nc > wrote: > Dear SIG members, > > The proposal "prop-123-v001: Modify 103/8 IPv4 transfer policy" has > been sent to the Policy SIG for review. > > It will be presented at the Open Policy Meeting at APNIC 45 in > Kathmandu, Nepal on Tuesday, 27 February 2018. > > 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-123 > > Regards > > Sumon, Bertrand, Ching-Heng > APNIC Policy SIG Chairs > > https://www.apnic.net/wp-content/uploads/2018/01/prop-123-v001.txt > > --- > > prop-123-v001: Modify 103/8 IPv4 transfer policy > > --- > > Proposer:Alex Yang > yang...@126.com > > > 1. Problem statement > --- > > Policy Proposal prop-116-v006: Prohibit to transfer IPv4 addresses in > the final /8 block reached consensus at the APNIC 44 AMM on 14 Sep > 2017. Since that APNIC has stopped all the IPv4 transfers from 103/8 > block if the delegation date is less than 5 years. > > However, some of the 103/8 ranges were delegated before 14 Sep 2017. > Those resources should not be subjected to 5 years restriction. The > community was not aware of the restriction when they received those > resources, some of the resources have been transferred or planning to > transfer. If APNIC is not allow those transfers to be registered, > there will be underground transfers. This will cause incorrect APNIC > Whois data. > > > 2. Objective of policy change > --- > > To keep the APNIC Whois data correct. > > > 3. Situation in other regions > --- > > No such situation in other regions. > > > 4. Proposed policy solution > --- > > “Prohibit transfer IPv4 addresses under final /8 address block (103/8) > which have not passed five years after its allocation/assignment” > should only apply to those ranges were delegated from APNIC since 14 > Sep 2017. > > > 5. Advantages / Disadvantages > --- > > Advantages: > > - Allow APNIC to register those 103/8 transfers to keep the APNIC > Whois data correct. > > > Disadvantages: > > None. > > > 6. Impact on resource holders > --- > > Resource holders are allowed to transfer 103/8 ranges if the resources > were delegated before 14 Sep 2017. > > > > 7. References > --- > > > * sig-policy: APNIC SIG on resource management policy >* > ___ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy > * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] APNIC 45 Proposal deadline
Hey Bertrand, Can I make a request to propose a polict remotely? I will try to be there, but I will need to see how I go. ...Skeeve *Skeeve Stevens - Founder & The Architect* - eintellego Networks (Cambodia) Pte Ltd. Email: ske...@eintellegonetworks.asia ; Web: eintellegonetworks.asia Cell +61 (0)414 753 383 ; Skype: skeeve Facebook: eintellegonetworks <http://facebook.com/eintellegonetworks> ; Twitter: eintellego <https://twitter.com/eintellego> LinkedIn: /in/skeeve <http://linkedin.com/in/skeeve> ; Expert360: Profile <https://expert360.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises On Thu, Dec 14, 2017 at 2:10 PM, Bertrand Cherrier <b.cherr...@micrologic.nc > wrote: > Dear Colleagues, > > The APNIC 45 Policy SIG session and Open Policy Meeting (OPM) will be > held in Kathmandu, Nepal on Tuesday, 27 February 2018. > > https://conference.apnic.net/45 > > If you have any ideas to improve policy, or wish to make an informational > presentation about an aspect of resource management, please follow the > instructions below. > > The submission deadline for APNIC 45 is Friday, 19 January 2018. > Submit a Proposal or Presentation > > To propose a new policy, or submit a presentation synopsis visit the > APNIC 45 website. > > https://conference.apnic.net/45/policy/call-for-proposals/ > > We look forward to and encourage your participation in the APNIC 45 OPM. > > Kind regards, > > Sumon, Bertrand, Ching-Heng > Policy SIG Chairs > > Cordialement, > -- > > Bertrand Cherrier > Administration Systèmes - R > Micro Logic Systems > b.cherr...@micrologic.nc > https://www.mls.nc > Tél : +687 24 99 24 > VoIP : 65 24 99 24 > SAV : +687 36 67 76 (58F/min) > -- > > * sig-policy: APNIC SIG on resource management policy >* > ___ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy > * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] Proposal to revise SIG guidelines
This is worrying re Confer as I am quite sure I could register 100,000 people with unique addresses. We've entered a new era of bots - this would not be hard. ...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 ; Keybase: https://keybase.io/skeeve IP Address Brokering - Introducing sellers and buyers On Tue, Sep 6, 2016 at 9:14 AM, Adam Gosling <a...@apnic.net> wrote: > Hi Randy > > > >>>> On 5/09/2016, 20:52, "Randy Bush" <ra...@psg.com> wrote: > > >> [ this is address policy? ] > > No this is not address policy. The SIG Guidelines are the rules of > procedure for all SIGs. The proposal was also sent to the other SIG mailing > lists, but will be discussed in the Policy SIG as there is more agenda time > there. > > >> Secondary, it can be used by fraud, like hijacking the position of > >> Chair agaist the Community by inviting many persons who never attend > >> the community discussion. > >> ... > >> I would like to propose limiting eligible voters of SIG Chair > election > >> to registered participants of APNIC Conference where the election is > >> held. > >> > >> In this context, registered participants include remote participants > >> who register to Confer, or its successor in future. > > is there an unstated assumption that many persons could attend the > meeting who are not registered locally or remotely? does that > assumption hold? > > The Secretariat doesn’t physically check registrations at the door to the > Policy SIG sessions, I guess a bunch of extra people could wander in > without badges. I’m not sure if we would notice. > > At present remote participation (using the CONFER tool) only requires a > simple registration with unique email address. We tried more stringent > registration procedures with the Webcasting (like ARIN) and got a lot of > negative feedback. > > > > I would like to propose aligning Chair' term with Co-Chair's term, > > which means that Chair and all Co-Chair will serve for same two > years. > > could make for a tough transition if both are replaced at the same > time. > > > randy > > > * sig-policy: APNIC SIG on resource management policy >* > ___ > sig-policy mailing list > sig-policy@lists.apnic.net > https://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net https://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] An interesting policy question
Dean, This is a good policy and should be the sort of thing that is in place at all conferences, not just 2016. ...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 ; Keybase: https://keybase.io/skeeve IP Address Brokering - Introducing sellers and buyers On Mon, Dec 7, 2015 at 10:08 AM, Dean Pemberton <d...@internetnz.net.nz> wrote: > 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 > > * 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
Hi Lu, 1st: I would say no. There are no followups after allocation and there should not be due to the many complication issues that can happen. 2nd: I would say no. The changing of network infrastructure should NOT invalidate the original request which is approved. ...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 ; Keybase: https://keybase.io/skeeve IP Address Brokering - Introducing sellers and buyers On Fri, Dec 4, 2015 at 8:12 PM, Lu Heng <h...@anytimechinese.com> wrote: > Hi > > I have an policy question regarding the "need". > > We all know when RIR makes approves assignment LIR made if it is beyond > LIR's assignment window, while the "need" has changed, the assignment > become invalid. > > The question come to what the definition of need, as a young people here, > I am a bit confused, Below I have few examples, please enlighten me if > anyone has an thought about it. > > First one: > > Company A provides 100 customer dedicated server service at location A, > RIR makes an assignment for 100 IP for his infrastructure, if, under > condition that no other factor was changed, Company A moved his > infrastructure to location B, but still providing same service to same > customer, does the company's action need to be notified to RIR? And does > this action considered invalid the original assignment? > > Second one: > > Company A provides web hosting service, but any casted in 3 location, and > has provided the evidence of 3 location to the RIR during the time the > company getting valid assignment, then A decided to cut 3 location to 2 > location, does this invalid original assignment and need to be notified to > RIR? > > So the bottom line is, what is the definition of need, is it defined as > the service you are providing or defined as whole package of any of > original justification material was provided, if was the later, then does > it imply that anything, including location of the infrastructure, upstream > providers etc has changed due to operational need, it will be considered as > change of purpose of use and need to be notified to RIR? > > What should be the right interpretation of the policy by then? > > -- > -- > Kind regards. > Lu > > > * 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-115 returned to author for further consideration
Masato-san, With the greatest respect for Tomohiro-san and Ruri-san and yourself, I am very disappointed with your decision to return prop-115 to the list AGAIN for discussion and for a survey. You asked for consensus on a Survey and asked who was FOR it - no one (I can see)... who was AGAINST - no one (I can see). Your response was "since there is no objection to have such survey" - BUT there was no support either! You've chose to spend money and time of APNICs on something that no one cares about - at all. You say below that the proposal did not reach consensus. NO ONE supporting it - apart from the authors is the definition of consensus - which is that it is *not* supported. It is also now at its third version and there is STILL no support. (for history see https://www.apnic.net/policy/proposals/prop-115) It had no support even in Japan at APNIC 39 - does this not say something that a policy in the home country does not even get up? Masato, why are you keeping this proposal alive? to the point of spending money and resources on it. This is starting to smell like you are looking out for a fellow countryman or APNIC wants it to happen. I would hope as Chair this would not be the case, but all indications point to it as you will not let it die based on the overwhelming lack of support the proposal has. I have nothing against this policy as such... I just think that it is an overhead that the ISPs rather than APNIC needs to do. I am not against it... or for it. But I am against you trying to push along a policy on life-support until people get so bored someone supports it into existence. Community... if you support this proposal... then SHOW you do... here... now. If you do NOT support it, then please (again) also state that you do not - before money is spent on it. ...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 ; Keybase: https://keybase.io/skeeve IP Address Brokering - Introducing sellers and buyers On Sun, Sep 13, 2015 at 1:15 AM, Masato Yamanishi <myama...@gmail.com> wrote: > Dear colleagues > > Version 3 of prop-115: Registration of detailed assignment information > in whois DB, did not reach consensus at the APNIC 40 Open > Policy Meeting. > > The Policy SIG Chair requested the Secretariat conduct further research > into the problem statement and returned the proposal to the authors for > further consideration. > > Proposal details > > > This proposal seeks to require LIRs to register accurate filtering > information, such as IPv4 port-range information and IPv6 assignment > prefix size. > > Proposal details, including the full text of the proposal, history, and > links to the APNIC 40 meeting archive, are available at: > > http://www.apnic.net/policy/proposals/prop-115 > > Regards > > Masato and Sumon > > > > > prop-115-v003: 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. > > Without this information, operators cannot filter out specific > address range, and it might lead to 'over-filter' (i.e. filtering > whole ISP's address range). > > For example: > > 1) 'Port' range information in IPv4 > >ISPs are using 'CGN' or other kinds of IPv4 address sharing >technology with assignment of IP address and specified port >range to their users. > >In this case, port information is necessary to specify one user. > >ex) 192.0.2.24/32 1-256 is for HomeA >192.0.2.24/32 257-511 is for HomeB > >or 192.0.2.0/24 1-65536 is shared address of ISP-X >minimum size is /32 > > 2) address assignment size information in IPv6 > >The IPv6 address assignment size may be different from ISP and >its service estimation. Address assignment prefix size will be >necessary. > >ex) 2001:db8:1::0/56 is for HomeA >2001:db8:1:1::0/48 is for HomeB > >or 2001:db8:1::/36's minimum size is /56 > > > 2. Objective of policy change > -
Re: [sig-policy] New version of prop-113: Modification in the IPv4 eligibility criteria
How do you see needs basis going away in this wording? ...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, Mar 5, 2015 at 9:31 AM, Owen DeLong o...@delong.com wrote: +1… I’m with Dean… Still opposed. Let’s keep needs basis in place, please. I’m all for removing the requirement to multihome, but not the requirement to actually need the addresses for an operational network. Owen On Mar 4, 2015, at 16:09 , Dean Pemberton d...@internetnz.net.nz wrote: 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 myama...@gmail.com 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 * 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
Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria
Owen, It just feels like nitpicking and moving chairs around. I actually trust the Secretariat to do the right thing when allocating resources. We're also talking about a resource where there are over 4.1 billion ASN's still available... not that it should be a justification to wastage, but it is useful for context. The APNIC stats are: How many ASN - % of Membership no ASN 34.06% 1 56.59% 2 5.55% 3 1.78% 4 0.77% 5 0.35% 6 0.28% 7 0.15% 8 0.04% 10 0.13% more than 10 0.31% I'm unsure why you guys want to see each and every use-case set in stone. I don't want to have to come back and do amendments picking on a word here or there because there has been an innovation in the way networks are operated. I fully support the idea that this isn't a free-for-all.. but we need some flexibility in the community. ...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, Mar 5, 2015 at 8:33 AM, Owen DeLong o...@delong.com wrote: If said standard pre-existing procedure were subject to the PDP, I’d be fine with that. However, that’s not what the wording implies. In the case of the IPv6 policy, I think this is less than desirable, but it’s not on the table in this discussion. Certainly if someone proposed removing that wording from the IPv6 policy, I would support such a proposal. Owen On Mar 4, 2015, at 14:58 , Skeeve Stevens ske...@v4now.com wrote: Do we just move the 'proposed draft guidelines' to cases under 3.3? We were trying to be flexible for future use cases without going through this painful process for every future valid use case that comes up in future. This is an established process where for subsequent IPv6 allocations: === http://www.apnic.net/policy/ipv6-address-policy#5.3.2 5.3.2 Alternative allocation criteria Alternatively, a subsequent allocation may be provided where an organization (ISP/LIR) can demonstrate a valid reason for requiring the subsequent allocation. For guidelines on what will be considered a valid technical or other reason, see “APNIC guidelines for IPv6 allocation and assignment requests”. http://www.apnic.net/ipv6-guidelines === Why isn't a standard pre-existing procedure acceptable to you? ...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, Mar 5, 2015 at 3:11 AM, Owen DeLong o...@delong.com 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 myama...@gmail.com 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
Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria
Yes, because it seems to make more sense to you to waste everyones time discussing something that could be sorted out as much as possible on the list before we take it to the SIG. Good one. ...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, Mar 5, 2015 at 8:03 AM, Dean Pemberton d...@internetnz.net.nz wrote: I guess we'll get to discuss those issues during the policy sig today. On Thursday, 5 March 2015, Skeeve Stevens ske...@v4now.com wrote: Do we just move the 'proposed draft guidelines' to cases under 3.3? We were trying to be flexible for future use cases without going through this painful process for every future valid use case that comes up in future. This is an established process where for subsequent IPv6 allocations: === http://www.apnic.net/policy/ipv6-address-policy#5.3.2 5.3.2 Alternative allocation criteria Alternatively, a subsequent allocation may be provided where an organization (ISP/LIR) can demonstrate a valid reason for requiring the subsequent allocation. For guidelines on what will be considered a valid technical or other reason, see “APNIC guidelines for IPv6 allocation and assignment requests”. http://www.apnic.net/ipv6-guidelines === Why isn't a standard pre-existing procedure acceptable to you? ...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, Mar 5, 2015 at 3:11 AM, Owen DeLong o...@delong.com 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 myama...@gmail.com 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
Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria
Owen, That is almost, but not quite ok. There may be cases where you have the same reason to do this for a second or third ASN. Say I need one for an isolated network in HK, or NZ, or KH with a completely separate routing policy? The same criteria should apply for the first and 10th? ...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, Mar 5, 2015 at 9:30 AM, Owen DeLong o...@delong.com wrote: I don’t feel the need for every use case to be set in stone, but I do think that there are better ways to address this. Is there any reason that adding the following to the existing policy would be unacceptable to you? … or an organization which has received an assignment or allocation from APNIC and has not previously obtained an ASN may obtain one ASN upon request for purposes of setting up peering for their network with one or more other other autonomous systems. Why would that not suffice? Owen On Mar 4, 2015, at 15:47 , Skeeve Stevens ske...@v4now.com wrote: Owen, It just feels like nitpicking and moving chairs around. I actually trust the Secretariat to do the right thing when allocating resources. We're also talking about a resource where there are over 4.1 billion ASN's still available... not that it should be a justification to wastage, but it is useful for context. The APNIC stats are: How many ASN - % of Membership no ASN 34.06% 1 56.59% 2 5.55% 3 1.78% 4 0.77% 5 0.35% 6 0.28% 7 0.15% 8 0.04% 10 0.13% more than 10 0.31% I'm unsure why you guys want to see each and every use-case set in stone. I don't want to have to come back and do amendments picking on a word here or there because there has been an innovation in the way networks are operated. I fully support the idea that this isn't a free-for-all.. but we need some flexibility in the community. ...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, Mar 5, 2015 at 8:33 AM, Owen DeLong o...@delong.com wrote: If said standard pre-existing procedure were subject to the PDP, I’d be fine with that. However, that’s not what the wording implies. In the case of the IPv6 policy, I think this is less than desirable, but it’s not on the table in this discussion. Certainly if someone proposed removing that wording from the IPv6 policy, I would support such a proposal. Owen On Mar 4, 2015, at 14:58 , Skeeve Stevens ske...@v4now.com wrote: Do we just move the 'proposed draft guidelines' to cases under 3.3? We were trying to be flexible for future use cases without going through this painful process for every future valid use case that comes up in future. This is an established process where for subsequent IPv6 allocations: === http://www.apnic.net/policy/ipv6-address-policy#5.3.2 5.3.2 Alternative allocation criteria Alternatively, a subsequent allocation may be provided where an organization (ISP/LIR) can demonstrate a valid reason for requiring the subsequent allocation. For guidelines on what will be considered a valid technical or other reason, see “APNIC guidelines for IPv6 allocation and assignment requests”. http://www.apnic.net/ipv6-guidelines === Why isn't a standard pre-existing procedure acceptable to you? ...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, Mar 5, 2015 at 3:11 AM, Owen DeLong o...@delong.com 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 myama...@gmail.com 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
Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria
Good question David. Secretariat... can we have those numbers? ...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, Mar 5, 2015 at 9:33 AM, David Farmer far...@umn.edu wrote: On Mar 4, 2015, at 17:47, Skeeve Stevens ske...@v4now.com wrote: ... The APNIC stats are: How many ASN - % of Membership no ASN 34.06% 1 56.59% 2 5.55% 3 1.78% 4 0.77% 5 0.35% 6 0.28% 7 0.15% 8 0.04% 10 0.13% more than 10 0.31% Very interesting and useful stats. Are there non-member ASNs, maybe legacy or historic? If so, how many non-members have ASNs? Or, what is the ratio between member and non-member ASNs? I'm not really expecting that much, but on the other hand I don't want to assume either. -- === 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
[sig-policy] Updated Text - Prop-114v003
In this text, the suggested guidelines have been removed to be replaced with: - you have been previous allocated provider independent address space by APNIC AND - intend to multi-home in the future This policy can be reviewed on an annual basis for any impact on the number of allocations of ASN and if there has been any detrimental effect. == --- prop-114-v003: 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 organisation is eligible for an ASN assignment if: - they are currently multi-homed OR - you have been previous allocated provider independent address space by APNIC AND - intend to multi-home in the future 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. 7. References - == ...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 * 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] Updated Text - Prop-113v003
The only addition to this text was the clarification of demonstrated need. It is not being removed and will remain in place as below. Organizations requesting a delegation under these terms must demonstrate that they are able to use 25% of the requested addresses immediately and 50% within one year. = prop-113-v003: 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 Organizations requesting a delegation under these terms must demonstrate that they are able to use 25% of the requested addresses immediately and 50% within one year. 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. 7. References - ...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 * 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 SIG session schedule
I agree with Izumi. That a policy can be reverted at the AMM when it is passed at Policy SIG is unacceptable. It is duplication, redundant and a waste of time. Policy should be 'reported' at the AMM, but not discussed or debated, as the Policy SIG is the appropriate venue for this. ...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 Tue, Mar 3, 2015 at 6:25 PM, Izumi Okutani iz...@nic.ad.jp 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 myama...@gmail.com 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 ske...@v4now.com 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 tel:%2B61%20%280%29414%20753%20383 ; 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 myama...@gmail.com mailto:myama...@gmail.com wrote: Dear All, While this point was raised by Jessica, Skeeve, and Dean during the ML discussion, it is also big question for me, which day and time-slot is best for Policy SIG. Historically, we have SIG session somewhere in Thu. However, do you think it is a barrier for wider participation? (e.g. many operators are leaving in Thu PM?) Also, which session should not be in parallel with Policy SIG? (I also don't want to miss Lightning talks as Skeeve mentioned) Please share your thoughts on this list
Re: [sig-policy] Policy SIG session schedule
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 ; 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 Mon, Mar 2, 2015 at 11:18 AM, Masato Yamanishi myama...@gmail.com wrote: Dear All, While this point was raised by Jessica, Skeeve, and Dean during the ML discussion, it is also big question for me, which day and time-slot is best for Policy SIG. Historically, we have SIG session somewhere in Thu. However, do you think it is a barrier for wider participation? (e.g. many operators are leaving in Thu PM?) Also, which session should not be in parallel with Policy SIG? (I also don't want to miss Lightning talks as Skeeve mentioned) Please share your thoughts on this list and/or offline in Fukuoka. Regards, Masato Yamanishi APNIC Policy SIG Chair (Acting) * 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
That was bad planning :(. I was thinking of doing a lightening, but policy is more important. ...Skeeve On Saturday, February 28, 2015, Dean Pemberton d...@internetnz.net.nz wrote: We have the first policy sig session on at the same time as the Lightning talks on Thursday. It will be interesting to see which attracts more operators. On Saturday, 28 February 2015, Jessica Shen shen...@cnnic.cn javascript:_e(%7B%7D,'cvml','shen...@cnnic.cn'); wrote: Owen, What do you mean by 'If it’s _THE_ track at that time'? Jessica Shen -原始邮件- 发件人: Owen DeLong o...@delong.com 发送时间: 2015-02-28 05:33:59 (星期六) 收件人: Shen Zhi shen...@cnnic.cn 抄送: Mark Tinka mark.ti...@seacom.mu, sig-policy@lists.apnic.net 主题: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria On Feb 26, 2015, at 22:16 , Shen Zhi shen...@cnnic.cn wrote: Good point, getting greater operator participation in the policy processes is important. APRICOT and APNIC having joint meeting is one of the good ways to bring more operators to APNIC policy discussion. I noticed on the Policy SIG session @APNIC 39, there will be some short background instroductions by APNIC staff (could be someone from the community who is familiar with the policy history in future) before the proposal discussion, I think it's a very good way to faciliate the new comers to understand and join the discussion. I'm thinking if we set part of or whole Policy SIG session on the same days when APRICOT or APCERT sessions are running, say Tuesday, or Wednesday, will it help that more operators attend the policy discussions? That depends. If it’s a parallel track to something operators would consider more interesting, then probably not. If it’s _THE_ track at that time, then it might work, or, it might turn into shopping time, etc. As near as I can tell, the problem is less one of accessibility than interest. Owen Cheers, Jessica Shen -邮件原件- 发件人: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] 代表 Owen DeLong 发送时间: 2015年2月27日 4:42 收件人: Mark Tinka 抄送: sig-policy@lists.apnic.net 主题: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria In theory, this is why each RIR has a public policy process open to any who choose to participate. The fact that operator participation in the process is limited (voluntarily by the operators themselves) continues to cause problems for operators. This not only affects RIRs, but also the IETF, ICANN, and other multi-stakeholder fora covering various aspects of internet governance and development. If you have a suggestion for getting greater operator participation in these processes, I’m all ears. Owen On Feb 25, 2015, at 5:27 PM, Mark Tinka mark.ti...@seacom.mu wrote: While I tend to agree that the current draft policy in its form needs more work, I empathize with the long-held concern of detachment between the RIR and network operations. This is a well-documented issue that affects several other policies within various RIR communities, and not just this one nor APNIC. Take assigned prefix length and what operators filter against as an example. Globally, perhaps we would do well to find way to make RIR operations and policy design reflect the practical day-to-day changes taking place within operator networks, or at the very least, make a provision for them that sufficiently covers what the future may throw up. I don't think any of us have the answers now, but it starts from somewhere. Mark. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy -- -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz javascript:_e(%7B%7D,'cvml','d...@internetnz.net.nz'); To promote the Internet's benefits and uses, and protect its potential. -- ...Skeeve (from an iPhone 6 Plus) * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Yes we did... Like when Cisco started rolling out 1.1.1.1 to Wireless Controllers and other things. ...Skeeve On Friday, February 27, 2015, Dean Pemberton d...@internetnz.net.nz wrote: 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 javascript:; To promote the Internet's benefits and uses, and protect its potential. On Fri, Feb 27, 2015 at 7:19 PM, Aftab Siddiqui aftab.siddi...@gmail.com javascript:; 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 d...@internetnz.net.nz javascript:; wrote: It did say immediate future. I would say that it seems reasonable that if you're claiming that you're going to multihome in the immediate future that you would know the ASNs with whom you were going to peer. If it was more of a Well at some point we might want to multihome, then you might not know the ASN. But in those situations RFC1930 says that you should be using a private AS until such time as you are closer to peering. Dean -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz javascript:; To promote the Internet's benefits and uses, and protect its potential. On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui aftab.siddi...@gmail.com javascript:; wrote: Hi Guangliang, The option b is acceptable. b. If an applicant can demonstrate a plan to be multihomed in immediate future, it is not a must they are physically multihomed at the time of submitting a request But even then applicant has to provide the details of those ASN with whom they may or may not multhome in future. right? Regards, Aftab A. Siddiqui * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net javascript:; http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net javascript:; http://mailman.apnic.net/mailman/listinfo/sig-policy -- ...Skeeve (from an iPhone 6 Plus) * 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 will have new wording soon. ...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 7:03 AM, Masato Yamanishi myama...@gmail.com wrote: Skeeve, As acting chair, I'm neutral for each proposal, but even for me, proposed text sounds everybody can get AS by just saying I need it within 6 months without any explanation howto use it. If your intension is covering more usecases, but not allowing for everyone, can you tweak proposed text? 4. Proposed policy solution --- An organization is eligible for an ASN assignment if it: - Is planning to use it within next 6 months Masato Yamanishi Feb 25, 2015 6:03 PM、Skeeve Stevens ske...@v4now.com のメッセージ: Dean, What you are saying is your rose coloured view of this. You say they can get an ASN anytime they need one for operation purposes. I am saying that the case exists that operators will want to do this - WITHOUT the requirement for being multi-homed. The requirement for being multi-homed, 'as written' causes members to either lie to provide false information or find a way around the restriction (using HE or someone else) to choose how they wish to manage their network. You choosing to ignore this use case or situation doesn't make it go away because you don't understand why they would want to manage their network in that way. ...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:55 AM, Dean Pemberton d...@internetnz.net.nz wrote: On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens ske...@v4now.com 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 * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Dean, You are quoting an RFC from 1996 (19 years ago)? What next, the Old Testament? Thou shalt be multi-homed? I don't think this RFC ever envisioned the IP runout and that networks hosted by businesses themselves (of any size) would need multi-homing and in the reading of this, you could make an argument that no-one needs an ASN and that all their upstreams could host their portable space for them. Please understand, that I am not suggesting giving an ASN to anyone who has no intention of ever multi-homing. I am wanting to policy to reflect that if a network operator wants to design their network for multi-homing, that they should be able to, with no requirement to immediately multi-home. At no point did I say 'never' multi-home, or no intention of multi-homing the intention should be there. 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. ...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:36 AM, Dean Pemberton d...@internetnz.net.nz wrote: 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 ske...@v4now.com 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
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 o...@delong.com wrote: On Feb 24, 2015, at 22:47 , Raphael Ho raphael...@ap.equinix.com wrote: All, I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree) 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 “as ASN”, but I’d need to better understand why they need one ahead of time. What’s wrong with getting the ASN when you need 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 * 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
David, I agree very much with the operational perspective (obviously), but since when in this day and age of infrastructure that size still matters? Having to change your infrastructure (of any size), potentially with outages and so on, is not acceptable if you are able to design around it from day one. I see it enough that a member should be able to proactively design their connectivity (should they want to - no one is being forced here) to have the potential for multi-homing. The silly thing with the multi-homing barrier as Guangliang confirmed, you could multi-home for 1 day and meet the criteria and then disconnect and then you are still allowed to continue using it. So why have the restriction there in the first place? Surely if someone thinks having an ASN is important in their design, they should be allowed to have one. ...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:10 AM, David Farmer far...@umn.edu wrote: On 2/25/15 15:44 , Dean Pemberton wrote: ... 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 From a policy perspective there is no barrier to entry. However, from an operational perspective, I see it a little differently; having deployed my network using a private ASN, I then need to migrate to a new unique registry assigned ASN. Which you are saying I can't have until I've grown to the point were I need to multi-home or connect to an IX. If I'm a small network, this may not be a big hardship. But if you connect to a single provider in multiple cities you could build a fairly extensive network that would not qualify for a registry assigned ASN until you got a second provider or connected to an IX, at which point the transition to the new ASN could be rather complicated. I'm not sure that justifies obliterating the current policy, but there is at least an operational barrier to entry in some situations. I think maybe a compromise would be to allow a network of a certain size to obtain an ASN regardless of having a unique routing policy, being multi-homed, or connected to an IX. A network of 1 or 2 routers probably doesn't justify an ASN unless it is multi-homed or connected to an IX. A network of 100 routers probably justifies an ASN regardless. Then the question becomes, where to draw the line. -- 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 * 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
Guangliang, What are the rules about someone with a ASN, later de-multi-homing? ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.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 6:53 PM, Guangliang Pan g...@apnic.net wrote: Hi Gaurab, If they can provide 2 peer ASNs in their application, based on the policy they can receive an ASN assignment. Regards, Guangliang On 25 Feb 2015, at 6:10 pm, Gaurab Raj Upadhaya gau...@lahai.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guangliang, can you clarify these questions for me. If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ? - -gaurab On 2/25/15 4:05 AM, Guangliang Pan wrote: Hi Dean and All, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. Best regards, Guangliang = -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong o...@delong.com wrote: On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nz wrote: On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.com wrote: Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this. This is not true. You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation. I don't agree (Damn and we were getting on so well this year =) ). I would argue that the situation you describe above DOES constitute multihoming. I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR. Clarification from APNIC staff on the exact behavior from APNIC could render this moot. However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”. If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy. What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”. I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help. Agreed. While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective. I really want to find out what those multi-homing requirements are. I suspect that they amount to BGP connections to two or more other ASNs In which case I think we can go back to agreeing. As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.). I think it is more a case that smaller and simpler policy proposals that seek to change
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
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 pfsi...@gmail.com wrote: Dean Pemberton wrote on 25/02/2015 15:06 : Great - Thanks for that. As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114. Same, I simply don't understand what problem is trying to be solved here. If an organisation is connected to only one other organisation, there is no need for an ASN. If these two orgs want to use BGP, that's a private matter, and is what private ASNs are for - and there are now around 1 billion of those. If an organisation needs to connect to at least two other ASNs, then they qualify under the APNIC definition which Guanliang shared. philip -- I do not support the proposal -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan g...@apnic.net wrote: Hi Dean and All, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. Best regards, Guangliang = -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto: sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong o...@delong.com wrote: On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nz wrote: On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.com wrote: Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this. This is not true. You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation. I don't agree (Damn and we were getting on so well this year =) ). I would argue that the situation you describe above DOES constitute multihoming. I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR. Clarification from APNIC staff on the exact behavior from APNIC could render this moot. However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”. If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy. What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”. I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help. Agreed. While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective. I really want to find out what those multi-homing requirements
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Sorry Dean, I don't agree with you. You guys are trying to tell people how to run their networks, and that they aren't allowed to pre-emptively design their connectivity to allow for changing to multi-homing, or away from it, without going through a change in network configuration. That might be easy for you, but that is simply your opinion on how things should be done... not a reason why others shouldn't be allowed to do it the way they want to. If a member has a portable range, they should be entitled to - with no restrictions - a ASN number to be able to BE as portable as they want to. ...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 5:20 PM, Dean Pemberton d...@internetnz.net.nz wrote: 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 ske...@v4now.com wrote: Please see my other email Phil.. there is very valid reasons for this policy change. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service 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 pfsi...@gmail.com wrote: Dean Pemberton wrote on 25/02/2015 15:06 : Great - Thanks for that. As far as I can tell this covers all possible use cases I can see. I do not believe that there is a need for prop-114. Same, I simply don't understand what problem is trying to be solved here. If an organisation is connected to only one other organisation, there is no need for an ASN. If these two orgs want to use BGP, that's a private matter, and is what private ASNs are for - and there are now around 1 billion of those. If an organisation needs to connect to at least two other ASNs, then they qualify under the APNIC definition which Guanliang shared. philip -- I do not support the proposal -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan g...@apnic.net wrote: Hi Dean and All, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. Best regards, Guangliang = -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto: sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong o...@delong.com wrote: On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nz wrote: On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.com wrote: Firstly I
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Dean, I'm not debating the time it takes to get an ASN allocated... I'm talking about everything else around it... and changing your setup when you shouldn't even have to... again, you're telling people how to run their networks. I'm simply saying that leave the running of the networks to them... let them decide when, if they multi-home, if they choose to de-multi-home, etc. We all know we can lie our way around this... but people shouldn't have to... and if that is the only reason, then it is still a valid one. A rule that isn't enforced, or has any repercussions for going around, shouldn't even be there in the first place. If the only reason it remains is to annoy some small number of ethical people, it should be remediated. ...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 5:35 PM, Dean Pemberton d...@internetnz.net.nz wrote: Thanks for that Guangliang. Thats really helped to clarify the position here. Another question. Whats the normal time lag between a member applying for an ASN (assuming that all the information is present and correct) and it being allocated? 1 day? 1 week? 1 month? I'm trying to gauge if it really takes longer to apply for an ASN than it does to arrange and configure a BGP peering session. Thanks Dean -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan g...@apnic.net wrote: Hi Dean and All, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. Best regards, Guangliang = -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto: sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong o...@delong.com wrote: On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nz wrote: On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.com wrote: Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this. This is not true. You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation. I don't agree (Damn and we were getting on so well this year =) ). I would argue that the situation you describe above DOES constitute multihoming. I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR. Clarification from APNIC staff on the exact behavior from APNIC could render this moot. However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”. If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy. What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”. I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
I would think it would... why does it matter how you get to another peer? ...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 5:09 PM, Gaurab Raj Upadhaya gau...@lahai.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guangliang, can you clarify these questions for me. If a provider connects to a v4 only transit provider over a physical circuit, but does v6 transit from Hurricane Electric over a tunnel, would that be considered multihoming ? - -gaurab On 2/25/15 4:05 AM, Guangliang Pan wrote: Hi Dean and All, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. Best regards, Guangliang = -Original Message- From: sig-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able to proceed here. -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong o...@delong.com wrote: On Feb 24, 2015, at 12:38 , Dean Pemberton d...@internetnz.net.nz wrote: On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong o...@delong.com wrote: Firstly I agree with Randy here. If you're not multi-homed then your routing policy can not be 'unique' from your single upstream. You may wish it was, but you have no way to enforce this. This is not true. You can be single homed to a single upstream, but, have other peering relationships with other non-upstream ASNs which are also not down-stream. These relationships may not be sufficiently visible to convince APNIC that one is multihomed, even though technically it is a multihomed situation. I don't agree (Damn and we were getting on so well this year =) ). I would argue that the situation you describe above DOES constitute multihoming. I agree, but it may not necessarily constitute “multihoming” in a manner that is recognized or accepted by the RIR. Clarification from APNIC staff on the exact behavior from APNIC could render this moot. However, I have past experience where RIRs have rejected peerings with related entities and/or private ASNs of third parties as not constituting valid “multihoming” whereupon I had to resort to “a unique routing policy”. If an LIR were connected to an upstream ISP but also wanted to participate at an IXP I would consider them to be multihomed and covered under existing APNIC policy. What if they only connected to the IXP with a single connection? I’ve also encountered situations where this is considered “not multihomed” and to be a “unique routing policy”. I couldn't find the strict definition on the APNIC pages as to what the hostmasters considered multihoming to be, but if one of them can point us to it then it might help. Agreed. While I oppose that (and thus completely oppose the other proposal), as stated above, I think there are legitimate reasons to allow ASN issuance in some cases for organizations that may not meet the multi-homing requirement from an APNIC perspective. I really want to find out what those multi-homing requirements are. I suspect that they amount to BGP connections to two or more other ASNs In which case I think we can go back to agreeing. As long as it’s not more specific than that (for example, two or more public ASNs or via distinct circuits, etc.). I think it is more a case that smaller and simpler policy proposals that seek to change a single aspect of policy are more likely to succeed or fail on their merits, where large complex omnibus proposals have a substantial history of failing on community misunderstanding or general avoidance of complexity. I can see
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
To me, relaxing these rules is less about lying - although is easy, but it is to do with flexibility. I understand the routing policy wont be different that an upstream without being multi-homed, but it does curtail the convenience of being able to add these things easily. Lets say I was a company with a /23 and upstream into Telstra Only. If I had my own ASN and was announcing to Telstra, then at any time I could add another ISP, IXP, direct peering without having to go apply for an ASN, reconfigure my network to bring the announcement in-house, etc. I also might want to maintain a single provider, but be able to migrate easily to another provider without having to rely on the providers to do the right thing while changing announcements between them. I think this policy has VERY valid applications for many smaller entities to be able to have an ASN without having to be multi-homed either initially, or maintain that multi-homing. As Randy used to say - Why do you have the right to tell me how to manage my network? If I want to be multi-homed, or change my mind and not be, it is none of your damn business. I think this policy change reflects the changing way for businesses to get online since APNIC has run out of IP's, and are often charging significant amounts of money - so people are going to APNIC directly - which they are entitled to do. And being flexible and being able to change their circumstances is a more common thing nowadays. If you want, suggest charging for ASN's... but don't tell networks how they should be connected at any time. Btw... I am happy for this to apply ONLY to ASN4 and not ASN2. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Wed, Feb 25, 2015 at 3:33 PM, Dean Pemberton d...@internetnz.net.nz wrote: Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas. It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies. Regards, Dean -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: Thanks Guangliang for the update, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future? Regards, Aftab A. Siddiqui. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Agreed... Aftabs use case is one of many... the others I just posted about. ...Skeeve *Skeeve Stevens - Senior IP Broker* *v4Now - *an eintellego Networks service ske...@v4now.com ; www.v4now.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/v4now ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com IP Address Brokering - Introducing sellers and buyers On Wed, Feb 25, 2015 at 3:47 PM, Raphael Ho raphael...@ap.equinix.com wrote: All, I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible since they will require an ASN to peer/multihome at some point in the future (which I do agree) Currently they all have to commit fraud² in order to get an ASN, and I guess some religion takes that more seriously than others. Would we the proposal be acceptable if we reworded the proposal to say something on the lines of ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible for as ASN²? This would cover the use case without opening the floodgates. Thoughts? Raf On 25/2/15 2:33 pm, Dean Pemberton d...@internetnz.net.nz wrote: Members potentially lying on their resource application forms is not sufficient justification to remove all the rules entirely. If someone lies on their a countries visa application about a previous conviction for example, thats not justification for the entire country to just give up issuing visas. It sounds like you are accusing the hostmasters of doing an inadequate job of checking policy compliance of member applications for resources. Perhaps this is something that you'd like to take up with them directly rather than proposing that we remove all the rules in the existing policies. Regards, Dean -- Dean Pemberton Technical Policy Advisor InternetNZ +64 21 920 363 (mob) d...@internetnz.net.nz To promote the Internet's benefits and uses, and protect its potential. On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: Thanks Guangliang for the update, According to the current APNIC ASN policy document, the definition of multihomed is as below. http://www.apnic.net/policy/asn-policy#3.4 3.4 Multihomed A multi-homed AS is one which is connected to more than one other AS. An AS also qualifies as multihomed if it is connected to a public Internet Exchange Point. In the ASN request form, you will be asked to provide the estimate ASN implementation date, two peer AS numbers and their contact details. It is also acceptable if your network only connect to an IXP. So what if I only have one upstream provider and doesn't have a Public IX in place? What If I just whois any member from my country and provide AS numbers and contact details publicly available? Do you check back after 3 months that the AS you provided to the applicant is actually peering with the ones they mentioned in the application? Do you send email notification to those contacts provided in the application that XYZ has mentioned your AS to be peer with in future? Regards, Aftab A. Siddiqui. * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * ___ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
Dean, 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 d...@internetnz.net.nz wrote: There is a version of this that I would support, this isn't it. On Sunday, 8 February 2015, Owen DeLong o...@delong.com 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 ske...@v4now.com 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 o...@delong.com 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 d...@internetnz.net.nz 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 geo...@apnic.net 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 myama...@gmail.com 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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
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 o...@delong.com 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 d...@internetnz.net.nz 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 geo...@apnic.net 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 myama...@gmail.com 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 javascript:_e(%7B%7D,'cvml','aftab.siddi...@gmail.com'); Skeeve Stevens ske...@eintellegonetworks.com javascript:_e(%7B%7D,'cvml','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
Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria
I did actually think that... but Aftab rightly pointed out that there are people who still can use them, due to their own equipment or due to their upstreams. ...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 4, 2015 at 1:21 PM, Gaurab Raj Upadhaya gau...@lahai.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/3/15 9:19 PM, Randy Bush wrote: so the little hack above should be - Is planning to use it within next 6 months ^ for multi-homing make it applicable only for 32 bits ASNs. (duck) - -gaurab -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlTRgkAACgkQSo7fU26F3X3BnACaA/cWeaPosz/0m4Oh9rCkS8Qc PHkAn1QaM551nYWJojMBVjNpeR/LyRET =Ad7X -END PGP SIGNATURE- * 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] Resignation as Policy SIG chair
Owen/Dean, At no point did I say that Randy Bush had not made contributions, nor does not continue to do so in other ways. I did however say that he was a negative person and had a sour demeanour and had an arrogance towards the community. This doesn't mean he hasn't contributed - he just does it in a very unpleasant way. And anyone who thinks the mechanism in which Randy engages this community is acceptable, clearly has no respect for the community or those who give their time to it. Supporting an abusive, sarcastic and disrespectful means of engagement is saying it is acceptable, and it is not. Ever. ...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 21 September 2014 06:34, Owen DeLong o...@delong.com 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 myama...@japan-telecom.com 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 a...@lpnz.org のメッセージ: 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 or enthusiasm. I can do no better that quote from a paper from Milton Mueller: Stewardship and the Management of Internet Protocol Addresses ( www.internetgovernance.org/pdf/CyberDialogue2012_Mueller.pdf). I don't agree with everything Mueller says but this encapsulates the problem very well: But here we face the exact same problem as before: all reforms in IP address governance structure must come from the RIRs themselves. The ASO of ICANN is nothing more than the NRO, and the NRO is nothing more than
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
Elvis, Owens position has been quite simply explained. He does NOT oppose the increase in the size of the allocation just just wants it done more cleanly. Deans argument is that this will potentially waste additional space. I see, and actually agree with both positions... I like to conserve address space, but Owens point is very valid... even if 1 million organisations took a /28, it would still make minimal impact on the address space over a significant period. But, planning for the future is something we should keep in our mind... but, not at the detriment of todays operations. His point of the number of name servers for reverse delegation for a /29 being 8 and a /28 being 1 is quite a compelling reason to increase the default 'larger' allocation to /28. So... balancing the two.. I support increasing the standard large allocation to a /28. ...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 18 September 2014 09:59, Elvis Velea el...@velea.eu wrote: Hi Owen, what has ARIN to do with the policy in APNIC? I could also justify my arguments by saying that the RIPE policy allows up to a /29 per member.. and that policy works very well as well. Let's not use other regions' policies to justify disapproval of this policy proposal. Especially when both ARIN and RIPE have different policies that work very well. I would like to ask you to explain what kind of errors/difficulties may induce the allocation of a /29 (instead of a /28) in regards to RPKI and DNSSSEC. I do not really understand that part (sorry, I am not very technical). If it's fat-fingering you are talking about, that can happen regardless of the size of the allocation. I find it surprising that you oppose to a policy proposal that would allow members of APNIC to use more IPv6 addresses just because the policy does not say 'more than more' (/28s instead of /29s). cheers, elvis On 18/09/14 09:35, 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 el...@velea.eu 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 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/藤崎 智宏) fujis...@syce.net wrote
Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)
Ok, thinking about this some more, I am still conflicted. There are two schools here... simplicity and conservation. I think worrying about conservation is important. But are we trying to converse needlessly? If we think we will be using v6 in 20 years, I think we are kidding ourselves. With the IoE/IoT, the consumption of address space is going to accelerate in a huge way. If we're not thinking about what is after IPv6, then we're doing ourselves a disservice anyway. But that is the future, and extremely difficult to predict in this area. I think simplicity is better in this case... except if it is not really simple. If we have to alter a significant amount of policy to make it simpler, then it isn't really simple. The question is, how critical is this at the moment? I'd like to see thing simpler, but I'd like to know how complex it would be to implement it - correctly. ...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 18 September 2014 12:02, Skeeve Stevens ske...@v4now.com wrote: Elvis, Owens position has been quite simply explained. He does NOT oppose the increase in the size of the allocation just just wants it done more cleanly. Deans argument is that this will potentially waste additional space. I see, and actually agree with both positions... I like to conserve address space, but Owens point is very valid... even if 1 million organisations took a /28, it would still make minimal impact on the address space over a significant period. But, planning for the future is something we should keep in our mind... but, not at the detriment of todays operations. His point of the number of name servers for reverse delegation for a /29 being 8 and a /28 being 1 is quite a compelling reason to increase the default 'larger' allocation to /28. So... balancing the two.. I support increasing the standard large allocation to a /28. ...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 18 September 2014 09:59, Elvis Velea el...@velea.eu wrote: Hi Owen, what has ARIN to do with the policy in APNIC? I could also justify my arguments by saying that the RIPE policy allows up to a /29 per member.. and that policy works very well as well. Let's not use other regions' policies to justify disapproval of this policy proposal. Especially when both ARIN and RIPE have different policies that work very well. I would like to ask you to explain what kind of errors/difficulties may induce the allocation of a /29 (instead of a /28) in regards to RPKI and DNSSSEC. I do not really understand that part (sorry, I am not very technical). If it's fat-fingering you are talking about, that can happen regardless of the size of the allocation. I find it surprising that you oppose to a policy proposal that would allow members of APNIC to use more IPv6 addresses just because the policy does not say 'more than more' (/28s instead of /29s). cheers, elvis On 18/09/14 09:35, 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 el...@velea.eu 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
Re: [sig-policy] Returned to SIG: prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure
Masato, Can it be explained how this occurred. Did something change between the two? I thought it was practice that the AMM essentially confirmed the proceedings on the Policy SIG - to avoid these kinds of events, especially at APRICOT meetings where support/non-support may not be able to make both events. I find it extraordinarily a waste of time if all the effort of the Policy SIG is undone on an individual policy basis. The AMM should be confirming the whole Policy SIG event, not individual policies.. or you might as well not call for consensus during Policy SIG and just save time and do it once at the AMM, or the other way around. I've seen this happen a number of times at combined Apricot events with a lot of other parties present. One might say that it would be wiser to propose policies only at the mid-year events. ...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 Tue, Mar 4, 2014 at 12:27 AM, Masato Yamanishi myama...@japan-telecom.com wrote: 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 RD 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 noted that as long as providers who use this address use basic route scope limitations, the side effect of large volumes of unsolicited incoming traffic would be, to some extent mitigated down to manageable levels. 3. Situation in other regions - Improper use of this address space is a globally common issue. However the block is delegated only APNIC and so therefor, no other RIR has equivalent policy to deal with the situation. 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
Re: [sig-policy] prop-111-v001: Request-based expansion of IPv6 default allocation size
I completely agree with Aftabs evaluation of the fee related issue. This would create a significant burden on small LIR's. I no longer/do not support this proposal. ...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 Sat, Feb 1, 2014 at 6:03 AM, Aftab Siddiqui aftab.siddi...@gmail.comwrote: Hi David, Also, correct me if I'm mistaken, but by raising the default from /32 to /29, you are raising the barrier to entry for small LIRs. I believe APNIC's fees are based on your allocation size. Yes, its a logarithmic function, but it still raises the fees. So a small LIR that doesn't currently need a /29 may prefer to stick with a /32 for the lower fees. This policy seems to force all new allocations to /29, regardless of what an LIR needs or wants. Minimally, this change should be optional, allowing an LIR request range a larger range, but not requiring a larger range. IMO The whole idea of this prop is to remove the justification barrier to get more address space during initial allocation or at subsequent allocation level. No change in minimum initial allocation (/32 for LIRs and /48 for end-sites) has been proposed (or atleast I don't see it). So any who doesn't agree with the positives of /29 which came out during the discussion here doesn't have to pay higher amount.. APNIC fee for /32 is AUD 1,994 and for /29 it is AUD 4,381 (provided that you don't have more then /22 IPv4) *Proposed Changes (as requested in prop):* *Organizations that meet the initial allocation criteria are eligible to receive an initial allocation of /32. For allocations up to /29 no additional documentation is necessary. * *And for existing members* *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 and providing further documentation.* * 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
