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

Warner Losh <imp@bsdimp.com> Mon, 02 December 2013 15:32 UTC

Return-Path: <imp@bsdimp.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD31AE493 for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 07:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts2EsTFCKlWd for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 07:32:07 -0800 (PST)
Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id D9F421A1F74 for <dhcwg@ietf.org>; Mon, 2 Dec 2013 07:32:06 -0800 (PST)
Received: by mail-ie0-f173.google.com with SMTP id to1so20973068ieb.18 for <dhcwg@ietf.org>; Mon, 02 Dec 2013 07:32:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=9SR3GvhEptT54gn7lUwnPRYSCeME0P8YR+HWO1DQY/s=; b=Jm3iYALmVCjZFbSPNuYT95VbJpMYAH6+tTrdjVwfq61qsQOLpzikiqX/HL1UGqdqyK ogovGankamT9kVuFaaQ2+xn8yoC1nKWW8hulaMeNg5lZnUBwLWvllZVvdZs1lXGvCwvD E08+Is3EuGgH0DK9c0/1N/q7PG6O7KTy9ISPKf0DeuHNwucffpf2ppNrxkjaMkLhLqeL tE/o/HYLqbuy1rhRgdgm43R4k8Z3r8Aond3wmU7cwZ2WnZtHFvsjjiTObYuhGEQScYAJ fsBM9XZXxTn9zgp+wu5pwlMsFSWNHN5PaM25gjoNuhSg2hm+cyO6eHwshMd6b6qi3HvG tuFg==
X-Gm-Message-State: ALoCoQmBGlSV9uAiK61RY70wN4ZUoBiofxoiaO3eHleVyidaxe7ICDsE0H3/EiZLiVOfd0phasOV
X-Received: by 10.50.16.68 with SMTP id e4mr18460998igd.12.1385998324247; Mon, 02 Dec 2013 07:32:04 -0800 (PST)
Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id da14sm26843873igc.1.2013.12.02.07.32.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 07:32:03 -0800 (PST)
Sender: Warner Losh <wlosh@bsdimp.com>
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Warner Losh <imp@bsdimp.com>
In-Reply-To: <529CA616.3010402@ntp.org>
Date: Mon, 2 Dec 2013 08:32:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <19575403-444E-4CBA-8818-5F46328787AE@bsdimp.com>
References: <20131202044734.B78E0406060@ip-64-139-1-69.sjc.megapath.net> <529C1A31.2080900@ntp.org> <258D838F-F4BA-45D2-AA41-BB05E3AB147C@ogud.com> <529CA616.3010402@ntp.org>
To: mayer@ntp.org
X-Mailer: Apple Mail (2.1085)
Cc: Hal Murray <hmurray@megapathdsl.net>, Bernie Volz <volz@cisco.com>, NTP Working Group <ntpwg@lists.ntp.org>, Ted Lemon <ted.lemon@nominum.com>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] [ntpwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 15:32:09 -0000

On Dec 2, 2013, at 8:24 AM, Danny Mayer wrote:
>> Danny, Thanks for the kind introduction 
>> 
>> 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.

Warner