Re: [DNSOP] sentinel and timing?

Paul Wouters <paul@nohats.ca> Thu, 08 February 2018 06:02 UTC

Return-Path: <paul@nohats.ca>
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 51CD312D7F1 for <dnsop@ietfa.amsl.com>; Wed, 7 Feb 2018 22:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 TqJfe4HeFfGw for <dnsop@ietfa.amsl.com>; Wed, 7 Feb 2018 22:02:33 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 AE016127342 for <dnsop@ietf.org>; Wed, 7 Feb 2018 22:02:33 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zcSK2045pz3Cg; Thu, 8 Feb 2018 07:02:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1518069750; bh=8MKqnwwxzQZD5KLAg+ZEHFOETGhLcDlZJqgq5YN64cE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=blA5Kv2/Wwd0QS64Nrz8hiSYee/ISFp1Yiv+8OXJ0BgZhL9l10eWLoIdsuIm/SMlZ U0yeUI8YyVeqwYFboWSc9T8LCExPGdbsjHBpq6sHwqFU5U6Ur4MnO1zyC8DrdGBPhi BPDJzNs/xGdrp/CyjI1KDbvUonsJ80gAFi4kJqyI=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id lDnPkrxiM3u8; Thu, 8 Feb 2018 07:02:28 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 8 Feb 2018 07:02:28 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id C0D5A30B3F6; Thu, 8 Feb 2018 01:02:27 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C0D5A30B3F6
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B61E54023330; Thu, 8 Feb 2018 01:02:27 -0500 (EST)
Date: Thu, 08 Feb 2018 01:02:27 -0500
From: Paul Wouters <paul@nohats.ca>
To: Robert Story <rstory@isi.edu>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <20180207215502.46daf6bc@titan.int.futz.org>
Message-ID: <alpine.LRH.2.21.1802080059480.6658@bofh.nohats.ca>
References: <alpine.LRH.2.21.1802071035280.6369@bofh.nohats.ca> <20180207215502.46daf6bc@titan.int.futz.org>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/U1H44r2QZHjQ0VPwHqt0fu2rmsU>
Subject: Re: [DNSOP] sentinel and timing?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 08 Feb 2018 06:02:35 -0000

On Wed, 7 Feb 2018, Robert Story wrote:

> On Wed 2018-02-07 10:43:16-0500 Paul wrote:
>> How about using this query to also encode an
>> uptime-processstartedtime value? Maybe with accurancy reduced to
>> minutes. I think that would return valuable data.
>
> -1 for feature creep and the technical reasons Joe mentioned.

We have a giant hole in our understanding of why there are updated
nameservers running the latest software with the older keys. We
need to gain understanding and we know we need more data.

Getting more data is the core mission, not feature creep. If there is
a technical better way to do this, it's worth considering.

Paul