Zusammenfassung

  • Die Bangladesh Telecommunication Regulatory Commission und die ISP Association of Bangladesh führen Planet Information Technology Solution Limited als ISP in Dhaka.[8][9] APNIC verbindet die Organisation mit dem aktiven AS136903, der IPv4-Zuteilung 103.98.106.0/23 und der IPv6-Zuteilung 2001:df1:1780::/48.[10][11][13][14] Diese Register bestimmen Identität und Zuständigkeit, nicht die Qualität eines Dienstes.
  • RIPE NCC beobachtete zum Abfragezeitpunkt die Routen 103.98.107.0/24 und 2001:df1:1780::/48 mit Ursprung AS136903.[15][16] Das ist eine begrenzte BGP-Sammlersicht. Sie misst weder Verfügbarkeit, Kapazität, Latenz noch die Erfahrung aller Kunden.
  • In der abgefragten öffentlichen Ansicht erschien AS137491 als einziger Nachbar.[17] Daraus folgt nicht, dass Planet nur einen Lieferanten, nur einen physischen Weg oder keine privaten beziehungsweise nicht bevorzugten Ersatzverbindungen hat. Die Beobachtung macht Vielfalt zu einer Prüfungsfrage.
  • Beide beobachteten Routen waren im RIPE-NCC-RPKI-Validator valid.[18][19] Das bestätigt eine zur Route passende Ursprungsautorisierung zum Prüfzeitpunkt. Es garantiert weder den gesamten Pfad noch Filterung, Sicherheit, Betriebszeit oder Vertragserfüllung.
  • Die First-Party-Seiten beschreiben Privat- und Geschäftszugang, Glasfaser, dedizierte Bandbreite, statische Adressen, VPN-Unterstützung, BDIX/CDN und Serviceziele.[1]-[7] Das sind veröffentlichte Fähigkeiten und Zusagen. Der eingefrorene Belegsatz enthält keine unabhängige Messreihe zu Durchsatz, Verlust, Latenz, Verfügbarkeit, Wiederherstellung oder Kundenergebnis.
  • Die aktuelle Domain planet-itsolutions.com funktionierte in der Beobachtung. Die historische, im Verzeichnis erhaltene Domain antwortete dagegen mit NXDOMAIN. Dieses Signal zeigt Synchronisationsaufwand für die öffentliche Identität; es belegt weder einen Dienstausfall noch Dauer, Ursache oder Kundenwirkung.
  • Der nachhaltige Aufwand liegt in Register- und Routenaufsicht, ROA-Integration, IPv4-/IPv6-Parität, DNS- und Mailpflege, Abuse-Kontakten, Lieferantenkoordination, Ausnahmebehandlung, Nachweisen und Portabilität.

Ein Verzeichnisobjekt, mehrere öffentliche Namensformen

Das BTW-Verzeichnis bindet den Artikel an Md. Abdus Salam T/A Planet Information Technology Solution Ltd. Öffentliche Seiten verwenden häufiger Planet Information Technology Solution Ltd. oder Planet Information Technology Solution Limited. Diese Schreibweisen dürfen nicht aus Bequemlichkeit als unterschiedliche Unternehmen oder als automatisch identische Rechtsträger behandelt werden. Die Verbindung muss über Kennungen, Adressen, Rollen und voneinander unabhängige Dokumente hergestellt werden.

Der ISPAB-Eintrag liefert eine erste Brücke. Er nennt Planet unter der Mitgliedsnummer G-351, führt eine divisional gültige ISP-Lizenz, eine Adresse in Dhaka und die aktuelle Website.[8] Eine BTRC-Liste vom 23. Dezember 2024 führt Planet in Zeile 127 mit der Lizenz 14.32.0000.702.45.591.24.292.[9] APNIC bezeichnet AS136903 als PITSL-AS-AP und verknüpft es mit ORG-PITS1-AP.[10][11] Diese drei Belegfamilien laufen auf dasselbe Verzeichnisunternehmen zu.

Die Übereinstimmung hat Grenzen. BTRC dokumentiert einen regulatorischen Stand zu einem bestimmten Datum. ISPAB führt eine Verbandsbeziehung. APNIC verwaltet Nummernressourcen und Kontakte. Keine dieser Stellen misst jede Leitung, bestätigt jeden Vertrag oder zertifiziert jede Websiteaussage. Eine belastbare Analyse bewahrt daher Funktion, Datum und Geltungsbereich jeder Quelle.

Die öffentliche Kontrollfläche von Planet umfasst ASN, IPv4- und IPv6-Ressourcen, BGP-Ankündigungen, ROA, administrative, technische und Abuse-Kontakte, Domain, Nameserver, Mail, Website, Angebote und Supportwege. Diese Elemente können auseinanderlaufen. Eine Route kann sichtbar bleiben, obwohl eine Rollenadresse veraltet ist. Eine neue Website kann funktionieren, während ein altes Verzeichnisfeld noch auf eine aufgegebene Domain zeigt. Kontinuität entsteht aus dem Abgleich dieser Ebenen.

Die Quellen beschreiben kein eigenes KI-Modell von Planet. Es gibt keine belastbare Aussage zu Trainingsverfahren, Modellleistung, Benchmark oder kundenseitigem KI-Einsatz. Die beobachtbare Fähigkeit ist die eines Netzbetreibers. Produktzuverlässigkeit verlangt wiederholte Messung. Ein Kundenproduktionsergebnis verlangt zurechenbare Kundenevidenz. Diese drei Ebenen zusammenzuziehen, würde eine glatte, aber unzutreffende Geschichte erzeugen.

APNIC als operatives Hauptbuch

Das RDAP-Objekt für AS136903 ist aktiv und verknüpft die Kennung mit Planet.[10] Das Objekt ORG-PITS1-AP hält den öffentlichen Organisationsnamen und Rollenbeziehungen fest.[11] IRT-PITSL-BD stellt einen öffentlichen Weg für Abuse-Meldungen und Validierungsdaten von Rollenpostfächern bereit.[12] Die Trennung ist wichtig: Eine Person, die ein Konto verwaltet, muss nicht dieselbe sein, die eine Route schaltet oder einen Vorfall behandelt.

Der Status active besagt nicht, dass alle Dienste gesund sind. Die Validierung eines Postfachs misst keine Antwortzeit und keine Befugnis zur Reparatur. Das Register wirkt als Hauptbuch: Es hält Eindeutigkeit, Delegation, Rollen und Historie fest. Es leitet keine Pakete weiter und sieht die Anwendung des Kunden nicht. Rollen müssen deshalb getestet und mit Wiederherstellungswegen verbunden werden, die Personalwechsel überstehen.

APNIC führt 103.98.106.0/23 als aktive IPv4-Zuteilung.[13] Sie umfasst zwei /24. Die beobachtete BGP-Sicht zeigte 103.98.107.0/24, also einen Teil dieser Zuteilung, als Route von AS136903.[15] Register und Route sind miteinander vereinbar, beantworten aber verschiedene Fragen. Das Register beschreibt delegierte Autorität; BGP beschreibt den von Sammlern gesehenen Ausführungszustand. Über die Nutzung jeder Adresse oder den Zustand des anderen /24 lässt sich daraus nichts Sicheres ableiten.

Auch 2001:df1:1780::/48 ist als aktive IPv6-Zuteilung registriert.[14] Derselbe Bereich erschien in BGP.[15][16] Das ist ein positives Signal für Dual-Stack-Betrieb. Es beweist nicht, dass jeder Kunde IPv6 erhält, jede Anwendung funktionale Parität besitzt oder Support und Monitoring beide Protokolle gleich gut behandeln.

Die eigentlichen Kosten entstehen im Lebenszyklus. APNIC-Konto, berechtigte Personen, Wiederherstellung, Rollenadressen, Präfixinventar, Filter, ROA, Reverse DNS und Kundenzuordnungen müssen gepflegt werden. Portabilität ist erst dann real, wenn diese Elemente in einer bekannten Reihenfolge geändert, überprüft und bei Bedarf zurückgesetzt werden können.

Beim Abuse-Kontakt kommt eine eigene Arbeitskette hinzu. Eine veröffentlichte Adresse öffnet einen Eingang. Danach müssen Meldung und Zeitstempel geprüft, die Adresse dem richtigen Dienst zugeordnet, Unbeteiligte geschützt, Abhilfe koordiniert, Nachweise aufbewahrt und der Fall geschlossen werden. Das Register erleichtert Zurechnung, garantiert aber nicht das Ermittlungsergebnis.

Was die beobachteten Routen tatsächlich zeigen

Die RIPE-NCC-Daten zu angekündigten Präfixen zeigten 103.98.107.0/24 und 2001:df1:1780::/48 im eingefrorenen Abfragefenster.[15] Der Routingstatus meldete Sichtbarkeit bei den abgefragten RIS-Peers für je eine Route beider Protokollfamilien.[16] Damit bleiben die Ressourcen nicht nur Registereinträge, sondern besitzen einen beobachtbaren laufenden Zustand.

Die Ansicht ist weder eine vollständige weltweite Routingtabelle noch eine Verfügbarkeitsmessung. Eine sichtbare Route kann zu einem überlasteten oder nicht antwortenden Dienst führen. Unterschiede zwischen Sammlern können auftreten, ohne dass Nutzer einen Ausfall erleben. Eine Untersuchung muss BGP-Sichtbarkeit, Paketreichweite, DNS-Gesundheit, Zustand des Zugangswegs und Anwendungserreichbarkeit getrennt behandeln.

AS137491 war der einzige in der verwendeten Antwort sichtbare Nachbar.[17] Es wäre falsch, diesen ASN automatisch als einzigen Upstream von Planet zu bezeichnen. Private Pfade, Internet Exchanges, nicht bevorzugte Sicherungswege, Route Server und Verträge werden von einer Sammlersicht nicht vollständig offengelegt. Die defensible Aussage ist enger: Die Vielfalt eines eingekauften Dienstes muss direkt belegt und getestet werden.

Eine Diversitätsprüfung umfasst Faserwege, Leerrohre, Gebäude, Strom, Geräte, Lieferanten, Policies und Umschaltverfahren. Zwei Verträge können dieselbe physische Fehlerdomäne teilen. Umgekehrt kann eine einzige sichtbare Beziehung einen nicht aktiven Ersatzweg verdecken. Die Messung muss zum versprochenen Kundendienst passen.

Die spezifischere IPv4-Ankündigung innerhalb des /23 erzeugt Integrationspflichten. Filter, maxLength des ROA, Sicherheitskontrollen, Monitoring und Dokumentation müssen denselben Plan abbilden. Eine Regel, die nur das Aggregat zulässt, könnte das beabsichtigte /24 verwerfen. Eine zu breite Regel könnte eine nicht geplante spezifische Route akzeptieren.

Dual Stack schafft zwei Kontrollpfade. IPv4 und IPv6 können bei Routing, Firewalls, DNS, Kundengeräten und Anwendungen unterschiedlich scheitern. Ein erfolgreicher IPv4-Test schließt keinen IPv6-Vorfall. Dashboards und Verfahren müssen die betroffene Familie benennen und den Dienst Ende zu Ende überprüfen.

RPKI: Ursprungsautorisierung, keine Dienstgarantie

Der RIPE-NCC-Validator stufte die Kombination aus AS136903 und 103.98.107.0/24 als valid ein.[18] Das ROA über 103.98.106.0/23 erlaubte dabei eine maximale Länge /24. Auch AS136903 mit 2001:df1:1780::/48 war gültig.[19] Diese Ergebnisse reduzieren Unsicherheit darüber, ob die beobachtete Ursprungslänge autorisiert war.

Der Geltungsbereich bleibt eng. Origin Validation authentifiziert nicht den ganzen Pfad, prüft nicht die Filterpraxis aller Netze und misst weder Verschlüsselung noch Verlust, Latenz oder Durchsatz. Eine gültige Route kann einen fehlerhaften Dienst liefern. Eine Route Leak kann sogar den richtigen Ursprung behalten und trotzdem unerwünschte Pfade erzeugen.

Der Änderungszyklus ist der wesentliche Aufwand. Ein neuer Ursprung, ein spezifischeres Präfix oder ein Ersatz-ASN muss mit dem ROA koordiniert werden. Wird die Route vor der Autorisierung aktiviert, kann sie invalid werden. Bleibt maxLength unnötig weit, wächst der autorisierte Bereich. Jeder Wechsel braucht Absicht, Reihenfolge, Prüfpunkt, Rücknahme und einen Verantwortlichen für den Abschluss.

Der Zugang zur RPKI-Verwaltung muss auch im Notfall funktionieren. Ein Ersatzweg ist nicht betriebsbereit, wenn niemand die Autorisierung anpassen kann. Konten, Rollen, Wiederherstellung und Freigaben müssen getestet sein. Validatorergebnisse sollten mit Zeitpunkt, Präfix, Ursprung und relevantem ROA aufbewahrt werden, damit spätere Abweichungen erklärbar bleiben.

Fähigkeit, Produktzuverlässigkeit und Kundenergebnis

Die Planet-Website beschreibt Privat- und Geschäftszugänge, Glasfaser, dedizierte Bandbreite, statische IP-Optionen und VPN-bezogene Unterstützung.[1][2][3] Eine Paketseite nennt Stufen und Eigenschaften wie BDIX, CDN oder ein Contention-Verhältnis.[4] Service- und Kontaktseiten verwenden Ziele für Wiederherstellung, Reaktion, Installation oder Dienstniveau.[3][5][7]

Diese Seiten zeigen, was das Unternehmen nach eigener Aussage liefern kann. Register und sichtbare Routen machen die Netzfähigkeit plausibel und beobachtbar. Sie prüfen nicht die Qualität jedes Produkts. Für Zuverlässigkeit bräuchte man Daten zu Verfügbarkeit, Verlust, Latenz, Jitter, Durchsatz, Auslastung, Reparatur und Support über einen benannten Zeitraum und Dienstumfang.

Der Belegsatz enthält keine unabhängige Serie dieser Art. Eine Zahl auf einer Unternehmensseite bleibt Ziel, Zusage oder Marketingaussage. Für eine belastbare Schlussfolgerung müssen Messpunkt, Ausschlüsse, Zeitraum, Datenverantwortung, Verteilung der Vorfälle und vertraglicher Rechtsbehelf bekannt sein. Ein Monatsmittel kann wiederkehrende Störungen in einem kritischen Zeitfenster verbergen.

Das Kundenergebnis ist nochmals eine andere Ebene. Ein Unternehmen könnte Filialen, Sprache, Zahlungen, Cloudzugriff oder Sicherungen aufrechterhalten wollen. Hier liegt kein zurechenbarer Kundenfall vor. Diese Abwesenheit beweist weder Erfolg noch Misserfolg. Sie verbietet lediglich, ein Zeugnis oder einen Produktionsnutzen zu erfinden.

Abnahmetests sollten vor Dienstbeginn vereinbart werden: IPv4 und IPv6, DNS, Anwendungspfade, Durchsatz zu definierten Zeiten, Umschaltung, Sicherheitsgrenzen, Kontaktwege und Nachweisformat. Für diesen Artikel wurden keine privaten Tests und kein Vergleichstest durchgeführt. Er beschreibt, welche Evidenz nötig wäre, um von sichtbarer Fähigkeit zu einer Zuverlässigkeitsaussage überzugehen.

Kosten einer wechselnden öffentlichen Identität

Die aktuelle Website und ISPAB verwenden planet-itsolutions.com.[1][8] In der Beobachtung löste die Domain auf und veröffentlichte Web-, Nameserver-, Mail- und SPF-Daten. Die im Verzeichnis erhaltene ältere Domain antwortete NXDOMAIN. Das bedeutet, dass der abgefragte Name zu diesem Zeitpunkt im DNS nicht existierte. Es verrät weder Dauer, Ursache noch Auswirkung.

Ein Domainwechsel betrifft Registrar, Delegation, Website, Mail, Zertifikate, Konten, Verträge, Rechnungen, Verzeichnisse, APNIC-Kontakte, Support und Monitoring. Eine neue Website korrigiert keine alte Rollenadresse automatisch. Eine Webweiterleitung leitet keine E-Mail weiter. Ein sauberer Abschluss braucht Inventar, Eigentümer und externe Tests.

Der Verlust einer alten Domain kann Abuse-Meldungen, Lieferanten oder Kunden treffen, die historische Angaben verwenden. Er kann ein Risiko erzeugen, falls ein aufgegebener Name später neu registrierbar wird. Eine Übergangsstrategie muss entscheiden, welche Dienste weiterlaufen, welche Partner benachrichtigt und welche Restverweise geprüft werden.

Auch die aktuelle Domain besitzt mehrere Grenzen: Registrar, Nameserverdelegation, autoritative Zone, Webursprung, MX und SPF. Der Verlust eines Registrar-Kontos kann Korrekturen verhindern, obwohl die Website noch funktioniert. Ein DNS-Fehler kann Web und Mail stören, ohne eine BGP-Route zurückzuziehen. Monitoring muss diese Ebenen unterscheiden.

Aufsicht, Integration, Wartung und Ausnahmebehandlung

Aufsicht

Aufsicht beginnt mit einem kontrollierten Inventar: ASN, Präfixe, erwartete Routen, ROA, Filter, Kontakte, DNS, Mail, Lizenzbeleg, Lieferanten, Zusagen und Kundentests. Jedes Element hat eine eigene Prüffrequenz. Routingänderungen können eine schnelle Warnung erfordern; Kontakte und Dokumente eine regelmäßige Revision. Eine einzige Ampel kann diese Zustände nicht sinnvoll zusammenfassen.

Auch die Belegqualität muss überwacht werden. RIPE RIS beschreibt eine datierte Ansicht. APNIC dokumentiert registrierte Autorität. Eine First-Party-Seite beschreibt eine Zusage. Die BTRC-Liste ist ein datiertes Dokument. Das Team sollte Quelle, Zeitpunkt, Wert und beantwortete Frage festhalten.

Integration

Integration verbindet Inventar mit Routern, ROA, Filtern, Sicherheitskontrollen, Reverse DNS, Monitoring, Tickets und Verträgen. Lieferanten bringen Konten, Eskalationen, Rechnungen und Exitbedingungen ein. Kunden bringen statische Adressen, VPN, Firewalls, Geräte und Anwendungsabhängigkeiten ein. Eine korrekte Änderung auf einer Seite kann eine Annahme auf der anderen brechen.

Verantwortung am Übergabepunkt muss ausdrücklich sein. Wer misst? Wer darf einen Router ändern? Wer besitzt DNS? Wer autorisiert eine Notfallroute? Wer informiert Kunden? Ohne diese Karte können alle beteiligten Teams ihre Teilaufgabe abschließen, während der Gesamtdienst weiter gestört ist.

Wartung

Routen, Filter, ROA, Kontakte, Konten, Zertifikate, DNS, Angebote und Dashboards verändern sich. IPv4 und IPv6 verdoppeln einen Teil der Prüfungen. Aktuelle Identität und historische Domain müssen in Registern und Verzeichnissen abgeglichen werden. Änderungen und Ausnahmen brauchen genug Nachweise, um Absicht, Freigabe, Wirkung und Rückkehr in den akzeptierten Zustand rekonstruieren zu können.

Ausnahmen

Eine Notfallroute kann auf RPKI-Zugriff warten. Eine Abuse-Meldung kann unvollständig sein. Das DNS-Konto kann während einer Migration gesperrt sein. IPv4 kann vor IPv6 zurückkehren. Jede Ausnahme benötigt Klassifizierung, zuständige Autorität, Ablaufzeit, Rücknahme und Abschlussbeleg. Eine vorübergehende Maßnahme ohne Enddatum wird zu einer verborgenen Abhängigkeit.

Zu prüfende Fehlermuster

  1. Veralteter Kontakt: Das APNIC-Objekt ist aktiv, aber Postfach oder Rolle reagieren nicht. Rollen regelmäßig testen und eine Wiederherstellung außerhalb derselben Fehlerdomäne erhalten.
  2. Abweichung zwischen Route und ROA: Ein neuer Ursprung oder eine neue Länge wird ungültig. Absicht, BGP und ROA vor und nach dem Wechsel vergleichen.
  3. Routenrückzug: Ein Sammler sieht IPv4, IPv6 oder beide nicht mehr. Mehrere Ansichten und den Kundendienst prüfen, bevor eine Ursache benannt wird.
  4. Verdeckte Konzentration: Öffentlich ist nur eine Nachbarschaft sichtbar. Lieferanten, Faserwege, Strom und Umschaltung für den gekauften Dienst direkt prüfen.
  5. IPv4-/IPv6-Divergenz: Eine Familie arbeitet, die andere scheitert. Routing, DNS, Firewall und Anwendung je Familie testen.
  6. Verlust der DNS-Autorität: Werte sind noch korrekt, das Konto ist aber nicht wiederherstellbar. Rollen, Mehrfaktorzugang und Export testen.
  7. Historische Domain: Partner verwenden noch einen Namen mit NXDOMAIN. Verweise inventarisieren und Ersatzwege bereitstellen.
  8. Support-Eskalation: Der erste Kontakt antwortet, darf aber keine Reparatur freigeben. Eskalationsrollen, Erreichbarkeit und Stellvertretung nachweisen.
  9. Unbelegte Zusage: Eine Zahl wird als allgemeine Zuverlässigkeit verstanden. Messmethode, Dienstgrenze, Zeitraum und Ausschlüsse verlangen.
  10. Dauerhafte Ausnahme: Eine manuelle Route, ein breites ROA oder eine Ersatzadresse bleibt ohne Eigentümer bestehen. Jede Ausnahme mit Ablauf und Abschlussbeleg versehen.

Beschaffung und Austritt

Ein Käufer sollte die öffentliche Evidenz als Ausgangspunkt verwenden, nicht als Endurteil. Zu prüfen sind Lizenz- und Organisationsidentität, erwartete Präfixe, Ursprung, RPKI, IPv4-/IPv6-Support, Lieferantenvielfalt, physische Wege, DNS- und Mailverantwortung, Monitoring, Incidentverfahren, Messdaten, Eskalation und Exit.

Ein Vertrag sollte Fähigkeit und gemessenen Dienst auseinanderhalten. Statische IP, VPN-Hilfe, BDIX/CDN oder Wiederherstellungsziele brauchen Definitionen. Wer misst, von wo, in welchem Fenster und mit welchem Rechtsbehelf? Eine allgemeine Verfügbarkeitszahl ohne Messgrenze verlagert Interpretationskosten auf den Kunden.

Der Exit ist vor dem Eintritt zu planen. Kundeneigene Adressen, Konfiguration, DNS, Mail, Zertifikate, Konten und Beweise müssen übertragbar sein. Providergebundene Adressen können eine Umnummerierung erzwingen. Ein Domainwechsel braucht Parallelbetrieb und verifizierte Abschaltung. Ein Ersatzweg zählt erst, wenn Autorisierung, Routing, DNS, Sicherheit und Anwendung gemeinsam getestet wurden.

Das belastbare Urteil ist weder Lob noch Ausfallbehauptung. Planet besitzt eine reale, prüfbare Netzoberfläche: AS136903 und die Ressourcen sind aktiv registriert, IPv4 und IPv6 waren sichtbar und die beobachteten Ursprungspaare waren RPKI-gültig. Datierten Institutionen und First-Party-Seiten liefern weitere Zuständigkeits- und Fähigkeitsmerkmale. Diese Fakten belegen keine dauerhafte Zuverlässigkeit und keine Kundenerfolge. Qualität entsteht daraus, wie konsequent registrierte Autorität, laufender Zustand, kommerzielle Verantwortung und Wiederherstellung zusammengeführt werden.

Quellen

  1. First-Party-Startseite von Planet.
  2. First-Party-Unternehmensseite.
  3. First-Party-Diensteseite.
  4. First-Party-Paketseite.
  5. First-Party-Kontaktseite.
  6. First-Party-Seite des Vorsitzenden.
  7. Von Planet veröffentlichte BTRC-Tarifunterlage.
  8. ISPAB-Eintrag für Planet.
  9. BTRC-Liste divisionaler ISP-Lizenzen vom 23. Dezember 2024.
  10. APNIC RDAP für AS136903.
  11. APNIC RDAP für ORG-PITS1-AP.
  12. APNIC RDAP für IRT-PITSL-BD.
  13. APNIC RDAP für 103.98.106.0/23.
  14. APNIC RDAP für 2001:df1:1780::/48.
  15. RIPE-NCC-Liste angekündigter Präfixe.
  16. RIPE-NCC-Routingstatus.
  17. RIPE-NCC-Beobachtung benachbarter ASN.
  18. RPKI-Prüfung für 103.98.107.0/24.
  19. RPKI-Prüfung für 2001:df1:1780::/48.

Bildhinweis: Das Foto einer aufgewickelten Glasfaserleitung und eines Leerrohrs stammt von Rubin Observatory / NSF / AURA und ist über Wikimedia Commons unter CC BY 4.0 verfügbar. Es dient nur als allgemeiner Infrastrukturkontext und zeigt weder Planet noch dessen Netz, Einrichtungen, Personal, Kunden, Vorfälle, Zuverlässigkeit oder Produktionsergebnisse.