要約

  • draft-ietf-asdf-nipc-21 は、SDF のプロトコル非依存な affordance を BLE や Zigbee などの具体的な操作へ対応付け、IP アプリケーションから非 IP の物理機器を扱えるようにする。
  • アクションは非同期で、最初に HTTP 202 と追跡用の場所が返り、その後の状態は IN_PROGRESS または COMPLETED となる。後者は、あらゆる機器に共通する物理的な達成証明として定義されてはいない。
  • 物理作動レシートには、認可、対象とグループ構成、SDF モデルと対応付けの版、接続とトリガーの経路、機器ごとの状態、独立した観測、例外処理と復旧を残すべきである。

一つの緑色表示が答えられないこと

夜間の設備制御では、「完了」という表示は強い安心感を生む。アプリケーションが換気装置を動かすよう要求し、ゲートウェイが短距離無線へ命令を送り、アクションの追跡状態を閉じた。未処理キューは空になり、画面は緑色になる。

しかし、現場ではファンが回っていても必要な風量に達していないかもしれない。モーターが途中で止まったかもしれない。通信上の応答は得られたが、位置センサーは古い値のままかもしれない。あるいは、すべてが期待どおりに動いているかもしれない。

ここで COMPLETED が誤っているとは限らない。ゲートウェイが管理する処理の終端を正しく表している可能性がある。問題は、運用組織がその状態に「現実世界も目的どおり変化した」という別の意味まで背負わせることである。

NIPC が解こうとする課題は明確だ。多くの照明、センサー、バルブやアクチュエーターは IP を直接使わず、BLE、Zigbee などの運用ネットワークに属する。一方、上位のアプリケーションは、プロパティ、アクション、イベント、トリガー、グループを一貫した方法で扱いたい。アプリケーション層ゲートウェイは、この異質性を共通の操作面へ変換する。

優れた抽象化ほど、どこまでを知っているかを明示しなければならない。

202、完了、後置条件は同じ時刻ではない

NIPC のアクションは非同期である。POST が受け付けられると、HTTP 202 Accepted、アクション・インスタンスを示す Location、次の確認までの Retry-After が返る。RFC 9110 が定める 202 は処理の完了を意味せず、後の段階で実行されない可能性も含む。

クライアントはその後、インスタンスをポーリングする。第 21 版の状態語彙は IN_PROGRESS と COMPLETED の二つである。この単純さは、極めて多様な機器に共通する API として合理的だ。ランプの点灯は照度で確認でき、バルブは位置または流量で確かめられる。モーターの回転と工程上の成果は同一ではない。低機能な機器には、命令の受信より先を独立して報告する能力がない場合もある。

したがって、証拠の時計を三つに分ける必要がある。第一は受理時刻で、どの要求がいつゲートウェイに受け付けられたか。第二は実行時刻で、インスタンスがどの状態に移り、下位プロトコルがどんな応答を返したか。第三は観測時刻で、あらかじめ定めた物理的後置条件を何が確認したかである。

観測できない対象については「独立確認なし」と記録する方が正確だ。実行状態を物理証明へ読み替えるべきではない。

SDF の共通名にも履歴がある

NIPC の操作は SDF グローバル名でプロパティ、アクションまたはイベントを指定する。RFC 9880 の Semantic Definition Format は、機器クラスの能力をプロトコルに依存しない形で表す。ゲートウェイは登録済みのプロトコル・マッピングを使い、その affordance を BLE、Zigbee などの具体的な操作へ変換する。

この分離により、アプリケーションは Zigbee のフレームを組み立てずに「点灯する」という意味を扱える。新しいプロトコル版も、上位 API を変更せずに追加しやすい。

ただし、意味から命令への経路は版管理の対象である。SDF モデルが更新され、マッピングが修正され、ゲートウェイと機器のファームウェアが異なる版を解釈することがある。同じ名前のアクションでも、実際の変換規則が同じとは限らない。

レシートには SDF グローバル名、モデルとマッピングの不変な版またはダイジェスト、選択されたプロトコル、入力値のハッシュ、アクション・インスタンス URI を残す。秘密情報や全ペイロードを保存する必要はない。どの規則で意図が変換されたかを再現できればよい。

グループの成功を平均してはいけない

操作に先立ち、ゲートウェイは一意な UUID と通信に必要な資格情報・信頼材料を含む機器インスタンス情報へアクセスする必要がある。草案は RFC 7644 の SCIM と RFC 9944 の機器スキーマを推奨するが、プロビジョニング自体は NIPC の範囲外に置く。

UUID は制御系で対象を指すために必要である。しかし、現物が交換された時刻や、ある UUID がどの設備に付与されていたかを単独で証明しない。グループ所属も時間とともに変わる。

NIPC のグループ状態は、この違いを隠さない。結果は機器ごとの配列で返り、ある機器は COMPLETED、別の機器は IN_PROGRESS、失敗した機器には RFC 9457 の Problem Details が付く。一つの「グループ完了」へ丸めると、規格が残した異質性を上位画面が捨てることになる。

必要なのは命令時点のメンバー・スナップショットである。各 UUID に実行状態と物理観測を結び、後日の削除や追加で過去の対象が書き換わらないようにする。

接続の使い方は因果関係の一部

下位プロトコルが接続を必要とする場合、ゲートウェイは通常、操作のために暗黙的に接続し、終了後に解放する。明示的な接続管理も可能で、既存の明示接続があるときはそれを変更せず再利用する。

新規接続では発見、認証、サービス解決に失敗しうる。長く維持された接続には古い状態が残りうる。ゲートウェイの再試行によって、アプリケーション上は一度の要求でも、機器には複数回の命令が届く可能性がある。投入、カウント、短時間の駆動など非冪等な動作では、重複は重大な差になる。

そこで業務要求、NIPC インスタンス、接続インスタンス、各プロトコル試行を区別する。暗黙接続か明示接続か、再利用か、何回試したか、各試行を閉じた応答やエラーは何かを残す。再試行を安全策として評価するには、この粒度が欠かせない。

BLE のイベントから Zigbee の動作へ

NIPC のトリガーは、一つの機器またはグループのイベントを別の機器またはグループのアクションへ結ぶ。草案は、BLE 機器のイベントが Zigbee 機器のアクションを起動する例を示す。遠隔アプリケーションを毎回経由せず、ローカルで素早く反応できる点は大きな利点である。

一方、因果関係は複数の管理面へ分かれる。誰かがトリガーを設置し、源となる機器がイベントを出し、ゲートウェイが有効な定義と対象グループを選び、マッピングを解決してアクションを作る。最後に別のセンサーが結果を観測することもある。

最終アクションだけでは、イベントが正当だったか、重複したか、古いトリガーが残っていたかを判別できない。イベントだけでは、当時どの機器が対象に選ばれたか分からない。イベントの識別子またはダイジェスト、トリガー定義の版、設置権限、有効期間、対象スナップショット、生成されたアクションを一続きに残す必要がある。

認可は結果から推測できない

草案は、NIPC が TLS などのトランスポート・セキュリティ上で動作することを要求し、TLS 利用時にはサーバー識別確認を求める。NIPC 自身はペイロード暗号化を提供せず、下位プロトコルまたはトランスポートに委ねる。管理者はアプリケーションを認可し、Provisioning、Control、Data の基本ロールが推奨される。API や affordance 単位への細分化も可能で、Bearer token の寿命は有限でなければならない。

これらは別々の証明である。TLS は通信路を保護し、認可は主体が操作を呼び出せるかを決める。COMPLETED はゲートウェイの実行状態であり、センサーは物理状態を観測する。望ましい結果が偶然得られても、無認可の操作は正当化されない。正しく認可されても、物理的な失敗は消えない。

レシートにはトークンそのものではなく、認可判断への参照、ロール、ポリシー版を残す。期待する後置条件と観測方法は事前に定義する。結果を見てから成功条件を書き換えないことが重要である。

物理作動レシートの最小構成

意図欄には、必要に応じて仮名化した主体、ロール、認可判断、機器またはグループ、メンバー・スナップショット、SDF 名、入力ハッシュ、要求時刻、期待する物理状態を置く。変換欄にはモデル、マッピング、プロトコル、接続コンテキストを置く。

実行欄には HTTP 202 の時刻、アクション・インスタンス、状態遷移、再試行、機器ごとの結果と Problem Details を置く。トリガー起点なら源イベントとルールを結ぶ。観測欄には測定対象、時刻、情報源、鮮度、信頼度、期待との差を記録する。矛盾した観測を上書きしてはならない。

最後に例外の責任者、エスカレーション条件、補償動作、取り消し権限、保持期間、訂正方法を定める。利便用の照明と、産業・医療・安全に関わるアクチュエーターでは必要な証拠強度が異なる。共通の最低線は、因果の接続点を残すことであり、あらゆる生活データを永久保存することではない。

これは運用ガバナンスの提案であり、NIPC の新しい必須フィールドではない。相互運用の仕様を小さく保ちながら、地域ごとの責任を検証可能にできる。

実装一覧を採用証明にしない

調査時点で Datatracker は、2026 年 8 月 11 日更新の第 21 版を、公開に向けて提出された ASDF ワーキンググループの有効な Internet-Draft として示し、想定ステータスを Proposed Standard としていた。まだ RFC ではない。

草案の実装状況節も、掲載情報は寄稿者から提供され未検証であり、IETF の承認を意味せず、利用可能な実装の完全な一覧でもないと明記する。各項目が対応する草案版も同一ではない。

プロトタイプや製品の経験は設計への有用な入力である。だが、それだけで COMPLETED の意味、物理観測、認可運用がすべての現場で統一されたとは言えない。現実に忠実な説明は、実装の存在と、実証された運用結果を分ける。

出典