Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

Stig Venaas <Stig.Venaas@uninett.no> Fri, 20 August 2004 16:48 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26554; Fri, 20 Aug 2004 12:48:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByBVo-0006qi-7d; Fri, 20 Aug 2004 11:41:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByB4o-0000nv-HN for dhcwg@megatron.ietf.org; Fri, 20 Aug 2004 11:13:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19848 for <dhcwg@ietf.org>; Fri, 20 Aug 2004 11:13:02 -0400 (EDT)
Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByBBL-000135-1F for dhcwg@ietf.org; Fri, 20 Aug 2004 11:19:58 -0400
Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i7KF8G2M005146; Fri, 20 Aug 2004 17:08:16 +0200
Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i7KF8F1q015281; Fri, 20 Aug 2004 17:08:15 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f
Date: Fri, 20 Aug 2004 17:08:15 +0200
From: Stig Venaas <Stig.Venaas@uninett.no>
To: Joe Quanaim <jdq@lucent.com>
Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
Message-ID: <20040820150815.GG14315@sverresborg.uninett.no>
References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <200408201053.49786.jdq@lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200408201053.49786.jdq@lucent.com>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, Bernie Volz <volz@cisco.com>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

On Fri, Aug 20, 2004 at 10:55:04AM -0400, Joe Quanaim wrote:
> Bernie Volz wrote:
> > I'm OK to restricting the Lifetime Option to replies to
> > Information-Request's.
> >
> > The client MUST ignore a Lifetime Option that is in any message other than
> > a REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime
> > Option number in an ORO except when sending an INFORMATION-REQUEST message.
> >
> > The server MUST NOT include the Lifetime Option in any message other than a
> > REPLY to an INFORMATION-REQUEST.
> 
> This sounds good to me.
> 
> Also, did we reach consensus on a default value?  This seems like the 
> appropriate place to mention it:
> 
> If a client requests a Lifetime Option and does not receive one in the reply, 
> it should use the default value of n hours.
> 
> Or something to that effect...

Yes, I've already written some text to that effect, it's not done.
What I have so far is:

   In some cases a default lifetime LT_DEFAULT is used.
   The recommended value for LT_DEFAULT is 21600 (6 hours).

I just took 6 out of the air, input needed.

and then under client behaviour:

   A client implementing this option MUST when a reply to an
   Information-Request message does not contain the option, behave
   as if the option with value LT_DEFAULT was provided.

   A client MUST also use the default lifetime LT_DEFAULT if the
   value of the option is zero.

   If client has received a lifetime with this option, and contacts
   server to receive new or update any existing data prior to its
   expiration, it SHOULD also update data covered by this option.
   If no new lifetime is received, it MUST use the default lifetime
   LT_DEFAULT.

I need to work a bit more on the text, but let me know if this is not
in line with what you think.

Stig

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