If you have not already done so, you should talk to Johan Ihrn. About 8 years ago, he and a few others hammered much of the parent/child signaling/sync issues that you and Warren are revisiting now. There was some documentation, but it never made the IETF. /bill On 12August2014Tuesday, at 19:23, Olafur Gudmundsson <ogud@xxxxxxxx> wrote: > > On Aug 10, 2014, at 8:50 PM, Randy Bush <randy@xxxxxxx> wrote: > >> as the threat models seem similar why do we need two separate >> mechanisms, one for NS >> draft-ietf-dnsop-child-syncronization-02.txt >> and one for DS >> draft-ietf-dnsop-delegation-trust-maintainance-14.txt >> >> randy >> > > Well there are two things going on here. > > 1. Rules for child expressing how to indicate new trust anchor along with acceptance rules for parent > 2. Child signaling to parent please update “these types” from my zone in the delegation information i.e. NS change or glue changes. > > Warren and I started doing #1 first as that was more critical to our thinking, once people saw that we could update > TA info with DNSSEC in place a light bulb went off and people realized much of mundane delegation maintenance could be automated. > While pushing this through we had to fight get people to realize that there are many different relationships between the parties that > a) operate parent DNS > b) operate DNS for child > c) child > d) Intermediary that handles transaction to create the delegation (i.e. registrar) and processes updates from Child. > > When maintaining delegation information strictly speaking only a) and b) need to be involved but in some cases d) insists to be in the middle > and frequently forces c) to perform some manual action. > #1 tried hard to avoid expressing operational models other than polling and I envision that a better automated model will be created > around CSYNC, which would express if there is a CDS and/or CDNSKEY for parent to consume. > > The WG told DNSOP chairs that they wanted the documents separate even when editors volunteered to merge them. > > Olafur >