Re: [dhcwg] [ntpwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt

Warner Losh <> Mon, 02 December 2013 20:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7FA881AD8D5 for <>; Mon, 2 Dec 2013 12:09:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X2jfgJzPf_Aq for <>; Mon, 2 Dec 2013 12:09:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BBE3B1ADEC4 for <>; Mon, 2 Dec 2013 12:09:11 -0800 (PST)
Received: by with SMTP id to1so22177209ieb.32 for <>; Mon, 02 Dec 2013 12:09:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=nD9qyZRQWP+8a0aK7r3rOhfixl0Br4i8b0ZCbbROZ5g=; b=WFj2FBRfxWeW4rszf9eD8hRhlKjoYZKzv8RVoohee/Dsmxspgwcal/43Jz6vwrQXu5 t8i1zff8HdN+xxjlCcqWrm77qfz8hLhFFtMB2VPiZ5qT8zIqc7S1JpOYFZoMPslD2gO5 Nq3F4CjM4olRhKapnKjtmmcSa0UMuMlMKIL8lTFXNgZDqdexcBi7dgameBUTweQK0zSB 3IUxU1QJBMJHyc5jroyl1u1GSPuu0kNjTOJazWSQeuBMc6jJC3mON0Tnim4gZhKZB0RW BT0rrmJXHceqtnJTsMzsWBDDojuIXDLCm8XFhhawfHi6H4dK381HbdMDU5v/GoVamv9J DUMQ==
X-Gm-Message-State: ALoCoQmw4seVhjXopzhOHFNEWzJ/u7fc7Bv4AA4++K9BXIGs/RiYTi6PuhnK+naYwpCffoVwpPF6
X-Received: by with SMTP id q2mr19728670igh.17.1386014949269; Mon, 02 Dec 2013 12:09:09 -0800 (PST)
Received: from ([]) by with ESMTPSA id j16sm67621228igf.6.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 12:09:08 -0800 (PST)
Sender: Warner Losh <>
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Warner Losh <>
In-Reply-To: <>
Date: Mon, 2 Dec 2013 13:09:06 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Harlan Stenn <>
X-Mailer: Apple Mail (2.1085)
Cc: Hal Murray <>, Bernie Volz <>, NTP Working Group <>, Ted Lemon <>, " WG" <>
Subject: Re: [dhcwg] [ntpwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Dec 2013 20:09:13 -0000

On Dec 2, 2013, at 12:58 PM, Harlan Stenn wrote:

> Warner Losh writes:
>>>> The reason for time_t is the dhcp-client can feed that directly into
>>>> following call: settimeofday(const struct timeval *tp, const struct
>>>> timezone *tzp)
>> During a leap second, the value of time_t is not well defined because
>> by definition leap seconds don't happen in time_t/POSIX time scale
>> (don't happen -- well don't consume space in the time_t timescale is
>> more pedantically correct). Obscure point likely worth noting...  But
>> using a NTP time stamp doesn't save you, since during a leap second
>> its value is well defined, but the same as another second (ntp
>> distinguishes in bits set in other parts of the header). Assuming the
>> tolerance for this application is >> 1s, this won't matter, but might
>> be worth specifying that during a leap second, the value returned
>> shall be either the value of the prior second or the value of the next
>> second to make it conform to most current usage.
> It's actually fuzzier than that, and this situation (which is handled
> differently with ntpd under unix, ntpd under windows, and on systems
> that "smear" the leap second over a longer period) is one of the cases
> handled by the General Timestamp API project at Network Time Foundation,
> described at .

Actually, in all those cases it is within a second of the 'real' time, hence specifying that it should be one second or the other seems appropriate. The timestamp APIs are for sub-second resolution, while the time_t in this protocol has only a second resolution... The main point is that it should be (a) specified to be what's going to most likely happen (or keep bounds on the error)  and (b) something sane that doesn't introduce errors > tolerance of the protocol. Having it be completely unspecified is a mistake, since -1 could be returned...