On Mon, Sep 23, 2019 at 11:36 PM Paul Wouters <[email protected]> wrote:
> > > > > Hi Paul. This was my thought process... > > > > A mechanism for a log to change its base url might be "nice to have", > > but it would add complexity. Adding complexity should be avoided unless > > it's "really necessary". "nice to have" is not "really necessary", and > > besides, there is already a mechanism for achieving the same goal: > > retire the current log and spin up a new log. > > > > The ecosystem needs to be agile enough to support regular log retirement > > and regular spinning up of new logs, so let's not (over)engineer an > > alternative mechanism that assumes the ecosystem lacks that agility. > > While I agree with you, I am just a WG chair. So we need to hear a few > more opinions of people and then if there is a consensus, we can go ahead > and make this change. Sorry about that, Paul. I’m so used to the CA/Browser Forum and related, where it’s more pressing to chime in on the bad ideas early, rather than the good ideas like this one. To be clear: I agree with Rob that the flexibility to make that change seems better addressed through agility of the client. I realize this is somewhat divergent from how 6962 was initially promoted (“just a few logs and never need to change them”), but the operational experience there has emphasized the importance of client agility. Similar to the Base URL discussion by Andrew Ayer, the less flexibility we attempt to accommodate log operators with, the greater predictability and verifiability we offer clients. Thus, avoiding “nice to haves” that introduce unpredictable flexibility is... nice to have. So that’s why Rob’s response sounds right to me, and the best answer is rely on client agility for exceptional situations. >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
