[Ballot comment]
I've decided that this should be a comment rather than a discuss; here's the text, if the authors
wish to consider it, but I will not block on this:

The authors have made a lot of progress on the privacy issue.  I would like
to suggest one tweak on the approach.  The idea of returning the list
according to the client provided parameters will handle most things.  The
list of sensitive options to not return is also a good idea, but I wonder
if we can shift it to the same sort of mechanism but with the opposite
default (everything assumed sensitive until configured non-sensitive). 
That is, can we say "If you are returning something not requested
by the client, check the list to see if it has been configured as non-sensitive".
Would that work okay?

On the congestion control, I've asked Allison to check it and she's agreed.

[Ballot discuss]
Section 7 says:
  >
  > DHCP servers SHOULD prevent exposure of location information
  > (particularly the mapping of hardware address to IP address lease,
  > which can be an invasion of broadband subscriber privacy) by
  > employing some form of relay agent authentication between the
  > DHCPLEASEQUERY client and the DHCP server.
  >
  There needs to be more discussion of the authentication requirements.
  I would prefer the specification to name a mandatory-to-implement
  mechanism, but that may be asking too much.

  Section 7 also says:
  >
  > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
  > path to the DHCP server is secure.
  >
  What security services are needed?  Integrity, authentication, access
  control, replay protection confidentiality?  The hint about Relay Agent
  Information security, with no reference, is not sufficient.

= = = = = = = = = =

  In an email exchange with the authors after -08 was posted:
  >
  > I will revise the draft in the next round to say "SHOULD
  > use RFC 3118 authentication" unless you believe that MUST
  > is necessary, in which case I will revise the draft to
  > say "MUST use RFC 3118".
  >
  SHOULD is okay with me.  If the WG is willing, MUST implement
  and SHOULD use would be even better.

[Ballot discuss]
The authors have made a lot of progress on the privacy issue.  I would like
to suggest one tweak on the approach.  The idea of returning the list
according to the client provided parameters will handle most things.  The
list of sensitive options to not return is also a good idea, but I wonder
if we can shift it to the same sort of mechanism but with the opposite
default (everything assumed sensitive until configured non-sensitive). 
That is, can we say "If you are returning something not requested
by the client, check the list to see if it has been configured as non-sensitive".
Would that work okay?

On the congestion control, I've asked Allison to check it and she's agreed.

[Ballot discuss]
- It seems to be implicitly IPv4 specific without explaining/justifying why
  and uses "IP address" to mean IPv4 addresses only. Do we not want them
  to either be IPv4/v6 agnostic or to be specific in stating that they
  are IPv4 only if such is the case and justified?

  Added 25 May 2005:

  Rev 8 is still not very explicit about the IPv4 specifics

- what is the status of this solution vs DHCP MIB solution (I thought
  they were competing solutions some time back).
  The DHC MIB has also been submitted for PS, no? I know it is still in
  MIB Doctor review... but it is a 2nd solution to same problem.

  Added 25 May 2005:

  Rev 8 still does not contain a clear statement w.r.t. the choice made,
  possible scenarios where this protocol applies and possible scenarios
  where a MIB approach applies. I have seen explanantions in email, but
  no clarifications in the document yet

- The reasonings for not using SNMP and MIB seem very weak to me

  see previous point.

[Note]: 'Returning to update the status of current discusses from Ted, Russ and Bert, to resolve the status of old discusses from Thomas and Steve, and to determine what blocking issues (if any) remain in the latest version of this document.  Thanks.' added by Michelle Cotton

IANA Comments:
Upon approval of this document, the IANA will register 5 new
DHCP Message Type 53 Values and 2 new DHCP Options at the following:
<http://www.iana.org/assignments/bootp-dhcp-parameters>

[Note]: 'Returning to update the status of current discusses from Ted, Russ and Bert, to resolve the status of old discusses from Thomas and Steve, and to determine what blocking issues (if any) remain in the latest version of this document.  Thanks.' added by Margaret Wasserman

I've talked to the authors about things needed to resolve Ted's discuss.  I'm waiting to see a new version with the needed changes before I ask to have the discuss cleared.

[Ballot discuss]
I wonder if the following is a possible protocol issue:

Assume a client is connected to access concentrator A, and obtains a
lease. Client moves to concentrator B, and obtains a second lease. B
looses state, and issues lease query. Server will return two
addresses. How does B know which addresses (and location info) applies
to it (i.e, B) rather than A? Is there info in the protocol messages
that allows B to determine which address is its? E.g., does the
relay-agent info include such an identification in it?

Make it absolutely clear what a server must implement (in terms of the
options it must store), especially in the case of options that already
exist, but that a server may not be required to store. E.g, what is
required for this spec that is different from normal DHC. relay agent
option, client identifier (??).

Specific comments:

>      o Query by IP address:
>
>        For this query, the requester supplies only 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.

make clear what info must be echoed back, esp. relay agent option,
since there is no requirement in existing DHC that a server store
it...

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

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

>    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? Also, for
interoperabilty, SHOULD->MUST??

>          client-last-transaction-time

is this really critical? How is it used? Document doesn't say.

>                      8    DHCPINFORM
>                      TBD  DHCPLEASEQUERY
>                      TBD  DHCPLEASEUNASSIGNED
>                      TBD  DHCPLEASEUNKNOWN
>                      TBD  DHCPLEASEACTIVE
>                      TBD  DHCPUNIMPLEMENTED

To simplify IANA's task, use TBD1, TBD2, etc. so that when IANA
assigns them, it's clear which values go where.

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

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

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

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

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


Editorial:

>    DHCPLEASEACTIVE message.  The DHCP server MUST the Relay Agent
>    Information option that was received when from the relay agent
>    associated with this IP address.

omitted word.

>    When a DHCPUNIMPLEMENTED message is received by an access
>    concentrator, it means that DHCPLEASEQUERY processing is not
>    implemented in the responding server.  This information SHOULD be
>    cached may not be the case that other aspects of DHCPLEASEQUERY
>    processing are not implemented in that server.

parsing problem

[Ballot discuss]
This whole method has "invitation to mischief" printed in large, block letters across its
shirt.  After being told repeatedly that there is no restriction on the use cases for this
mechanism, this text:

        For this query, the requester supplies only 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.

sets off lots of alarm bells.  If I read this right, *any information* associated
with that IP address is returned?  If information used to construct a location
object is present (as in the geopriv dhcp-li draft), that would get returned?
That seems kind of excessive for an access concentrator, but very, very nice
for a black hat.  This whole section on Parameter Request List options:

The Parameter Request List option (option 55) SHOULD be set to
        the options of interest to the requester.  The interesting
        options are likely to include the IP Address Lease Time option
        (option 51), the Relay Agent Information option (option 82) and
        possibly the Vendor class identifier option (option 60).  In the
        absence of a Parameter Request List option, the server SHOULD
        return the same options it would return for a DHCPREQUEST
        message which didn't contain a DHCPLEASEQUERY message, which
        includes those mandated by [RFC 2131, Section 4.3.1] as well as
        any options which the server was configured to always return to
        a client.

has no restrictions of any type on the return of any data.  Why is all
of this data being made available via this method?

It's too bad that SNMP is off the table here, as that would give you a realistic
way to limit data to specific queries and queriers.

Limiting the protocol to a very specific use that fits the
demonstrated need seems like it would make getting the security
mechanisms right easier; if this is meant to be truly general purpose,
it needs a general purpose mechanism that would give it the same level
of security as SNMP would for this same purpose.

Also, why is the exponential backoff for repeated queries a SHOULD here and not
a MUST?  Are there conditions in which some other backoff is appropriate,
but exponential is not?  Having any conditions under which there is *no*
backoff seems pretty bad practice to me....

[Ballot comment]
Ted has captured all my concerns.  No further objection.

It would probably be a good idea for DHCP to have a guideline
draft added to its charter that includes principles:

retransmission MUST use exponential backoff

Options that leak location information MUST use privacy considerations:
these were exemplified by the GEOCONF option design.

[Ballot discuss]
- Have IPCDN and/or ADSLMIB WGs looked at this?
  Both CABLE and ADSL are used as typical examples of where
  this functionality would be used/needed. So I like to know
  what these WGs think of this. I see Rich Woundy as one of the authors,
  he is IPCDN co-chair, so prossibly that aspect is OK.
- It seems to be implicitly IPv4 specific without explaining/justifying why
  and uses "IP address" to mean IPv4 addresses only. Do we not want them
  to either be IPv4/v6 agnostic or to be specific in stating that they
  are IPv4 only if such is the case and justified?
- what is the status of this solution vs DHCP MIB solution (I thought
  they were competing solutions some time back).
  The DHC MIB has also been submitted for PS, no? I know it is still in
  MIB Doctor review... but it is a 2nd solution to same problem.
- The reasonings for not using SNMP and MIB seem very weak to me

[Ballot comment]
Reviewed by Lucy Lynch, Gen-ART

Summary of review:

This draft is very clearly written, and well organized. My only question
has to do with "other  processes and devices" (not a show stooper).
The abstract states that "Other  processes and devices, many that already
send and receive DHCP format packets, sometimes need to access this
information". Much of the draft is focused on "access concentrator"s
(see for example section 5), a list of those other potenial uses might be
helpful. I also notice a number of lower case shoulds & musts in this
section which may actually be 2119 keywords and should be reviewed in that
light.

[Ballot comment]
Proposed Abstract:
 
    A DHCP server is the authoritative source of IP addresses that it has
    provided to to DHCP clients.  Other processes and devices that already
    make use of DHCP may need to access this information.  The leasequery
    protocol provides these processes and devices a lightweight way to
    access IP address information.

[Ballot discuss]
Section 7 says:
  >
  > DHCP servers SHOULD prevent exposure of location information
  > (particularly the mapping of hardware address to IP address lease,
  > which can be an invasion of broadband subscriber privacy) by
  > employing some form of relay agent authentication between the
  > DHCPLEASEQUERY client and the DHCP server.
  >
  There needs to be more discussion of the authentication requirements.
  I would prefer the specification to name a mandatory-to-implement
  mechanism, but that may be asking too much.

  Section 7 also says:
  >
  > Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
  > path to the DHCP server is secure.
  >
  What security services are needed?  Integrity, authentication, access
  control, replay protection confidentiality?  The hint about Relay Agent
  Information security, with no reference, is not sufficient.

[Ballot discuss]
This whole method has "invitation to mischief" printed in large, block letters across its
shirt.  After being told repeatedly that there is no restriction on the use cases for this
mechanism, this text:

        For this query, the requester supplies only 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.

sets off lots of alarm bells.  If I read this right, *any information* associated
with that IP address is returned?  If information used to construct a location
object is present (as in the geopriv dhcp-li draft), that would get returned?
That seems kind of excessive for an access concentrator, but very, very nice
for a black hat.  This whole section on Parameter Request List options:

The Parameter Request List option (option 55) SHOULD be set to
        the options of interest to the requester.  The interesting
        options are likely to include the IP Address Lease Time option
        (option 51), the Relay Agent Information option (option 82) and
        possibly the Vendor class identifier option (option 60).  In the
        absence of a Parameter Request List option, the server SHOULD
        return the same options it would return for a DHCPREQUEST
        message which didn't contain a DHCPLEASEQUERY message, which
        includes those mandated by [RFC 2131, Section 4.3.1] as well as
        any options which the server was configured to always return to
        a client.

has no restrictions of any type on the return of any data.  Why is all
of this data being made available via this method?

The reason for not using SNMP and a well constructed MIB for this looks really
bogus; that would give you a realistic way to limit data to specific queries and
queriers, but it is too hard because it is not already implemented in one
specific class of devices?  That will presumably need an upgrade for this anyway?

If that is the reason, limiting the protocol to a very specific use that fits that
demonstrated need makes sense; if this is meant to be truly general purpose,
it needs a general purpose mechanism that would give it the same level
of security as SNMP would for this same purpose.

Also, why is the exponential backoff for repeated queries a SHOULD here and not
a MUST?  Are there conditions in which some other backoff is appropriate,
but exponential is not?  Having any conditions under which there is *no*
backoff seems pretty bad practice to me....

[Ballot discuss]
(26 March 2004)
The Security Considerations section says this:

  DHCP servers SHOULD prevent exposure of location information
  (particularly the mapping of hardware address to IP address lease,
  which can be an invasion of broadband subscriber privacy) by
  employing some form of relay agent authentication between the
  DHCPLEASEQUERY client and the DHCP server.

  Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
  path to the DHCP server is secure.  Clients SHOULD use Relay Agent
  Information security as a way to achieve this goal.

What is "some form of ... authentication"?  What is "Relay Agent Information security"?  Put another way, what is mandatory to implement?

[Ballot discuss]
The Security Considerations section says this:
  DHCP servers SHOULD prevent exposure of location information
  (particularly the mapping of hardware address to IP address lease,
  which can be an invasion of broadband subscriber privacy) by
  employing some form of relay agent authentication between the
  DHCPLEASEQUERY client and the DHCP server.

  Clients of the DHCPLEASEQUERY message SHOULD ensure that their data
  path to the DHCP server is secure.  Clients SHOULD use Relay Agent
  Information security as a way to achieve this goal.

What is "some form of ... authentication"?  What is "Relay Agent Information security"?  Put another way, what is mandatory to implement?

Thomas' comments on this document:

From: Thomas Narten <narten@rotala.raleigh.ibm.com>
To: Ralph Droms <rdroms@cisco.com>, Margaret.Wasserman@nokia.com
Date: Tue, 25 Nov 2003 11:07:06 -0500
Subject: review of draft-ietf-dhc-leasequery-06.txt

This document is in way better shape than the one reviewed in SF. That
is goodness. But I'm still uncomfortable with parts of it. Here are my
review comments. We probably need to sync up in how to proceed given
the history. Note that I reviewed it to close on the earlier review I
had done, where I had raised numerous issues.

Thomas

2003-11-25 review of -06 (ralph says advance)

Nits: needs TOC.

Meta questions:

1) the need to map from IP address to link-layer info seems
  clear. What is less clear is the need to map from l2 information
  back to IP addresses. The document doesn't really say why this is
  necessary or "what problem this solves". But the protocol includes
  two query types (by client ID and by MAC addr), both of which are
  optional, to solve this problem. It would be good to motivate the
  need for this better. Also, this document  discourages the use of query by
  MAC addr:

  >    Generally, the query by IP address is likely to be the most efficient
  >    and widely implemented form of leasequery, and it SHOULD be used if
  >    at all possible.  Use of the other two query formats SHOULD be
  >    minimized, as they can potentially place a large load on some
  >    servers.

  This makes me wonder if this functinality is actually really
  needed, and whether it can just be removed.


2) My assumption is that this document is intended to modify DHC only
  minimally. I.e., the state goal is to allow relay agents to
  rebuild the same state that they glean from DHC transactions they
  are relaying. But this document seems to go a lot further than
  that, in that it says what options to query for, requires the
  server to cache a previous relay agent option, etc.

  Why isn't the model just that a relay sends a LEASEQUERY providing
  the same info the client would have provided - to the ability of
  the relay agent to actually know such information (e.g., MAC
  address, relay agent option, etc.) and let the server do its normal
  thing?

  Things that don't seem to fit that model that are currently defined
  include:

  - New rules about giaddr not being used by the server to do an
    address lookup. Why wouldn't the server just do the same lookup
    as it would if the request came from the client?

  - Redefinition of relay agent option. The server returns an older
    (cached value), it doesn't just echo back the one provided by the
    relay agent.

  - No mention of including the relay agent option in the LEASEQUERY,
    which seems like it would be critical in helping the server
    figure out the right address info to return for given L2
    information.

3) the query by MAC address seems incomplete. In some deployments, you
  need a relay-agent option to identify the right parameters for a
  client. the MAC address isn't enough. But this document doesn't
  seem to provide for including such information in the LEASEQUERY.

 
4) there is MUST/SHOULD language in the overview. There probably
  should be none, since it is only an overview.

5) DHCPLEASEKNOWN is less descriptive than it could be. How about
  renaming it to DHCPLEASEUNASSIGNED (or something else?). I.e., this
  means the server is configured to hand out this address, but right
  now the lease is unassigned and available.

6) This protocol includes timestamps and rules that allow a relay
  agent to chose between two servers that return conflicting
  information in response to a LEASEQUERY. Is this really necessary?
  If two servers have conflicting information, that is a problem that
  needs fixing. Why complicate this protocol to try and deal with it?
  (and does it actually help solve the underlying
  problem?). Specifically:

>   
>      2. There is a new option, the client-last-transaction-time:
>
>          client-last-transaction-time
>
>          This option allows the receiver to determine the time of the
>          most recent access of the client.  It is particularly useful
>          when DHCPLEASEACTIVE messages from two different DHCP servers
>          need to be compared, although it can be useful in other
>          situations.  The value is a duration in seconds from the
>          current time into the past when this IP address was most
>          recently the subject of communication between the client and
>          the DHCP server.

7) Under what conditions does a lease query return multiple addresses?
  (I'd like to understand this as it would likely make me understand
  the big picture better).

 
Specific comments:

first paragraph of intro and abstract are the same. Would be better to
make the intro standalone. See section 4.5 of
draft-rfc-editor-rfc2223bis-07.txt.

>      o "location information"
>
>        Location information is information needed by the access
>        concentrator to forward traffic to a broadband-accessible host.
>        This information includes knowledge of the host hardware
>        address, the port or virtual circuit that leads to the host,
>        and/or the hardware address of the intervening subscriber modem.

I assume it also includes the IP addresses (and indeed, that this is
critical)...

>      o "primary DHCP server"
>
>        The primary DHCP server in a DHCP Failover environment is
>        configured to provide primary service to a set of DHCP clients
>        for a particular set of subnet address pools.
>
>      o "secondary DHCP server"
>
>        The secondary DHCP server in a DHCP Failover environment is
>        configured to act as backup to a primary server for a particular
>        set of subnet address pools.

I think we don't need these defintions (if a change suggested below is
made).

>    An alternative approach is to send in a DHCPLEASEQUERY message with
>    the "ciaddr" field empty and the MAC address (i.e., "htype", "hlen",
>    and "chaddr" fields) with a valid MAC address or a Client-identifier

The transition to this paragraph could be better. In the prior paragraph,
the problem being solved is that an access concentrator gets an IP
packet and needs to learn the L2 information for that address so that
it can forward the packet correctly.

But for the above paragraph, it is not clear what the problem actually
is. One has the L2 information, but one wants to know the IP address
information? Would be good to explain why one needs to do that.

>    address. In the absence of specific configuration information to the
>    contrary (see Section 6.4) it MUST be the IP address most recently
>    used by the client described by the MAC address or Client-identifier
>    option (or the client described by both, if both appear).

This seems to require that the DHC server keep state about a lease
after the lease expires. This document should not require that. Also,
what is the justification for this? It seems sufficient for the server
to reply "here is the lease information" or "no lease information
available." That seems sufficient to address the problem this document
sets out to address (at least, from my perspective of what the problem
statement says).

>      o "MAC address"
>
>        In the context of a DHCP packet, a MAC address consists of the
>        fields: hardware type "htype", hardware length "hlen", and
>        client hardware address "chaddr".

Seems incomplete. Specifically, later, the doc says:

>      o Query by MAC address:
>
>        For this query, the requester supplies only a MAC address in the
>        DHCPLEASEQUERY message.  The DHCP server will return any

Actually, I expect the requestor can supply a  bunch of other things,
like relay agent options, etc. I.e., it would supply the same info
that would be supplied for a DHC request the relay agent
forwards. Right?

>      o Query by MAC address:
>
>        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.

Why is the above a MAY? Seems like it should be a SHOULD/MUST. Also,
the wording about "different subnets" seems wrong. If I have a home network
with three devices, are they all on different subnets? Do they have
different MAC information? I.e, if it is the case that multiple IP
addresses can be associated with the same MAC address, then the above
query should provide all answers, not just one.

>        MAC address in the DHCPLEASEQUERY message corresponds to an MAC

s/an MAC/a MAC/

>        The DHCP server replies with a DHCPLEASEACTIVE message if the
>        MAC address in the DHCPLEASEQUERY message corresponds to an MAC
>        address with an active lease on an IP address in this server.
>        The server replies with a DHCPLEASEUNKNOWN message if the server
>        does not presently have an active lease by a client with this
>        MAC address in this DHCP server.

No mention of DHCPLEASEKNOWN (assuming its really needed)?

>        A server which implements the DHCPLEASEQUERY message SHOULD
>        implement this capability.  If it does not, it SHOULD respond
>        with a DHCPUNIMPLEMENTED message when it receives a query by MAC
>        address.

Make the above a MUST. Why is this only a SHOULD?

>      o Query by Client-identifier option:
>
>        For this query, the requester supplies only a client-id option
>        in the DHCPLEASEQUERY message.  The DHCP server will return any

Why are there separate sections for query by different things? If this
option is supposed to basically mirror existing DHC server
functionality, the query should simply allow the client to be
identified by any means that DHC currently allows. I.e., the normal
combination of  MAC addr, client ID option, relay agent options,
etc. The above seems to make the rules different  for lease query. For
example, what if both the client identifier option and MAC address are
supplied? What happens then?


>        addition IP addresses which have been associated with client-id

s/addition/additional/

>        A server which implements the DHCPLEASEQUERY message SHOULD
>        implement this capability.  If it does not, it SHOULD respond
>        with a DHCPUNIMPLEMENTED message when it receives a query by
>        Client-identifier option address.

Again, make this a MUST.

>    Generally, the query by IP address is likely to be the most efficient
>    and widely implemented form of leasequery, and it SHOULD be used if
>    at all possible.  Use of the other two query formats SHOULD be
>    minimized, as they can potentially place a large load on some
>    servers.

Please explain. ALso, it seems poor design to provide a query
mechanism but at the same time recommend that it not be used due to
performance considerations.

>    The DHCPLEASEKNOWN or DHCPLEASEACTIVE message reply MUST always
>    contain the IP address in the ciaddr field.  The DHCPLEASEACTIVE
>    message SHOULD contains the physical address of the IP address lease
>    owner in the "htype", "hlen", and "chaddr" fields. The Parameter
>    Request List (option 55) can be used to request specific options to
>    be returned about the IP address in the ciaddr.  The reply often
>    contains the time until expiration of the lease, and the original
>    contents of the Relay Agent Information option [RFC 3046].  The

Hmm. again, a seeming change from DHC spec. E.g, if the lease query
contains a relay agent option (to identify the client), the response
doesn't echo this back, but instead echos back the one it has saved
from earlier? Is this really the intent? Are there implications here?

>    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

New requirement on servers.

>    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
>    DHCPLEASEQUERY message will ask for the Relay Agent Information
>    option (option 82) in the Parameter Request List (option 55), and so
>    supporting the DHCPLEASEQUERY message without having the Relay Agent
>    Information option around to return to the client is likely to be
>    less than helpful.

See above.

>    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 would a relay agent request this? Also, yet another new server
requirement.

Please explain why the vendor class option information would be of use
to the relay agent to rebuild its state.

>      2. There is a new option, the client-last-transaction-time:
>
>          client-last-transaction-time
>
>          This option allows the receiver to determine the time of the
>          most recent access of the client.  It is particularly useful
>          when DHCPLEASEACTIVE messages from two different DHCP servers
>          need to be compared, although it can be useful in other
>          situations.  The value is a duration in seconds from the
>          current time into the past when this IP address was most
>          recently the subject of communication between the client and
>          the DHCP server.

Yet more server requirements. Also, this means that neither DHC server
is really authoritative. That seems broken. I.e, when will different
servers return LEASEACTIVE that conflict? Why should this  protocol
deal with that problem?

>      3. There in a second new option, the associated-ip option:
>
>          associated-ip
>
>          This option is used to return all of the IP addresses
>          associated with the DHCP client specified in a particular
>          DHCPLEASEQUERY message.
>
>          The code for this option is TBD.  The minimum length for this
>          option is 4 octets, and the length MUST always be a multiple of
>          4.
>
>
>              Code  Len        Address 1              Address 2
>            +-----+-----+-----+-----+-----+-----+-----+-----+--
>            | TBD |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
>            +-----+-----+-----+-----+-----+-----+-----+-----+--

Is this enough? I.e., can't the lease times be different for the
different addresses? A: yes, and one has to then send individual
follow queries to get the specific information.

>    The giaddr is used only for the destination address of any generated
>    response and, while required, is not otherwise used in generating the
>    response to the DHCPLEASEQUERY message.  It MUST NOT be used to
>    restrict the processing of the query in any way, and MUST NOT be used
>    locate a subnet to which the ciaddr (if any) must belong.

Seems unnecesssary. The same algorithm DHC servers already use should
be used. This document shouldn't be changing the rules for finding the
IP address associated with a particular client.

>      o DHCPLEASEKNOWN
>
>        The server MUST respond with a DHCPLEASEKNOWN message if this
>        server has information about the IP address, but there is no
>        active lease for the IP address.  The DHCPLEASEKNOWN 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.

What is this message good for? How is it used?

>        When responding with a DHCPLEASEUNKNOWN, the DHCP server SHOULD
>        NOT include other DHCP options in the response.

why not a MUST NOT?

>        The DHCPUNIMPLEMENTED response to the DHCPLEASEQUERY message
>        indicates that the particular form of DHCPLEASEQUERY used is not
>        implemented in this DHCP server. It may mean that the
>        DHCPLEASEQUERY message as a whole is not implemented by this
>        DHCP server although it is usually used to indicate that a query
>        by Client-identifier or MAC address is not implemented by a DHCP
>        server that otherwise supports a DHCPLEASEQUERY by IP address.

Wouldn't it be better to make "unimplemented" more generic (for future
use) by having it return an indication of what query message it didn't
implement?

>    In order to accommodate DHCPLEASEQUERY messages sent to a DHCP
>    Failover secondary server [FAILOVER] when the primary server is down,
>    the primary server MUST communicate the Relay Agent Information
>    option (option 82) values to the secondary server via the DHCP
>    Failover BNDUPD messages.

I don't think this is appropriate for this document. Don't want a
normative reference to that doc here. Can't this text just be put in
the failover document, and have it point to this one (as appropriate)?

>    When a DHCPLEASEKNOWN message is received in response to the
>    DHCPLEASEQUERY message that means that there is no currently active
>    lease for the IP address present in the DHCP server, but that this
>    server does in fact manage that IP address. In this case, the access
>    concentrator SHOULD cache this information in order to prevent
>    unacceptable loads on the access concentrator and the DHCP server in
>    the face of a malicious or seriously compromised device downstream of
>    the access concentrator.  This cacheing could be as simple as simply
>    setting a bit saying that a response was received from a server which
>    knew about this IP address but that there was no current lease.  This
>    would of course need to be cleared when the access concentrator next
>    "gleaned" that a lease for this IP address came into existance.

Finally, I understand why this message exists. Note: should there be
any timeouts associated with this entry? I.e., caching for (say) ten
minutes would probably reap all the benefits yet allow reasonable
recovery in case the cached info turns out to be bad. It is not clear
that caching this infinitely would be good. Currently, there is no
text here regarding reasonable lifetimes.

>    When a DHCPUNIMPLEMENTED message is received by an access
>    concentrator, it means that the particular aspect of DHCPLEASEQUERY
>    processing requested is not implemented in the responding server.  It
>    may or may not be the case that other aspects of DHCPLEASEQUERY
>    processing are not implemented in that server.

Shouldn't this information be cached and further queries disallowed to
such servers?

>  started.  At that time, multiple DHCPLEASEQUERY message can be sent

s/message/messages/

>    In this case, some information in the response packet SHOULD be used
>    to decide among the various responses.  The client-last-transaction-
>    time (if it is available) can be used to decide which server has more
>    recent information concerning the IP address returned in the "ciaddr"
>    field.

>    DHCP servers SHOULD prevent exposure of location information
>    (particularly the mapping of hardware address to IP address lease,
>    which can be an invasion of broadband subscriber privacy) by
>    leveraging DHCP authentication [RFC 3118].  With respect to
>    authentication, the access concentrator acts as the "client".  The
>    use of "Authentication Protocol 0" (using simple unencoded
>    authentication token(s) between the access concentrator and the DHCP
>    server) is straightforward. Alternatively, use of IPsec would also be
>    a way to ensure security between the relay agent and the DHCP server.

Using normal authentication seems wrong. These messages are between
the relay agent/server. Why not use relay authentication?

Security section in general is inadequate. It says nothing about the
vulnerabilities relating to spoofed lease query messages, etc. See the
RFC on security considerations.

AD review questions for draft-ietf-dhc-leasequery

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes and no.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.
 
4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.
 
5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

Strong concurrence of a few individuals with no objections raised
during WG last call.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

This specification defines a protocol through which a network element
can obtain information about IP addresses and other information a DHCP
server has provided to clients.  Network elements and other processes
may need to access the information maintained by the DHCP server when
those entities are first started or when restarted, for example after
a power failure.

For example, access concentrators that act as DHCP relay agents
sometimes derive information important to their operation by
extracting data out of the DHCP packets they forward, a process known
as "gleaning".  Unfortunately, the typical access concentrator loses
its gleaned information when the access concentrator is rebooted or is
replaced.  This protocol provides a mechanism through which, when
gleaned DHCP information is not available, the access
concentrator/relay agent can obtain the location information directly
from the DHCP server(s) using the DHCPLEASEQUERY message.

This specification applies only to DHCPv4.  At present, there is
little demand for address assignment through DHCPv6 and, therefore,
little demand for leasequery function in DHCPv6.  Because of the
differences between the DHCPv4 and DHCPv6 protocols, there is little
advantage to generalizing this specification for DHCPv6.  If there is
a requirement for a leasequery function in DHCPv6 in the future, the
specification will be developed as a separate protocol.

  - Working Group Summary

This specification has received significant review and revision by the
WG.  There have been no unusual circumstances in the WG review and
last call process.  There is explicit support and no objection in the
WG to submitting this specification for publication.

  - Protocol Quality

This specification and protocol have been reviewed by the dhc WG.
Several implementations of the protocol as specified in earlier
revisions of draft-ietf-dhc-leasequery have been completed.

Added this document to the tracker and moved it to AD Review.  Publication request was sent to the
iesg-secretary on 24-Nov, but hasn't been processed yet.