Zusammenfassung

  • RFC 5381 zeigt, wie Axis aus WSDL Client-Stubs und Server-Skeletons erzeugt und wie Ant/Tomcat diese Artefakte bereitstellt; das Skeleton bleibt dennoch eine Vorlage für die eigentliche NETCONF-Logik.
  • Die zusätzlich verwendete HTTP-Cookie-Korrelation machte das Paar intern funktionsfähig, wich aber von der RFC-4743-Sitzungsbindung ab und war laut Dokument nicht interoperabel.

Der grüne Endpunkt

Das Build-System erzeugt Klassen. Ant kopiert sie in das Axis-Verzeichnis des Servlet-Containers. Ein Deployment Descriptor wird eingespielt. Tomcat antwortet. Für viele Betriebsmodelle ist das der Moment, in dem ein Dienst als „live“ gilt.

RFC 5381 lässt diese Abkürzung nicht zu. Beim Top-down-Ansatz wird aus einer vorhandenen WSDL ein Server-Skeleton erzeugt. Dieses Gerüst kann selbst als Web-Service-Struktur funktionieren, doch die benötigten NETCONF-Funktionen müssen in die Implementierung eingefügt werden. Die Erreichbarkeit des Containers ist damit zeitlich früher als die Vollständigkeit des Managementdienstes.

Ein Availability-Check kann also korrekt grün sein, obwohl die fachliche Funktion fehlt. Das ist kein Messfehler. Der Check beantwortet nur eine engere Frage.

Vier verschiedene Fertigstellungen

Die Implementierungskette enthält mindestens vier Abschlüsse. Erstens erzeugt das Werkzeug Quellcode aus einer Beschreibung. Zweitens kompiliert der Code. Drittens lädt der Container die Klassen und routet Anfragen. Viertens führt der NETCONF-Service eine autorisierte Operation am richtigen Datastore aus und das Gerät realisiert sie.

Zwischen diesen Abschlüssen liegen verschiedene Eigentümer. Das WSDL-Team besitzt die Schnittstellenbeschreibung. Das Build-Team besitzt reproduzierbare Artefakte. Die Plattform besitzt Axis und Tomcat. Der Managementdienst besitzt NETCONF-Semantik und Sitzung. Die Geräteebene besitzt die Realisierung.

Wenn ein einziges Feld deployed=true alle vier Rollen vertritt, ist der Status nicht falsch, aber bedeutungslos geworden.

RFC 5381 nennt zusätzliche Abhängigkeiten. netconf-soap_1.0.wsdl enthält keinen vollständigen Service-Endpunkt; eine weitere WSDL importiert die Definition und ergänzt das Service-Element. Gerätespezifische Datenmodelle müssen über XML Schema verbunden werden. Die generierten Klassen sind daher Ergebnis mehrerer Eingaben, nicht eines selbstgenügsamen Standardsdokuments.

Das Skeleton konnte die private Abweichung verbergen

Noch deutlicher wird die Grenze bei der Sitzung. RFC 4743 band den NETCONF-Sitzungszustand an die dauerhafte Transportverbindung. Die in RFC 5381 dokumentierte Implementierung kopierte die Sitzungskennung zusätzlich in ein HTTP-Cookie. Das Gerät vergab die Kennung nach hello; der NMS speicherte und wiederholte sie; beim Schließen wurde sie entfernt.

Client und Server konnten damit zuverlässig zusammenarbeiten, solange beide dieselbe private Regel kannten. Das Dokument bezeichnet diese Konstruktion ausdrücklich als alternative Binding, die nicht mit RFC-4743-konformen Implementierungen interoperiert.

Ein Deployment-Test zwischen den beiden Geschwistern prüfte somit dieselbe Annahme auf beiden Seiten. Er konnte gerade deshalb erfolgreich sein, weil keine unabhängige Interpretation beteiligt war. Die Abweichung befand sich nicht zwingend in der WSDL-Signatur, sondern in der Zuordnung von HTTP-Anfrage zu NETCONF-Sitzung.

Bei Reconnect, Proxy, Load Balancer oder Cookie-Replay kann diese Zuordnung auseinanderbrechen. Ein aussagekräftiger Sitzungsbeleg muss Verbindung, TLS-Identität, Cookie, NETCONF session-id, Capability-Austausch und Schließereignis gemeinsam zeigen.

Ein SOAP-Erfolg ist ein Zwischenbeleg

Auf ressourcenarmen Geräten kann die Architektur aus HTTP-Daemon, SOAP-Modul und NETCONF-Serviceprovider bestehen. Das SOAP-Modul entfernt den Umschlag und reicht die Nutzlast weiter. Erst danach interpretiert der NETCONF-Teil die Operation und konfiguriert das Gerät.

Diese Abfolge ordnet Belege sauber. HTTP-Empfang beweist Zustellung zum Web-Endpunkt. SOAP-Parsing beweist die syntaktische Annahme des Umschlags. NETCONF-Verarbeitung beweist eine protokollbezogene Entscheidung. Autorisierung, Datastore-Änderung, Commit, Geräterealisierung und beobachteter Netzeffekt folgen jeweils später.

Ein rpc-reply darf deshalb nicht nur nach seinem Vorhandensein bewertet werden. Sein Inhalt, der betroffene Datastore und die Zuordnung zur Autorisierungsentscheidung gehören zum Beleg. Selbst ein erfolgreicher Commit braucht eine spätere Beobachtung, wenn das Geschäftsziel ein aktives Netzwerkverhalten ist.

HTTPS beendet die Sicherheitsfrage nicht

RFC 5381 übernimmt die Security Considerations von NETCONF und der SOAP-Bindung. Authentisierung und Verschlüsselung sollen über TLS bereitgestellt werden. Das schützt die Verbindung und hilft, den Kommunikationspartner zu bestimmen.

TLS entscheidet nicht, welche Konfiguration dieser Partner ändern darf. Es entscheidet auch nicht, ob Cookie oder Verbindung die Sitzung besitzen. Ein unverfälschter Request kann unzulässig sein; ein zulässiger Request kann am Datastore scheitern; ein Commit kann ohne den beabsichtigten Geräteeffekt bleiben.

Die IESG-Notiz zieht eine weitere Grenze: Eine damalige NETCONF-Implementierung, die nur SOAP und nicht wenigstens SSH unterstützte, war nicht vollständig standardkonform. Ein sicherer, erreichbarer SOAP-Endpunkt blieb also nur ein Teil des geforderten Profils.

Nach dem öffentlichen Ende bleibt der lokale Endpunkt

Später ersetzten RFC 6241 und RFC 6242 Basisprotokoll und SSH-Mapping. RFC 9900 erklärte die SOAP- und BEEP-Transporte für Historic und gab ihre Ports frei. Der bestehende BTW-Beitrag zu RFC 9900 behandelt die Differenz zwischen Registerfreigabe und lokaler Stilllegung.

RFC 5381 besitzt eine andere Nachwirkung: Selbst wenn ein alter Endpunkt noch erreichbar ist, sagt das nichts darüber, ob sein Skeleton vollständig, seine Sessionregel öffentlich kompatibel oder seine Gerätewirkung nachweisbar ist. Alte Container, generierte Klassen und Deployment Descriptors können länger leben als die Teams, die ihre Lücken verstanden.

Heng Lus Running-Code-Prinzip verlangt daher mehr als einen Portscan. Man muss feststellen, welcher Code geladen ist, aus welchen Eingaben er entstand, welche private Zustandsregel er ausführt und welchen Effekt er tatsächlich besitzt.

Quellen