[Plants] Re: Nits

[David Benjamin <[e-mail]>]

On Wed, Apr 8, 2026 at 7:06 PM David Benjamin <[e-mail]> wrote:

> On Wed, Apr 8, 2026 at 5:20 PM Watson Ladd <[e-mail]> wrote:
>
>> I'm not sure 503 is the right error code for the landmark-relative cert
>> in ACME: a 400 series code would make more sense given that some are about
>> resource conditions. There isn't one that fits though. 503 may complicate
>> infrastructure monitoring as it is usually a server problem you want to
>> worry about.
>>
>
> Hmm. I think I picked 503 just because that was the existing semantics for
> Retry-After paired it with 503. But that is a good point that we don't
> *really* satisfy the expectations around 503.
> https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3
>
> I've filed https://github.com/ietf-plants-wg/merkle-tree-certs/issues/202
> to track this. Do folks have thoughts on what it should be instead?
>

After some poking around, it turned out:
- ACME already has precedent, for better or worse, for using 200 +
Retry-After in how it models the "processing" state
- Updating the order avoids a lot of silliness where an alternate URL is
provided ahead of time, fails to download, but the client needs to know
this fatal to the transaction.

So this PR describes another possible spelling, where the idea is we
basically construct a "valid-but-still-processing" state that has
certificates, but is still updated like a processing order. That should
hopefully avoid the 503 mess along with it.
https://github.com/ietf-plants-wg/merkle-tree-certs/pull/203

David

>