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

[Ralph Droms <[e-mail]>]

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

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg