Re: [Trans] Martin Duke's No Objection on draft-ietf-trans-rfc6962-bis-39: (with COMMENT)

[Paul Wouters <[e-mail]>]

On Thu, 29 Jul 2021, Ryan Sleevi wrote:

> On Thu, Jul 29, 2021 at 5:44 PM Martin Duke <[e-mail]> wrote:
>       So returning to my previous point, it seems rather heavyweight to update the IANA registry
>       every time this happens, and it would arguably be efficient to assign a given operator a range
>       so that these need not be deconflicted in perpetuity?
> 
> 
> Isn’t that just reinventing PENs under a shorter arc, at that point?
> 
> In practice, what we see is log operators creating multiple logs at once (e.g. for six annual shards), and
> then updating annually or semi-annually to add new temporal shards.
> 
> So I’m not sure which part of the heavy handed is being optimized for, mostly due to ignorance on my part:
> is the concern this is process intensive on the IANA part, or the log operator part? If the log operator
> sees this as intensive, then they’ve got the PEN route as a readily deployable alternative (at the cost of
> larger messages). If it’s overhead on the IANA part, then that would seem to argue scrapping the whole
> “too clever and a half” idea of “use a short OID because, for historic reasons, IANA has some”, and just
> pay the 4-10byte tax for using PENs.

Martin,

Thanks for your thorough review and voluntary Merkle Tree diving.

It seems the above answers your question. Log operators have a choice on
how to get their unique log ID(s). They can get a larger assignment and
use numbers within their assignment trivially, so there is no problem
of something being too "heave handed" I believe. They don't have to use
IANA if they already have their own OID space, and if they don't they
can easilly get a suitably large assignment by a one-time action.

I think we are really late into the game to go and change anything
related to this now, especially as we have seen years of no issues with
RFC 6962 and log IDs. As you stated your comment was "non-blocking",
we will consider this comment resolved.

Thanks,

Paul