Hi Dean, You’ve resumed my thinking ! As long as it doesn't support allocation on nibble boundaries I will oppose it.
Regards, > Le 4 févr. 2015 à 14:54, Dean Pemberton <d...@internetnz.net.nz> a écrit : > > There are a number of things that concern me about this proposal. > > 1) it doesn't appear to support needs based allocation > 2) it doesn't support allocation on nibble boundaries which operators have > said repeatedly is a major issue. > > As such I do not support this proposal in its current form. > > > > On Wednesday, 4 February 2015, HENDERSON MIKE, MR > <michael.hender...@nzdf.mil.nz <mailto:michael.hender...@nzdf.mil.nz>> wrote: > I agree with Owen > > > > > > Regards > > > > > > Mike > > > > From: sig-policy-boun...@lists.apnic.net <> > [mailto:sig-policy-boun...@lists.apnic.net <>] On Behalf Of Owen DeLong > Sent: Wednesday, 4 February 2015 4:05 p.m. > To: Masato Yamanishi > Cc: sig-policy@lists.apnic.net <> > Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand > expansion of IPv6 address allocation size in legacy IPv6 space > > > > I will again oppose this as written. I would much rather see policy deliver > nibble-boundary based allocations. > > > > I would rather see such organizations issued new /28s than expand these /32s > into /29s. > > > > Owen > > > > On Feb 3, 2015, at 9:55 AM, Masato Yamanishi <myama...@gmail.com <>> wrote: > > > > Dear SIG members > > The proposal "prop-112: On demand expansion of IPv6 address allocation > size in legacy IPv6 space" 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-112 > <http://www.apnic.net/policy/proposals/prop-112> > > Regards > > Masato > > > > > ---------------------------------------------------------------------- > prop-112-v001: On demand expansion of IPv6 address allocation size in > legacy IPv6 space > ---------------------------------------------------------------------- > > > Proposer: Tomohiro Fujisaki > fujis...@syce.net <> > > > 1. Problem statement > -------------------- > > IPv6 minimum allocation size to LIRs is defined as /32 in the "IPv6 > address allocation and assignment policy"[1]. > > In late 2006, sparse address allocation mechanism has implemented > to manage APNIC IPv6 address pool. The block `2400:0000::/12' has > managed with this mechanism. > > Before 2006, /29 was reserved for all /32 allocations by sequential > allocation method made from those old /23 blocks (Legacy IPv6 > block). > > These reserved blocks might be kept unused in the future. > > > 2. Objective of policy change > ----------------------------- > > This proposal modifies the eligibility for organizations in the > legacy IPv6 block to extend their IPv6 address space up to a /29 > (/32 -/29) by request basis. > > > 3. Situation in other regions > ----------------------------- > > RIPE-NCC: > The policy "Extension of IPv6 /32 to /29 on a per-allocation vs > per-LIR basis" is adopted in RIPE-NCC and LIRs in RIPE region can > get up to /29 by default. > > > 4. Proposed policy solution > --------------------------- > > - define 'legacy IPv6 address blocks' > 2001:0200::/23 > 2001:0c00::/23 > 2001:0e00::/23 > 2001:4400::/23 > > - Add following text in the policy document: > > for Existing IPv6 address space holders > > LIRs that hold one or more IPv6 allocations in the legacy IPv6 > address blocks 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. > > > 5. Advantages / Disadvantages > ----------------------------- > > Advantages: > > It is possible to utilize address blocks which is potentially > unused into the future. > > > Disadvantages: > > Some people may argue this will lead to inefficient utilization of > IPv6 space since LIRs can obtain huge address size unnecessarily. > However, this will not happen because larger address size needs > higher cost to maintain that address block. > > > 6. Impact on resource holders > ----------------------------- > > NIRs must implement this policy if it is implemented by APNIC. > > > 7. References > ------------- > > [1] IPv6 address allocation and assignment policy > http://www.apnic.net/policy/ipv6-address-policy > <http://www.apnic.net/policy/ipv6-address-policy> > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy@lists.apnic.net <> > http://mailman.apnic.net/mailman/listinfo/sig-policy > <http://mailman.apnic.net/mailman/listinfo/sig-policy> > > > The information contained in this Internet Email message is intended for the > addressee only and may contain privileged information, but not necessarily > the official views or opinions of the New Zealand Defence Force. If you are > not the intended recipient you must not use, disclose, copy or > distribute this message or the information in it. If you have received this > message in error, please Email or telephone the sender immediately. > > > -- > -- > Dean Pemberton > > Technical Policy Advisor > InternetNZ > +64 21 920 363 (mob) > d...@internetnz.net.nz <mailto: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 <mailto:sig-policy@lists.apnic.net> > http://mailman.apnic.net/mailman/listinfo/sig-policy > <http://mailman.apnic.net/mailman/listinfo/sig-policy> <https://www.mls.nc/> Bertrand Cherrier, Administrateur Systèmes b.cherr...@micrologic.nc <mailto:b.cherr...@micrologic.nc> www.mls.nc <https://www.mls.nc/> @micrologicnc <http://twitter.com/micrologicnc> Sur facebook <https://www.facebook.com/mls.nc> Téléphone: 24 99 24 VoIP: 65 24 99 24 Service Clientèle: 36 67 76 (58F/min)
* 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
