On Thu, 29 Jul 2021, Ryan Sleevi wrote:
On Thu, Jul 29, 2021 at 5:44 PM Martin Duke <[email protected]> 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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
