"Hibbs, R Barr (rbhibbs)" <rbhibbs@pbsrv02.isp.pacbell.com> Thu, 08 August 1996 16:34 UTC
Received: from ietf.org by ietf.org id aa16645; 8 Aug 96 12:34 EDT
Received: from cnri by ietf.org id aa16641; 8 Aug 96 12:34 EDT
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa10072;
8 Aug 96 12:34 EDT
Received: from localhost by reef.bucknell.edu with SMTP
(5.65/IDA-1.2.8) id AA09776; Thu, 8 Aug 1996 12:20:28 -0400
Date: Thu, 8 Aug 1996 12:20:28 -0400
Message-Id: <9608081612.AA02466@gw3.pacbell.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@ietf.org
From: "Hibbs, R Barr (rbhibbs)" <rbhibbs@pbsrv02.isp.pacbell.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject:
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
X-Mailer: Worldtalk (NetConnex V4.00a)/MIME
Erikas, Stephen, et al.: I appreciate your sharing the MIB for the CMU DHCP server with us. I don't have a position regarding whether the command and control of a DHCP server should be part of a server-to-server protocol or a separate protocol. I have just begun to examine the CMU server, and hope to have some comments in a few days regarding C&C matters. Have you had any discussions with Ted Lemon, who, I believe, is working on a server-to-server protocol? I would enjoy working with you and others to define a suitable proposal for command and control of (multiple) DHCP servers, either conducting all discussion on the general list, or doing some of the work privately. Our existing DHCP servers at Pacific Bell utilize a separate command interface process that accepts operator commands, forwards them to a specific server, then formats the replies for human readability. The mechanism is a process-to-process message protocol specific to the systems on which our servers execute, but the ideas used are generally applicable to any server platform. The format of the C&C messages and replies in no way resembles ASN/1, but that is merely an implementation detail: because our server does not [currently] have to interoperate with any other system, we can afford a proprietary interface. Many of the parameters that appear to be controlled by your MIB we handle in an entirely different way, through an automatic workstation configuration mechanism that pre-dated [by several years] our implementation of TCP/IP, that we adopted to provide configuration data for our DHCP servers. While I haven't taken a position regarding the choice of C&C message formats and protocol, the size of our intranet requires [forgive me] "industrial-strength" solutions, such as a mechanism for supplying all boot data for a client [for static IP addresses] as a formatted BOOTP/DHCP packet: the time to parse ASN/1 or other configuration syntax by a DHCP server is unacceptable in our environment. Barr Hibbs Pacific Bell +1 (415) 545-1576 rbhibbs@pacbell.com