> This is the place for me to say that I believe the draft is > wrong in delegating this as an RIR policy matter. Like > existing ULAs, ULA-C should be treated as *technical* address > space, and we should specify that assignments will be made > and recorded by a single instance of a robot, operated by a > trusted party. Designation of that trusted party could > certainly be a matter for IANA to negotiate with the community.
In my earlier comment I mentioned that the RIRs should stock a supply of already-generated ULA-C addresses so that the applicants did not have to wait while 5 RIRs worked out whether or not there was a conflict. Add that to Brian's comment above and you have a scenario where IANA runs the robot, ensures global uniqueness (just like they do with IP addresses) and allocates a supply of ULA-C addresses to an RIR when their supply runs low. Since running the robot and maintaining the database of already-generated ULA-C addresses is a minor technical matter requiring very little technical infrastructure, it seems reasonable for the RFC to specify that IANA should do this. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
