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

Ralph Droms <> Tue, 28 August 2001 02:30 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id WAA08212; Mon, 27 Aug 2001 22:30:43 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id WAA17097; Mon, 27 Aug 2001 22:29:46 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id WAA17072 for <>; Mon, 27 Aug 2001 22:29:44 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA07816 for <>; Mon, 27 Aug 2001 22:28:20 -0400 (EDT)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA14741; Mon, 27 Aug 2001 22:29:08 -0400 (EDT)
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Aug 2001 22:29:05 -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: <>

Ted - I specifically titled this new option "Elapsed Time" 
(see the original text I sent out) to be more descriptive
(rather than 'secs' or 'milliseconds') and to allow for
other units in the expression of the data value.

I'm not asking for proof of the requirement for milliseconds
or 32 bits.  We have a difference of opinion, and I'd like to
find out if there's any operational experience that would give
us something more than opinion to base a decision on.
If nobody speaks up to say that the 'secs' field in DHCPv4
has actually been used in practice,
perhaps we don't need to define an "Elapsed Time" option
at all.

More comments in line...

- Ralph

At 10:17 PM 8/27/2001 -0400, Ted Lemon wrote:

>> Are there specific examples of when millisecond granularity is needed?
>I have definitely found that 1s granularity is too coarse for DHCPv4,
>at least in the ISC DHCP server, and I have been meaning to make it
>more fine-grained, but have not yet done so.

Are you referring to the granularity of the 'secs' field?  How
would you make it more fine-grained if the units for the fields
are defined as "seconds" in the spec?

>I think it violates the principle of least surprise to call an option
>milliseconds when it's not - if it's centiseconds, call it that.   WRT
>granularity, if we are specifying millisecond granularity, people are
>likely to do their math in millisecond granularity, and I think it's
>confusing to specify a variety of different granularities.
>I will not respond to any further questions about this.  I think I've
>made my reasoning clear.  I can't prove that we need 32 bits.  I think
>we do.  I am not without experience in these matters, so I think that
>my gut feeling on this is worth something, but I can't prove it, and
>it's pointless for you to ask me to try.  Do what you will.
>                               _MelloN_

dhcwg mailing list