Re: snmpv2 Will it flood us or be slow

Bill Norton <wbn@merit.edu> Mon, 11 October 1993 19:37 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26557; 11 Oct 93 15:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26553; 11 Oct 93 15:37 EDT
Received: from JArthur.CS.HMC.Edu by CNRI.Reston.VA.US id aa03788; 11 Oct 93 15:37 EDT
Received: from jarthur by jarthur.Claremont.EDU id ac27393; 11 Oct 93 12:05 PDT
Received: from lists.psi.com by jarthur.Claremont.EDU id aa26781; 11 Oct 93 11:48 PDT
Received: by lists.psi.com (4.1/SMI-4.1.2-PSI) id AA11214; Mon, 11 Oct 93 14:29:21 EDT
Received: from psi.com by lists.psi.com (4.1/SMI-4.1.2-PSI) id AA11178; Mon, 11 Oct 93 14:29:09 EDT
Received: from merit.edu by psi.com (4.1/2.1-PSI/PSINet) id AA09494; Mon, 11 Oct 93 14:29:51 EDT
Return-Path: <wbn@merit.edu>
Received: from fox.merit.edu by merit.edu (5.65/1123-1.0) id AA23243; Mon, 11 Oct 93 14:29:50 -0400
Received: by fox.merit.edu (5.65/client-0.9) id AA19894; Mon, 11 Oct 93 14:29:49 -0400
Message-Id: <9310111829.AA19894@fox.merit.edu>
To: snmp@psi.com
Subject: Re: snmpv2 Will it flood us or be slow
Date: Mon, 11 Oct 1993 14:29:49 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Norton <wbn@merit.edu>

Karl -

I'm actually being swayed towards the other side by the workable
reference implementations.  I fetched the ISODE and CMU implementations
and have been doing interoperability experiments.  So far, everything
seems to work very well, indicating to me that the spec is definately
implementable.  I would note a few things though:

1) Other (non-snmpv2 author written) implementations need to speak up
with respect to their interoperability/implementation experiences.  This
will tell us whether or not the specs stand on their own and lead to
interoperable standards.

2) The end-user shouldn't notice much of a difference during normal
operations, right?  The users are really concerned about getting at the
instrumentation, and both SNMPv2 and SNMPv2 provide that.  In fact
SNMPv2 will make apps like stats gathering and table dumps quicker.

3) I (in theory) agree that SNMPv2 problems, if they arise, will be more
difficult to debug.  Problems like clock synching, secret exchanges,
diagnosing authentication and encryption implementation problems, and
diagnosing problems when the data is encrypted seems like it would be
trouble. 

4) These reference implementations don't include all the pieces (ISODE
doesn't have Manager-to-manager or privacy) making it difficult to
explore these potential problems.

  >1) It is very easy for people who are 'in' to things to think
  >that everyone else has the same level of commitment and interest.
  >They can end up designing somthing that may be very elegant and
  >comprehensive but is totally unusable by end users. SNMP achieved
  >acceptance because it was 'simple' - to implement, to use and to
  >diagnose. What we are looking at with v2 is somthing that - while
  >it addresses shortcomings in v1 - requires drastic increases in
  >storage, processing power and developer time. This does not bode
  >well.

Well come on now Karl, you don't believe companies are sending
their employees here for totally altruistic reasons, do you?

  >2) I'm inherently suspicous of draft standards that are proposed
  >by people who may have a pecunary interest in their being
  >adopted.
  >


Bill