<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12"> <TITLE>RE: [address-policy-wg] Re: Registration of IPv6 DHCPv6-PD pools</TITLE> </HEAD> <BODY>  >Ideally we're going to find a consensus interpretation on how to deal with >dynamic pools (of any size), be it for single IPs or prefix delegations >via DHCP-PD. I think it depends very much on how big an assignment you would want to make out of these, in my personal opinion, I think that anything larger than /64 (which is the minimum you need to get anything done) should be documented. Why do I think this? In the IPv4 world, we take a /24 pool and divide it up into /32s which we need to connect the customer to us ("infrastructure") and no per-customer documentation is needed. The minute an IPv4 customer asks for some addresses to be routed to them, enough to create another "network", we give them at minimum a /29 and document this. In the IPv6 world, I think I would be following the same approach, only on a bigger scale. The minute a customer wants more than just to have their home IPv6 devices work in a basic fashion (i.e they want another /64 or a /56) then I would expect there to be some documentation for it, I'm not trying to be restrictive about what they do with their home networks, just trying to draw a line in the sand somewhere, below which I don't care about usage and above which I do. Now, as for the question of what this documentation should be or where it lives, I can't see much use in populating the RIR DB with all of this small assignment stuff, perhaps best draw another line and make this the RIR reporting threshold. Dave. </BODY> </HTML>