[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