Hi again, Richard: Do you have any subsequent thoughts now that Roland and myself have given feedback on your proposed changes and why we still prefer the suggestions I made initially?
Andrew's original support of proactive issuance was the most constructive vote for why that behaviour was preferred during the initial discussion period. Given that his support is now withdrawn and Roland and Jacob have voiced support for my proposal I feel like we are approaching consensus. There has not been any arguments made for the benefit of proactive issuance. Boulder is beginning implementation of my proposed specification update and I feel the best way to minimize Rich Salz's concerns about cycle disruption is to resolve this thread quickly. Thanks all, On Tue, Sep 26, 2017 at 1:34 PM, Andrew Ayer <a...@andrewayer.name> wrote: > FWIW, I previously expressed support for proactive issuance because > I thought it would lay the groundwork for a better renewal process, > especially for short-lived certificates. However, this idea never > gained traction and the other necessary bits weren't added. Instead, > STAR seems to be handling this use case. > > Therefore, I no longer see a compelling reason for proactive issuance. > If it's causing problems it should be removed. I also agree with Roland > that issuing upon an unauthenticated GET request is a bad idea. > > Regards, > Andrew > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
