Re: [dhcwg] Other comments on the leasequery spec

At 08:53 PM 4/6/2004, Ralph Droms wrote:
>Thomas Narten:
>
>Specific comments:
>
>>         For this query, the requester supplies only a MAC address in the
>>         DHCPLEASEQUERY message.  The DHCP server will return any
>>         information that it has on the IP address most recently accessed
>>         by a client with that MAC address.  In addition, it may supply
>>         addition IP addresses which have been associated with that MAC
>>         address in different subnets.  Information about these bindings
>>         can then be found using the Query by IP Address, described
>>         above.
>
>may or does above? (multiple occurrences) Seems like this should be a
>MUST (in order for good interoperability/correctness). I.e., if only
>one address is returned (when there are several) it might be  the
>wrong address and incorrect behavior may result.

        Yes, it MUST supply them if any exist, so the client
        "may" or "may not" see any, depending on whether they
        exist.  We'll fix this.


>>    Any DHCP server which supports the DHCPLEASEQUERY message should save
>>    the information from the most recent Relay Agent Information option
>>    (option 82) [RFC 3046] associated with every IP address which it
>>    serves. It is assumed that most clients which generate the
>
>seems like should -> MUST.

        Sure.  Except that you said that section 5 couldn't have
        SHOULD or MUST's in it, since it is the overview.


>>    A server which implements DHCPLEASEQUERY should also save the
>>    information on the most recent Vendor class identifier, option 60,
>>    associated with each IP address, since this option is also a likely
>>    candidate to be requested by clients sending the DHCPLEASEQUERY
>>    message.
>
>Why? How is this info useful to the relay agent? 

        Some devices (notably DOCSIS) encode lots of stuff in the
        vendor-class-id.

>Also, for
>interoperabilty, SHOULD->MUST??

        Sure, but again, we either need to rescind the
        prohibition on RFC 2119 keywords in the overview, or just
        make sure that we do this properly elsewhere (or both, of
        course).


>>          client-last-transaction-time
>
>is this really critical? How is it used? Document doesn't say.

        That certainly slipped through the cracks.  The
        client-last-transaction time is what is used to decide
        the "latest" and therefore most important IP address to
        return in the ciaddr when the query is by MAC address or
        client-identifier.  It is also used to order the list of
        other IP addresses, returned in the associated-ip option.

        We'll make sure that we add that somewhere.


>>       o DHCPLEASEUNASSIGNED
>>
>>         The server MUST respond with a DHCPLEASEUNASSIGNED message if
>>         this server has information about the IP address, but there is
>>         no active lease for the IP address.  The DHCPLEASEUNASSIGNED
>>         message is only returned for a query by IP address, and
>>         indicates that the server manages this IP address but there is
>>         no currently active lease on this IP address.
>
>Are any DHC options returned? I'd assume no, but it would be good to
>say that explicitely.

        I agree with your assumption.  We can certainly say that
        explicitly.


>>    If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the
>>    IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message
>>    MUST be that of an IP address for which the client that most recently
>>    used the IP address matches the Client-identifier or MAC address
>>    specified in the DHCPLEASEQUERY message.
>
>wording: not "must recently used" but the one who currently owns the
>lease. Right?

        Yes.


>>    In the case where more than one IP address has been accessed by the
>>    client specified by the MAC address or Client-identifier option, then
>>    the DHCP server MUST return the IP address returned to the client in
>>    the most recent transaction with the client unless the DHCP server
>>    has been configured by the server administrator to use some other
>>    preference mechanism.
>
>Shouldn't it return _all_ the addresses? Above reads like only one
>address needs to be returned.

        It returns the IP address associated with this client
        that was most recently accessed by this client.  It
        returns this one and all of the others in the
        associated-ip option.  We can make that more clear.


>>    If the Client-identifier option (option 61) is specified in the
>>    Parameter Request List option (option 55), then the Client-identifier
>>    (if any) of the client associated with the IP address in the "ciaddr"
>>    field SHOULD be returned in the DHCPLEASEACTIVE message.
>
>Does a server already normally store the client identifier option?
>I.e., is this required already?

        Yes.


>>    In the case where more than one IP address has been involved in a
>>    DHCP message exchange with the client specified by the MAC address
>>    and/or Client-identifier option, then the list of all of the IP
>>    addresses SHOULD be returned in the associated-ip option (option
>>    TBD), if that option was requested as part of the Parameter Request
>>    List option.
>
>Seems potentially problematic for a client to ask for just one, and
>get only one, if there are many.  It might get back the wrong one and
>do the wrong thing.

        What is the "wrong" one?  If it gets the one most
        recently accessed by the client, then that is only the
        wrong one if it wants something else.  If it wants
        something else, it should ask for all of them.  I guess I
        don't see the problem here.  If you want the most recent,
        then you don't have to ask for them all.  If you don't
        want the most recent, then you should ask for them all.

        Cheers -- Kim


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