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.