IETF Logo Mail Archive

Re: Re[2]: [dhcwg] Overconstraining

Ralph Droms <rdroms@cisco.com> Wed, 10 October 2001 14:45 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 KAA11555; Wed, 10 Oct 2001 10:45:06 -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 KAA18005; Wed, 10 Oct 2001 10:44:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17982 for <dhcwg@optimus.ietf.org>; Wed, 10 Oct 2001 10:44:14 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11470 for <dhcwg@ietf.org>; Wed, 10 Oct 2001 10:44:12 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-111.cisco.com [161.44.149.111]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA24221; Wed, 10 Oct 2001 10:42:39 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011010103715.03a6e428@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 10:40:34 -0400
To: Jim Bound <seamus@bit-net.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: Re[2]: [dhcwg] Overconstraining
Cc: Artur Guja <skybird@3miasto.net>, "Dhcwg (E-mail)" <dhcwg@ietf.org>
In-Reply-To: <Pine.OSF.3.95.1010922122232.6818C-100000@www.bit-net.com>
References: <1141412763.20010922125901@3miasto.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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

I've changed the text (section 16.1.1) to allow selection of a 
less-preferable server.

An interim rev of the DHCPv6 spec is now available at http://www.dhcp.org

- Ralph

At 12:23 PM 9/22/2001 -0400, Jim Bound wrote:
>ralph and I got input and it will be clear in the next rev that the client
>can go use less preferred advertise if it chooses.  making it a SHOULD
>would permit implementors to do this.  SHOULD means do this unless you
>have a really good reason to not do this.
>
>
>/jim
>
>
>On Sat, 22 Sep 2001, Artur Guja wrote:
>
> >
> > JB> If it was a SHOULD would that be fine?  I don't think going back to
> > JB> solicit in the spec is prudent though?
> >
> > Of course, going back to SOLICIT is a bit wierd.
> >
> > But if the client got more than one advertise,
> > it chooses the best one. If this one fails,
> > it could settle on a less preferable one.
> > Of course, it there was only one ADVERTISE,
> > or the rest of them were unacceptable, the client
> > MUST abort (in my opinion), or else we could get an
> > infinite loop of SOLICITs.
> >
> > Artur
> >
> >
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>http://www1.ietf.org/mailman/listinfo/dhcwg


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

v2.23.0 | Report a Bug | By Email