RE: [dhcwg] Clarification necessary

Erik Nordmark <Erik.Nordmark@eng.sun.com> Mon, 17 September 2001 19:30 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18784; Mon, 17 Sep 2001 15:30:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11642; Mon, 17 Sep 2001 15:25:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11618 for <dhcwg@optimus.ietf.org>; Mon, 17 Sep 2001 15:25:26 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18734 for <dhcwg@ietf.org>; Mon, 17 Sep 2001 15:25:24 -0400 (EDT)
Received: from bebop.France.Sun.COM ([129.157.208.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01690; Mon, 17 Sep 2001 13:24:33 -0600 (MDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8HJOYr01094; Mon, 17 Sep 2001 21:24:34 +0200 (MET DST)
Date: Mon, 17 Sep 2001 21:20:23 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: RE: [dhcwg] Clarification necessary
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
Cc: "'Artur Guja'" <skybird@3miasto.net>, dhcwg@ietf.org
In-Reply-To: "Your message with ID" <66F66129A77AD411B76200508B65AC697B35C5@eambunt705.ena-east.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.1000754423.2553.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> 2) Should the client save its leases to a file or do they just go to
> the memory? IOW, are they lost upon reboot?
> 
> BV> A client SHOULD save them such that they survive reboots. This
> BV> is what many DHCPv4 clients already do so it really shouldn't be
> BV> such a big deal. Some of the revised text we're working on will
> BV> provide more clarification around this in cases where a client
> BV> has no permanent storage capabilities. Basically, an ADVERTISE
> BV> will be able to include other IAs for the client that the server
> BV> knows about and it is recommended that these types of clients
> BV> always use the same IA ID (such as 0).

Hmm, has there been any discussion what impact this will have on reconfigure
to do renumbering? I guess the same issue appears with DHCPv4 and its
new ability to do reconfigure.

At a minimum it might make sense to document that reconfigure might not
be able to reach nodes that are turned off but that those nodes
might retain the leases in stable storage.

  Erik


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