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

Ted Lemon <ted.lemon@nominum.com> Mon, 02 December 2013 02:37 UTC

Return-Path: <Ted.Lemon@nominum.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 1DC571AE2C3 for <dhcwg@ietfa.amsl.com>; Sun, 1 Dec 2013 18:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 7bO3JgZHIufu for <dhcwg@ietfa.amsl.com>; Sun, 1 Dec 2013 18:37:04 -0800 (PST)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5CC1AE238 for <dhcwg@ietf.org>; Sun, 1 Dec 2013 18:37:04 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUpvyTgwqxvKP1RiyfjSgXzLi2akBRs5z@postini.com; Sun, 01 Dec 2013 18:37:02 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 655561B82F0 for <dhcwg@ietf.org>; Sun, 1 Dec 2013 18:37:02 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 40901190043; Sun, 1 Dec 2013 18:37:02 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Dec 2013 18:37:02 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <529BD4CF.6000408@ntp.org>
Date: Sun, 1 Dec 2013 21:36:59 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <A775B456-E8F6-4111-AFB3-B51BB92ABFC7@nominum.com>
References: <20131201204227.7978.2067.idtracker@ietfa.amsl.com> <83842BD2-0261-472F-9CA1-AFBFB47EAD91@ogud.com> <C0A2F49F-7695-47E9-8AB0-7F94116437F9@nominum.com> <B0A571B5-438A-47AB-AAA4-00D3FC077E22@ogud.com> <331C154E-1A09-4BDD-A70A-AB67BEA2E1E8@nominum.com> <529BD4CF.6000408@ntp.org>
To: <mayer@ntp.org>
X-Mailer: Apple Mail (2.1822)
X-Originating-IP: [192.168.1.10]
Cc: NTP Working Group <ntpwg@lists.ntp.org>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>, Bernie Volz <volz@cisco.com>
Subject: Re: [dhcwg] 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 02:37:06 -0000

On Dec 1, 2013, at 7:31 PM, Danny Mayer <mayer@ntp.org> wrote:
> We need a joint agreement on how to deal with this between DHCP and NTP
> Working Groups assuming that is a viable option in the first place.
> RFC5908 was not a good indication of this.

RFC 5908 got approved pretty much accidentally, without finishing the review process in the DHC working group.   It was a major screwup, and I don't precisely know how it happened.   It doesn't really do what you wanted, and it certainly doesn't do what we wanted.   I agree that this needs to be resolved, but the resolution has to be based on reasoning, not an instinctive reaction to past pain.

I'm not even convinced that DHCP is the right way to distribute NTP server information.   I suspect Olafur may be thinking about the case that's more common at present, which is that an FQDN is hard-coded into the O.S. distribution, and resolved at startup time.   In that case, DHCP's ability to deliver NTP server IP addresses doesn't help.

As for the home router use model, it may be that what you really want is for the home router to query for an FQDN-only DHCP option from the ISP DHCP server, and then resolve that FQDN and respond to DHCP clients on the homenet with an IP address.   Since the FQDN is not hard-coded, and the IP address is (one hopes) resolved either at query time or when its TTL expires, this ought to prevent a repeat of the firmware burn-in incident.