I fully support this work moving forward, but I believe we need to
address a bunch of issues (mostly editorial) and respin before sending
this work on to the IESG.

--> I do hope others will chime in before the END
--> OF THE LAST CALL, which concludes *TODAY* (at
--> 1700EDT on 05-19-2008). Otherwise, this draft
--> may fail to progress as there has been *NO*
--> support for it (at least posted to the DHC WG
--> mailing list)!!!

Here are my review comments:

- Abstract

I question whether this is an "extension to the Leasequery Protocol".
This is a new protocol and I think we should declare it as such.

- 1. Introduction

3rd paragraph:
   Server(s).  The individual query mechanism is only useable when the
   target binding is known to the requestor.  In the case of DHCPv6
                                           ^ (add text below)
   Prefix Delegation, the PD binding data may need to be known before

Consider adding "such as upon receipt of traffic"?

- 3. Protocol Overview

1st paragraph:
   Leasequery client has server IP address(es) available via
   configuration or some other means, and that it has unicast IP
   reachability to the server.  The client sends a LEASEQUERY message,
   containing a query-type and data about bindings it is interested in.

I suggest move the "The client sends" to the next pargraph (perhaps
adding "Once the connection has been established, the client sends..."
and adding to the end of this first 1st paragraph: "No relaying of bulk
leasequery is specified."
 
2nd paragraph:
   Each end of the TCP connection can be closed after all data has been
   sent.

As this text makes it appear that only a single query / response is
possible, how about changing this to "Additional queries may be
performed. Each end of the TCP connection can be closed after all data
has been sent."

4th paragraph:

Change "RFC5007" to a reference number ([6]).

- 4. Interaction Between UDP Leasequery and Bulk Leasequery

2nd paragraph:

Again, change "RFC5007" to reference number ([6]).

3rd paragraph:

Is it worth adding a reference [6] after the "NotAllowed" status 

Other issue:

Is it worth mentioning that only LEASEQUERY, LEASEQUERY-REPLY,
LEASEQUERY-DATA, and LEASEQUERY-DONE messages are allowed over the
connection. No other DHCPv6 messages (SOLICIT, ...) are allowed. This is
not an alternative DHCPv6 communication option for clients to obtain
leases.

- 5.2.2. LEASEQUERY-DONE

1st paragraph:

   of a stream of reply messages.  A single LEASEQUERY-DONE MUST BE sent
   after all replies to a successful Bulk Leasequery request that
                    ^ (add text below?)
   returned at least one binding.

Would it help to insert "(a successful LEASEQUERY-REPLY and zero or more
LEASEQUERY-DATA messages)"?

- 5.3.3. QUERY_BY_REMOTE_ID

1st paragraph:

Change "Relay-ID" option to "Relay Agent Remote-ID Option [5]". May also
be best to include reference to [5] in the QUERY_BY_REMOTE_ID definition
(last "paragraph").

- 5.4.1. Relay-ID Option

1st paragraph:

Best to add a reference to [1] for DUID?

- 5.5. Status Codes

   TODO: are any new status codes needed - to indicate a connection or
   resource problem e.g.?

This section is obviously incomplete. I think we should define one new
status code:

QueryTerminated (11) - Indicates that the server is unable to perform a
query or has prematurely terminated the query for some reason (which
should be communicated in the text message). This may be because the
server is short on resources or is being shut down. The requester may
retry the query at a later time (the requestor should wait at least a
short interval before retrying). Note that while a server may simply
prematurely close its end of the connection, it is preferrable that a
server send a LEASEQUERY-REPLY or LEASEQUERY-DONE with this status-code
to notify the requestor of the condition.

- 6.3. Processing Replies

Last paragraph:

   The LEASEQUERY-DONE message ends a successful Bulk Leasequery session
   that returned at least one binding.  A LEASEQUERY-REPLY without any

I think "session" should be "request" here. Session might confuse the
issue about when the TCP connection is closed.

- 6.4. Querying Multiple Servers

   A Bulk Leasequery client MAY be configured to attempt to connect to
   and query from multiple DHCPv6 servers in parallel.  The DHCPv6
             ^^^^ drop from
   Leasequery specification [6] includes a discussion about reconciling
   binding data received from multiple DHCPv6 servers.

- 6.5.  Multiple Queries to a Single Server

In this section, we need to be clear about how this works (we don't want
to the confusion that exists with multiple DNS queries over TCP
connections!). We need to be clear that *IF* a client sends another
LEASEQUERY message to the server before the first is done, the client
MUST be prepared for the responses from the server to be interleaved
(i.e., the client must use the XID to match up the responses with the
request). A server is not required to process more than a request at a
time from the connection, but if it chooses to do so, it will send back
replies for each active query interleaved over the TCP connection.

The main points here are:
- A client MAY send more than one request at a time. If the client is
not capable of dealing with interleaved responses from a server, the
client MUST NOT send more than one request at a time.
- A server MAY process more than one request at a time and is allowed to
interleave the responses if it does so.

I also wonder whether we should provide an example here (or perhaps in a
new 6.7 section)? Such as:

     Client                        Server
     ------                        ------
     LEASEQUERY xid 1 ----->
                                   LEASEQUERY-REPLY xid 1 (w/error)
     LEASEQUERY xid 2 ----->
                      <-----       LEASEQUERY-REPLY xid 2
                      <-----       LEASEQUERY-DATA xid 2
                      <-----       LEASEQUERY-DATA xid 2
                      <-----       LEASEQUERY-DONE xid 2
     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->
                      <-----       LEASEQUERY-REPLY xid 4
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-REPLY xid 3
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DATA xid 3
                      <-----       LEASEQUERY-DONE xid 3
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DONE xid 4

Note that a server that did not support multiple queries would have
responded as:

     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->
                      <-----       LEASEQUERY-REPLY xid 3
                      <-----       LEASEQUERY-DATA xid 3
                      <-----       LEASEQUERY-DONE xid 3
                      <-----       LEASEQUERY-REPLY xid 4
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DONE xid 4

7.4. Closing Connections

Perhaps in the 2nd paragraph, we should reference the QueryTerminated
status added to 5.5.

9. IANA Considerations

Add QueryTerminated status code assignment.

BTW: For the Query (and status codes) should the draft provide numbers
of leave them unspecified for IANA to assign them? IANA was requested to
create a registry for these in RFC 5007 (3315 did the status codes), so
perhaps best IANA is left to do the assignment?

- Bernie 

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
Of Ralph Droms (rdroms)
Sent: Monday, April 28, 2008 1:33 PM
To: DHC WG
Cc: Dhc Chairs
Subject: [dhcwg] dhc WG last call on
draft-ietf-dhc-dhcpv6-bulk-leasequery-00


This message announces a WG last call on "DHCPv6 Bulk Leasequery"
<draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt>.  The last call will  
conclude at
1700EDT on 05-19-2008.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

There was an issue raised during the discussion of this draft at the
dhc WG meeting during IETF-71 regarding the termination of the TCP
connection after a bulk leasequery transaction.  That issue should be
discussed during this last call, and the duration of the last call has
been extended to three weeks to allow for that discussion.

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings.  That mechanism is limited to
queries for individual bindings.  In some situations individual
binding queries may not be efficient, or even possible.
draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt specifies extensions to
the Leasequery protocol that add new query types and allow for bulk
transfer of DHCPv6 binding data.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequer
y-00.txt

- John Brzozowski, Ralph Droms
   dhc WG chairs


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg