要約

  • RFC 9176 の登録は、リンク、エンドポイント名、ベース URI、寿命を RD に記録する操作であって、現在の稼働を測る操作ではない。
  • 登録、検索、到達確認、認証、リソース応答、アプリケーション上の効果は、それぞれ別の時刻と責任者を持つ。

制約の多いネットワークでは、常に直接発見を行えるとは限らない。ノードは眠り、マルチキャストは効率的でないことがある。そのため RFC 9176 は、他のサーバーが持つリソース情報を保存する Resource Directory、すなわち RD を定義する。端点またはコミッショニングツールは情報を登録し、更新し、削除できる。利用者は登録済みリンクを検索できる。この仕組みが返すのは登録情報であり、端点の現在の観測値ではない。

登録には名前、ベース URI、寿命、RD 内の登録リソース位置、リンク、任意の sector と属性が結び付く。RD が返す位置は、作成者が将来の更新や削除に使う安定した識別子である。これは RD 側の記録が作られたことを示す。機器に電源があり、接続され、同じアプリケーションを実行していることまでは示さない。

寿命はこの区別を制度化する。登録はソフト状態であり、定期的に更新されなければならない。寿命が切れた後、RD はその端点について発見検索に応答しないべきである。一方で、遅れて戻る登録者が更新できるよう登録リソースを残してよく、後にガベージコレクションしてよい。期限後に管理用の記録が存在しても、それは端点が生きている、あるいはサービスが回復したという証拠ではない。

検索の結果もリンクの意味に留まる。RFC 9176 は、登録者が提出したリンクをベース URI で解決して返す。それは過去に宣言された参照を読む手掛かりになる。しかし検索者の場所から URI に接続し、経路、トランスポート、資格情報、リソース処理、機器の動作を確認するものではない。形式上正しい URI の先で端点が停止していることも、リソース応答があっても物理的な効果が確認できないこともある。

名前も自動的な本人確認ではない。RFC は、プロトコル、ポート、IP アドレスだけで端点を同定してはならないとする。これらは端点の生存期間中に変わり得るからである。名前や sector の利用を誰に認めるかは具体的なセキュリティ方針の問題であり、登録へのアクセスと検索へのアクセスも分離されるべきだ。リンクを読めることは操作権限ではなく、登録できることは将来の状態の保証でもない。

運用上は、登録要求と応答、RD が返した位置、名前・sector の認可、ベース URI、リンク、寿命、更新履歴を分けて残す。その上で、検索結果には時刻と観測場所を付ける。サービスの現状を主張するなら、到達確認、トランスポートと認証の結果、リソース要求・応答、アプリケーション側の効果を別に取得する。Lu Heng の最小共通面と実行中の観測という考え方は、ここで記録を軽視しないための方法になる。登録は共有面を提供する。運転中の事実は、なお別に確かめる必要がある。

Sources