Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

Richard Gibson <> Sat, 24 November 2018 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76C14130DE2; Fri, 23 Nov 2018 17:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.76
X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 QnaStFGq-l_U; Fri, 23 Nov 2018 17:03:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D42C130DCF; Fri, 23 Nov 2018 17:03:09 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id wAO10Ekc132569; Sat, 24 Nov 2018 01:03:08 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2018-07-02; bh=A2uxEDxdUQkvEDl89JtmUeBcPC6Li/T7C3MbYv/orgg=; b=ybkdETAHjOs8+XnYLUoQ7Mdc/sXtuUexeW9oh3S/xWwrhfnjhMt0WMOOdP2gqPv4vXPp h8RhDGHVWTBlRj7jLm9i6iKebzVxTDH97vBJgAzEy0kwzHR79gin+IDuQZx0Lztc9wDE +EqveRJIc0LJgnOlpLWQYERNWfszemE2clyKHMWijSvUMho4887k3YIrf1tElhhrrt6F B1+Zkqt3w6r9v9+hn1UU37xuLWpxCy7WJnGGw2gk9dmGal92/raCo4NEy7tX0s8vr/bN ool4EWmkjZvJvvFRvZ79KfnR0aJW0ibjaAkM20hCEq2nLkdUYUPlaBM6+0BzO0F8SsAC vw==
Received: from ( []) by with ESMTP id 2ntaxqmb47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Nov 2018 01:03:07 +0000
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id wAO131GK003034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Nov 2018 01:03:02 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id wAO130II026211; Sat, 24 Nov 2018 01:03:01 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Nov 2018 17:03:00 -0800
To: Sara Dickinson <>, Benjamin Kaduk <>
Cc: Tim Wicinski <>,,, The IESG <>,
References: <> <>
From: Richard Gibson <>
Message-ID: <>
Date: Fri, 23 Nov 2018 20:02:57 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------FBF717B70E5AB7B771A8787C"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9086 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811240008
Archived-At: <>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
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: Sat, 24 Nov 2018 01:03:12 -0000

On timekeeping:

On 11/22/18 07:01, Sara Dickinson wrote:
>> Section 7.5.1
>> Does "earliest-time" include leap seconds?
> Thanks for noticing this…after digging into it…
> The description specifies the number of seconds to be the
> number of seconds since the POSIX epoch ("time_t"). POSIX requires that
> leap seconds be omitted from reported time, and all days are defined as
> having 86,400 seconds. This means that a POSIX timestamp can be
> ambiguous and refer to either of the last 2 seconds of a day containing
> a leap second (who knew time could stand still in POSIX world - aargh?!)
> However, libpcap (for example) can only provide POSIX timestamps for
> packets as far as we can see…
> Do you think we should just document this as a limitation or do you have
> another option in mind?

I am currently going through a similar exercise in another context, and 
the best current text there explicitly characterizes the non-obvious 
day-based accounting of POSIX time. In this context, it would look 
something like

    A time value that is a multiple of 86,400 (i.e., is equal to 86,400
    × /d/ for some integer /d/) represents the instant at the start of
    the UTC day that follows the 1970-01-01T00:00Z epoch by /d/ whole
    UTC days. Every other finite time value /t/ is defined relative to
    the greatest preceding time value /s/ that is such a multiple, and
    represents the instant that occurs within the same UTC day as /s/
    but follows it by /t/ − /s/ seconds.

    Time values do not account for UTC leap seconds—there are no time
    values representing instants within positive leap seconds, but there
    are time values representing instants removed from the UTC timeline
    by negative leap seconds. However, the definition of time values
    nonetheless yields piecewise alignment with UTC, discontinuities
    only at leap second boundaries, and zero difference outside of leap

However, there may be C-DNS purposes that cannot tolerate such 
discontinuities, and they would presumably want to use a continuous 
monotonic timescale with a fixed offset from TAI (as is the case for 
e.g. GPS time). It would be nice to have a field in StorageParameters 
defining the time scale and therefore proper interpretation of 
Timestamps, defaulting to UTC-approximating POSIX but also accommodating 
unadjusted seconds counting.