Bewertung

Dieser Ansatz hat folgende Nachteile

• Die Schattenobjekte sind sehr komplex. Jedes Schattenobjekt stellt im Prinzip einen einfachen SNMP-Manager dar, der nur für wenige Managementobjekte eines einzigen Agenten zuständig ist.
• Eine SNMP-GetResponse kann ausschließlich anhand der in ihr enthaltenen request-id dem ursprünglichen SNMP-Request zugeordnet werden. Da viele Schattenobjekt-Prozesse unabhängig SNMP-PDUs verschicken, ist die Erzeugung notwendigerweise eindeutiger request-ids problematisch.
• Die PDUs GetNextRequest und GetBulk können von den Schattenobjekten, auch wenn sie von der SNMP-API angeboten werden, nicht sinnvoll verwendet werden, da damit vom Zielagenten unter Umständen Werte von Managed Objects zurückgeschickt werden, die nicht vom Schattenobjekt repräsentiert werden. Während z. B. ein Schattenobjekt, das die i-te Zeile einer SNMP-Tabelle darstellt, mit einer GetRequest-PDU nur Werte von Tabelleninstanzen der i-ten Zeile erhält, werden bei einer GetNextRequest-PDU mit den gleichen Parametern die Instanzen der (i+1)-ten Tabellenzeile zurückgegeben.
• Die Erweiterung der Schattenobjekte, beispielsweise die Einführung von einer neuen API ist nur durch Verändern (neu Übersetzen) aller betroffenen Schattenobjekte möglich.
• Oftmals ist erwünscht, daß ein Gateway Schnittstellen zu Verfügung stellt, durch die das Gateway selbst überwacht werden kann. Bei diesem Ansatz müßten globale, nicht das Schattenobjekt betreffende Daten für Statistiken, wie etwa die Anzahl der fehlerhaft empfangenen SNMP-Messages, in jedem Schattenobjekt gespeichert und aktualisiert werden.