要約

  • 9月29日付のNFSv4作業部会草案第06版は、任意の属性ACL_Choiceの提案番号を87から89に変更した。別の二つの作業中の草案では、ファイルデータのキャッシュ制御に87、ディレクトリエントリーのメタデータ制御に88を用いる。
  • ACLの大きさに関する四つの新しいエラー値も20000–20003から10095–10098に変わった。AclChoiceをサーバーまたはアクセス先のファイルシステムがサポートしない場合、そのエラーを返してはならないという文が追加されたが、この節にはなお合意待ちの印がある。

異なる版で作られた試験用クライアントを比べるなら、最初に確認すべきなのは成功率ではなく、どの版の属性表を読んでいるかだ。9月14日のdraft-ietf-nfsv4-acls-update-05では、ACLの選択情報を伝えるACL_Choiceが87だった。第06版の属性一覧とXDR定数では89になった。変更履歴は、uncacheable_file_dataとuncacheable_dirent_metadataの提案番号を収めるためだと説明する。それぞれの現行草案は87と88を使う。

三つの属性は、似た名称の別形式ではない。ACL_ChoiceはNFSv4.1の再記述で提案される任意のACL関連属性である。一方、残る二つはファイルのデータやディレクトリエントリーのメタデータをクライアントがどうキャッシュするかを扱う。番号の調整は文書間の衝突を避ける作業として重要だが、すでに現場で衝突が起きた証拠ではない。旧値で出荷された製品があるとも、89が最終的に固定されたとも、これらの公開資料だけからは言えない。

第06版にはエラーの扱いでも変化がある。大きすぎるACLを保存できない、あるいは取得できない場合を区別する四つのNFS4ERR_値が、従来案の20000から20003ではなく10095から10098になった。それに加えて、新しい説明はAclChoiceの情報に依存するエラーを返せる条件を狭める。サーバーに属性がない場合だけでなく、アクセスしているファイルシステムで属性が使えない場合も、返してはならないという提案だ。

例えば同一のNFSサーバーが、性質の異なる二つのファイルシステムを公開しているとする。片方でACL_Choiceを読めた経験を、もう片方へ自動的に持ち込むのは危うい。クライアントがエラー番号を名前に変換できても、その操作対象でACLの選択情報が提供されたことにはならない。これは検証手順を説明する仮定であり、既知の障害報告ではない。

Datatracker上で第06版は依然として有効な作業部会Internet-Draft、状態はI-D Existsである。表紙にあるRFC 7530と8881の更新は「承認された場合」に限る。本文は将来の作業部会ラストコールに向けた作業を挙げ、エラー節には合意が必要との注記も残す。したがって草案内の強い規範語を、現行RFCの確定した要求として読み替えてはならない。

出典