>
> +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.
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.
* 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
