Trotz der kontinuierlichen Weiterentwicklung der Internet-Managementarchitektur bleibt das Problem nicht vorhandener Konsistenzsicherung hinsichtlich verfügbarer Managementinformation zwischen Agenten und Managern auch weiterhin ungelöst: Es ist für ein SNMP-basiertes Managementsystem nicht automatisch ermittelbar, welche über den Umfang der MIB-II hinausgehende Menge an Managementinformation von Agenten angeboten wird. Diese in der Praxis kritische Discovery-Problematik ist sowohl im OSI-Management (mit der Management Knowledge Management Function) als auch in CORBA (DII, Interface Repository, Query Service) gelöst. Es gibt darüber hinaus Anzeichen, daß die Ausdehnung des ursprünglich auf das Komponentenmanagement fokussierenden Internet-Managements auf Bereiche wie das System- und Anwendungsmanagement Schwierigkeiten grundlegender Art hervorruft: Die oben angesprochene Application Management MIB liefert ein gutes Beispiel für die Anwendung des SNMP-Managements auf einen Bereich, für den diese Architektur ursprünglich nicht vorgesehen war. Schließlich sind Netzkomponenten wie Sternkoppler und Router bereits von ihrem Aufbau ,,tabellenartig`` strukturiert: In die 19-Zoll-Chassis dieser Geräte wird eine nach oben beschränkte Zahl von Modulen eingesetzt, die ihrerseits Eigenschaften besitzen, welche leicht durch skalare Variablen instrumentiert werden können. Eine Repräsentation dieser Systeme (deren Informationsmenge überdies verhältnismäßig statisch ist) durch skalare Variablen und Tabellen bietet sich daher an.
Bei abstrakten Softwarekomponenten wie Diensten und Anwendungen ist diese einfache Struktur nun nicht mehr gegeben, da einerseits die Menge ihrer Instanzen unbeschränkt und darüberhinaus sehr dynamisch ist. Aufgrund der Beibehaltung der Tabellenstruktur ist man jedoch gezwungen, diese Softwaremodule ebenfalls auf Tabellen, diesmal mit a priori unbekannter Länge abzubilden. Hierdurch ergibt sich einerseits die Notwendigkeit, zur Laufzeit Tabellenzeilen hinzuzufügen bzw. zu entfernen, andererseits müssen (Vererbungs-) Beziehungen zwischen diesen Tabellen durch weitere Tabellen dargestellt werden. Diese Tabellen müssen nun konsistent gehalten werden, was in Ermangelung von Mechanismen wie Fremdschlüsseln (wie man sie von relationalen Datenbanksystemen kennt) in der Regel sehr komplex gerät. ,,Simple`` ist heutzutage de facto nur noch das Protokoll, mit dem auf die Managementagenten zugegriffen wird. Die MIBs selbst (und damit die diese MIBs implementierenden Agenten) erreichen durch die Beibehaltung der Tabellen und der damit einhergehenden komplizierten Indexverwaltung eine beachtliche Größe: Zur Administration der Beziehungen müssen spezielle Tabellen definiert werden, die mit den eigentlichen Ressourcen nichts mehr unmittelbar zu tun haben, sondern lediglich der besseren Indizierung derjenigen Tabellen dienen, die die eigentliche Managementinformation beinhalten.
Ferner bedingt die wechselhafte Geschichte der Internet-Managementarchitektur daß Entwickler, die sich heutzutage mit der Implementierung einer SNMP-basierten Lösung für verteiltes Management befassen, in einem Dilemma stecken: Sie haben die Wahl zwischen einem 6 bis 7 Jahre alten Minimalumfang, dessen Mängel offenkundig sind (vgl. hierzu [#!yemi94!#] und [#!zele95!#]) und einer nicht unbeträchtlichen Zahl relativ junger RFCs bzw. Internet Drafts, die durchaus noch Modifikationen unterliegen. Es ist somit nachvollziehbar, daß Hersteller von Ressourcen zumeist die erste Alternative wählen und neue Geräte mit MIBs ausstatten, die lediglich der ersten Version des SNMP-Managements entsprechen.
Zusammenfassend sei an dieser Stelle gesagt, daß gegenwärtig ein breiter Konsens besteht, daß das ursprüngliche SNMP Management Framework für die heutigen Bedürfnisse nicht mehr geeignet ist und grundlegend erneuert werden muß, um die weite Verbreitung dieser Architektur auch in Zukunft zu gewährleisten. Dies betrifft wesentliche Aspekte (wie die vorher erwähnten modularen Managementagenten sowie DISMAN) und führt damit zu einer umfassenden Restrukturierung und Neuausrichtung dieser Managementarchitektur. Jedoch hat wohl kaum eine Aktivität in der Internet Engineering Task Force zu solch großer Uneinigkeit geführt, wie die Frage, wie ein neues SNMP-basiertes Management aussehen soll. Beispielhaft sei an die zweite Version des SNMP-Managements (SNMPv2) erinnert, das zuerst in den RFCs 1440 bis 1450 im Jahre 1993 standardisiert, 1997 durch eine neue Version (RFCs 1901-1910) überflüssig wurde und durch das gegenwärtig in der Abschlußphase befindliche SNMPv3 ersetzt werden soll, in das die Konzepte der oben angesprochenen Arbeitsgruppen nahtlos integrierbar sein werden. In [#!harr97!#] findet man einen guten Überblick über die historische Entwicklung von SNMPv1 bis SNMPv3.
Herstellerseitig ist jedoch nach den negativen Erfahrungen mit SNMPv2 die Bereitschaft, ein weiteres Mal Investitionen für Implementierungen einer neuen SNMP-Version bereitzustellen, erheblich eingeschränkt. Es ist daher gegenwärtig noch nicht entschieden, inwieweit das Internet-Management seine bisherige Bedeutung beibehalten kann; die in den vorigen bzw. folgenden Abschnitten skizzierte Vielzahl alternativer, konkurrierender Managementarchitekturen erschweren den Übergang zu SNMPv3 zusätzlich. Das Internet-Management scheidet somit sowohl aufgrund konzeptioneller Schwächen als auch aufgrund der Unsicherheit bezüglich seiner weiteren Entwicklung gegenwärtig als Kandidat für eine Enterprise Management Architektur aus.