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

Ted Lemon <> Thu, 21 February 2019 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D4F812D4F0 for <>; Thu, 21 Feb 2019 15:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ppvMWPLkqG9 for <>; Thu, 21 Feb 2019 15:22:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90BDB12D4ED for <>; Thu, 21 Feb 2019 15:22:19 -0800 (PST)
Received: by with SMTP id q3so167091pll.4 for <>; Thu, 21 Feb 2019 15:22:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pMdEdr+cP7TYtDwC6IZiG9B7bPpJOsOKMC14GNi8ysw=; b=uWnF8tfzG+MwTNlDV/5twAnotSol09MV633ufblx5q71NPGIgc72l7Usavjs7u9St9 gMMfz9Znh3jLG0DndMDArbn6/8vMNZFxLpF5Ai9DKeYR3Le+nRuhx4eAgH1+YUib42B2 BKRYPyLM/RZuNUubHyaxjGemWEPGlkbXPJwdJw9PfQH25cNIud/31OuY2SEKsS7TtBQl jQEzOHpuzV+E6oNSXLgPLiBHp5gMh5OPPso1FbPRYS5bfs9Lll8+D99kBDAJV7v65Jn9 ADbg4+lcHmnPj+CdXuWBdw3TypyuPFNz0kecWmwuLgOsa1femjbze/ac9oZxk3dxYBVX vG6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pMdEdr+cP7TYtDwC6IZiG9B7bPpJOsOKMC14GNi8ysw=; b=VqCy4WofWSUBqqoqzPbXESsBpK4/mN/KoWtOY86mkwN0Zeg5fwylvom4INa9wVeWht 11SJqaRWpTMt5hSZKLDs4txcFAbCleFTZX3lWk61vqeUCTxWJBa5VPS6HTF6d4eyzst/ 1ZnYXrM+kN89wk2g0upqmBX1EWEqHqTAP+SWqtoLYPCSCj0QCXCNN3RZSMxzv3C40Sur GSnNN+X50pVH3PO/OI7xlyGlgzgZPUkWdAJ0JPE2R4zBJQYwarC6gCDaelyDcvf3sEaE RX8Yxigok3avL04IMbXXvwR1zxaawR9uySGbJNUrw1qgVNGg3IwWNfblxkzwH8jpa5/q mbIg==
X-Gm-Message-State: AHQUAuZN3gl8S5UhxvSF8cODLJ1DVKQVV8Mc2tKZ/+YwSCxqltxzpu5o 37ZQltszqAs1MgUXBD+7jz9/Xg==
X-Google-Smtp-Source: AHgI3Ia1Ld3ua0sdGosFlvknleWbbRy4aiHh6nNpETYO7LBN2hqT+eVuvr0r2wZauLUDtioH/rEpSw==
X-Received: by 2002:a17:902:449:: with SMTP id 67mr1073880ple.310.1550791338760; Thu, 21 Feb 2019 15:22:18 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id r131sm121526pgr.65.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 15:22:17 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_74B27F5D-4BC5-4AE9-A373-70F0C38114C1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\))
Date: Thu, 21 Feb 2019 15:22:16 -0800
In-Reply-To: <>
Cc: Mark Andrews <>, dnsop <>, Paul Wouters <>
To: Joe Abley <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.2)
Archived-At: <>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Feb 2019 23:22:22 -0000

On Feb 21, 2019, at 2:52 PM, Joe Abley <> wrote:
> The master could apply policy based on criteria like owner name pattern matching or source of the update. Garbage collection might not happen with the kind of split-second accuracy that I sense this mechanism's proponents are suggesting, but does it need to? Don't we believe that applications that expect more than loose coherence from the DNS are broken?

The impression that you are working from here seems to be that what is being designed is a hacky kludge that would go well with heuristics like this.   But what is actually being worked on here is a system that is not a hacky kludge, and that does not have leaks, and does not rely on clever heuristics to approximate good behavior.   Please read the service registration protocol document I mentioned in a previous message (draft-ietf-dnssd-srp).

Granted, I am not convinced that the document we are discussing is the right solution to the problem, but it’s an actual solution to the problem, not a hacky kludge, and that’s definitely a good thing.