Re: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>

Mark Stapp <mjs@cisco.com> Mon, 27 August 2001 22:13 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 SAA02419; Mon, 27 Aug 2001 18:13:55 -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 SAA07768; Mon, 27 Aug 2001 18:08:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07696 for <dhcwg@ns.ietf.org>; Mon, 27 Aug 2001 18:08:02 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02088 for <dhcwg@ietf.org>; Mon, 27 Aug 2001 18:06:35 -0400 (EDT)
Received: from MJS-W2K.cisco.com (dhcp-161-44-149-89.cisco.com [161.44.149.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA28936; Mon, 27 Aug 2001 18:07:22 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010827175744.037dc870@funnel.cisco.com>
X-Sender: mjs@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Aug 2001 18:08:23 -0400
To: Stuart Cheshire <cheshire@apple.com>
From: Mark Stapp <mjs@cisco.com>
Subject: Re: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>
Cc: <dhcwg@ietf.org>
In-Reply-To: <200108272106.OAA02524@scv1.apple.com>
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

Stuart,
You misunderstood. A server that doesn't know about Ted's domain shouldn't 
try to prevent his client from updating it. On the contrary, the only 
server that should tell him *not* to update that zone would be a server 
configured both to update the zone, and to tell clients not to update it 
themselves. That's why I asked Ted the question: the only time his client 
should see the 'don't update' bit is the time that he *should* pay 
attention to it. He shouldn't see it from dhcp servers that he's visiting, 
servers who aren't configured to update his zone. Do both you and Ted think 
that the default behavior for servers should be to tell all clients not to 
perform updates, regardless of the domain names that the clients present? I 
don't agree with that. The specification is about exchanging configuration 
information, and the server who has no information about the administrative 
policy in a zone shouldn't make up a policy and tell clients about it. A 
server which does know a zone's policy about updates should tell clients 
about it, and the clients should pay attention to it.

-- Mark

At 02:06 PM 8/27/2001 -0700, Stuart Cheshire wrote:
> >I agree with you about the purpose of the bit, but I'm a little confused by
> >your last paragraph. Do you mean that even if the server was configured by
> >you, and it asked your client not to update grosse.fugue.com, you'd like
> >your client to update that zone anyway?
>
>How would Ted's DHCP client *know* that the server was configured by Ted?
>
>When Ted's sitting in Starbucks with his laptop and the Starbucks DHCP
>server tells it not to update "grosse.fugue.com.", how can Ted's DHCP
>client distinguish that case from Ted's own DHCP server telling it not to
>update "grosse.fugue.com."?
>
>Furthermore, if Ted's laptop has the software and the credentials to
>safely update "grosse.fugue.com.", why would Ted *ever* set his DHCP
>server to tell his client not to?
>
>Surely Ted will want his laptop to *always* ignore the "don't update"
>bit, because he knows that if the bit is ever set, it will be from a DHCP
>server that has no authority to tell him not to update his own domain?
>
>Stuart Cheshire <cheshire@apple.com>
>  * Wizard Without Portfolio, Apple Computer
>  * Chairman, IETF ZEROCONF
>  * www.stuartcheshire.org


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