要約

  • RFC 9984はUDP client/serverの再利用可能なYANG groupingを定めるが、protocolから取得できるconfig false nodeを一つも定義しない。これは運用inventoryではない。
  • hostnameには解決結果、local port 0にはOSが選んだ実port、wildcard addressには実際のlistenerという別の証跡が必要である。
  • Kent WatsenはAlex Huang-Feng、Pierre Francoisとの共同著者である。共通層を薄く保ちながら、実装側がschema、意図、socket、traffic、application outcomeを別々に結合することが重要だ。

ツリーには枝があるのに、待受点がない

監査担当者がYANG treeを開く。local-bindが一件あり、addressもportも型に合い、commitも成功している。そこで「listenerあり」と記録する。

しかし、その画面が示したのは、processに何をさせたいかである。portが既に使われていればbind()は失敗する。addressが別のnetwork namespaceにあればprocessから見えない。いったんbindしたprocessが終了しても、設定treeは残る。

RFC 9984はこの差を隠していない。文書はNMDA準拠を示した直後、protocol-accessibleなconfig false nodeを定義しないと明記する。つまり、socketの稼働状態を語るためのnodeは、このgroupingからは出てこない。

groupingは配置前の部品である

2026年6月にStandards Trackとして公開されたRFC 9984は、ietf-udp-clientとietf-udp-serverを提供する。目的は、上位protocolやapplication modelが同じendpoint表現を再利用できるようにすることだ。

RFC 7950によれば、groupingは再利用可能なschema nodeの集合だが、data definition statementではなく、単独ではschema treeにnodeを作らない。別moduleのusesが初めてnodeをinstantiationし、その場でrefineやaugmentも行える。

したがって、検証には二段階がある。artifactの段階ではmodule revision、namespace、IANA登録、file hashを確認する。具体化の段階ではconsuming module、usesの場所、feature、refinement、augmentation、schema fingerprintを確認する。

IANAのYANG Module Names registryは、2026年6月15日版の二つのmodule file、prefix、namespaceを記録する。これは共通部品の同一性を保証する座標であり、deviceが読み込んだことやserviceがsocketを作ったことの証明ではない。

hostnameはまだpeerではない

client groupingではremote-addressが必須だが、IPv4、IPv6、hostnameのいずれも許される。hostnameならresolverがaddressを選ぶ。結果はview、cache、policy、時刻によって変わり得る。

RFC 9984は、local addressも指定される場合、解決後のaddress familyが通常は整合すべきだとする。しかし、選択address、resolver、解決時刻、期限を格納するleafはない。これは一回解決、定期更新、複数address選択などを一つのgroupingに押し込まないための余白である。

その余白を埋めるのは運用証跡だ。configured hostnameをeffective peer tupleと表示してはいけない。DNSが変わった後、current answerだけを保存しても、既存socketがどのaddressを使ったかは分からない。

remote-portにもdefaultとmandatoryがない。well-known portを持つapplicationはconsuming moduleでdefaultをrefineし、必須のapplicationはmandatoryにする。base groupingだけではdestination tupleが完成しない場合がある。

port 0は数字ではなく委任である

local-binding featureを使うclientでは、local-portのdefaultは0である。OSが利用可能な任意のportを選べるという意味だ。設定のゼロと、packetに現れる実portは別の値である。

再起動のたびに実portが変わっても、意図は変わっていない。反対に、設定だけを保存した監査記録から過去の実portを復元することはできない。必要なのは、configured valueとeffective valueを同じinstance IDと時刻で結ぶreceiptである。

server groupingは一件以上のlocal-bindを持ち、IPv4/IPv6を併記できる。wildcard addressも許す。wildcardは「利用可能なaddressにbindする」というpolicyであって、実interface一覧ではない。container、namespace、address変更、dual-stack behaviorが実際の露出面を決める。

schema validationは重要だが、その成功は入力が型とconstraintに従うことを示すだけである。kernelの受理、file descriptorの保持、packet到着、applicationの受理は別のeventだ。

NMDAが意図と使用中を分ける

Kent Watsenが五人の著者の一人であるRFC 8342は、設定値とdeviceが実際に使用する値を明確に分ける。<intended>は変換後にsystemが適用しようとするconfigurationである。applied configurationは現在使われている部分、system stateは一時的なruntime情報、<operational>はその二つを合わせたものだ。

clientは<intended>と<operational>内のconfig true部分を比較し、どれだけ適用されたかを調べられる。software、hardware、protocol interaction、resource不足、変換、時間差が不一致を生む。connectionやfile handleの解放中にはremnant configurationも残り得る。

RFC 9984はUDP socket用のoperational leafを提供しない。consuming modelが追加してもよいし、実装が別telemetryを使ってもよい。共通形式を強制しないことと、証拠が不要であることは同義ではない。

addressとportはprivacy情報にもなり得る。RFC 9984は再利用側にsecurity considerationを求める。したがってeffective tupleの収集にはaccess control、短いretention、payload非保存などの制限が必要だ。秘密にすべき事実を守ることと、存在しないhealthを表示することは別問題である。

一人の発明家ではなく、境界を守る共同作業

2026年9月2日に取得したIETF Datatrackerのpublic profileは、Kent Watsenをnetwork management/securityのexpertと説明し、当時のchair/reviewer roleと21件のRFCを示す。RFC 8040、8342、9984も含まれる。roleと件数は取得時点の情報である。

RFC 9984はAlex Huang-Feng、Pierre Francois、Kent Watsenの共同著作だ。module内contactはHuang-FengとFrancoisを記し、acknowledgementsにはさらに多くのreviewerがいる。WatsenをYANG全体の所有者、唯一の発明者、特定製品のoperatorとする根拠はない。

人物として重要なのは、管理技術の長い文脈で「モデルが知ること」と「実装だけが知ること」の線を保っている点だ。RESTCONFが構造化accessを、NMDAがdatastoreの意味を、RFC 9984が再利用部品を提供する。どの層もkernelの証言を先取りしない。

Heng LuのRunning-Code Primacyに従えば、documentは実行によって現実性を得る。Minimum Initial Specificationに従えば、共通層にはinteroperabilityに必要な最小限だけを置く。resolver policy、port選択、process監視、traffic評価、application successはlocal decisionのままでよい。ただし、各decisionには検証可能なreceiptが必要だ。

一つの「稼働中」を六つに分解する

artifact receiptはrevision、namespace、IANA reference、hashを保存する。instantiation receiptはconsuming module、uses、feature、refine、augmentを保存する。

intent receiptはactor、change、transformation、時刻、<intended> snapshotを保存する。runtime receiptはservice instance、resolution、effective local/remote tuple、bind result、作成・終了時刻を保存する。

traffic receiptはmeasurement window、packet/byte count、最初と最後の観測、drop、socket errorを保存する。application receiptはpeer identity、handshake、valid response、transaction acceptanceを定義する。

この分解なら、「設定済みだが未適用」「bind済みだが無通信」「packetありだが認証失敗」「一部addressだけ利用可能」と表現できる。設定を運用事実に昇格させる必要はない。

情報源