Re: [Acme] Happy Birthday ACME!

Thanks for starting the discussion, Rob! One aspect of RFC 8555 that is quite clunky in practice is utilizing the notBefore/notAfter dates in the new-order request [1 ]. I believe there are a few problems with it. 1. "new-order" may

Re: [Acme] Happy Birthday ACME!

Hi, Rob The first question whenever someone proposes a bis document is, of course, “are you volunteering to edit?” Jokes aside, it’s always a question of whether or not it is worth the effort. Not just for whoever is editing, but the usual effort associated with any document, such as WG

Re: [Acme] Happy Birthday ACME!

I think when doing a bis document you need to ask yourself: 1) am I trying to move it to Internet Standard? -or- 2) am I trying to do ACME v2.0. (1) involves ripping out everything that wasn't implemented/used. (2) involves adding everything you forgot last time. -- Michael Richardson. o O

Re: [Acme] Happy Birthday ACME!

Happy birthday, RFC8555! I've thought frequently about the idea of an ACME-bis over the last few years. I have a note going since at least 2022 which I occasionally add new ideas to, and I've had a few offline conversations with others about their wishlists. At the end of the day, I think only

[Acme] Happy Birthday ACME!

RFC8555 was published [1] 5 years ago today! Just thinking aloud, 'cos I'm curious what folks here think... At what point might it make sense to start work on an 8555-bis? There's a fairly long list of Errata [2]: 10 Verified, 5 Reported, and 4 Held for Document Update. Would it make sense for