[dhcwg] dhcpv6-24: Elapsed Time option

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 LAA11724 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:13:30 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05124 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:13:39 -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 LAA04846; Wed, 8 May 2002 11:12:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04822 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:12:06 -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 LAA11521 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:11:57 -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 g48FC564063878 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:12:05 -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 g48FC5Q106066 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:12:05 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FCT419328 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:12:29 -0400
Message-Id: <200205081512.g48FCT419328@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Wed, 08 May 2002 11:12:29 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-24: Elapsed Time option
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

> 22.9. Elapsed Time

>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |      OPTION_ELAPSED_TIME      |           option-len          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |          elapsed-time         |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>       option-code   OPTION_ELAPSED_TIME (8)
> 
>       option-len    2.
> 
>       elapsed-time  The amount of time since the client began its
>                     current DHCP transaction.  This time is expressed in
>                     hundredths of a second (10^-2 seconds).

Would it make sense to change this option to carry the retransmission
number rather than an actual time? I.e., backup servers would respond
only on (say) a retransmission?

I understand this to be a holdover from DHC. But if the goal is to
provide backup servers info on when they should respond, the
retransmission count might be more useful than the elapsed time.

Thoughts?

Thomas

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