FW: Additions to CMU's proposed DHCP MIB

["Hibbs, R Barr (rbhibbs)" <[e-mail]>]

 ----------
From: Hibbs, R Barr (rbhibbs)
To: dhcp-v4
Subject: Re: Additions to CMU's proposed DHCP MIB
Date: Mon, 26 Aug, 1996 13:44


 ----------
From: dhcp-v4
To: Multiple recipients of list
Subject: Re: Additions to CMU's proposed DHCP MIB
Date: Monday, August 26, 1996 10:16AM


At 1:37 PM 8/16/96, Hibbs, R Barr (rbhibbs) wrote:
>Erikas provided a copy of Carnegie-Mellon's enterprise MIB for SNMP control
>of a DHCP server last week.  After examining CMU's  work, I believe it 
could
>be the basis for a general command and control facility for DHCP servers.

I agree.  The CMU MIB is a good start.

To follow current conventions,  counter values need to be defined as per
the SMIv2 in RFC1902.  We need to define if we want Counter32 or Counter64
values.

>DHCP performance statistics
>     1.  Inter-arrival time
>          DHCPMinArrival  OBJECT-TYPE
>          DHCPMaxArrival  OBJECT-TYPE
>          DHCPSumArrival  OBJECT-TYPE
>          DHCPSumSquaresArival  OBJECT-TYPE
>

I'm a bit concerned about the performance statistics you've defined.  They
seem to be interesting values, but I'm curious what a network administrator
will do with the information?  Please include a detailed DESCRIPTION
section for each of the values.

=== I will create a detailed DESCRIPTION section, and restate the counters 
in SMlv2 form shortly, and forward a more complete proposal -- Barr


>     2.  Response time
>          DHCPMinResponse  OBJECT-TYPE
>          DHCPMaxResponse  OBJECT-TYPE
>          DHCPSumResponse  OBJECT-TYPE
>          DHCPSumSquaresResponse  OBJECT-TYPE

This section is very unclear.  Is this time calculated from reciept of the
query?  My question from above regarding the value of this to a net admin
is repeated here.

=== I will attempt to clarify (1) how we define the times, and (2) how we 
[plan to] use them --Barr
>

>From information in this and previous emails, it sounds like you've built
an interesting server.  Is Pac Bell willing to release it for others to
use?

Milt Roselinsky                                 [e-mail]


=== Our server may not be useful for the general internet community for 
several reasons:  (1) it is implemented on a Tandem Himalaya system, under 
control of Guardian 90 rather than Tandem's Unix offering, (2)  unlike a 
general-use product, we picked and chose the DHCP functionality that we 
implemented in order to maximize performance [examples:  we don't support 
dynamic BOOTP, nor do we accept client suggestions for either hostname or 
domain name], (3) we took full advantage of an existing set of proprietary 
network management and configuration services processes also implemented on 
the Tandem platform to provide on-line updating of static IP address 
assignments and that also provide the basic server configuration data -- 
services that we are not prepared to offer to the general community, and (4) 
while we might freely share requirements, design ideas, algorithms, and even 
code fragments, we are not in a position to offer any product support for 
the server itself -- that comes suspiciously close to a prohibited activity 
under the MFJ, as well as requiring a great investment in resources that we 
just can't offer without receiving compensation [remember, we must answer to 
the California Public Utilities Commission regarding expenses charged to the 
ratepayer base.]

 --Barr Hibbs
  Pacific Bell
  [e-mail]
  [phone]