On 18/09/2014, at 4:11 pm, Skeeve Stevens <ske...@v4now.com> wrote: > 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?
No. We need to try harder. > > If we think we will be using v6 in 20 years, I think we are kidding > ourselves. It took 20 years to agree IPv6. Next time around the change will be even harder. We should expect that IPv6 will last at least the next 50 years. > 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. That's seems to be the most egregious excuse for not doing things correctly now - "It doesn't matter because we're going to replace it anyway". An argument that could be applied to IPv7, 8 and so on. Jay > 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 ; 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 ; 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] 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: >>>> >>>> > >>>> > Hi, >>>> > >>>> > Thank you so much for your comments. >>>> > >>>> > Here, just I would like to confirm, >>>> > >>>> > | 1. unrestricted issuance of /29s to every >>>> > organization regardless of needs. >>>> > >>>> > I've added some texts that LIRs would like to to obtain a additional >>>> > block larger than /32 need to demonstrate their needs in version 3 >>>> > (prop-111-v003). >>>> > >>>> >> From the mail I sent on 1st August: >>>> > | >>>> > | I submitted revised version of: >>>> > | “prop-111: Request-based expansion of IPv6 default allocation size" >>>> > | >>>> > | At the last policy sig discussion, I got concern about address >>>> > | allocation without any constraint, and some criteria should be added >>>> > | to expand the block size. >>>> > | >>>> > | In this revised proposal, I added the requirement to demonstrate >>>> > | need for both initial and subsequent allocations to reflect such >>>> > opinions. >>>> > | >>>> > | For initial allocation: >>>> > | > The organizations >>>> > | > can receive up to /29 by providing utilization information of >>>> > the whole >>>> > | > address space. >>>> > | >>>> > | For subsequent allocation: >>>> > | > LIRs that hold one or more IPv6 allocations are able to request >>>> > | > extension of each of these allocations up to a /29 without >>>> > meeting >>>> > | > the utilization rate for subsequent allocation by explaining >>>> > | > how the whole address space will be used. >>>> > >>>> > # The wording is slightly different from latest (v004) version. >>>> > >>>> > Do you think corrent text is not enough? >>>> > >>>> > Yours Sincerely, >>>> > -- >>>> > Tomohiro Fujisaki >>>> > * sig-policy: APNIC SIG on resource 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 >>>> The information contained in this Internet Email message is intended for >>>> the addressee only and may contain privileged information, but not >>>> necessarily the official views or opinions of the New Zealand Defence >>>> Force. If you are not the intended recipient you must not use, disclose, >>>> copy or >>>> distribute this message or the information in it. If you have received >>>> this message in error, please Email or telephone the sender immediately. >>>> >>>> >>>> * sig-policy: APNIC SIG on resource management policy >>>> * >>>> _______________________________________________ >>>> sig-policy mailing list >>>> >>>> sig-policy@lists.apnic.net >>>> http://mailman.apnic.net/mailman/listinfo/sig-policy >>> >>> * sig-policy: APNIC SIG on resource management policy >>> * >>> _______________________________________________ >>> sig-policy mailing list >>> sig-policy@lists.apnic.net >>> http://mailman.apnic.net/mailman/listinfo/sig-policy >> > > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy > > > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley * 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
