Re: [DNSOP] summary of WG current status

Suzanne Woolf <> Fri, 21 February 2014 21:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E2311A0293 for <>; Fri, 21 Feb 2014 13:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eYL1e0jDW26e for <>; Fri, 21 Feb 2014 13:41:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::234]) by (Postfix) with ESMTP id C5C4A1A02CF for <>; Fri, 21 Feb 2014 13:41:10 -0800 (PST)
Received: by with SMTP id j15so3973280qaq.39 for <>; Fri, 21 Feb 2014 13:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MEaWf0dLsvlZH1FYjNwk03CSnZDCJpjGCYX1XPhCYnw=; b=C5ul/h33+oiMQVcSFqsK1rFsBJt77r9MiUTah4L9vBLSdG4CHQovAwM2KnVsePpomh mbX+r2NerSzDNgjZrPpblMN/2cd3zbcd0q5nqf356vpUMBoZJ//MxKlfLPCY+AuwHs+R P2+s8FEVmkEDY8LNMkgspZEfsAqATTTcRUMQoYNhJLoZTMkB+D54ElDew3HndRPCWYXB oUCAT5IVwmLcqE8mIQPhP3BuSGmk+wYLGjphAz3dgoG/sX2/wmrl7axZDizqyhXQlwBj 5C7fxXIeg7DMsLcdvosl84aeAlB6fnF6NZT/c56e+957mgiItCJNER8SCVdh13UYmrwx zQEA==
X-Received: by with SMTP id j69mr12683338qgd.42.1393018866694; Fri, 21 Feb 2014 13:41:06 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g36sm558573qge.7.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 13:41:04 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <>
In-Reply-To: <>
Date: Fri, 21 Feb 2014 16:41:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Warren Kumari <>
X-Mailer: Apple Mail (2.1510)
Cc: " WG" <>
Subject: Re: [DNSOP] summary of WG current status
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Feb 2014 21:41:13 -0000


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 :)

Your Chairs

On Feb 21, 2014, at 4:06 PM, Warren Kumari <> wrote:

> On Fri, Feb 21, 2014 at 12:17 PM, Suzanne Woolf <> 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.
> We don't think that there are differences -- they are *complementary*,
> not *competing*.
> They solve related, but different problems.
> From:
> "  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:
>   "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