Re: [sig-policy] prop-073-v003: Automatic allocation/assignment of IPv6
On 27/08/2009, at 04:05 , Izumi Okutani wrote:
Andy, Terry,
I support the concept of your proposal to make the allocation
procedure
simple for members.
Thanks for support and your constructive comments below.
At the same time, I think we should maintain a certain level of check
that hostmasters make for applications now to see if the space is
planned to be used, and not just because they feel like asking for
it in
a click.
May I therfore suggest to have members to at least explicitly state
their usage when they make request?
e.g. they will prepare equipment in x years
what type of network(native/dual stack/tunneling) they run
It can just be a tick in a box style rather than members having to
provide information, and I'm happy to leave the details to the
secretariat.
I'm comfortable with this part - as you say we should leave the
details to the secretariat.
I'm also still concerned that /32 will be allocated to endsites (it
may
be considered sometime in the future like assigning a /16 for networks
that needs a /24 in IPv4 and create legacy space) as a result of this
proposal.
If this concern is also shared by others, perhaps, this can also be
handled as in the same manner as above?
e.g. ask the applicant to chose if they plan to make assignments to
other organization OR will only be use it within their
organization
if it's the latter, assign /48 even if they have IPv4
allocations
I understand and agree with your desire to make sure we assign
resources in a responsible manner. Again I think we should leave the
exact details to the secretariat.
I think it's important for us to balance the requirement for
responsible allocation/assignment with the need to be sure that the
prefixes are routable - if there's any risk that a /48 ends up less
routable than a /32 then we should favour use of the /32.
Additionally if an organisation gets a /48 as this initial allocation
and then has to come back to for more space then we've ended up with
two entries in the routing table instead of one and that would be
something we want to avoid.