On 25 February 2015 at 07:13, Dean Pemberton <d...@internetnz.net.nz> wrote:
> > > > +1 to most of what Dean says. > > > > My point is that if you need more than a /32, then you should be able to > get a /28 rather than having to make a /[29..31] work. > > It's my understanding that current policy allows just that. If you > need a /28 then APNIC will be able to allocate you one. It might not > be an extension of your existing allocation if you were one of the > early adopters (limited to a /29 boundary), but this policy doesn't > provide anything new. > > All it proposes is that anyone in the position of having an allocation > from: > 2001:0200::/23 > 2001:0c00::/23 > 2001:0e00::/23 > 2001:4400::/23 > > Can request their allocation be extended to a /29 without any further > justification needed. > > Owen opposes this as it wouldn't support allocation on a byte boundary > (/28). That is never going to be possible for allocations within this > block as they were initially allocated too close together. > > I oppose this on the grounds that it violates needs based allocation > guidelines AND non byte boundary allocation for IPv6. > So you would support it if it only violated one of those two concerns? > A way forward that I would support is: > > 1. Have the hostmasters confirm that a member with an allocation in > this block could, if justified, receive an allocation up to a /29 by > extending their current allocation. > 2. Have the hostmasters confirm that a member with an allocation in > this block could, if justified, swap the allocation for one allocated > from a different block where the /29 restriction on growth did not > apply. > 3. Withdraw this proposal. > My reading of the policy proposal is that it aims to allow people who received allocations under the legacy allocation scheme to expand their address space in a contiguous fashion without having to shift out of their existing address space. Given that the address space between the legacy /32s is completely wasted at present, I don't see an issue with removing the justification requirements in this specific case (it's been mentioned that we're setting a dangerous precedent - I'd argue that leaving the space wasted if we have a technically feasible way to make better utilisation of it is a more dangerous precedent). I do not see an issue with this, given the specific limitations which are documented in the proposal. We have to accept that (short of handing everyone with a legacy allocation a new allocation based on today's allocation policy and forcing them to move over to it, handing back their legacy allocation - and I believe that the fact that this proposal is even being considered means we'd not go down that path) we will never resolve the requirement for contiguous address space within the legacy allocation ranges without allowing non-byte allocations. So, in my mind, the issue comes down to "Do we want to allow allocation on non byte boundaries [in a limited sense, only within the legacy allocation policy blocks] in order to allow us to better utilise what is currently wasted space, and provide a non-disruptive allocation expansion capability for those who's only crime was to ask for their allocation when the policy was different to what it is now?" In the end, I believe that we do want to do this. And thus, in the absence of an alternative policy proposal which resolves the issues this one does, I support this proposal.
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
