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

Ralph Droms <rdroms@cisco.com> Sun, 17 November 2002 04:28 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01588 for <dhcwg-archive@odin.ietf.org>; Sat, 16 Nov 2002 23:28:04 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gAH4UJm15365 for dhcwg-archive@odin.ietf.org; Sat, 16 Nov 2002 23:30:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAH4UJv15362 for <dhcwg-web-archive@optimus.ietf.org>; Sat, 16 Nov 2002 23:30:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01582 for <dhcwg-web-archive@ietf.org>; Sat, 16 Nov 2002 23:27:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAH4Rvv15273; Sat, 16 Nov 2002 23:27:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAH4MWv15195 for <dhcwg@optimus.ietf.org>; Sat, 16 Nov 2002 23:22:32 -0500
Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01473 for <dhcwg@ietf.org>; Sat, 16 Nov 2002 23:19:47 -0500 (EST)
Received: from rdroms-w2k.cisco.com (rtp-vpn1-552.cisco.com [10.82.226.40]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA20450; Sat, 16 Nov 2002 23:22:22 -0500 (EST)
Message-Id: <4.3.2.7.2.20021116220458.00b88dd0@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 16 Nov 2002 22:26:12 -0500
To: Mark Stapp <mjs@cisco.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] update on dhcp/dns drafts' progress
Cc: dhcwg@ietf.org
In-Reply-To: <4.3.2.7.2.20021115133432.01ebd688@goblet.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=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:
>Folks,
>
>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:
>
>http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-05.txt
>http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-06.txt
>
>History
>
>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 
>drafts.
>
>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@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg