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