"Louis A. Mamakos" <> Wed, 04 January 1995 17:06 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa04789; 4 Jan 95 12:06 EST
Received: from [] by IETF.CNRI.Reston.VA.US id aa04784; 4 Jan 95 12:06 EST
Received: from [] by CNRI.Reston.VA.US id aa02624; 4 Jan 95 12:06 EST
Received: from rodan.UU.NET by (5.65c/5.61+local-20) id <AA03248>; Wed, 4 Jan 1995 08:41:24 -0800
Received: by rodan.UU.NET id QQxxgc06594; Wed, 4 Jan 1995 11:41:14 -0500
Message-Id: <QQxxgc06594.199501041641@rodan.UU.NET>
Cc: "Craig A. Finseth" <>,
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Louis A. Mamakos" <>
Subject: Re:
In-Reply-To: Your message of "Wed, 04 Jan 1995 10:43:09 EST." <>
Date: Wed, 04 Jan 1995 11:41:13 -0500

> I agree with the "it's too soon" contingent.  Reworking your thoughts
> into that straitjacket I come up with this proposal:  MUST SNMPv1.
> MAY (or SHOULD?) SNMPv2.  DISCUSSION: Transition from SNMPv1 to SNMPv2
> is a goal for a future Internet standard.  However, this is unlikely to
> occur until SNMPv2 is a full standard and more operational experience
> has been gained.  Also, such a transition cannot be carried out
> simultaneously throughout the operational Internet, so coexistence
> of both versions for some period of time is a practical necessity.

My really big problem with "MAY SNMPv2" is that some vendors build
products which are configured and managed almost exclusively with
SNMP.  In a real production network, this is really scary, having to
do SNMP SET operations with SNMPv1 and clear text community strings.

It's almost as bad as typing passwords in clear text over TELNET

The language and intent should make is painfully clear that there
should be some reasonably strong mechanisms to protect management
operations which affect the state of the router.  Protect against
eavesdropping, replay, etc.

I think that the transition issue is just so much smoke and mirrors.
There is no reason that an old, non-conformant device can't continue
to be managed with SNMPv1 or clear text TELNET sessions with reusable
passwords.  There is no "simultanous" conversion that has to occur.

I suspect that the new RREQ RFC will achive "standard" status after
the SNMPv2 RFC does, right?  This would be interesting information to
get from the SNMP folks.  I think that not mandating some sort of
secure management mechanism is doing a big disservice to folks that
build networks.  Real, operational experience on the internet supports
this requirement.

Louis A. Mamakos                    
Backbone Architecture & Engineering Guy       uunet!louie
AlterNet / UUNET Technologies, Inc.
3110 Fairview Park Drive., Suite 570          Voice: +1 703 204 8023
Falls Church, Va 22042                        Fax:   +1 703 204 8001