Re: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

Joe Abley <> Wed, 09 October 2013 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9890821E8179 for <>; Wed, 9 Oct 2013 11:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f4TC8p9+kUez for <>; Wed, 9 Oct 2013 11:00:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22f]) by (Postfix) with ESMTP id B4E8D21E8157 for <>; Wed, 9 Oct 2013 11:00:01 -0700 (PDT)
Received: by with SMTP id kp14so1417132pab.6 for <>; Wed, 09 Oct 2013 11:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ijwhYAiyrBwWKq0mQTB/5PzwTsyn0aWjUbDqdU+0tpY=; b=opHDIugjhu7LIqsaxkwqRfK97f5uB3Pr2q0yqGWJs2Z3MU6cG+KtulyBS2iOhTDJ3N qa7/aoAwxZwWZRA8uE89wPUq7eUIncuR5wyqnycKDCjG6FP4bXEMiMxmLUd70CcztqYD 5u8K/yeoLPW4W2HQteE/sZ2dp6ywQHIkb3Z0Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ijwhYAiyrBwWKq0mQTB/5PzwTsyn0aWjUbDqdU+0tpY=; b=MxdUz0B6MUqewbLwXj4SZdbHLEPnsp21IyexmDjD+xfQr6u6ift0bdRTF40oMBVRaF NVA3PtHbRgACpyGOZpJ2FubYyfPTmBCnQQ0kU5DZrBm0SA21Y+fO9ZGTC+4wUQO6qB9L mdh4p2NRsNbdaGzt1axLuNy85owbVG2j1J+cQ/JjQKDthxTHVZbsuA6zOT/Wi0lLw9cN LOvnP3oxafKUAWwhCzOH9TFcPPALtfGbQ1upUKYcfMAE9c6DAcXii2lxSkuvQpedF6uS G/EZC6MGpcRnQXA1K1pueBYTqgHLywuOnkBs82822ACfM1DMX+i4WEJymuvlsce8ceUq JeYg==
X-Gm-Message-State: ALoCoQnYt+hTxuQVwOCBsLCaZChwizyAJC3u1z5xT5PHsBNZWeJDVhOS/maLLNcTc+NZtJ8AbBZQ
X-Received: by with SMTP id an8mr11079387pac.58.1381341600303; Wed, 09 Oct 2013 11:00:00 -0700 (PDT)
Received: from ?IPv6:2620::ce0:104:a8af:1749:23a8:ed08? ([2620:0:ce0:104:a8af:1749:23a8:ed08]) by with ESMTPSA id tz3sm47980277pbc.20.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 10:59:59 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
From: Joe Abley <>
In-Reply-To: <>
Date: Wed, 09 Oct 2013 10:59:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.1510)
Cc: "" <>, "" <>, Cullen Jennings <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Oct 2013 18:00:36 -0000

On 2013-10-09, at 10:53, Ted Lemon <> wrote:

> Of course there are cases where this doesn't matter, and DHCP is just fine, but I can't think of any other than perhaps a self-setting wall clock.

DNSSEC validation imposes a requirement for clock sync (to the accuracy reasonably required to consider signature inception and expiry times). There is a possible future in which such validation takes place on end hosts, rather than intermediate resolvers. (We may wind up somewhere else, but there are certainly people who think that is the Right Way).

In that sense any device that needs to look up names in the DNS has a potential requirement for time sync.

Of course even the wall clock you imagine might have a vendor who is capable of running their own array of time servers as (e.g.) Apple does, but it seems reasonable to imagine that there will be people who are not in that position, and since I agree with you when you say:

> Of course, if a CPE vendor were to hard-code the FQDN of an NTP server belonging to someone else into their devices, that would be disastrous.

it seems to me that there's a plausible use case for a DHCP client to receive direction on what servers to chime against.