Subject: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Oct 2003 08:34:42 -0400

This message announces a WG last call on "DHCP Lease Query"
<draft-ietf-dhc-leasequery-05.txt>.  The last call will conclude at 5PM ET
on Friday, 10/31/2003.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.

This document defines new messages through which devices can communicate with
a DHCP server.  A DHCP server contains considerable authoritative
information concerning the IP addresses it has leased to DHCP clients.
Other processes and devices, many that already send and receive DHCP format
packets, sometimes need to access this information.  The leasequery protocol
is designed to give these processes and devices a lightweight way to access
information that may be critical to their operation. This
draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-05.txt

- Ralph Droms 

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

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 21 Oct 2003 21:39:15 -0400

I support this document moving forward.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph
Droms
Sent: Tuesday, October 21, 2003 8:35 AM
To: [email-masked]
Subject: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt

This document defines new messages through which devices can communicate
with

- Ralph Droms

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 22 Oct 2003 10:22:51 -0400

Ralph,

I think this document should move forward.  But that's no
surprise.

I do want to mention an issue which was raised by Andre Kostur
which we will want to fix along with any other issues raised in
last call.

In email to this list on 22 Sept 2003, Andre pointed out that it
the draft says that T1 and T2 (renewal and rebinding times) are
supposed to be handled the same as the lease time -- but that
while the lease time can't have passed if there is an active
lease, the renewal and rebinding times can certainly be in the
past, even though the lease has not yet expired.

I propose that we say that these options will not be returned if
they are already passed.

He also points out a typo which needs to be fixed.

Other than that, I think the document is ready to go.

Cheers -- Kim

---

From: John Schnizlein <[email-masked]>
Date: Wed, 22 Oct 2003 10:41:54 -0400

><draft-ietf-dhc-leasequery-05.txt>.  The last call will conclude at 5PM ET

I support this document going forward to RFC.

John

---

From: Mark Stapp <[email-masked]>
Date: Wed, 22 Oct 2003 10:52:33 -0400

I support this draft and would like to see it progress.

-- Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Oct 2003 13:17:03 -0500

I support acceptance of the leasequery draft without change.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 24 Oct 2003 08:07:51 -0400

I read from the specification that the device using DHCPLEASEQUERY
must be aware if the DHCP failover protocol is being used.  This
requirement implies that devices must be configured to know about
failover, when they need not be so configured today, and (potentially)
that the leasequery spec should be delayed until the failover spec is
published.  I think it's important to avoid both of those conditions.

In particular, a device may be in a situation in which multiple DHCP
servers are in use regardless of whether failover is in use.  The
important issue from the device's point of view is that it may be
configured with the addresses of more than one DHCP server, and it may
receive multiple, potentially conflicting, responses from those DHCP
servers.

I suggest that the reference to failover in section 3 can be left as
is, perhaps striking the phrase about where to send the DHCPLEASEQUERY
messages when failover is in use.  The reference to failover in
section 4 should be replaced by instructions to the device about how
to behave if it is configured with a list of DHCP servers.  The
reference in section 6.4.2 looks OK (instructions on how to
configure failover).  The reference in section 6.7 should be extended
to something like "If the device receives multiple responses, it must
use some information in the responses to choose which to use.  For
example, the client-last-transaction-time can
be used."  (Is client-last-transaction-time restricted to use by
servers that are using failover?)

I'm not quite sure I understand the relationship between the 'R' bit
and the IP Address Lease Time.  Are they mutually exclusive?  That is,
if a server receives a DHCPLEASEQUERY for a client with a reservation
and an active lease, does the server just return the IP Address Lease
Time in a DHCPLEASEACTIVE message, *without* setting the 'R' bit?  Or,
is it not possible to have a reservation with an active lease?

Nits:

Hyphenation of words at line breaks (for example, "operation" at the
end of the first paragraph of section 1) is not allowed in an Internet
Draft or RFC (see http://www.ietf.org/ID-nits.html for a checklist of
formatting instructions)

The references need to be split into Normative and Informative
references.

Section 1, second paragraph: delete "new lightweight" in last
sentence.

Section 1, second paragraph after Figure 2, replace "due to reboot"
with "because the access concentrator has rebooted".

Section 6.1, numbered list, change "three" to "four".  Also, the
second phrase is a sentence fragment, and should be edited to be a
complete sentence.

Section 6.4, bullet list item "DHCPLEASEUNKOWN", second paragraph,
replace DHCPLEASEKNOWN with DHCPLEASEUNKNOWN and replace "response"
with "respond".

Section 6.4.1, 5th paragraph seems redundant ('R' bit is described
elsewhere) and out of context; can it be deleted?

Section 6.4.2, is the last paragraph redundant with the next to last
paragraph in section 3?  Can the paragraph in section 3 be deleted
(probably not appropriate for the Background?)

Section 6.6, last two paragraphs, the exponential backoff algorithm
needs more detail: what are the initial and incremental timeout
values?  I suggest reusing the backoff algorithm from RFC 2131.