Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default
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/藤崎 智宏) <fujisaki at syce dot 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 at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy