Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)
RFC 4039
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
05 | (System) | Notify list changed from rdroms@cisco.com, soohong.park@samsung.com, kimps@samsung.com, volz@cisco.com to rdroms@cisco.com |
2005-04-06 |
05 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2005-04-06 |
05 | Amy Vezza | [Note]: 'RFC 4039' added by Amy Vezza |
2005-03-29 |
05 | (System) | RFC published |
2004-11-02 |
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-11-01 |
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-11-01 |
05 | Amy Vezza | IESG has approved the document |
2004-11-01 |
05 | Amy Vezza | Closed "Approve" ballot |
2004-10-29 |
05 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
2004-10-29 |
05 | (System) | Removed from agenda for telechat - 2004-10-28 |
2004-10-28 |
05 | Steven Bellovin | [Ballot comment] - |
2004-10-28 |
05 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
2004-10-28 |
05 | Steven Bellovin | [Ballot comment] This draft seems harmless, but I confess that I don't see the point -- both parties are supposed to check if the address … [Ballot comment] This draft seems harmless, but I confess that I don't see the point -- both parties are supposed to check if the address is already in use via a timeout-based mechanism, and I'd think that that would take longer than an extra round trip. |
2004-10-28 |
05 | Thomas Narten | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten |
2004-10-28 |
05 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2004-10-28 |
05 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2004-10-28 |
05 | Harald Alvestrand | [Ballot comment] I do wonder about whether saving these 2 messages will really save any time. Reviewed by Spencer Dawkins, Gen-ART His review: I'm reviewing … [Ballot comment] I do wonder about whether saving these 2 messages will really save any time. Reviewed by Spencer Dawkins, Gen-ART His review: I'm reviewing this specification as a Working Group Submission for Proposed Standard. This document is mostly ready to go. I didn't even see nits. It's well-written and explains its motivation clearly. I have one comment - the example given in Figure 1 shows what happens when you have two DHCP servers on a subnet, but only one of them supports Rapid Commit. It would be really nice to have a second short discussion that shows the same flow when both servers support Rapid Commit. I THINK I know what's supposed to happen, based on side comments in the discussion of Figure 1, and I even think that what's supposed to happen would actually work, but it would be clearer if this was broken out separately. This is a nice short document, so I'll be a good sport and point out that it makes sense to delete the discussion of "one server on a subnet". The discussion on "one server on a subnet" in this draft seems to be skating along the edge of "wireless topology = IP subnet topology", and this isn't true in the general case, except by accident. If there's any part of this solution that relies on "one server on a subnet", that's bad, because it will break the second you have multipath reflection from another subnet, and it will also break the second someone plugs in another router without wondering if there's already a Rapid Commit router plugged in. I don't THINK this will happen, but that's because the protocol specified is safe whether or not the router is the only one on the subnet or not. |
2004-10-28 |
05 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
2004-10-28 |
05 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2004-10-28 |
05 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2004-10-27 |
05 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-10-25 |
05 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2004-10-25 |
05 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin |
2004-10-24 |
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
2004-10-22 |
05 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-10-21 |
05 | Margaret Cullen | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Margaret Wasserman |
2004-10-21 |
05 | Margaret Cullen | Placed on agenda for telechat - 2004-10-28 by Margaret Wasserman |
2004-10-21 |
05 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman |
2004-10-21 |
05 | Margaret Cullen | Ballot has been issued by Margaret Wasserman |
2004-10-21 |
05 | Margaret Cullen | Created "Approve" ballot |
2004-10-18 |
05 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2004-10-18 |
05 | Michelle Cotton | IANA Last Call Comments: We understand upon approval of this document the IANA will assign a DHCPv4 option code for Rapid Commit. This assignment will … IANA Last Call Comments: We understand upon approval of this document the IANA will assign a DHCPv4 option code for Rapid Commit. This assignment will occur in the DHCP Options registry found at the following: <http://www.iana.org/assignments/bootp-dhcp-parameters> |
2004-10-04 |
05 | Amy Vezza | Last call sent |
2004-10-04 |
05 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-10-03 |
05 | Margaret Cullen | Last Call was requested by Margaret Wasserman |
2004-10-03 |
05 | Margaret Cullen | State Changes to Last Call Requested from Publication Requested by Margaret Wasserman |
2004-10-03 |
05 | (System) | Ballot writeup text was added |
2004-10-03 |
05 | (System) | Last call text was added |
2004-10-03 |
05 | (System) | Ballot approval text was added |
2004-10-03 |
05 | Margaret Cullen | 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the … 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 and 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? WG as a whole understands and agrees with the spec; this spec is an adaptation of a feature in DHCPv6 back to DHCPv4. 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 new mechanism for DHCPv4, modeled on the DHCPv6 Rapid Commit option and mechanism, for obtaining IP address and configuration information using a 2 message exchange instead of the usual 4 message exchange. - Working Group Summary There was consensus in the WG for approval of the DHCPv4 rapid commit option and associated mechanism. It has been thoroughly reviewed by the dhc WG and discussed in WG meetings and on the dhcwg mailing list. Samsung has published an IPR claim, in which it promises to provide zero-cost licensing, related to this specification. - Protocol Quality This extension to the DHCPv4 protocol and its specification is of high quality and had been thoroughly reviewed by the dhc WG. Several vendors have expressed interest in implementing this extension to DHCPv4. |
2004-10-03 |
05 | Margaret Cullen | Draft Added by Margaret Wasserman in state Publication Requested |
2004-06-28 |
05 | (System) | New version available: draft-ietf-dhc-rapid-commit-opt-05.txt |
2004-06-23 |
04 | (System) | New version available: draft-ietf-dhc-rapid-commit-opt-04.txt |
2004-06-22 |
(System) | Posted related IPR disclosure: Samsung Electronics Statement about IPR Claimed in draft-ietf-dhc-rapid-commit-opt | |
2004-05-13 |
03 | (System) | New version available: draft-ietf-dhc-rapid-commit-opt-03.txt |
2004-04-19 |
02 | (System) | New version available: draft-ietf-dhc-rapid-commit-opt-02.txt |
2004-03-18 |
01 | (System) | New version available: draft-ietf-dhc-rapid-commit-opt-01.txt |
2003-12-02 |
00 | (System) | New version available: draft-ietf-dhc-rapid-commit-opt-00.txt |