Warren,

You're right-- our apologies for a misunderstanding combined with a bad edit in 
the summary as sent.

Both drafts are on the agenda for London, so you (all the authors) can do an 
update if you feel it's necessary, and we'll move them ahead for final 
review/WGLC.

Thanks for your attention and helping us get it right :)

best,
Your Chairs

On Feb 21, 2014, at 4:06 PM, Warren Kumari <[email protected]> wrote:

> On Fri, Feb 21, 2014 at 12:17 PM, Suzanne Woolf <[email protected]> 
> wrote:
>> Dear Colleagues,
>> 
>> 4. CDS and related: what are we doing about the topic of DNSSEC in-band key
>> maintenance? This has previously been somewhat contentious and seems to have
>> stalled without resolution. We now have current versions of two drafts and
>> would like to make progress on resolving differences.
>> http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
>> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
> 
> We don't think that there are differences -- they are *complementary*,
> not *competing*.
> They solve related, but different problems.
> 
> From: 
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
> "  The solution described in this document only allows transferring
>   information about DNSSEC keys (DS and DNSKEY) from the child to the
>   parental agent.  It lists exactly what the parent should publish, and
>   allows for publication of stand-by keys.  A different protocol,
>   [I-D.csync], can be used to maintain other important delegation
>   information, such as NS and glue.  These two protocols have been kept
>   as separate solutions because the problems are fundamentally
>   different, and a combined solution is overly complex."
> and:
>   "Special thanks to Wes Hardaker for contributing significant text and
>   creating the complementary (CSYNC) solution, and to Paul Hoffman and
>   Mukund Sivaraman for text and review."
> 
> 
> And from: 
> http://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
>   "This specification does not address how to perform bootstrapping
>   operations to get the required initial DNSSEC-secured operating
>   environment in place.  Additionally, this specification was not
>   designed to synchronize DNSSEC security records, such as DS pointers.
>   For such a solution, please see the complimentary solution
>   [I-D.kumari-ogud-dnsop-cds] for maintaining security delegation
>   information."
> and:
>   "A thank you goes out to Warren Kumari and Olafur Gu[eth]mundsson,
>   who's work on the CDS record type helped inspire the work in this
>   document, as well as the definition for "Parental Agent" and "DNS
>   Publisher" definitions. "
> 
> There is no monkey knife fight here -- we are all one big happy family.
> The CDS authors believe we have integrated all the suggestions and
> addressed the questions and would like to go to WGLC.
> 
> W

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to