[dhcwg] Overconstraining

"Guja, ArturX" <ArturX.Guja@intel.com> Fri, 21 September 2001 07:34 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17129; Fri, 21 Sep 2001 03:34:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05565; Fri, 21 Sep 2001 03:33:50 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA05540 for <dhcwg@optimus.ietf.org>; Fri, 21 Sep 2001 03:33:49 -0400 (EDT)
Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17124 for <dhcwg@ietf.org>; Fri, 21 Sep 2001 03:33:45 -0400 (EDT)
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com []) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4, v 1.42 2001/09/04 16:24:19 root Exp $) with SMTP id HAA15248 for <dhcwg@ietf.org>; Fri, 21 Sep 2001 07:33:07 GMT
Received: from fmsmsx29.FM.INTEL.COM ([]) by fmsmsxvs042.fm.intel.com (NAVGW with SMTP id M2001092100323624073 for <dhcwg@ietf.org>; Fri, 21 Sep 2001 00:32:36 -0700
Received: from alpha.igk.intel.com ([]) by fmsmsx29.FM.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T2T6Y2WT; Fri, 21 Sep 2001 00:33:11 -0700
Received: by alpha.igk.intel.com with Internet Mail Service (5.5.2653.19) id <NMB58DXT>; Fri, 21 Sep 2001 09:33:05 +0200
Message-ID: <413FBB0BA5AED1119122000083234B1A0247B42E@alpha.igk.intel.com>
From: "Guja, ArturX" <ArturX.Guja@intel.com>
To: "Dhcwg (E-mail)" <dhcwg@ietf.org>
Date: Fri, 21 Sep 2001 09:32:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-2"
Subject: [dhcwg] Overconstraining
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


One thing I noticed while implementing draft 19.
It says, that after failing to get a REPLY to a REQUEST,
the client MUST abort configuration attempt. Isn't it a bit harsh
on the poor soul :)))

After all, the server, whose ADVERTISE the client chose to answer,
could have been shutdown or disconnected in the meantime.
Shouldn't we allow the client to select another ADVERTISE and try again.
I'd even risk allowing it to send a SOLICIT again, although I appreciate it
lead to perpetual flood of SOLICITS.

But If a client got more than one ADVERTISE, it COULD select another one
and try again, possibly with a different server.

What do you think?

Artur G.
(TUG student)

dhcwg mailing list