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

Ted Lemon <mellon@fugue.com> Fri, 24 August 2018 18:59 UTC

Return-Path: <mellon@fugue.com>
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 0FF6B130DD5 for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 11:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 Bk2uUMTIZUVF for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 11:59:33 -0700 (PDT)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE36A130E2A for <dnsop@ietf.org>; Fri, 24 Aug 2018 11:59:28 -0700 (PDT)
Received: by mail-yb0-x22a.google.com with SMTP id o17-v6so3860668yba.2 for <dnsop@ietf.org>; Fri, 24 Aug 2018 11:59:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=prlPWFFuju6iCnIOQjwrMAzeZ4PNtk94gIbg6oU9nwA=; b=kEMUcj0Z0943CZ1jvk7id6BQBob05hIM/6R7JHtj6eZdL8g/DDsfWW+nMeLcfpokQN 0fP7DuEqfUi/JAcgcDoqWPweMN2QuaQ2cSXqG+nPF33dyXPeUvko2oIWGigtzhhOYNBc NIOGqaB/KvrV/eMufLnTsxkqRcIg8136CNyjzlXmnAopFoqV5unmv4vcG1NdZP4rSkai 2gPy+IEwTbPepBNGyep9l8e4NO9pjGD06VQNIK//H7rKShvaaePVI+IFBGinZ58Qx7Fj jYE8oL8hYImKCxUmIMWozpv7QzGZdVtwpUaGNs3hyVoL8/xcEevGyrCrW92i/YagRqVt aVvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=prlPWFFuju6iCnIOQjwrMAzeZ4PNtk94gIbg6oU9nwA=; b=qxexfv5Rj7yN2lLTccn4Y4gRabvYlz5UuMh8ktZIniUj5oWVpn9MEkYINlmyd4EsAh nmOWEjBwdkzdugyp+e4VXHZpy1ec6IghJPqrfQcuH9oHGd/MLFbfClhTLVoQ7r1/Q8Nb lGbxHxOAagnNxMUmkwbbRl5GT3mzgqUY8nlN2X61YwSYbU2SkL+4fbN2D3lKYknn5SX0 j0AjBt7A79hK3l4M1jAHrjS3GDYQOVKI36qiKfJ2EXRKVJPPoXz7yzTxvzcvZWL/fGME DgjcFUemR+0wnXHB9zQW9lXCLdWMNpk9AVP7NLvn+vxksitsFCqHE7oEuh2MzMei5vgz RT3g==
X-Gm-Message-State: APzg51AJQ3QzZ3Yakiy6CxRCUxANUUceBVszLe5Nf4Wb0WRykgTeznR6 uPj5uav4Td9g93PCtEpRxSVqgw==
X-Google-Smtp-Source: ANB0VdZdzTqZSj+vp9zUa9+mOUYgNNE/1CyReAsOWetHxaGoTQqUuN+Vu+nO8bvYYZ1pC3xGiZ75rA==
X-Received: by 2002:a5b:4e:: with SMTP id e14-v6mr1838711ybp.138.1535137167628; Fri, 24 Aug 2018 11:59:27 -0700 (PDT)
Received: from [10.0.100.12] (c-73-167-89-221.hsd1.ma.comcast.net. [73.167.89.221]) by smtp.gmail.com with ESMTPSA id h63-v6sm3115300ywb.28.2018.08.24.11.59.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Aug 2018 11:59:27 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <F4335D3A-0241-437F-A428-8EA95F0A1C18@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6766645F-F084-40E0-A0EC-8AF37F3904E1"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.38\))
Date: Fri, 24 Aug 2018 14:59:25 -0400
In-Reply-To: <47AE41F8-9F5F-4CC8-B4F0-7E8191011E99@bangj.com>
Cc: dnsop WG <dnsop@ietf.org>
To: Tom Pusateri <pusateri@bangj.com>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com> <5B7F5E07.5080100@redbarn.org> <7F91FFF7-71C3-4F8E-82CD-266B170983E0@bangj.com> <C0EE2719-B662-4231-AF51-D3B98B00AD0D@fugue.com> <6D607922-393D-4549-AAFA-49279C260CA4@bangj.com> <3C6100BD-62D6-41ED-B7BF-679F0D4E4113@fugue.com> <5063A32B-4877-4860-BA73-CCB068AB7FCB@bangj.com> <CAPt1N1=tXZNgT6ygAaLFfOMze7hbGZ6q_eN1C3iEo9ryBNcyLg@mail.gmail.com> <98EF2CAC-7C13-4E68-8D2B-EC0659EA9646@bangj.com> <CAPt1N1kFNY4=CUMsTvXmeRREeLAkY8xpBdw4vPDxujgke6QT8A@mail.gmail.com> <963460AA-14BB-44AA-87CA-7F09A707DB5D@bangj.com> <47AE41F8-9F5F-4CC8-B4F0-7E8191011E99@bangj.com>
X-Mailer: Apple Mail (2.3445.100.38)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/L3E7ffksT7lp-YthSlE6Jc6OLuU>
Subject: Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 24 Aug 2018 18:59:37 -0000

On Aug 24, 2018, at 2:43 PM, Tom Pusateri <pusateri@bangj.com>; wrote:
> It seems odd to take the position that the authoritative server shouldn’t need to clean up stale entries because it assumes the client will do it for you. I can’t imagine you taking this position under any other scenario.

The issue here is that this is a pretty major change to the DNS.   If we really want something this heavy, we should have a good reason for wanting it.   That's all.

The idea that some unnamed DHCP server somewhere doesn't do the right thing with cleaning up stale entries doesn't seem like a good enough reason, particularly given that the DHCID record tags the thing as having been added by the DHCP server, and considering that there are several open source implementations that do automatically delete records when the lease expires.

I think it might make sense to just wait on this.  I agree that it's an interesting idea for completeness, but we don't have enough operational experience yet to know whether we have a problem worth solving.   With respect to the DHCP use case, I'm certain we don't.

The good news is that if we do need this, you've done a design, and we also have Paul's design to look at.   So if operational experience a few years down the road shows us that we have a gap here, we can move on it pretty easily. I just don't see any reason to rush into it.