Aaron, You can issue a new version of the draft, even as it sits in my queue. I'd prefer you do that before I start my review.
Deb On Mon, Nov 4, 2024 at 11:18 PM Aaron Gable <aaron= 40letsencrypt....@dmarc.ietf.org> wrote: > Thanks Yoav! > > I've already spoken with Jacob about this change offline, and plan to > bring it up as part of my timeslot this week. You're absolutely right that > it doesn't affect any of the bits on the wire; it's just instructions on > client behavior. I'm in favor of incorporating this language (or a slightly > edited version of it); I'm just unfamiliar with the process for > incorporating changes like this as we move out of WGLC and into IESG. > > Aaron > > On Mon, Nov 4, 2024 at 12:34 PM Yoav Nir <ynir.i...@gmail.com> wrote: > >> Thanks for that. >> >> If I’m reading this correctly, this is all clarification, not >> bits-on-the-wire changes. Changes like that can be added after WGLC if they >> don’t raise objections. >> >> I see that you are not registered for the IETF meeting, so it probably >> doesn’t make sense to discuss it at the ACME session, but we’ll mention >> that the PR exists, and the discussion can continue on the mailing list. >> >> Yoav >> >> On 29 Oct 2024, at 22:09, Jacob Hoffman-Andrews <jsha= >> 40letsencrypt....@dmarc.ietf.org> wrote: >> >> Hi all, and especially to Yoav and Aaron for getting the ARI draft >> through Last Call. >> >> I'm very sorry to make a substantive proposal _after_ Last Call, but >> after talking to a client author I became concerned that we're not being >> explicit enough about how frequently clients should check. I've just >> uploaded this PR: >> >> https://github.com/aarongable/draft-acme-ari/pull/82 >> >> For convenience, I'm reproducing the added sections below: >> >> ## Schedule for checking RenewalInfo objects >> >> RenewalInfo objects must be fetched frequently so that clients learn >> about renewal quickly. But requests must not overwhelm the server. This >> protocol uses the Retry-After header to indicate to clients how often to >> retry. Note that in other HTTP applications, Retry-After often indicates >> the earliest time to retry a request. In this protocol, it indicates both >> the earliest time and a target time. >> >> Clients SHOULD fetch a certificate's RenewalInfo object immediately after >> issuance. After that, clients SHOULD fetch the certificate's RenewalInfo as >> soon as possible after the time indicated in the Retry-After header >> (backoff on errors takes priority, though). Clients SHOULD set reasonable >> limits on the value in the Retry-After header. For instance, values under 1 >> minute should be treated as if they were one minute and values over one day >> should be treated as if they were one day. >> >> Clients SHOULD stop checking RenewalInfo after a certificate is expired. >> Clients SHOULD stop checking RenewalInfo after they consider a certificate >> to be replaced (for instance, after a new certificate for the same >> identifiers has been received and configured). >> >> ### Error handling >> >> Temporary errors include, for instance: >> >> - Connection timeout >> - Request timeout >> - 5xx HTTP errors. >> >> On receiving a temporary error, clients SHOULD do exponential backoff >> with a capped number of tries. If all tries are exhausted, clients SHOULD >> treat the request as a long-term error. >> >> Long term errors include, for instance: >> >> - Retry-After is invalid or not present >> - RenewalInfo object is invalid >> - DNS lookup failure >> - Connection refused >> - Non-5xx HTTP error >> >> On receiving a long term error, clients SHOULD perform the next >> RenewalInfo fetch as soon as possible after six hours have passed (or some >> other locally configured default). >> >> ### Server choice of Retry-After >> >> Servers set the Retry-After header based on their requirements on how >> quickly to perform a revocation. For instance, a server that needs to >> revoke certificates within 24 hours of notification of a problem might >> choose to reserve twelve hours for investigation, six hours for clients to >> fetch RenewalInfo, and six hours for clients to perform a renewal. Setting >> a small value for Retry-After means that clients can respond more quickly, >> but also incurs more load on the server. Servers should estimate their >> expected load based on the number of clients, keeping in mind that third >> parties may also monitor RenewalInfo endpoints. >> _______________________________________________ >> Acme mailing list -- acme@ietf.org >> To unsubscribe send an email to acme-le...@ietf.org >> >> >> _______________________________________________ >> Acme mailing list -- acme@ietf.org >> To unsubscribe send an email to acme-le...@ietf.org >> > _______________________________________________ > Acme mailing list -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
