> On Aug 26, 2018, at 12:58 PM, Ted Lemon <mel...@fugue.com> wrote: > > On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <pusat...@bangj.com > <mailto:pusat...@bangj.com>> wrote: > I think I already agreed with you here. > > My main point was that the primary needs a database and it already has one > and probably doesn’t want another one. Because of the added benefit that Paul > points out with promoting a secondary to primary after an extended outage, > and the points that Joe makes about treating all records the same, it seems > logical to store the lease lifetime information as actual resource records > and transfer them to the secondary. > > FWIW, I think the database storage argument is actually the best argument for > this proposal: we need a way to represent the data structure on disk, and > what we know how to store are RRs. > That said, I think that it's worth asking the question of what the right > format is, and not just assuming that it's a hash.
Nice properties of the hash: 1. the length of the output value is consistent across varying input lengths of any RR type (128 bits in the case of the algorithm specified in the draft) making it easy to sequence through. 2. it’s independently verifiable between servers and across time on the same server 3. it’s independent of position of the RR it covers 4. it works the same for all existing RR’s as well as RR’s yet to be defined Other methods may share some of these properties but I’m just listing all of the ones I can think of. Thanks, Tom
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
