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

Sten Carlsen <> Sat, 12 October 2013 18:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68F0321E8108 for <>; Sat, 12 Oct 2013 11:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6i16GDBW4Cli for <>; Sat, 12 Oct 2013 11:02:50 -0700 (PDT)
Received: from ( [IPv6:2001:16d8:dd00:81ac::17]) by (Postfix) with ESMTP id B237B21E8063 for <>; Sat, 12 Oct 2013 11:02:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPA id 0A62241B5; Sat, 12 Oct 2013 20:02:44 +0200 (CEST)
Message-ID: <>
Date: Sat, 12 Oct 2013 20:02:43 +0200
From: Sten Carlsen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Bernie Volz (volz)" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------020009020804060800030704"
Cc: " WG" <>, Ted Lemon <>
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Oct 2013 18:02:52 -0000

My 0.02EUR/$

On 12/10/13 16:26, Bernie Volz (volz) wrote:
> Two points:
> 1. A server should NOT be required to do a "fresh" lookup if the TTL for the DNS information has not expired [or it not close to expiring].
This is ok, we *should* expect that change in e.g. ntp servers coincide
with a change in DNS, hence new information should appear at a time
"natural" lookup time.
> 2. This doesn't solve all of the issues since the DNS TTL, as Ted has pointed out in some discussions, is not generally related to the lease (or renewal) time. Thus, it really depends on when the client is expected to use this information which could be long after the TTL for the original DNS query has expired.
It clearly does not solve the issue but makes it possible to manage the
world so it does partly solve the issue. -> make sure your DHCP renewal
period is short enough that a renewal will pick up the change soon
enough, coordinated with DNS TTLs.

I know it is not too pretty, so any better ideas are welcome.
> Hence, depending on when a client is expected to use this information should greatly influence the decision as to whether to define an option as an FQDN or address(es). For example, for a next step bootstrap loader (or configuration file such as for DOCSIS), an address is fine as this is expected to be used by the client almost immediately. Something that may be used hours or days later when a user requests a particular application really SHOULD use an FQDN.
> - Bernie
> -----Original Message-----
> From: [] On Behalf Of Ted Lemon
> Sent: Thursday, October 10, 2013 10:46 AM
> To: Sten Carlsen
> Cc: WG
> Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
> On Oct 10, 2013, at 10:45 AM, Sten Carlsen <> wrote:
>> What about requiring that it does a fresh lookup, IF it has the server specified as an FQDN? If it is only specified as an IP, obviously there is no option for lookup.
> I think you just answered your own question. :)
> _______________________________________________
> dhcwg mailing list

Best regards

Sten Carlsen

No improvements come from shouting: