Just for the avoidance of any doubt, I completely agree with Owen's
position on this matter.
To reiterate:
·I can accept that sparse allocations already made on /29 boundaries
can be expanded to fill the entire /29, if there is no room to
expand them to a /28.
·I do not agree that any new/ 29 allocations should be made, the
next size above /32 should be /28
Regards
Mike
-----Original Message-----
From:[email protected][mailto:[email protected]]
On Behalf Of Owen DeLong
Sent: Thursday, 18 September 2014 6:16 a.m.
To: "(Tomohiro -INSTALLER- Fujisaki/藤崎智宏)"
Cc:[email protected]
Subject: Re: [sig-policy] prop-111-v004: Request-based expansion of
IPv6 default allocation size
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] <mailto:[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] <mailto:[email protected]>
>http://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
[email protected] <mailto:[email protected]>
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.
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
[email protected]
http://mailman.apnic.net/mailman/listinfo/sig-policy
