the cadr software triggered updates on either a change in value of a referenced retype, OR, when sent a signal in an oob fashion (e.g. look for an update now)
in either case, the child was triggering synchronization - which is also what your draft does. /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 6January2015Tuesday, at 22:05, Wes Hardaker <wjh...@hardakers.net> wrote: > manning bill <bmann...@isi.edu> writes: > >> just for the record, the prior art was not referenced in this draft, even >> though >> Warren was notified when he was working on its predecessor. it would be nice >> to actually acknowledge prior art. > > It just passed iesg review, and the posted changes this time were > wording agreements between myself and the IESG (the WG was cced for the > important changes). > >> http://archive.icann.org/en/meetings/saopaulo/presentation-cadr-07dec06.pdf > > I'll try to get an acknowledgment in the AUTH48 period if that works for > you. It looks like the last (major) bullet on your slide 10 indicates > that a parent can trust the child information because of dnssec, which > is what we're making use of certainly. Your slides seem to hint at a > much more active "update request" though, which is not the way the CSYNC > record works. > -- > Wes Hardaker > Parsons _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
