Subject: [dhcwg] WG last call for "DHCP Lease Query"

From: Ralph Droms <[email-masked]>
Date: Mon, 08 Jul 2002 08:15:00 -0400

Announcing the WG last call for "DHCP Lease Query", 
<draft-ietf-dhc-leasequery-03.txt>.  If you have any comments about this 
I-D, please respond to [email-masked], preferably before the DHC WG meeting 
in Yokohama on 7/16.  The last call discussion will close on Monday, 7/22/2002.

- Ralph Droms

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

---

From: Ralph Droms <[email-masked]>
Date: Sun, 14 Jul 2002 10:35:17 -0400

RIch and Kim,

The items in this bullet list are more substantive, while the
remaining items are mostly editorial and listed in order of
appearance in the draft...

* This draft proposes extending and overloading the
   Requested IP Address option to carry IP addresses in
   leasequery messages.  Now that the pressure on new
   option codes in DHCPv4 has eased up, we should consider
   defining a new option (we could even assign it the
   unused failover option code) rather than reusing the
   existing option.
* I would prefer to see all the messages used with leasequery
   transactions renamed to uniformly use the prefix DHCPLEASE.
   This isn't as silly as it might sound; using names like
   DHCPLEASEKNOWN would point out relationship among the messages,
   and leave us room for the name for another message about
   knowing something in DHCP (DHCP
* Details in Section 5, Protocol Overview, are repeated in
   section 6.  It would be better to leave the details out
   of section 5 to avoid potential confusing or contradictory
   specification.  For example, the first bullet item in Section
   5 could be edited to:

       o Query by IP address:

         For this query, the requester supplies an IP address in the
         DHCPLEASEQUERY message.  The DHCP server will return any
         information that it has on the most recent client to have
         been assigned that IP address.

         The DHCP server replies with a DHCPKNOWN or DHCPACTIVE
         message if the IP address in the DHCPLEASEQUERY message corresponds to
         an IP address about which the server has definitive information
         (i.e., it is authorized to lease this IP address).  The server
         replies with a DHCPUNKNOWN message if the server does not have
         definitive location information concerning address in the
         DHCPLEASEQUERY message.

Section 1, last paragraph: What do DHCPKNOWN and DHCPUNKNOWN do?

Section 2, definition of "reservation": clarify by inserting the following 
sentence before the last sentence in the definition: A reservation defines 
a mapping between a client and an IP address but doesn't establish or 
record a lease for the address.

Section 3, third paragraph: why is "DHCPACTIVE" not mentioned in the 
parenthetical phrase?  Perhaps simply drop the parenthetical?

Section 5, paragraph 4: why is "(and are expected to)" included after 
SHOULD?  Can you give guidance about when a server might send the 
DHCPUNIMPLEMENTED message instead of silently discarding the DHCPLEASEQUERY 
message.  Also, for consistency, in the same sentence replace "Servers 
which do not support..." with "Servers that do not implement..."

Section 5, last paragraph: why is saving the Relay Agent Information option 
called out specifically here?  Shouldn't this be a MUST for the specific 
use by access concentrators in reconstructing location information?  Also 
in this paragraph, why is the vendor-class-identifier option mentioned?  I 
don't see it mentioned elsewhere in the document.

Section 6.1, in the first numbered list change "three" to "four" in item 1.

Section 6.2, 1st bullet list, 2nd bullet: under what circumstances will a 
requester not include a parameter request list option?  What will be the 
consequences if the option is not included - will the server return no 
options, all options, a subset of options the server thinks is interesting?

Section 6.2, next to last paragraph: what does ""ciaddr" field mentioned in 
the DHCPLEASEQUERY message [...] is a local subnet of the interface 
specified for the client" mean?

Section 6.3, last paragraph: any reason not to simply write: The 'giaddr' 
field MUST contain a valid IP address assigned to the relay agent that sent 
the DHCPLEASEQUERY message.

Section 6.4, DHCPKNOWN bullet: the first paragraph says the R bit MAY be 
set, the second paragraph says the R bit MUST be set and the third 
paragraph says the R bit "is set"; those three statements seem 
contradictory.  The three paragraphs also contain significant repeated 
information.

Section 6.4: I think the last paragraph of section 6.4 should be moved to 
be the first paragraph of 6.4.1.  The paragraph in question specifically 
addresses the topic of 6.4.1 - determining which IP address to respond to.

Section 6.4.1, paragraph 7: add "address" after the first occurrence of "IP".

Section 6.4.2, paragraph 6: what does "set from the client" mean?  "Set to 
the MAC address belonging to the client"?

Section 6.4.2, paragraph 7: replace "DHPC" with "DHCP"

Section 6.4.2, paragraph 8: here, as well as elsewhere, the document 
mentions "IP [BTW, insert "address" here] has been accessed by the 
client".  What does "accessed by the client" mean?  The address has been 
involved in a DHCP message exchange?  And, *please*, don't use "IP" for "IP 
address" (shudder).

Section 6.4.2, paragraph 9: doesn't the use of DHCPKNOWN and DHCPACTIVE 
differentiate whether there is a valid lease for the client?

Section 6.4.2, paragraph 10: the first sentence says "if the R bit is set 
in the DHCPLEASEQUERY", while earlier, section 6.4.1 says "the Reservations 
bit (the R bit) has no meaning in the DHCPLEASEQUERY message."; these two 
bits of text seem contradictory.

Section 6.5, the explanations of the contents of the various messages are 
redundant and could be elided (e.g., the first sentence of the first 
paragraph).  In the second paragraph, perhaps I'm being dense or it's late 
or I'm still recovering from flying to Japan - how does an access 
concentrator use DHCPKNOWN to accomplish the good stuff in the last 
sentence?  And is caching the DHCP server information a SHOULD?  Why would 
the access concentrator use that information and under what circumstances 
would it not cache the information?

Section 6.5,, paragraph 4: add "does" between "server" and "not" in the 
first paragraph.

Section 7: I thought I read at one point, but can't find it now, a 
suggestion that a DHCP server be configured with the addresses of the relay 
agents from which it would accept DHCPLEASEQUERY messages as a security 
measure.  My apologies if the text is in the draft and I missed it; if I'm 
hallucinating, would the suggestion make any practical and useful sense?

Section 11: Some of this information is stale (mea culpa for taking so long 
to do the last call)...