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

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