Re: [dhcwg] I-D Action:draft-ietf-dhc-leasequery-by-remote-id-05.txt

[Pavan Kurapati <[e-mail]>]

Hello Stephen,

Thanks for the detailed review. I will take care of the editorial changes
that you suggested in the next version. Regarding your suggestion on
UNKNOWN, the reason we thought it as definitive is because for a data-driven
query type, we dont know how many hosts are connected behind a "connection"
whereas in the Remote ID query we get definitive response for all the hosts.
I understand that if all servers do not reply or if host do not get all the
replies we cannot be certain. However, the same is true even for
LEASEACTIVE. We may have a case where not all LEASEACTIVEs are sent or
client has not received all. Then why should there be a difference in
behavior for LEASEACTIVE and UNKNOWN? Can you please clarify this.

Thanks,
Pavan

On Tue, Jul 20, 2010 at 11:43 PM, Stephen Jacob
<[e-mail]>wrote:

> I have read the updated draft.
>
> My apologies for not being able to look at this sooner.  At the
> point where I was made aware of the new draft, I was unable to get
> any time to read it or comment upon it.  I hope this review is
> useful in spite of the fact that it may be past the end of a last
> call.
>
> The new version of the draft addresses some of my concerns with the
> previous version of the draft (notably, elimination of the
> DHCPLEASEUNASSIGNED response to this type of query) ... but I am
> still not convinced by the suggestion that a DHCPLEASEUNKNOWN
> response can be "definitive" or that it can be cached indefinitely.
>
> It is possible that I am missing something subtle, but it seems to
> me that either with cooperating servers or with failover if there
> is network partition or (more simply) if the DHCPLEASEQUERY message
> does not reach one or more servers (or their responses do not reach
> the client [relay agent]) then a DHCPLEASEUNKNOWN response from one
> or more servers cannot, in fact, be considered definitive at all,
> unless the router/relay agent performing the DHCPLEASEQUERY knows
> that all of the servers have responded or there is some a priori
> shared knowledge outside the DHC protocol about servers knowing
> definitive information (like if the router knows that all the
> DHCP servers will consult a common database or authorization
> system before responding to DHCPLEASEQUERY--which is not something
> that can be considered to be generally true).
>
> It seems to me this is exactly why RFC 4388 says such responses
> should be cached only short-term (e.g. 5m).
>
> I do not think section 4.6 of the draft should be suggesting
> changed caching semantics for DHCPLEASEUNKNOWN (after all, it
> seems to me that the caching semantics are really the whole reason
> to use DHCPLEASEUNKNOWN and not DHCPLEASEUNASSIGNED).  Periodic
> retries seem to me to be necessary, as specified in RFC 4388.
>
> Other than the above, I only have copy edit style comments, which
> I will include in-line:
>
> | DHC Working Group                                            P. Kurapati
> | Internet-Draft                                     Juniper Networks Ltd.
> | Expires: December 9, 2010                                     R. Desetti
> |                                                                 B. Joshi
> |                                                Infosys Technologies Ltd.
> |                                                             June 7, 2010
> |
> |
> |                DHCPv4 Leasequery by relay agent remote ID
> |              draft-ietf-dhc-leasequery-by-remote-id-05.txt
> |
> <snip>
> | Table of Contents
> |
> |    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
> |    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
> |    3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  7
> |    4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  8
> |      4.1.  Sending the DHCPLEASEQUERY Message . . . . . . . . . . . .  8
> |      4.2.  Responding to the DHCPLEASEQUERY Message . . . . . . . . .  9
> |      4.3.  Determining the IP address to be used in response  . . . .  9
> |      4.4.  Building a DHCPLEASEUNKNOWN or DHCPLEASEACTIVE message . . 10
> |      4.5.  Sending a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message  . . 10
> |      4.6.  Receiving a  DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
> |            Message  . . . . . . . . . . . . . . . . . . . . . . . . . 10
>
> This may be waaaaaay too nick-picky, but it stood out to my brain
> when scanning this that the ordering of the message names in the
> titles of 4.4, 4.5 and 4.6 was arbitrarily different (perhaps 4.4
> should be re-ordered?).
>
> |      4.7.  Receiving No Response to the DHCPLEASEQUERY Message  . . . 11
> |      4.8.  Lease Binding Data Storage Requirements  . . . . . . . . . 11
> |      4.9.  Using the DHCPLEASEQUERY Message with Multiple DHCP
> |            Servers  . . . . . . . . . . . . . . . . . . . . . . . . . 11
> |    5.  RFC 4388 Considerations  . . . . . . . . . . . . . . . . . . . 12
> |    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
> |    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
> |    8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
> |    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
> |      9.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 16
> |      9.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 16
> |    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
> <snip>
> | 4.1.  Sending the DHCPLEASEQUERY Message
> |
> |    The DHCPLEASEQUERY message is typically sent by an access
> |    concentrator.  The DHCPLEASEQUERY message uses the DHCP message
> |    format as described in RFC 2131 [RFC2131], and uses message number 10
> |    in the DHCP Message Type option (option 53).  The DHCPLEASEQUERY
> |    message has the following pertinent message contents:
> |
> |    o  The giaddr and Parameter Request List option" are set as explained
> |       in section 6.2 of RFC 4388 [RFC4388].
>
> Excess " after "option".
>
> |    o  There MUST be a Relay Agent Information option (option 82) with
> |       only Agent Remote ID sub-option (sub-option 2) in the
> |       DHCPLEASEQUERY message.
> |
> |    o  The "ciaddr" field MUST be set to zero.
>
> Should "ciaddr" appear in quotes?
>
> giaddr doesn't, above, and nor do htype, hlen and chaddr below.
>
> |    o  The values of htype, hlen, and chaddr MUST be set to zero.
> |
> |    o  The Client-identifier option (option 61) MUST NOT appear in the
> |       packet.
>
> Should this not be either "Client Identifier" or "client-identifier"?
> The capitalization seems inconsistent.
>
> <snip>
> |    o  DHCPLEASEUNKNOWN
> |
> |    The DHCPLEASEUNKNOWN message indicates that the client associated
> |    with the agent remote-ID suboption of the DHCPLEASEQUERY message is
> |    not allocated any lease or it is not managed by the server.
>
> I think this should be "Remote ID" to match below (section 4.3) or
> at least the usage should be made consistent throughout.  Other
> possible options: "Remote-ID", "remote-id".
>
> RFC 3046 uses "Agent Remote ID" and "Remote ID", occasionally
> lowercasing the 'R' but never using a dash (-), so I would vote for
> "Remote ID" or "Agent Remote ID" and making it consistent throughout
> the document.
>
> <snip>
> | 4.6.  Receiving a  DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message
> <snip>
> |    When a DHCPLEASEUNKNOWN message is received by an access concentrator
> |    that had sent out a DHCPLEASEQUERY message, it means that the DHCP
> |    server does not have definitive information concerning the DHCP
> |    client specified in the Agent Remote ID sub-option of the
> |    DHCPLEASEQUERY message.  The Access Concentrator MAY store this
> |    information for future use.  However, a DHCPLEASEQUERY SHOULD NOT be
> |    attempted with the same Remote ID sub-option.
> |
> |    For leasequery by remote-id, the impact of negative caching is
> |    greatly reduced as the response leads to "definitive" information on
> |
> |    all the hosts connected behind the connection.  Note that in the case
> |    of data-driven approach [RFC4388], a host spoofing several IP
> |    addresses can lead to negative caching of greater magnitude.  Another
> |    important change this draft brings is the removal of "periodic"
> |    leasequeries generated from negative caching caused by
> |    DHCPLEASEUNKNOWN.  Since the information obtained through query by
> |    remote-id is complete, there is no need of attempting leasequery
> |    again for the same connection.
>
> See top of e-mail for my disagreement with this section.
>
> <snip>
> | 5.  RFC 4388 Considerations
> <snip>
> |    o  RFC 4388 [RFC4388] suggests that a DHCPLEASEUNASSIGNED is returned
> |       only in the case of 'query by IP address'.  All other query types
> |       will have a return message of either DHCPLEASEACTIVE or
> |       DHCPLEASEUNKNOWN.  Although it would be possible to return
> |       DHCPLEASEUNASSIGNED in case of a query by remote-id, in order to
> |       maintain compatibility with other similar query types (MAC and
> |       Client-id) a query by remote-id does not support a
> |       DHCPLEASEUNASSIGNED response.
>
> I disagree with this statement.  For reasons I stated at the top of
> this e-mail, I think DHCPLEASEUNASSIGNED would be invalid.  Thus, I
> don't think the draft should be on the one hand not using it but on
> the other hand asserting that we could have chosen to use it.
>
> <snip>
> | 8.  Acknowledgments
> |
> |    Copious amounts of text in this document are derived from RFC 4388
> |    [RFC4388].  Kim kinnear, Damien Neil, Stephen Jacob and Alfred Hoenes
> |    provided valuable feedback on this document
>
> Capitalize "Kinnear". :)
>
> That's it!
>
> Regards,
> Stephen
> --
>  Stephen Jacob | [e-mail] | [phone]
>  Nominum, Inc. |  http://www.nominum.com/  | [phone]
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>