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?
On Thu, Jul 29, 2021 at 2:36 PM Ryan Sleevi <[email protected]> wrote: > > On Thu, Jul 29, 2021 at 5:15 PM Salz, Rich <[email protected]> wrote: > >> >> - I'm not sure this is correct, Rich? Logs regularly rotate IDs; >> presently annually, but it's reasonable to anticipate more frequently as >> the size/performance tradeoffs, precisely as the way of pruning the >> storage. >> >> >> >> Thanks for the correction! >> >> >> >> So how do replying parties know the log ID changed? >> > > To be clear, the log ID doesn't change (and refer to the same log). Each > Log ID uniquely identifies a log. For example, if a log changes a key, it's > functionally a new log - this is true in 6962 as it is in 6962-bis. The > only thing that changed in -bis is from identifying logs by key hashes to > identifying by OIDs, which was meant to make for smaller encoding. > > The draft flags that the communication of LogIDs is fundamentally > something that is done out-of-band - > https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-40.html#name-log-id > - i.e. up to client policy. For example, for two widespread 6962 > implementations (Apple's {mac, i, tv}OS and Google's Chrome), the list of > recognized logs is governed by user agent/vendor policy, and those logs are > communicated by the vendor (aka "Trusted Log Lists", although trust is a > bit of a stretch) > > >> And do we need to give Log’s not an ID but rather an arc? >> > > No. As with 6962, the idea here is not that "This log was ID X, and is now > ID Y" - but rather "I know of a log with ID X, and I now know of a log with > ID Y, and these are logically distinct, even if their contents are > identical" >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
