Re: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt)

Stig Venaas <Stig.Venaas@uninett.no> Tue, 06 July 2004 14:27 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 KAA18899; Tue, 6 Jul 2004 10:27:19 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhqWS-0006KQ-QQ; Tue, 06 Jul 2004 10:02:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhphV-00088G-0j for dhcwg@megatron.ietf.org; Tue, 06 Jul 2004 09:09:33 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12388 for <dhcwg@ietf.org>; Tue, 6 Jul 2004 09:09:26 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhphP-0001nT-7Z for dhcwg@ietf.org; Tue, 06 Jul 2004 09:09:27 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhpgT-0001Tg-00 for dhcwg@ietf.org; Tue, 06 Jul 2004 09:08:30 -0400
Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1Bhpg0-00018p-00 for dhcwg@ietf.org; Tue, 06 Jul 2004 09:08:00 -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 i66D7MDW007795; Tue, 6 Jul 2004 15:07:22 +0200
Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i66D7HLD009252; Tue, 6 Jul 2004 15:07:17 +0200
X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f
Date: Tue, 6 Jul 2004 15:07:17 +0200
From: Stig Venaas <Stig.Venaas@uninett.no>
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt)
Message-ID: <20040706130717.GA8927@sverresborg.uninett.no>
References: <20040629111425.GA14068@sverresborg.uninett.no> <200407021436.i62EaIAk022886@rotala.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200407021436.i62EaIAk022886@rotala.raleigh.ibm.com>
User-Agent: Mutt/1.4.1i
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Cc: dhcwg@ietf.org
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, Jul 02, 2004 at 10:36:18AM -0400, Thomas Narten wrote:
> Personally, I think that if one is trying to contact a DHC server, and
> none respond, there should be a generic algorithm used for
> retries. I.e., the case for this option should not be any different
> (for say) the case where one first boots, and no DHC server responds,
> or when one fails to renew an address after an address expires.
> 
> I.e., isn't there already a generic retranmission with backoff and
> some upper limit? Why not just do the same? Is there a need for
> multiple different algorithms?

You're right. I've looked more carefully at RFC 3315, and the obvious
thing is to follow the same rules. It specifies how a client should
send messages (including backoff) and we're after all not changing the
DHCP protocol.

I suggest the following text for the next version:

   Before making the request it MUST wait for a random amount of time
   between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].

   Then it can make the DHCP request to update the configuration.  The
   message MUST be created and transmitted according to [RFC 3315].  E.g.
   for an Information-request message it must be done according to the
   rules for creation and transmission of Information-request messages in
   section 18.1.5 of [RFC 3315].

Any other comments on the draft are welcome. I'm hoping the next version
may be the final one, I don't think there's much more that can be said
about this simple option...

Stig

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