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

From: Mark Stapp <[email-masked]>
Date: Fri, 15 Nov 2002 14:34:17 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Sat, 16 Nov 2002 22:26:12 -0500

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:
>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
>

---

From: Mark Stapp <[email-masked]>
Date: Mon, 18 Nov 2002 08:25:34 -0500

Ralph,

I reduced the 'strength' of the requirement in section 6.2 to address Ted's 
concern.

At the end of the email exchange this summer, Ted had provided sample text 
on handling of TTLs, and Olafur had responded to it. I mostly used Olafur's 
text - that's section 5.

-- Mark

At 10:26 PM 11/16/2002 -0500, Ralph Droms wrote:
>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:
>
>two issues as well.  If my understanding is correct, how have you 
>addressed the issues?
>
>- Ralph
>
>>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
>>
>>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
>>
>>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.
>>