[dhcwg] dhcpv6-24: confirm vs. renew vs. rebind
Thomas Narten <narten@us.ibm.com> Wed, 08 May 2002 15:13 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11780 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:13:56 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05184 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:14:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04935; Wed, 8 May 2002 11:12:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04898 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:12:44 -0400 (EDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11603 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:12:34 -0400 (EDT)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FCh64159450 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:12:43 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FChQ215392 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:12:43 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FD7W19372 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:13:07 -0400
Message-Id: <200205081513.g48FD7W19372@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Wed, 08 May 2002 11:13:07 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-24: confirm vs. renew vs. rebind
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
> CONFIRM (4) A client sends a Confirm message to servers to > request that the server validate and confirm > that the addresses and current configuration > parameters assigned by the server to the client > are still valid. > > RENEW (5) A client sends a Renew message to the server > that originally provided the client's addresses > and configuration addresses to update the > addresses assigned to the client and the > lifetimes for those addresses, as well as the > current configuration parameters assigned by > the server to the client. > > REBIND (6) A client sends a Rebind message to update > the addresses assigned to the client and the > lifetimes for those addresses, as well as the > current configuration parameters assigned by > the server to the client; this message is sent > after a client receives no response to a Renew > message. > The document still could do a better job of explaining what the difference between these three messages is. Having read the document carefully twice now, I still don't feel like I understand the difference. For the confirm, I gather that the only answer is "yes" or "no". If so, it would also be good to say that and point out that this message is used to decide whether a rebind/renew/request needs to be done. (note: In a separate note, I have questions about the overall utility of confirm.) For rebind, is it different from renew in that it is sent to all dhc servers, rather than just the one to which renew is sent? If so, saying that in the overview would be helpful. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] dhcpv6-24: confirm vs. renew vs. rebind Thomas Narten
- Re: [dhcwg] dhcpv6-24: confirm vs. renew vs. rebi⦠Alexandru Petrescu