Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

Patrik Fältström <paf@frobbit.se> Sat, 12 April 2014 07:28 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3E31A03F9 for <dnsop@ietfa.amsl.com>; Sat, 12 Apr 2014 00:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.523
X-Spam-Level:
X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_LAADyE71dX for <dnsop@ietfa.amsl.com>; Sat, 12 Apr 2014 00:28:26 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id B15DE1A03EA for <dnsop@ietf.org>; Sat, 12 Apr 2014 00:28:26 -0700 (PDT)
Received: from [IPv6:2a02:80:3ffc::dc27:3079:4c44:6c4c] (unknown [IPv6:2a02:80:3ffc:0:dc27:3079:4c44:6c4c]) by mail.frobbit.se (Postfix) with ESMTPSA id C6D0122894; Sat, 12 Apr 2014 09:28:24 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FD232CF3-EE2D-4B99-ACE9-ACDC8511BF91"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <CAHw9_iJCi7jY-tt_+oNozK-A5UQJHGghiqynSy7As9c9G7hBgw@mail.gmail.com>
Date: Sat, 12 Apr 2014 09:28:30 +0200
Message-Id: <EC850D1B-11E5-40C9-948A-023304E0D5F7@frobbit.se>
References: <CAHw9_iJCi7jY-tt_+oNozK-A5UQJHGghiqynSy7As9c9G7hBgw@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/8IJEjqpGjsUkKUVYf_Z_SIXHMfI
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Apr 2014 07:28:28 -0000

No, I want B. That CDS and CDNSKEY is staying in the zone.

  Patrik

On 12 apr 2014, at 00:11, Warren Kumari <warren@kumari.net> wrote:

> [ Apologies all - I initially sent this with no subject line.
> Resending. Hopefully this makes things clearer... Also, unless we hear
> strong objections I'm planning on doing what Patrik and Matthijs
> suggested, option A ]
> 
> 
> On Fri, Apr 11, 2014 at 5:12 PM, Warren Kumari <warren@kumari.net> wrote:
>> Hi there all,
>> 
>> At the moment this document says that the child SHOULD remove the
>> CDS/CDNSKEY record once the parent has consumed / acted on it (this
>> behavior was requested by someone -- unfortunately I cannot remember
>> whom).
>> 
>> I *think* that I'm hearing that folk would prefer that the child
>> SHOULD leave it in, or, less strongly MAY remove it.
>> 
>> This (IMO) makes the doc and the child's life simpler, but potentially
>> makes a bit more work for the parent -- currently most of the
>> time the parent will see no CDS, and so will go back to sleep. If the
>> child leaves them around, the parent will need to check them against
>> what is currently published and take action if they differ.
>> 
>> Can folk please let us know if they would prefer:
>> A: The child SHOULD remove the CDS/CDNSKEY RR from the zone once the
>> parent has published it (currently documented behavior) or
>> 
>> B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a
>> small edit to the doc)
>> 
>> My personal preference is for B - it seems more elegant, but (as
>> always) we'll do whatever the WG wants.
>> 
>> W
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop