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

[Stephen Jacob <[e-mail]>]

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]