Yes, I still feel it misses my point completely. 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/藤崎 智宏) <[email protected]> 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 > [email protected] > http://mailman.apnic.net/mailman/listinfo/sig-policy * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/sig-policy
