In this draft it has some requirements for generating ULA-C prefixes and then in 7.0 it requires the RIRs to publish an RFC documenting how they will implement these requirements.
I think it would be better not to require the RIRs to also go through the RFC process after a ULA-C RFC has been issued, if it ever gets to that point. One possible solution is to downgrade this to simply require the RIRs to publish an RIR document explaining how they implement section 3.2. But a better way is for the ULA-C document to include this. I note that any algorithm for checking (and registering) a generated prefix in the 5 RIR databases could easily be done in advance so that each RIR keeps a supply of unique ULA-C prefixes on hand based on their forecast rate of requests for such addresses. That means that an applicant does not have to wait for turnaround time of the uniqueness test. As far as protocols for communication between the RIRs, this should also be specified in the ULA-C document, however it should not develop any new protocols, merely specify that something like XML-RPC or REST be used, and the semantics of the transaction which should be atomic, i.e. test uniqueness and register in one transaction. This transaction should provide some kind of positive response so that there is no possibility of a false positive. And since it will likely be most heavily used to register batches of unique ULA-C prefixes, it should allow for a single transaction to register the entire batch (or at least as many are actually unique). Race conditions can occur here but it is not necessary for a protocol or application to resolve these since this can be done by some manual exception process. As long as conflicting prefixes (ones which have not passed all 5 RIR checks) are removed from all the databases regularly, that is sufficient. ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: [EMAIL PROTECTED] Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
