Re: [dhcwg] "client identifier" in server replies

John Schnizlein <jschnizl@cisco.com> Tue, 08 July 2003 21:44 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 RAA11641; Tue, 8 Jul 2003 17:44:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0Fk-00013D-WA; Tue, 08 Jul 2003 17:44:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0F0-00012p-0N for dhcwg@optimus.ietf.org; Tue, 08 Jul 2003 17:43:14 -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 RAA11601 for <dhcwg@ietf.org>; Tue, 8 Jul 2003 17:43:09 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a0Ex-000751-00 for dhcwg@ietf.org; Tue, 08 Jul 2003 17:43:11 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19a0Ew-00074O-00 for dhcwg@ietf.org; Tue, 08 Jul 2003 17:43:10 -0400
Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2003 14:45:24 -0700
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h68Lgc7F014080; Tue, 8 Jul 2003 14:42:38 -0700 (PDT)
Received: from jschnizl-w2k.cisco.com (sjc-vpn1-500.cisco.com [10.21.97.244]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA18999; Tue, 8 Jul 2003 14:42:38 -0700 (PDT)
Message-Id: <4.3.2.7.2.20030708173205.020b8ed0@wells.cisco.com>
X-Sender: jschnizl@wells.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Jul 2003 17:37:16 -0400
To: Thamer Al-Harbash <tmh@whitefang.com>
From: John Schnizlein <jschnizl@cisco.com>
Subject: Re: [dhcwg] "client identifier" in server replies
Cc: dhcwg@ietf.org
In-Reply-To: <Pine.BSF.4.51.0307081519180.92951@helena.whitefang.com>
References: <200307081344.02867.mellon@nominum.com> <79A2DB53BC51BD448F0D19A86FB1DB637F1FF7@siebe002.apac.nokia.com> <200307081449.44328.budm@weird-solutions.com> <200307081344.02867.mellon@nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
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>

At 03:28 PM 7/8/2003, Thamer Al-Harbash wrote:

>...
>We already have the DHCP Hostname option. Clients can be
>configured to pass this option when the admnistrator expects high
>xid collisions. The DHCP server can also be configured to assign
>leases per the DHCP Hostname option. We just need to promote the
>use of the DHCP Hostname option to be used to counter this
>problem.
>
>Is this too kludgy?

Yes. IMHO

The part of this that relies on DHCP clients to provide different
host-name parameters violates the design goal of RFC 2131:

   1.6 Design goals

   The following list gives general design goals for DHCP.

      o DHCP should be a mechanism rather than a policy.  DHCP must
        allow local system administrators control over configuration
        parameters where desired; e.g., local system administrators
        should be able to enforce local policies concerning allocation
        and access to local resources where desired.

      o Clients should require no manual configuration.  Each client
        should be able to discover appropriate local configuration
        parameters without user intervention and incorporate those
        parameters into its own configuration.

      o Networks should require no manual configuration for individual
        clients.  Under normal circumstances, the network manager
        should not have to enter any per-client configuration
        parameters.

John


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