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

[Rob Stradling <[e-mail]>]

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