DHCPv6 Bulk Leasequery
draft-ietf-dhc-dhcpv6-bulk-leasequery-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2009-01-22
|
06 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-01-22
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-01-22
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-01-22
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-01-21
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-01-21
|
06 | (System) | IANA Action state changed to In Progress |
2009-01-21
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-01-21
|
06 | Amy Vezza | IESG has approved the document |
2009-01-21
|
06 | Amy Vezza | Closed "Approve" ballot |
2009-01-21
|
06 | Jari Arkko | State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko |
2009-01-21
|
06 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2009-01-14
|
06 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2009-01-14
|
06 | Jari Arkko | Waiting on Lars to check if the new version is acceptable. My own evaluation says that it is. |
2009-01-13
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-01-13
|
06 | (System) | New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt |
2008-12-21
|
06 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko |
2008-12-11
|
06 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-12-11
|
06 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2008-12-11
|
06 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2008-12-11
|
06 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2008-12-11
|
06 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-12-11
|
06 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-12-10
|
06 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-12-10
|
06 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-12-10
|
06 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-12-10
|
06 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-12-10
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-12-10
|
06 | Lars Eggert | [Ballot comment] Section 6.6., paragraph 1: > The Requestor MAY close its end of the TCP connection after sending a > LEASEQUERY message … [Ballot comment] Section 6.6., paragraph 1: > The Requestor MAY close its end of the TCP connection after sending a > LEASEQUERY message to the server. The Requestor MAY choose to retain > the connection if it intends to issue additional queries. Note that > this client behavior does not guarantee that the connection will be > available for additional queries: the server might decide to close > the connection based on its own configuration. The end system closing a TCP connections needs to maintain the TIME-WAIT state, which is undesirable for servers serving many clients. It may hence be a good idea here to recommend that the client close the connection under normal operation. |
2008-12-10
|
06 | Lars Eggert | [Ballot discuss] Section 5.6., paragraph 2: > This section presents a table of values used to control Bulk > Leasequery behavior, including recommended … [Ballot discuss] Section 5.6., paragraph 2: > This section presents a table of values used to control Bulk > Leasequery behavior, including recommended defaults. Implementations > MAY make these values configurable. > > Parameter Default Description > ------------------------------------------ > BULK_LQ_CONN_TIMEOUT 30 secs Bulk Leasequery connection timeout > BULK_LQ_DATA_TIMEOUT 30 secs Bulk Leasequery data timeout > BULK_LQ_MAX_RETRY 60 secs Max Bulk Leasequery retry timeout > BULK_LQ_MAX_CONNS 10 Max Bulk Leasequery TCP connections DISCUSS: I'm OK with permitting these to be configurable, but it SHOULD NOT be possible to make these timeout values any shorter. (Or at least much shorter, but then we need to define what the acceptable lower limits are.) Please add a corresponding statement. Section 6.2., paragraph 2: > If the TCP connection becomes blocked while the Requestor is sending > its query, the Requestor SHOULD be prepared to terminate the > connection after BULK_LQ_DATA_TIMEOUT. We make this recommendation > to allow Requestors to control the period of time they are willing to > wait before abandoning a connection, independent of notifications > from the TCP implementations they may be using. DISCUSS: Typical TCP APIs don't let applications know when a connection "gets stuck", at least not before the socket buffer has completely filled up, which is unlikely to be possible here due to the size of the messages. I would rephrase this paragraph (as well as other text in the document that talks about connections getting "blocked" or "stuck", e.g. in Sections 6.3, 7.1, 7.2, ...) to talk about the reply to a request not arriving within the BULK_LQ_DATA_TIMEOUT period, because that is always visible to an application using TCP. |
2008-12-10
|
06 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2008-12-10
|
06 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2008-12-08
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2008-11-25
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-11-25
|
05 | (System) | New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-05.txt |
2008-11-24
|
06 | Jari Arkko | Telechat date was changed to 2008-12-11 from 2008-12-04 by Jari Arkko |
2008-11-24
|
06 | Jari Arkko | Moved document one week forward to load balance December telechats |
2008-11-12
|
06 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Jari Arkko |
2008-11-12
|
06 | Jari Arkko | Status from the author: I think there have been two categories of comment. As there often are, there have been some suggestions about textual changes … Status from the author: I think there have been two categories of comment. As there often are, there have been some suggestions about textual changes to improve clarity or consistency. Your comments, Alfred's, and some of Robert Sparks's fall into that category, and pretty much all of those comments seem to me to help. Robert and Pekka Savola both had some other questions. Pekka seemed to object to the use of operational or management extensions to the DHCP protocol at all, and suggested developing an entirely new approach using SNMP. No one else seemed to support that position - the only two responses to it were negative. And it's not uncommon for protocols to include some operational capabilities along with their direct 'client-server' capabilities. As I see it, the working group has spoken there. Robert asked a question about TCP security considerations, and another about the possibility and consequences of implementor confusion around the TCP framing for the DHCP messages proposed in the draft. I plan to address those in the next draft version. I'll add some discussion about the framing issue, to try to make it clearer. I think the TCP overview RFC and associated docs cover TCP security, so I plan to just point clearly to them. So - I'm working on a new version, and I'm hoping to get it submitted this week. |
2008-11-12
|
06 | Jari Arkko | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko |
2008-11-11
|
06 | Sam Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Jürgen Schönwälder. |
2008-11-10
|
06 | Jari Arkko | Placed on agenda for telechat - 2008-12-04 by Jari Arkko |
2008-11-03
|
06 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-10-31
|
06 | Amanda Baber | IANA Last Call comments: Action 1: Upon approval of this document, the IANA will make the following assignment in the "DHCP Option Codes" registry at … IANA Last Call comments: Action 1: Upon approval of this document, the IANA will make the following assignment in the "DHCP Option Codes" registry at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml Value Description Reference ----- ----------- --------- [TBD] OPTION_RELAY_ID [RFC-dhc-dhcpv6-bulk-leasequery-04] Action 2: Upon approval of this document, the IANA will make the following assignment in the "Status Codes" registry at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml Code Name Reference ---- ------ ---------- [TBD] QueryTerminated [RFC-dhc-dhcpv6-bulk-leasequery-04] Action 3: Upon approval of this document, the IANA will make the following assignments in the "DHCP Message types" registry at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml Value Description Reference ----- ------------ ---------- [TBD] LEASEQUERY-DONE [RFC-dhc-dhcpv6-bulk-leasequery-04] [TBD] LEASEQUERY-DATA [RFC-dhc-dhcpv6-bulk-leasequery-04] Action 4: Upon approval of this document, the IANA will make the following assignments in the "OPTION_LQ_QUERY option" registry at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml Code Name Reference ---- ----- --------- [TBD] QUERY_BY_RELAY_ID [RFC-dhc-dhcpv6-bulk-leasequery-04] [TBD] QUERY_BY_LINK_ADDRESS [RFC-dhc-dhcpv6-bulk-leasequery-04] [TBD] QUERY_BY_REMOTE_ID [RFC-dhc-dhcpv6-bulk-leasequery-04] We understand the above to be the only IANA Actions for this document. |
2008-10-21
|
06 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Jürgen Schönwälder |
2008-10-21
|
06 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Jürgen Schönwälder |
2008-10-20
|
06 | Amy Vezza | Last call sent |
2008-10-20
|
06 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-10-20
|
06 | Jari Arkko | placed on the agenda |
2008-10-19
|
06 | Jari Arkko | Last Call was requested by Jari Arkko |
2008-10-19
|
06 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation by Jari Arkko |
2008-10-19
|
06 | Jari Arkko | State Changes to AD Evaluation from Last Call Requested by Jari Arkko |
2008-10-19
|
06 | Jari Arkko | I have made my AD review of this draft. The specification was well written and I had no major complaints -- thanks! The draft has … I have made my AD review of this draft. The specification was well written and I had no major complaints -- thanks! The draft has been sent for IETF Last Call. However, there were two minor editorial issues that I'd like the authors to address. Feel free to submit a new version right away, or wait for Last Call comments and address these along with the other received comments. Please expand the term DUID upon first use. > DATA message that does not contain an OPTION_CLIENT_DATA MUST BE s/MUST BE/MUST be/ |
2008-10-19
|
06 | Jari Arkko | State Changes to Last Call Requested from Publication Requested by Jari Arkko |
2008-10-19
|
06 | Jari Arkko | Last Call was requested by Jari Arkko |
2008-10-19
|
06 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2008-10-19
|
06 | Jari Arkko | Ballot has been issued by Jari Arkko |
2008-10-19
|
06 | Jari Arkko | Created "Approve" ballot |
2008-10-19
|
06 | (System) | Ballot writeup text was added |
2008-10-19
|
06 | (System) | Last call text was added |
2008-10-19
|
06 | (System) | Ballot approval text was added |
2008-10-19
|
06 | Jari Arkko | This summary sheet is submitted as part of the dhc WG request to publish draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt as a Proposed Standard. 1) Have the chairs personally reviewed … This summary sheet is submitted as part of the dhc WG request to publish draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt as a Proposed Standard. 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; 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; 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? WG as a whole understands and agrees with the document; most of the expressed support has come from a few key WG contributors representing several different vendors. 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). There are a couple of nits; the most serious is a normative down reference to an Informational RFC; I will have the author change the reference to informative. 8) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary DHCPv6 "leasequery" allows a DHCPv6 server to be queried for information about DHCPv6 bindings. As an example, a network element may use leasequery to recover state derived from DHCP message exchanges. The existing leasequery mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. DHCPv6 bulk leasequery expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. - Working Group Summary The dhc WG reviewed this document and raised several issues during the WG last call. All of the issues have been resolved or addressed in this revision of the draft. One set of issues was raised in http://www.ietf.org/mail-archive/web/dhcwg/current/msg08468.html; the issues were resolved in a revision to the draft. - Protocol Quality DHCPv6 bulk leasequery was originally developed as a simple extension to DHCPv6 leasequery, carried over UDP. Because of the possible effect on the network of a bulk data transfer over UDP, DHCPv6 bulk leasequery was re-architected to use TCP. The specification for the resulting protocol has been reviewed by both dhc WG members and external transport experts. DHCPv6 bulk leasequery was originally developed at the request of a large ISP, in anticipation of IPv6 service deployment. At least one DHCPv6 server vendor plans to implement DHCPv6 bulk leasequery. |
2008-10-19
|
06 | Jari Arkko | Draft Added by Jari Arkko in state Publication Requested |
2008-10-16
|
04 | (System) | New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt |
2008-06-12
|
03 | (System) | New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-03.txt |
2008-06-03
|
02 | (System) | New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-02.txt |
2008-05-23
|
01 | (System) | New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-01.txt |
2008-02-12
|
00 | (System) | New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt |