Owen and Mike, It is very clear. Thank you.
Rgs, Masato On 2014/09/03 15:00, "HENDERSON MIKE, MR" <michael.hender...@nzdf.mil.nz> wrote: > Masato, > > My position is exactly aligned with Owen’s: > “I do not support the proposal as written. I would support it if /28s were > issued whenever possible and /29s were only issued in cases where the existing > assignment or allocation cannot be expanded to at least /28.” > > > > Regards > > > Mike > > > From: Owen DeLong [mailto:o...@delong.com] > Sent: Thursday, 4 September 2014 9:27 a.m. > To: Masato Yamanishi > Cc: HENDERSON MIKE, MR; sig-pol...@apnic.net > Subject: Re: [sig-policy] New version of prop-111: Request-based expansion of > IPv6 default allocation size [SECURITY=UNCLASSIFIED] > > > On Sep 3, 2014, at 2:12 PM, Masato Yamanishi <myama...@japan-telecom.com> > wrote: > > > Hi Mike, > > > > Thank you for you comment and let me clarify your one point. > > > > On 2014/09/02 16:07, "HENDERSON MICHAEL, MR" <michael.hender...@nzdf.mil.nz > <mailto:michael.hender...@nzdf.mil.nz> > wrote: > > >> >> I do not favour IPv6 allocations on “non-nibble” boundaries, I believe that >> allocations ought to be made on “nibble” (i.e. 4-bit) boundaries. On that >> basis, the next allocation larger than /32 would be /28, not /29. >> >> Address masking and calculation on /29 boundaries will in my view be quite >> nasty, and the size of the IPv6 address space is sufficiently large that we >> need not, and therefore should not, impose such inconveniences on ourselves. >> >> >> >> Hence, in my IPv6 allocation world, a resource holder who has a demonstrated >> need (for whatever value of ‘need’ seems appropriate) for address space >> larger than /32, should be allocated a /28. >> >> If they are ‘growing’ an existing /32, then the new /28 would very preferably >> be one that includes the currently-allocated /28. >> >> >> >> >> >> However, I understand the current situation is that the ‘legacy’ IPv6 address >> allocation was for smaller allocations within blocks on /29 boundaries, if I >> read the Proposition correctly. >> >> As a special case only, I would support the allocation of these ‘legacy /29’ >> blocks. The provisos being that firstly they do fall into this ‘legacy’ >> category, and that secondly it is not possible (owing to allocation to a >> third party) to allocate a /28 to the relevant resource holder >> >> >> >> > > > > But this proposal is NOT ONLY for the special case. > > Every organizations, which are new comers, “legacy” IPv6 space holder, and > existing IPv6 space holder with sparse allocation mechanism, > > will be eligible for /29 by providing necessary information as shown in Sec.4. > > > Which I believe is a flaw in the proposal. > > > > > > So, can you share your preference for current proposed text as it is? > > > I do not support the proposal as written. I would support it if /28s were > issued whenever possible and /29s were only issued in cases where the existing > assignment or allocation cannot be expanded to at least /28. > > > > Owen > > > > >> 4. Proposed policy solution >> ---------------------------- >> >> - Change the text to "5.2.2 Minimum initial allocation size" of >> current policy document as below: >> >> Organizations that meet the initial allocation criteria are >> eligible to receive an initial allocation of /32. The organizations >> can receive up to /29 by providing utilization information of the whole >> address space. >> >> - Add following text in the policy document: >> >> for Existing IPv6 address space holders >> >> 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. >> > > Rgs, > > Masato > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net <mailto:sig-policy@lists.apnic.net> > http://mailman.apnic.net/mailman/listinfo/sig-policy > <http://mailman.apnic.net/mailman/listinfo/sig-policy> > > 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
