Re: [DNSOP] Last Call: <draft-ietf-dnsop-child-syncronization-02.txt> (Child To Parent Synchronization in DNS) to Proposed Standard

[manning <[e-mail]>]

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 <[e-mail]> wrote:

> 
> On Aug 10, 2014, at 8:50 PM, Randy Bush <[e-mail]> 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
>