要約

  • draft-cel-nfsv4-element-registries-00は、操作、コールバック、状態、属性、ACCESS/OPEN値の八つのIANAレジストリを提案し、著者が知る「次の空き番号」に依存する方法を置き換える。
  • RFC 7120の早期割り当ては標準化前の実装に公開座標を与えるが、期限付きの予約であり、機能の承認、実装対応、実行成功を証明しない。

実験に必要な番号と、まだ終わっていない判断

新しいNFSv4操作を試すには数値が要る。RFCになるまで待てば、実装経験を標準化に戻せない。だからといって各チームが「空いて見える値」を取れば、並行する二つの拡張が同じ番号を使う。

早期割り当てはこの空白を埋める。十分に記述され安定した仕様について、早期実装の需要または競合リスクが認められれば、IANAが一時的な値を公開する。通常は一年の期限と日付が記録される。実装は一つの座標で会話でき、他の作業はその座標を避けられる。

しかし予約は評価の結論ではない。第00版のRegistries of Network File System Version 4 Protocol Elementsは2026年9月25日に提出され、2027年3月29日に失効する。Datatracker上では有効な個人Internet-Draftであり、WG採択、文書ストリーム、担当AD、IESG承認はない。文書ヘッダーは承認された場合のStandards TrackとRFC 8178更新を掲げる。現時点ではRFCでも、IANAが提案を実施した証拠でもない。

NFSv4では数値が構造を選ぶ

NFSv4のファイル操作、ロック、セッション、pNFS動作はCOMPOUND内の操作で表現される。nfs_opnum4の値はXDR unionの引数・結果の腕を選ぶ。CB_COMPOUNDには逆方向の操作空間がある。状態コードは結果を表し、属性番号はfattr4のビット位置でもある。ACCESSとOPENの値は要求や応答の動作を変える。

同じ整数は異なるレジストリなら正当になり得る。したがって監査記録にはレジストリ、方向、外側のXDR型、バージョン範囲、参照文書が必要である。同じレジストリで異なる意味が同じ値を取れば、パケットに解決情報はない。受信側は自分のビルドにある表を使うだけだ。

RFC 8178は既存minor versionへのXDR拡張を許し、割り当て済み要素の削除と再利用を禁じる。だが新しい値の取得方法は定めない。第00版は、著者が知っている最大値の次を選ぶ慣行を問題にする。二つの草案が同時に進めば、双方の知識は完全ではない。

RFC 8276は、拡張属性の数値を既知の最新プロトコルとminor versionに照合したと記録した。慎重な手作業であり、試作には有用だった。それでも未知の並行草案に対する公開予約にはならない。

八つの表が分担するもの

提案されるのはOperations、Callback Operations、Status Codes、fattr4 Attributes、ACCESS Flags、OPEN Share Access Flags、OPEN Result Flags、OPEN Delegation Typesである。初期内容は公開済みRFCから集める。

提案が将来公開されれば、各表は対象型の割り当てについて単一の権威になる。新要素の文書はIANA Considerationsで値を求め、登録値からXDR定数を導出する。別の定数を自分で固定してはならない。

方針はStandards Action with Expert Reviewである。Standards Actionは、既存minor versionへの拡張をProposed Standardとして公開するRFC 8178の要件を保つ。Expert Reviewは登録の整合性を確認する。

専門家は正しいレジストリと方向、最低の未割り当て値または当該文書の早期割り当て、名前の一意性、命名規則、XDR定義、Versionsと参照を調べる。機能の価値は判断しない。それはIETF合意の役割である。

この分離により、登録済みという事実が技術的推奨へ膨張しない。IANAは座標、標準は規範意味、ビルドは実装表、サーバーは認可と実行、ストレージとアプリケーションは結果について証拠を持つ。

Temporaryの後にも状態遷移がある

RFC 7120の割り当てには追跡、更新、期限切れ、非推奨化、場合によっては再開放の手順がある。期限切れの値を、現在有効な予約として扱ってはいけない。実装者は値だけでなく状態と日時を保存する必要がある。

第00版は、WG文書が採択後に早期割り当てを求めるべきであり、登録も早期割り当てもない値を使ってはならないとする。ここでの目的は草案を承認済みに見せることではなく、審議中にも衝突しない実験を可能にすることだ。

正式割り当て後は、最低の未割り当て非予約値が使われる。割り当て済み値は要素が全minor versionから撤回されても再利用されない。行は残り、Versionsはnoneになり、撤回文書が参照へ加わる。

残す行は、残るコードのためにある

標準から削除することと、世界中のコードから消えることは同時ではない。古い生成XDR、解析器、テスト、ファームウェア、保存パケットが残り得る。番号を新しい意味に渡せば、古い送信側と新しい受信側が静かに別の構造を想定する。

Versions: noneは現在の規範適用がないことを示すが、送信者がゼロであるとは示さない。4.1+も全ての4.1実装が対応するという意味ではない。RFC 8178では同じminor version内に、異なるオプション拡張集合を持つ有効なvariantが存在できる。

レジストリにないことは、対象値が公開割り当て権威を欠く有力な証拠になる。ただし私的forkや古い仮実装が値を出さない証明ではない。行があることも、実行中バイナリの対応を証明しない。

九段階の証跡

必要なのは、文書版と状態、レジストリ行、割り当て判断と日付、正確なXDR仕様、ソース・生成表・バイナリのfingerprint、端点能力、方向とCOMPOUND文脈を含むwire記録、認識・認可・返却状態・状態変化、最後のストレージとアプリ観測である。

登録はビルドを更新しない。decode成功は権限を与えない。成功応答だけでは永続化を証明できない。移行では、ソース、生成XDR、binding、dissector、fixture、機器を「表・方向・値」で棚卸しし、番号変更前のパケットとbuildを保存しなければならない。

情報源が証明しないもの

固定した十三の情報源は、八つの表、並行作業の競合、早期割り当て、非再利用、専門家の範囲を示す。実際のNFSv4競合、製品欠陥、WG採択、IETF合意、IANA実施、普及率、インシデント、攻撃は示さない。

Lu Hengの観点では、記録の権威は記録が答えられる問いに限定すべきである。レジストリは誰がどの根拠で座標を持つかを答える。動作中の真実は、実装、通信、実行、結果の証跡からしか得られない。

出典