Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header

Ralph Droms <> Tue, 28 August 2001 01:04 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id VAA05547; Mon, 27 Aug 2001 21:04:42 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id VAA14796; Mon, 27 Aug 2001 21:04:06 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id VAA14770 for <>; Mon, 27 Aug 2001 21:04:04 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id VAA05511 for <>; Mon, 27 Aug 2001 21:02:42 -0400 (EDT)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA10091; Mon, 27 Aug 2001 21:03:29 -0400 (EDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Aug 2001 21:03:24 -0400
To: Ted Lemon <>
From: Ralph Droms <>
Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header
In-Reply-To: <>
References: <Message from Ralph Droms <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

Comments in line; anyone have specific examples of the use of the
'secs' field in DHCPv4?  If it hasn't been used at all in DHCPv4
perhaps we don't need to define it at this point in DHCPv6.

- Ralph

At 10:35 AM 8/27/2001 -0400, Ted Lemon wrote:

>> Can anyone give us the benefit of experience with the 'secs' field
>> in DHCPv4?  There hasn't been any interest in defining a new option
>> with greater range or precision than the current 0-255 seconds
>> measured in seconds.  Has the range or precision in DHCPv4 been
>> inadequate in any specific instance?
>A millisecond is a thousandth of a second. 

The original definition I sent out defined the value in the
option field to be expressed in hundredths of a second
(10^-2 seconds), giving the range of 0-655.36 seconds,

>> Another alternative for greater range would be to define the units
>> of the data value to be tenths of a second.  My intuition is that
>> tenths of a second should be sufficiently precise...
>I think it's good to have better granularity than that.   We specify
>the retry timeout in milliseconds, so the retry interval should also
>be computed in milliseconds.

Are there specific examples of when millisecond granularity is needed?

>This is an option that will only be present in exceptional cases, and
>we are discussing a difference in space consumption of 33%.  I am all
>in favor of saving space in frequently-transmitted packets, but this
>is not much space, and will not be in the most frequently-transmitted
>I may be wrong that we need this extra breathing room, but the cost is
>low, and I'd really appreciate it if we could stop arguing about this
>and just take the risk that we might be being a little bit generous in
>our allocation of bits.
>                               _MelloN_

dhcwg mailing list