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

"Bernie Volz" <volz@cisco.com> Thu, 12 August 2004 14:13 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 KAA03833; Thu, 12 Aug 2004 10:13:04 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG6R-0004hq-Gz; Thu, 12 Aug 2004 09:58:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BvG1b-0003RQ-Pp for dhcwg@megatron.ietf.org; Thu, 12 Aug 2004 09:53:48 -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 JAA02233 for <dhcwg@ietf.org>; Thu, 12 Aug 2004 09:53:46 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BvG6T-0004LY-1r for dhcwg@ietf.org; Thu, 12 Aug 2004 09:58:56 -0400
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Aug 2004 06:54:49 -0700
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i7CDr3pp012878; Thu, 12 Aug 2004 06:53:04 -0700 (PDT)
Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKU34874; Thu, 12 Aug 2004 09:53:02 -0400 (EDT)
From: Bernie Volz <volz@cisco.com>
To: 'Stig Venaas' <Stig.Venaas@uninett.no>
Subject: RE: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
Date: Thu, 12 Aug 2004 09:53:01 -0400
Organization: Cisco
Message-ID: <000001c48073$af492fa0$d0412ca1@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <20040812131034.GI8177@sverresborg.uninett.no>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, jdq@lucent.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
Content-Transfer-Encoding: 7bit

I do think you should remove that last paragraph:

>    The lifetime option is mainly intended for Stateless DHCP service as
>    specified in [RFC 3736].  If the client receives IA Address options
>    containing lifetimes, the lifetime option should be ignored.  The
>    client should get updated configuration data from the server when it
>    renews the addresses. 

It confuses the issue.

Perhaps something like:

  The primary motivation for the lifetime option is for situations where
  no lifetime (or renewal time) is communicated to the client, such as for
  Stateless DHCP service as specified in [RFC 3736]. However, it applies
  to both stateful and stateless DHCP clients and is an upper bound for
  when a client should initiate renewal of at least its non-address based
  configuration parameters - a stateful client MAY renew its addresses at
  the same time and SHOULD always get updated configuration data from the
  server when it renews any addresses.

  One difference between Stateful and Stateless clients with regards
  to this option is that a Stateful client that does not receive this
  option MUST NOT apply the default lifetime. 

- Bernie

> -----Original Message-----
> From: Stig Venaas [mailto:Stig.Venaas@uninett.no] 
> Sent: Thursday, August 12, 2004 9:11 AM
> To: Bernie Volz
> Cc: jdq@lucent.com; 'JINMEI Tatuya / ?$B?@L@C#:H'; 
> dhcwg@ietf.org; tjc@ecs.soton.ac.uk
> Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
> 
> 
> On Thu, Aug 12, 2004 at 08:43:27AM -0400, Bernie Volz wrote:
> > If a server sets the T1/T2 times to infinity, it gets what it asked 
> > for - the configuration is static FOREVER. This is one 
> reason it would 
> > be an extremely bad idea to ever use these values. We added 
> them for 
> > clarity in the RFC, though never really figured they would 
> be used in 
> > practice.
> > 
> > The no address issue is an interested one.
> > 
> > On a SOLICIT, the server is ONLY to return the Status 
> Message response 
> > with NoAddrAvail status. It is *NOT* supposed to return any 
> > configuration information!!!
> > 
> > Though it is always possible that a subsequent REQUEST or 
> RENEW/REBIND 
> > would result in no addresses. However, in those cases the IA_NA is 
> > still returned with T1 and T2 times and those would, IMHO, 
> apply. (In 
> > these cases, the NoAddrAvail status is embedded *INSIDE* the IA_* 
> > options so these options are still returned.)
> > 
> > I suppose there is the case when a 
> SOLICIT/REQUEST/RENEW/REBIND for an 
> > IA_NA and IA_TA results in no addresses for a IA_NA and one or more 
> > addresses for a IA_TA, in which case no T1/T2 times are provided - 
> > thought the IA_TA does have lifetimes.
> > 
> > But, all of this gets very messy fairly quickly.
> > 
> > So, perhaps the easiest thing to do is to *ALWAYS* allow 
> the LIFETIME 
> > option
> > - for stateful and stateless. A client *SHOULD* renew (etc) 
> its information
> > whenver the shortest time expires - LIFETIME, T1, or 
> lifetime on an address
> > (and the client needs a replacement address). If the client 
> is stateful, is
> > uses RENEW (whether the client includes on or more IA_NAs 
> if no T1 time has
> > expired is a matter of local policy - though it would seem 
> reasonable for me
> > if it did since there's no harm in doing so). If a client 
> is stateless, it
> > uses INFORMATION-REQUEST.
> > 
> > This also makes server implementations easier since the T1/T2 times 
> > and "other-configuration-parameters" lifetime can be configured 
> > independently and a server need not assure that no T1 time 
> is greater 
> > than "other-configuration-parameters".
> 
> This is more in line with my original idea for lifetime. I've 
> started improving the draft, and I now have these paragraphs:
> 
>    The lifetime option specifies a lifetime for all configuration data
>    contained in other options in an advertise or reply 
> message that have
>    no associated lifetime.  If any of the options have an associated
>    lifetime of their own which is shorter than the lifetime 
> option value,
>    then that should take precedence.
> 
>    Or in other words, the lifetime option specifies an upper bound for
>    how long the client should wait before attempting to renew 
> the data.
>    If there are options with a shorter lifetime or the client 
> has other
>    reasons for requesting data from the DHCP server, then it 
> should also
>    update the data covered by the lifetime option.
> 
> I think this should pretty much cover what you say and is in 
> line with my own thinking.
> 
> After that I have the paragraph:
> 
>    The lifetime option is mainly intended for Stateless DHCP 
> service as
>    specified in [RFC 3736].  If the client receives IA Address options
>    containing lifetimes, the lifetime option should be ignored.  The
>    client should get updated configuration data from the 
> server when it
>    renews the addresses.
> 
> Personally I'm happy to remove that again. I guess we should 
> try to come to some consensus before I do more writing.
> 
> Stig
> 


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