Review comments

Author: davidben

draft-ietf-plants-merkle-tree-certs.md

@@ -1676,9 +1676,11 @@ This section describes how to issue Merkle Tree certificates using ACME {{!RFC85
 
 {{Section 7.4.2 of !RFC8555}} describes how an ACME server uses the "alternate" link relation {{!RFC8288}} to serve multiple certificate chains for an ACME order. An ACME client might fetch all of them and deploy them in the authenticating party. Different relying parties need different chains, so the ACME client might reasonably treat any unavailable alternate as an error.
 
-This behavior is not ideal for landmark-relative certificates, which are available asynchronously and should not block deployment of their corresponding standalone certificate. This section defines the "acme-optional-alternate" link relation. When serving a certificate, an ACME server MAY provide one or more link relation header fields of type "acme-optional-alternate". "acme-optional-alternate" identifies an alternate certificate chain, but one that is optional. Relying parties that accept the optional alternate are expected to also accept either the original certificate chain or chains served under the "alternate" link relation.  If the certificate chain is not yet available, the "acme-optional-alternate" URL MAY serve an HTTP 202 (Accepted) response, with a Retry-After header ({{Section 10.2.3 of !RFC9110}}) estimating when it will become available.
+This behavior is not ideal for a landmark-relative certificate, which is available asynchronously and is not intended to delay the corresponding standalone certificate. This section defines the "acme-optional-alternate" link relation. When serving a certificate, an ACME server MAY provide one or more link relation header fields of type "acme-optional-alternate". "acme-optional-alternate" identifies an alternate certificate chain, but one that is optional. Relying parties that accept the optional alternate are expected to also accept either the original certificate chain or chains served under the "alternate" link relation. If the certificate chain is not yet available, the "acme-optional-alternate" URL MAY serve an HTTP 202 (Accepted) response, with a Retry-After header ({{Section 10.2.3 of !RFC9110}}) estimating when it will become available.
 
-An ACME client MAY fetch these URLs to collect additional alternate certificate chains. If the resource is unavailable, the ACME client SHOULD NOT fail the overall transaction. If the resource returns an HTTP 202 (Accepted) response, the ACME client SHOULD retry the request later, incorporating any Retry-After header, but it SHOULD NOT block deployment of other chains on this process.
+An ACME client MAY fetch these URLs to collect additional alternate certificate chains. If the resource is unavailable, the ACME client SHOULD NOT fail the overall transaction. If the resource returns an HTTP 202 (Accepted) response, the ACME client SHOULD retry the request later, incorporating any Retry-After header, but this process SHOULD be independent of deploying other chains in the ACME order. In particular, if deploying a new service, the ACME client SHOULD NOT block deployment on optional alternates.
+
+If renewing certificates, the ACME client MAY opt to wait for optional alternates to simplify certificate replacement, but only while the previous certificates remain valid.
 
 ## Using ACME with Merkle Tree Certificates