Zusammenfassung

  • draft-toutain-t2trg-coreconf-m2m-01 projiziert ein kompaktes YANG/SID-Modell in Ontologien, FROST und MCP-Werkzeuge, die eingeschränkte Geräte lesen oder konfigurieren können.
  • Modellvalidierung, SID-Auflösung, geschützter Transport und Protokollerfolg sind begrenzte Quittungen; sie beweisen weder das Mandat des Principals noch die physische Postcondition.
  • Ein belastbarer Nachweis bindet Modellrevision, Projektion, Principal, Policy, Zustimmung, CORECONF-Entscheidung, Request, Commit, Interlock, Actuation und unabhängiges Readback.

Ein Validator kann eine Struktur akzeptieren, ein MCP-Client die passende Funktion auswählen und ein CORECONF-Server den Request erfolgreich verarbeiten. Trotzdem kann der Motor stillstehen. Schema, Autorisierung und Wirklichkeit haben unterschiedliche Prüfer.

Am 2. Oktober 2026 führte der IETF Datatracker Revision 01 von CORECONF for Machine-to-Machine Communication als aktiven individuellen Internet-Draft, aktualisiert am 16. September. Der Text trägt dasselbe Datum, strebt Informational an und läuft am 20. März 2027 aus. Es gibt keinen RFC-Stream, verantwortlichen AD oder Telechat. Der Datatracker erklärt, dass eine individuelle Einreichung weder IETF-Billigung noch einen formalen Stand im Standardsprozess besitzt. Die Diskussion auf der T2TRG-Liste ist keine IRTF-Adoption.

Die angezeigte YANG-Prüfung meldete an diesem Tag 19 Fehler und 8 Warnungen. Dazu gehören fehlende Referenzen für Revisionen, fehlende Beschreibungen, Verstöße gegen die kanonische Reihenfolge sowie ein Hinweis, dass der config false-Bootstrap-Knoten nicht im zugänglichen Baum liegt. Das sind Reifeinformationen zur eingereichten Version, keine Zahl von Sicherheitslücken und kein Bericht über ein fehlgeschlagenes Deployment.

Ein sauberer Bezeichner trägt noch keine aktuelle Identität

Der Entwurf verbindet YANG-Typisierung, CBOR-Kompaktheit, CoAP und Schema Item iDentifiers. Ein Transducer kann Sensor, Aktuator oder beides sein. Das Modell hält Quantity, Timestamp-Quelle, Statistik und Notification-Parameter. SIDs sparen auf knappen Verbindungen Bytes, indem lange Namen durch Zahlen ersetzt werden.

Revision 01 ergänzt SOSA- und SensorThings-Projektionen sowie zwei MCP-Server. coreconf-m2m wickelt Live-CoAP-Aktionen ab; frost-sensorthings liest und verändert historische, relationale Daten. Im Rennes-Beispiel findet der Agent ein Thing, folgt zu Datastreams, erhält Sensor-SID und Precision, liest live und speichert eine Observation.

Die Behauptung, keine gerätespezifische Zwischentranslation zu benötigen, bezeichnet einen echten Vorteil. Der MCP-Server interpretiert dennoch. Er löst Hostname, Endpoint, Transducer-Identität, Instance-SID, Target-SID, Einheit und Precision aus FROST auf. Wer diese Auflösung pflegt, lenkt den Zugriff.

Ein veralteter Endpoint kann einen korrekten Aufruf zum falschen Gerät schicken. Eine wiederverwendete Identität kann einen aktuellen Namen mit alter Hardware verbinden. Falsche Precision erzeugt aus einem gültigen Integer eine plausible falsche Größe. Eine geänderte Category kann einen Sensor als Aktuator exponieren.

Die Projektionsquittung muss deshalb exaktes YANG-Modul und Revision, Features, Deviations, SID-Datei, private Übersetzung, Geräte-/Transducer-Identität, Bootstrap-Generation, Endpoint, Einheit, Precision, Category, Control Type, Methode, Pfad, Target-SID und Version, Herkunft und Alter des FROST-Eintrags festhalten.

Das Control-Objekt beschreibt eine Handlung, keine Delegation

ccm2m:Control macht Operationen sichtbar: read-single, read-stat, Reset, History-Setup, Subscription und instant-write. Das Modell trennt Konfiguration vom Start; Stop hängt am CoAP-Observe-Zustand. Diese Präzision verhindert bereits einige falsche Gleichsetzungen.

Das Control benennt aber keinen berechtigten Principal. Es enthält weder Zweck und Wertebereich noch Wartungsfenster, Human Approval, Retry-Limit, Safety Interlock oder Not-Aus-Autorität.

Der zugrunde liegende CORECONF-Entwurf Revision 21 verlangt, dass der Server unberechtigte Leser und Schreiber verhindert. 4.01 Unauthorized gilt für fehlende Berechtigung auf Data Node, Datastore, RPC, Action oder Event Stream. Die Security Considerations nennen geeignete Authentication und Authorization. CORECONF hat also nicht „keine Autorisierung“; die offene Aufgabe ist deren prüfbare Bindung an den MCP-Aufruf.

Auch MCP 2026-07-28 trennt Discovery und Recht. Die Tool-Menge darf sich mit der pro Request vorgelegten Authorization ändern. Server müssen Inputs validieren, Access Controls und Rate Limits umsetzen und Outputs bereinigen. Clients sollen sensible Operationen bestätigen lassen, Inputs anzeigen, Ergebnisse prüfen und Nutzung protokollieren. Tool Annotations sind ohne vertrauenswürdigen Server nicht vertrauenswürdig.

Der Beleg muss MCP-Server und Tool-Definition-Hash, requesting client, authenticated principal, Credential Audience und Scopes, Policy-Version, Zustimmung, Ziel und Grenzen mit der CORECONF-Entscheidung verbinden. Ein Log mit Toolname und Argumenten beweist keine Vollmacht.

DTLS oder OSCORE schützt nicht vor falscher Betriebsentscheidung

Der ausgewählte Entwurf verlangt DTLS oder OSCORE für CORECONF über CoAP. Das schützt die Übertragung im jeweiligen Profil. Es legt nicht fest, ob eine Pumpe während Wartung hochfahren darf oder welche Drehzahl mechanisch sicher ist.

CORECONF unterscheidet Unauthorized, Not Found, Method Not Allowed und YANG-Constraint-Fehler. Ein 2.xx-Erfolg besagt, dass die Anfrage auf dieser Ebene verarbeitet wurde. Er misst keine Drehzahl, keinen Druck, keine Temperatur und keine Ventilposition.

Das instant-write-Beispiel setzt eine fiktive Pumpe auf 1.500 rpm. Weil die Pumpe im Beispielmodul nicht existiert, trägt ihre Identity das Platzhalter-SID PPPPPP; das strukturelle Quantity-SID ist real. Die sosa:Actuation speichert geschriebenen Wert und Ausgabezeitpunkt. Der Text erklärt ausdrücklich, dass dies ein Befehl und keine Observation ist.

Ein Befehl ist kein Tachometer. Ein späteres Readback braucht eigene Sensoridentität, Calibration, Einheit, Precision, Timestamp-Quelle und Kausalfenster. Liest das Gateway nur den eben beschriebenen Cache, bestätigt es die Absicht.

Die vollständige Leiter trennt Tool Invocation, Intent und Consent, Principal und Authorization, geschützten Request, Application Validation, Commit oder Action Start, lokalen Interlock, physische Ausführung, getrennte Beobachtung, Dauer und Reconciliation/Rollback. Eine Kette darf früh enden; die Oberfläche muss die letzte bestätigte Stufe nennen.

Gemeinsame Notification-Parameter vergrößern den Radius

Step, Precision, Max Samples, Time Period, Encoding, Payload-Limit, Thresholds, Hysteresis, Dampening und Check Interval sind schreibbar und allen Beobachtungen eines Transducers gemeinsam. Änderungen wirken während aktiver Notifications sofort auf alle Clients.

start_history_notify konfiguriert per iPATCH und startet dann FETCH+Observe. Was privat wirkt, kann Cadence, Encoding oder Bestätigung bestehender Streams ändern. active zeigt nur mindestens einen Observer, nicht Identität, Zweck oder Zustimmung.

Ein sicheres Tool muss Shared Scope anzeigen, Vorversion und Werte lesen, eine Precondition oder Conflict Rule anwenden, Before/After speichern und Betroffene identifizieren. Subscribe-Recht ist nicht automatisch Recht zur Rekonfiguration anderer. FROST-Leserecht ist nicht das Recht, die Live-Zuordnung zu bearbeiten.

NON verschiebt Wiederholung und Mehrdeutigkeit

FETCH und iPATCH müssen im Profil Non-Confirmable sein. Das spart ungeeignete CoAP-Retransmissionskosten, übergibt aber Timeout, Retry und Idempotenz an die Anwendung.

Ohne Response bleiben drei Möglichkeiten: Request verloren, Request ausgeführt und Antwort verloren, oder Verarbeitung läuft. Ein Set-Value kann unter Bedingungen wiederholbar sein; eine Action mit Side Effect nicht. Der Beleg braucht Request Identity, Token, Payload Hash, Attempt, Timeout Policy, Duplicate Handling und späteres Readback.

Ein ACK für eine Confirmable Notification belegt Empfang beim CoAP-Peer. Es beweist keine dauerhafte FROST-Ablage, Agentenentscheidung, menschliche Kenntnis oder Beendigung des physischen Zustands.

Zeit und Skalierung entscheiden über die Aussage

Bootstrap kann Reference Epoch, Uptime und Minimal Step liefern; absolute Zeit kann fehlen. Quantity-Zeit kommt vom Source oder Receiver, History-Zeit kann aus Arrival und Step rekonstruiert sein. Ausgabe, Firmware-Annahme, Bewegung und Speicherung sind verschiedene Zeitpunkte.

Der rohe Integer wird erst mit Identity, Unit und Precision zur Größe. Polling über minimal-step kann nur Batterie kosten. Eine Postcondition braucht Modellrevision, Skala, Calibration, Zeitursprung, Clock Quality und Freshness.

Die 19/8-Diagnose gehört ebenfalls nur in die Modellquittung. Sie fordert Reparatur dieser Revision. Ein späterer sauberer Lauf beweist Validator-Konformität, nicht Authorization, Interoperability oder Bewegung.