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
- [DNSOP] draft-ietf-dnsop-delegation-trust-maintai… Warren Kumari
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Patrik Fältström
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Warren Kumari
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Patrik Fältström
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Antoin Verschuren
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Patrik Fältström
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Matthijs Mekking
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Tim Wicinski
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Warren Kumari
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… Warren Kumari
- Re: [DNSOP] draft-ietf-dnsop-delegation-trust-mai… 神明達哉