Re: [dhcwg] update on dhcp/dns drafts' progress

Ralph Droms <> Sun, 17 November 2002 04:28 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id XAA01588 for <>; Sat, 16 Nov 2002 23:28:04 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id gAH4UJm15365 for; Sat, 16 Nov 2002 23:30:19 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gAH4UJv15362 for <>; Sat, 16 Nov 2002 23:30:19 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id XAA01582 for <>; Sat, 16 Nov 2002 23:27:33 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id gAH4Rvv15273; Sat, 16 Nov 2002 23:27:57 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gAH4MWv15195 for <>; Sat, 16 Nov 2002 23:22:32 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id XAA01473 for <>; Sat, 16 Nov 2002 23:19:47 -0500 (EST)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA20450; Sat, 16 Nov 2002 23:22:22 -0500 (EST)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 16 Nov 2002 22:26:12 -0500
To: Mark Stapp <>
From: Ralph Droms <>
Subject: Re: [dhcwg] update on dhcp/dns drafts' progress
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Mark - In addition to the issue concerning the description of the dhcid RR 
you describe below, two other issues were raised by Ted Lemon in the e-mail 
thread last July.  Here is an excerpt from Ted's e-mail:

 > Unfortunately, I have two tweaks left for
 > draft-ietf-dhc-ddns-resolution-04.txt:
 > 6.2 Adding PTR RR Entries to DNS
 >    The DHCP server submits a DNS query which deletes all of the PTR
 >    RRs associated with the lease IP address, and adds a PTR RR whose
 >    data is the client's (possibly disambiguated) host name. The server
 >    also adds a DHCID RR as specified in Section 4.
 > [...] I mentioned this before, but I don't recall getting any response.  I
 > don't see any reason for the last sentence in this paragraph. [...]
 > 5. DNS RR TTLs
 > [...] I don't think there's any practical reason why the RR
 > on a DHCP client's DNS records should be longer than ten minutes by
 > default.  [...] So I think the
 > text should be changed from this:
 >    A reasonable basis
 >    for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the
 >    expected lease duration might be reasonable defaults. Because
 >    configured DHCP lease times vary widely from site to site, it may
 >    also be desirable to establish a fixed TTL ceiling. DHCP clients
 >    and servers MAY allow administrators to configure the TTLs they
 >    will supply, possibly as a fraction of the actual lease time, or as
 >    a fixed value. In general, the TTLs of RRs added as a result of
 >    DHCP lease activity SHOULD be less than the initial lease time.
 > to this:
 >    The RR TTL on a DNS record added for a DHCP lease should be
 >    no longer than 10% of the lease time, and for leases longer than 100
 >    minutes, the TTL should be no longer than ten minutes.   DHCP
 >    servers and clients SHOULD allow administrators to configure
 >    TTLs, either as an absolute time interval or as a percentage of the
 >    lease time.   In general, the TTLs or RRs added as a result of DHCP
 >    lease activity SHOULD be less than the initial lease time.

I believe you have edited your recently published drafts to address these 
two issues as well.  If my understanding is correct, how have you addressed 
the issues?

- Ralph

At 02:34 PM 11/15/2002 -0500, Mark Stapp wrote:
>The advance summaries that several authors have sent about their drafts 
>have been pretty useful, and Ralph has prodded me to produce something 
>similar about the dhcp/dns drafts. The current versions are:
>The ddns-resolution and fqdn-option drafts last-called in October last 
>year. The related dhcid rr draft also last-called, after some last-minute 
>procedural hijinks almost caused it to be lost. I responded to some 
>post-last-call comments from Thomas Narten in November. It seemed by the 
>March 2002 ietf that the various working-group chairs and ads were in 
>synch. By the summer, I was concerned that we hadn't heard from the iesg, 
>and I asked Ralph to try to help me understand what was going on. In July, 
>a significant issue was raised. Ralph, Olafur, and I agreed that we should 
>address it, and I published revisions to the ddns-resolution and dhcid-rr 
>The Issue
>The evolution of the dhcid-rr draft led to a situation in which details 
>about the data within the dhcid-rr were present in two different drafts. 
>History is to blame here, as usual. Years ago, there was a very simple 
>dhcid-rr specification. It said, basically, "This RR holds binary data. If 
>you want to know how to generate this data, go look in the dhc wg's 
>ddns-resolution draft."
>The dnsext folks were not satisfied with this approach, and over time more 
>and more details about the dhcid rr data leaked from the ddns-resolution 
>draft into the dhcid-rr draft. By the summer, that had led to parallel 
>language in the two specifications. The wg chairs were concerned that that 
>would lead to implementation problems.
>The Current Drafts
>The current versions of the drafts have moved all of the specification of 
>the dhcid rr data into the dhcid-rr draft. The use of the dhcid-rr by 
>updaters remains in the ddns-resolution draft.
>The dhcid rr includes a 16-bit value specifying the source of the 
>client-identity information. The original proposal for the RR proposed 
>that this value would take on one of three values: the value zero if the 
>identifier was the client's MAC address, the value 0xffff was reserved, 
>and any other value would be the option number of the dhcp option that 
>supplied the identifier (like the client-id option number). There was 
>concern that this relied on non-overlapping v4 and v6 option 
>number-spaces. The current draft specifies that this field holds an 
>IANA-managed number. Four values are allocated initially: zero for the MAC 
>address, one for the dhcpv4 client-id option, two for the dhcpv6 duid, and 
>0xffff is reserved.
>There is a slot at the end of the Atlanta agenda for discussion about 
>these drafts, if that's necessary.
>-- Mark
>dhcwg mailing list

dhcwg mailing list