Reviewer: Geoff Huston
Review result: Ready with Nits
Overall the specification is quite reasonable. I have some nots that I feel
would improve the readability of the document.
1. Introduction, "All three techniques lead to load clustering for the
issuing CA."
I'm not sure I see the logic behind this assertion. I can parse this more
successfully if the text said "All three techniques may lead to load
clustering for the issuing CA due to the inability of the issuing CA to
schedule renewal requests".
2. Introductioon: "Allowing issuing CAs to suggest a period in which clients
should renew their certificates enables for dynamic time-based load
balancing."
There is a word missing here - enables WHAT?
3. Introduction, "by which ACME clients may inform ACME servers that a
certificate has been renewed and replaced."
I'm confused - I thought it was up to the server to renew and replace a
certificate, not the client. This sentence suggests the opposite.
4. Section 4.2 RenewalInfo Objects. The structure of this section is not
obvious to the reader. I suggest selective indentqation to highlight the
structure of the paragraph. For example:
The structure of an ACME renewalInfo resource is as follows:
- suggestedWindow (object, required): A JSON object with two keys,
"start" and "end", whose values are timestamps, encoded in the format
specified in [RFC3339], which bound the window of time in which the CA
recommends renewing the certificate.
5. Section 5 Extensions to the Order Object The same commect er per section
4.2 - some rudimentary text markup the structure of the paragraph would
help.
6. Section 6 Security Considerations.
This specification assumes time synchronisation betwEen client and server.
It would be useful for the document to note the potential failure modes when
client and server are not time-synchronised.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
