Re: snmpv2 pros and cons

"Lee D. Rothstein" <ldr@veritech.com> Tue, 12 October 1993 00:03 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29588; 11 Oct 93 20:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29584; 11 Oct 93 20:03 EDT
Received: from JArthur.CS.HMC.Edu by CNRI.Reston.VA.US id aa11037; 11 Oct 93 20:03 EDT
Received: from jarthur by jarthur.Claremont.EDU id af13163; 11 Oct 93 15:54 PDT
Received: from lists.psi.com by jarthur.Claremont.EDU id aa09770; 11 Oct 93 14:47 PDT
Received: by lists.psi.com (4.1/SMI-4.1.2-PSI) id AA14103; Mon, 11 Oct 93 17:31:23 EDT
Return-Path: <ldr@veritech.com>
Received: from psi.com by lists.psi.com (4.1/SMI-4.1.2-PSI) id AA14067; Mon, 11 Oct 93 17:31:01 EDT
Received: from mv.MV.COM by psi.com (4.1/2.1-PSI/PSINet) id AA12794; Mon, 11 Oct 93 17:31:41 EDT
Received: by mv.MV.COM (5.67/1.35) id AA12787; Mon, 11 Oct 93 17:30:27 -0400
Date: Mon, 11 Oct 1993 17:22:06 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Lee D. Rothstein" <ldr@veritech.com>
Subject: Re: snmpv2 pros and cons
To: Bill Norton <wbn@merit.edu>
Cc: snmp@psi.com, Steve Welch <smw@veritech.com>, "Stephen E. Kille" <S.Kille@isode.com>
In-Reply-To: <9310111829.AA19894@fox.merit.edu>
Message-Id: <Pine.3.05.9310111704.A11201-c100000@mv.mv.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> Date: Mon, 11 Oct 1993 14:29:49 -0400
> From: Bill Norton <wbn@merit.edu>
> To: snmp@psi.com
> Subject: Re: snmpv2 Will it flood us or be slow 
> 
> 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.

I must have been sleeping during earlier exchanges (:-(); ISODE is
manageable through SNMP2? What is going on here? SNMP1? CMIP? CMOT? (Sorry
to be so dense.)

> 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.

Have there not been proposals for these problems?

> 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?

Should the abobe sentence have been displaced downward one paragraph?

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




                  <> Lee D. Rothstein <> LDR@VeriTech.com <>
     <> VeriTech <> 7 Merrymeeting Drive <> Merrimack, NH 03054-2934 <>
                    <> 603-424-2900 <> Fax: 603-424-8549 <>
            <> Information Technology Verification & Leadership <>