The arguments to the reconsideration procedure are the (object id of the) certificate to be reconsidered and various values attached to that certificate object described in
When a stale certificate is reconsidered, this procedure is applied and the disposition of the certificate is determined by its result. If the procedure fails then the certificate remains stale, and presumably control passes to wherever the failure is caught; perhaps it will be enough for such failure to always immediately induce failure back to the original operation inducing staleness, restoring the current closed map. If the procedure completes, it returns one of three values: "intact", "delete", or a "new content" text.
One point about timing to emphasize is that reconsidering a certificate may involve operations that again should force reconsideration of the same certificate again after this reconsideration is completed. One way to account for this would be to stipulate that after a stale certificate is selected for reconsideration, but before reconsideration itself begins, the certificate is marked as NOT stale.
If the result is "delete" then the certificate is
Let us emphasize a few points:
|2.||Part of a certificate is an indication of its kind, which determines its creation and reconsideration procedures, and that part is beyond the reach of the reconsideration procedure (or the creation procedure for that matter).|
|3.||Certificates will not be deleted until no stale certificates remain; they can only be marked for deletion until then.|
|4.||Changing a certificate's content or marking it for deletion will make any pertinent certificates referring to it stale, thus it is possible for reconsideration to cascade.|
|5.||The difference between leaving a certificate "intact" upon reconsideration and using its old content as its new content is that the latter will induce staleness in pertinent certificates referring to it.|