Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

Mark Andrews <marka@isc.org> Wed, 20 February 2019 21:09 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2312D4F0 for <dnsop@ietfa.amsl.com>; Wed, 20 Feb 2019 13:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 O6s1yTFCcQ13 for <dnsop@ietfa.amsl.com>; Wed, 20 Feb 2019 13:09:55 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37771130E84 for <dnsop@ietf.org>; Wed, 20 Feb 2019 13:09:55 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 68DE93AB061; Wed, 20 Feb 2019 21:09:54 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 26739160070; Wed, 20 Feb 2019 21:09:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1251416006F; Wed, 20 Feb 2019 21:09:53 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v1afyUK_bykH; Wed, 20 Feb 2019 21:09:53 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 2139A16005B; Wed, 20 Feb 2019 21:09:51 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <alpine.DEB.2.20.1902201928250.19193@grey.csi.cam.ac.uk>
Date: Thu, 21 Feb 2019 08:09:49 +1100
Cc: Joe Abley <jabley@hopcount.ca>, dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9330E97B-76BF-4C6F-8F6F-01349A3E7427@isc.org>
References: <155053239541.25848.12960190085730298684.idtracker@ietfa.amsl.com> <969D8BA1-6ED3-47E8-AFFD-2BEE8EA3E66B@bangj.com> <alpine.DEB.2.20.1902191219070.766@grey.csi.cam.ac.uk> <0DE33073-93B1-4CF5-B12D-B7266E21E8B2@timwattenberg.de> <alpine.LRH.2.21.1902191715230.30381@bofh.nohats.ca> <1F461BFA-638A-4607-84BD-F8B8597A1114@isc.org> <alpine.LRH.2.21.1902200028210.29865@bofh.nohats.ca> <646C86F6-C10D-43DF-ADE8-19222994E4D1@hopcount.ca> <E41DDEED-DF50-481F-9378-D721C3612643@isc.org> <alpine.DEB.2.20.1902201928250.19193@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BPY_5LyGr1UMpskm7g8ARsV5Itg>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 20 Feb 2019 21:09:57 -0000


> On 21 Feb 2019, at 6:30 am, Tony Finch <dot@dotat.at> wrote:
> 
> Mark Andrews <marka@isc.org> wrote:
>> 
>> All that is missing is the automated cleanup.  DNS servers are quite
>> capable of doing that once specified how.
> 
> Does it need to be per-record? Why not GC the whole RRset?

Because there are scenarios where you do want to GC as single
record from the RRset. AD has them with SRV.  Each server adds
its own SRV record to the RRset.  When a server goes away without
cleaning up you want the SRV to go but the RRset to remain.

A machine has permanent and time limited addresses.

I’m sure there will be other cases where you want selective deletion
from a RRset.

Mark

> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Fair Isle: Southwesterly 5 or 6, occasionally 7 later in west. Moderate or
> rough, occasionally very rough at first in west. Rain. Good, occasionally
> moderate.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org