Michael- I dont believe that was the intent and there might be a little misinterpretation here due to how it was written. The document says:
>The designated allocation authority is required to document how they will meet the requirements described in Section 3.2 of this document in an RFC.< This states the RIR's need to document how they will meet the requirements once section 3.2. It dont believe the author intends for RIR's to write an RFC. I believe the intent of the sentence you question is actually saying in a round about way that RIR's need to use their policy process and write policy's that will meet the requirements stated in section 3.2 of the draft. Thus, synchronizing the RFC and RIR policy. Or at least that is what I had discussed on a conference call with R. Hinden and T. Narten before the revision was made. So Bob or Thomas, correct me if I am wrong here... Cheers! Marla -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, June 18, 2007 2:40 PM To: ipv6@ietf.org Subject: draft-ietf-ipv6-ula-central-02 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
