Subject: RE: Change to 'seconds' field in DHCP message header

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 26 Aug 2001 18:46:52 -0500

I think 16-bits is enough (with the counter maxing out). If an attempt goes
on that long, no server is probably available and the relays (or servers)
will likely long have taken alternative actions (which probably failed as
well). So, I see little need to make this more than 16-bits.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Friday, August 24, 2001 12:32 PM
To: DHCPv6 discussion list
Subject: Re: Change to 'seconds' field in DHCP message header 

Yup - as a first pass, I took the initiative to define the field to be 16 bits.

I'm happy to make it 32 bits, 64 bits - measured in milliseconds, microseconds or the time between the light turning green and the guy behind me honking his horn here in Boston.

Other feedback - 16 bits, measured in 10^-2 seconds seemed like enough to me...

- Ralph

At 11:57 AM 8/24/2001 -0400, you wrote:

>> >Perhaps also worth saying that if the elapsed time is >655.35 seconds, 
>> >655.35 seconds should be used? It probably will never be the case that 
>> >a client waits that long, but just in case (since it would be bad to 
>> >have it wrap around and start at low values again). 
>> 
>> OK.
>
>Ga-zikes, is the field only 16 bits?   I think 655 seconds is not very
>long for some possible applications.   Is there any reason not to make
>this a 32-bit field?
>
>                               _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Aug 2001 22:44:02 -0400

> well). So, I see little need to make this more than 16-bits.

That's a pretty set of suppositions, but you may well be wrong.   Why
not make sure that it works if you are?

			       _MelloN_