要約

  • RFC 6020は、登録簿にあるすべてのYANGモジュール名、サブモジュール名、XML名前空間を一意にするよう求めていた。一方、IANAの実務は、同じモジュールの改訂版に同じ名前と名前空間を維持していた。
  • Andy Bierman、Mohamed Boucadair、Qin Wuが著者となったRFC 9890は、一意性を初版に限定し、改訂版には初版の名前と、モジュールの場合は初版のXML名前空間を引き継がせた。
  • 名前の継続は内容の同一性ではない。改訂日、ファイルのハッシュ、importの選択、実装検証、配備と観測は別々の証拠である。

2026年9月1日のIANA YANG Module Names登録簿には、ietf-yang-typesという名前が3回現れていた。ファイルの日付は2010-09-24、2013-07-15、2025-12-22。参照RFCは異なるが、モジュール名とXML名前空間は同じだった。

RFC 6020の旧文を文字どおり読めば、これは規則違反に見える。第14節は、登録簿にあるすべての名前とXML名前空間が一意でなければならないとしていた。しかし3行は、無関係な3者が同じ初期識別子を奪い合った記録ではない。一つのモジュールが改訂された履歴である。

2025年10月に公開されたRFC 9890は、運用を隠すのではなく規則の対象を直した。新しい登録業務を増やしたのではない。初回割当てと改訂を別の事象として記述し直したのである。

文字列の一致だけでは衝突か継続か分からない

初回割当てで既存名と一致すれば衝突である。正規の改訂で同じ名前を使えば継続である。比較処理から見れば同じ一致でも、登録制度としての意味は逆になる。

RFC 9890の新しい境界は四つある。モジュールとサブモジュールの初版名は一意であること。初版モジュールのXML名前空間も一意であること。すべての改訂版は初版の名前を使うこと。モジュール改訂版は初版のXML名前空間も使うこと。

前半は独立した系統による識別子の重複を防ぐ。後半は、同じ系統が編集のたびに別名へ分断されるのを防ぐ。一意性と継続性は対立せず、異なる段階で保護される。

したがって「duplicate」という警告だけでは監査にならない。初版か改訂か、日付、根拠文書、名前、名前空間を一緒に保存する必要がある。この情報を捨てた自動整理は、正しい改訂を削除したり、真の二重割当てを改訂として見逃したりする。

同じ識別子の中で定義は変わる

規則を直した後には反対の誤解が起こり得る。同じ名前と名前空間なら、どの改訂版も同じように使えるという誤解である。RFC 7950は、YANG 1.1の改訂を明確に区別する。

revision文はモジュールの編集履歴を表し、引数には日付を使う。公開された編集変更ごとに、新しい改訂を逆時系列の先頭へ追加することが推奨される。ファイル名も、安定したモジュール名に任意の@revision-dateを組み合わせる形が推奨される。

名前は「どの系統か」を示す。日付は「その系統のどの編集状態か」を示す。前者を維持しても後者は変化する。

importでは違いが実際の選択になる。revision-dateがあれば指定改訂版の定義を使い、存在しない日付はエラーになる。日付がなければ、どの改訂版を使うかは未定義である。同じモジュールの複数改訂版を異なるprefixでimportすることもできる。

共通の名前空間はアップグレード承認ではない。ベンダーがどのファイルを同梱したか、ツールがどの定義を読んだか、運用者が安全に配備したかを示さない。公開識別子を安定させるだけである。

日付は選択を示し、ハッシュは実体を示す

ietf-yang-typesの2010年版はRFC 6021、2013年版はRFC 6991、2025年版はRFC 9911を参照する。名前と名前空間は継続し、日付付きファイルと文書上の根拠は切り替わる。

資産台帳に名前しかなければ3つの編集状態は一つに潰れる。勝手にv1、v2、v3と改名すれば、IANAが割り当てていない識別子を作ることになる。正しい台帳は、正規名と改訂日を別の軸として持つ。

本番証跡には、さらにファイルハッシュ、URL、根拠RFC、パッケージまたはファームウェアの版、parserの版、import関係、検証結果、配備範囲、観測結果が要る。日付は意図した版、ハッシュは正確なbyte列、manifestは配布物、試験は受理結果、telemetryは稼働状態を示す。

同じ日付なのにハッシュが違えば供給・梱包の問題を疑う。同じ改訂版をparserごとに異なる形で解釈すれば実装問題である。検証済みでも本番に出ていなければ、試験環境の証拠を配備済みと表現してはいけない。

登録簿が証明する範囲は小さい方がよい

RFC 9890はYANG Module Namesの割当て手続きにおける権威ある参照となった。同時に、新たな運用・管理要件も、新規または増大したsecurity riskも導入しないと明記した。

これは弱さではなく責任範囲である。IANAは初回名の衝突を防ぎ、日付付き改訂版が既存系統に属すると記録できる。モデルの品質、parserの正しさ、改訂間の互換性、配備判断までは認証しない。

Heng LuのMinimum Initial Specificationは、この境界を説明しやすい。名前と名前空間は全参加者に共通でなければ参照が壊れる。どの改訂版を採用するか、どの製品へ組み込むか、いつ切り替えるか、どのリスクを受け入れるかは、中央登録簿が決める必要はない。

登録された改訂版は利用可能な選択肢であり、全世界への更新命令ではない。共通識別子を維持しながら、将来の判断を各実装者と運用者に残すことができる。

Qin Wuの著者表示は出典であって運用権限ではない

RFC 9890の著者欄には、HuaweiのQin WuがAndy Bierman、Mohamed Boucadairとともに記載されている。公式IETF Datatrackerは同じ公開本人情報に多数のRFCを結び付けている。YANGとネットワーク管理に関する標準化活動の文脈は十分確認できる。

しかし、Qin Wuが規則を所有するわけではない。RFCはIETFの手続きと合意の成果であり、IANAが登録簿を運用し、仕様チームが改訂を書き、製品チームが実装し、ネットワーク運用者が本番採用を決める。

責任の分離は重要である。登録ミスは登録手続きで調べる。parserの不具合は実装で調べる。試験不足の移行は承認と配備の過程で調べる。著者名は文書の来歴を示すが、他者の稼働環境への責任を移さない。

この仕事の価値は狭いからこそ明確である。実務が必要としていた同一性継続を規範文が正しく表現できるようにし、その後の判断までは奪わなかった。

稼働実務は目的に合う時だけ規範を直せる

Running-Code Primacyは「すでに動いているから正しい」という免罪符ではない。広く使われる悪い実装もある。実務が規範を修正できるのは、共同規則が守ろうとした性質を維持する場合である。

改訂版が初版名と名前空間を保つことは、初回割当ての一意性を弱めない。むしろ改訂ごとに偽の新規識別子を作ることを避け、toolと文書の参照を継続させる。

RFC 9890は修正方法も監査可能にした。旧文を示し、IANA実務との不一致を述べ、新文を公開し、対象登録簿を明示した。矛盾を見えない編集作業として処理しなかった。

規格は、限定され検証可能な実務が誤った抽象を示した時に、それを認めて直せる方が強い。古い一文を守るために稼働系の識別子を壊す方が、技術的には不誠実である。

次の改訂後も使える証跡を作る

最初の記録には、モジュールまたはサブモジュール名、モジュール名前空間、割当て文書、登録日、初版であることを保存する。一意性検査はこの層で行う。

改訂記録には同じ識別子を引き継ぎ、改訂日、正確なURL、ハッシュ、根拠RFC、前版を追加する。revision-dateを明示選択したか、選択を未定義のままにしたかも区別する。

software層ではparser、版、import graph、feature、deviation、package、validationを保存する。運用層では承認、staging、本番範囲、error、観測、rollbackを結ぶ。

画面上の動詞も分ける。IANAは「登録した」。RFCは「規定した」。packageは「含んだ」。parserは「受理した」。vendorは「supportした」。operatorは「配備した」。serviceは「継続した」または「失敗した」。一つの緑色表示が次の段階を代弁してはならない。

出典