diff options
| -rw-r--r-- | scripts/README | 17 |
1 files changed, 16 insertions, 1 deletions
diff --git a/scripts/README b/scripts/README index b5cdb458..67339b1c 100644 --- a/scripts/README +++ b/scripts/README @@ -1,4 +1,4 @@ -$Id$ +$Id$ -*- Text -*- Python RPKI production tools. @@ -84,6 +84,21 @@ Current TO DO list: the cert is still live, otherwise is the date after which it should be added to the CRL. + Yes, but... every example of delayed revocation in the Common + Management Tasks page in the APNIC Wiki is triggered by the child, + not the parent. This suggests that revocation by the parent is + always immediate, whether it's due to overclaim or a child's class + going away or a child requesting revocation (as in key rollover). + + So apparently it's the child (probably ca_detail object) that needs + timestamps. Other text in Common Management Tasks suggests that + ca_detail also needs deferred transitions from pending to active. + + How to model this? An enumerated state value (already have that, + may need to rename states) and a timestamp (which may be NULL) for + next scheduled transition? Is the next state always predictable + from the current state or do we also need a next-state field? + - Publication protocol and implementation thereof. Defer until core functionality in the main engine is done. |