Michael, sorry it has been a while, but here are some comments on the Data Exchange design.
1. The the new design must support large volume installations, and the time taken to perform operations must not increase exponentially with the number of certificates in the PKI. 2. A mechanism must be provided to allow a full update to be completed to allow, for instance, a node to be rebuilt in the event of systems failure (e.g. a CA or RA is re-built form a previous weekly backup). 3. It might be sensible to consider providing for the compression of exchange files (especially useful for slow network links, high volume systems or restricted media size). 4. The new exchange solution must still support the configuration where the RA and CA "share" a single database. 5. It would be useful if the import/export routines were accessible from the new API. The important feature here is the ability to fully "automate" the task. The latest design documentation suggests that there may be 2 separate actions a maintenance action and an export/import action. If this is the case then it should be possible to automate both actions. 6. The "Maintenance Command" seems to perform a scan for missing entries. We are worried that this could be a performance overhead. If the PKI is a 100,000 certificate system, you are asking this maintenance command to go through each of the records in the database and check to see if it exists in the data exchange log. At the moment this takes a _VERY_ long time and we are worried that this performance problem has not been addressed in this design. Could the OpenCA functions not be modified to populate the data exchange log as they update the database with new records, i.e. populate the log when it knows it has new elements ? 7. This may be my understanding of the flow description, but we often have to perform a data exchange twice (becasue the media has failed or the RA was not available etc). Can you confirm that the design of the "EXPORT" and "PENDING" states does not stop the CA/RA from exporting the correct data even if an import is not received. I hope you understand what I am trying to say here. 8. Is it worthwhile giving some consideration as to how the new import/export implementation fits in with the future need of "real time" certificate generation ? Chris... ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ OpenCA-Devel mailing list OpenCA-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openca-devel
