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

[Kim Kinnear <[e-mail]>]

Folks,

I have recently submitted draft-ietf-dhc-leasequery-04.txt where
I made the following changes that came up during WG last call.

Essentially I made all of the changes that Ralph suggested, and
fixed several minor wording errors.  I also updated one of the
author's contact info.

Details are interspersed in the changes recommended by Ralph,
below.

Cheers -- Kim


At 09:35 AM 7/14/2002, Ralph Droms wrote:
>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.

        This is what I originally proposed, and we decided to
        overload the existing option instead.  But I changed it
        back, so now there are two new options defined by this
        draft:  client-last-transaction-time, and associated-ip.

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

        Done, except DHCPUNIMPLEMENTED was left without change, 
        since it likely has larger utility than just this draft.

        This changes makes DHCPLEASEUNKNOWN a bit awkward of
        a respone for a query by client-id where the client-id
        is unknown, but the benefits seem to outweight that
        small awkwardness.

>* 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.

        Done.


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

        Explained.


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

        Done.


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

        Dropped 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..."

        Clarified this language.


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

        Clarified the reasoning in the document.  Other options
        (e.g., vendor-class-identifier) are mentioned because other
        users of the leasequery capability may well want them.  I was
        trying to help out the people who implement leasequery realize
        some of what they may want to do.  


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

        Done.


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

        Clarified, referenced RFC 2131 on the subject.


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

        Tightened up the giaddr/ciaddr issues.


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

        Clarified the original sentence.  Need to ensure that
        people don't use the giaddr to find a subnet in which
        the ciaddr / client-id / MAC-address must appear.


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

        Clarified that the R bit is set only on output,
        per comments by Ted Lemmon.


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


        Done.


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

        All done.


>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).

        Added explanatory text.


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

        Yes, this is old text.  Fixed.


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

        Clarified this use of the R bit as well -- only
        on output.


>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). 

        Well, a nice idea.  I still think that it makes
        sense to leave them in, so I did.

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

        Clarified the use of the DHCPLEASEKNOWN/DHCPLEASEUNKNOWN
        caching.


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

        Done.


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

        Added these recommendations.


>Section 11: Some of this information is stale (mea culpa for taking so long to do the last call)...
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg

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