On 24/09/2019 03:05, Ryan Sleevi wrote: > On Mon, Sep 23, 2019 at 11:36 PM Paul Wouters 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.
Paul, I'm not sure what you mean by "this change". If there's consensus to not add a mechanism (that would allow logs to modify their base URLs) to 6962-bis, then...6962-bis already doesn't have such a mechanism. Are you perhaps suggesting that "this change" would be to add a sentence to the end of section 10.6.1 along these lines: "IANA is asked to reject all requests to modify or remove entries from the Log ID Registry" ? > 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. Ryan, thanks for chiming in here. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
