"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
  •   Hibbs, R Barr (rbhibbs)