FW: BOUNCE mibs@ops.ietf.org: Admin request of type /\bsubscribe\b/i at line 3

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Posting from a non-subscriber (or at least Ed was not yet subscribed
when he posted this.

Bert

> ----------
> From: 	owner-mibs@ops.ietf.org[SMTP:owner-mibs@ops.ietf.org]
> Sent: 	Saturday, February 03, 2001 2:42 AM
> To: 	mibs-approval@psg.com
> Subject: 	BOUNCE mibs@ops.ietf.org:     Admin request of type
> /\bsubscribe\b/i at line 3  
> 
> From eluwish@qwest.com Fri Feb 02 17:42:22 2001
> Received: from uswgne22.uswest.com ([204.26.87.76])
> 	by psg.com with esmtp (Exim 3.16 #1)
> 	id 14OriY-000AMm-00
> 	for mibs@ops.ietf.org; Fri, 02 Feb 2001 17:42:22 -0800
> Received: from egate-co2.uswc.uswest.com (egate-co2.uswc.uswest.com
> [151.119.214.10])
> 	by uswgne22.uswest.com (8.10.0/8.10.0) with ESMTP id f131fpL01237
> 	for <mibs@ops.ietf.org>; Fri, 2 Feb 2001 19:41:51 -0600 (CST)
> Received: from qwest.com (localhost [127.0.0.1])
> 	by egate-co2.uswc.uswest.com (8.10.0/8.10.0) with ESMTP id
> f131foT17868;
> 	Fri, 2 Feb 2001 18:41:50 -0700 (MST)
> Message-ID: <3A7B61DB.9B9B8CAC@qwest.com>
> Date: Fri, 02 Feb 2001 18:41:48 -0700
> From: Edward P Luwish <eluwish@qwest.com>
> X-Mailer: Mozilla 4.51 [en] (WinNT; U)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: mibs@ops.ietf.org
> Subject: About this list...
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> I am accustomed to lists with such great volume that I get several
> messages immediately after subscribing, but I am not familiar with this
> one.  If anyone has recommendations for other lists I should subscribe
> to, please respond.
> 
> My name is Ed Luwish, I work for Qwest Communications, in the Network
> Management Services development team.  Qwest runs a NOC that manages the
> internal enterprise networks of many medium-to-large size companies (my
> group has nothing to do with managing Qwest's backbone infrastructure or
> its ISP divisions).  As such, we need to manage network devices from
> many vendors, and need to do it with a minimum number of tools - we
> rarely use the vendors' EMS products, because of the geometric explosion
> in product administration, maintenance and user training that would
> result.  Also, for efficiency it is best that a NOC engineer need look
> at only one screen for fault management - anything more complex and
> alarms would be lost.
> 
> The disadvantage of this approach is that we depend heavily on
> interoperability between vendor-neutral management software and a huge
> number of different SNMP agents.  My job is to make this a reality by
> crafting tools and plugins, and filing trouble tickets with device and
> NMS vendors.
> 
> Several years ago I worked for Concord Communications adding new
> supported devices to its reporting product, and became intimately
> familiar with standard and enterprise MIBs, both as a source of accurate
> statistical information and for implementation of agent-type and
> managed-element discovery algorithms.  I must have a collection of
> several thousand of them, many from vendors who are no more than a faint
> memory.
> 
> I would like to participate in a forum that has some influence in the
> direction of SNMP, with participation by device and NMS developers and
> other leaders.  My primary concern is with interoperability in a
> multi-vendor environment, but am also interested in high-speed transport
> MIBs, network security, configuration management, agents for translating
> between SNMP and non-SNMP (CORBA, TL1, etc.) messaging and data, and
> other issues that would allow a NOC to give some support to customers
> for every device, every application and every communication layer.
> 
> Ed
> 
>