Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33

[Ryan Sleevi <[e-mail]>]

On Mon, Sep 23, 2019 at 11:36 PM Paul Wouters <[e-mail]> 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.

>