[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf midcom proposed charter

The following message bounced due to an email address change.

------- Forwarded Message

To: snmpconf@snmp.com
cc: iesg@ietf.org
Subject: midcom proposed charter
From: Jon Saperia <saperia@jdscons.com>
Date: Mon, 08 Jan 2001 09:08:33 -0500
Sender: saperia@jdscons.com

The following comments about the midcom charter are based on the posting
Randy Presuhn made of the proposed midcom charter to the snmpconf WG
list. He asked:

> Does anyone know how this relates to the snmpconf work?

If part of the charter is how to provision/control the behavior of these
devices then SNMP/SNMPCONF, should be investigated. If the charter means
something else, then it should be clarified.

What is clear is that there is work in the charter that is part of a
'plane' for 'signaling' - something outside the usual domain of a
management protocol. It is not clear to me how this work squares with
the security policy working group, they would have to comment on
that. There was recently a discussion in the new area about SNMP for
configuration and quite a lot of debate because where the
lines/functions were between management and signaling were not
clear. The issue is not: should any management protocol be used for real
time signaling?  It is using extant management protocols for
configuration of the network behavior and control and monitoring
subsequent to that configuration. Control in this [management] context
does not mean the control signals that are sent from one device to
another, e.g., ICMP messages. Control from the management perspective
means the configuration of the device/network behavior and subsequent
directives about how to behave such as turn protocol X on or off or, do
or do not respond to control messages of type Y.

We should resist the temptation to develop functionally overlapping
management protocols that are customized to each new technology. While
it is easy to create an optimized management protocol, it makes
management more, not less complex when deployed.

Any desire for management and control functions that does not use extant
protocols (e.g., SNMP), should be carefully scrutinized by the IESG -
BEFORE work is begun.  If deficiencies are found, then the management
technology should be fixed assuming there is no other reasonable way to
manage the new technology. This review metric should be true for
existing and proposed working groups. For those that say this would
inhibit progress, I would also point out that by the time something gets
far enough in the process where it can be evaluated as a proposed
standard, there is often too much investment for people to give it up.

These comments are as much for midcom as they are for requesting the
IESG review of new charters.


Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874

------- End of Forwarded Message