{ “protocol”: “YANG Notification Messages / MQTT Transport”, “status”: “Internet-Draft (draft-ietf-netconf-notification-messages-24 / draft-ietf-netconf-yang-notifications-mqtt-04)”, “layer”: “Application / Presentation”, “keywords”: [“YANG-Push”, “Message Broker”, “MQTT”, “Telemetry”, “RFC 8639”] } 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
YANG-Pushの進化：draft-ietf-netconf-notification-messages と メッセージブローカー統合
【背景と設計目標】
従来の1対1通信から、メッセージブローカーを介した多対多のパブリッシュ・サブスクライブ型テレメトリへの移行を実現する。
NETCONF/RESTCONF（RFC 6241/8040）による個別管理の限界を突破するため、RFC 8639 (Subscription to YANG Notifications) を拡張し、KafkaやMQTT等のメッセージブローカーとの親和性を高める「共通通知カプセル化」と「ブローカー転送」を定義します。
【通信シーケンスと動作】
メッセージブローカー（例: MQTT）を介したYANG通知の配信シーケンスを以下に示します。パブリッシャー（ネットワーク機器）は直接レシーバーを知る必要がなく、トピックベースで配信を抽象化します。
sequenceDiagram
participant "P as Publisher (Network Device)"
participant "B as Message Broker (MQTT/Kafka)"
participant "R as Receiver (Collector/NMS)"
Note over P, R: Setup phase (Config or Dynamic Subscription)
R ->> B: SUBSCRIBE (Topic: /ietf-notif/interfaces/...)
P ->> B: CONNECT / ESTABLISH
Note over P: Event Triggered or Periodic
P ->> B: PUBLISH (YANG Notification Message)
B -->> P: PUBACK (Quality of Service dependent)
Note over B: Message Routing
B ->> R: FORWARD (YANG Notification Message)
Note over R: Decode Header & Process YANG Payload
【データ構造 / パケットフォーマット】
draft-ietf-netconf-notification-messages で規定される共通メッセージフォーマットの論理構造です。バイナリエンコーディング（CBOR等）またはテキストエンコーディング（JSON/XML）のいずれでも、以下のヘッダー情報を共有します。
+-----------------------------------------------------------------------+ | Common Message Header (Logical Structure) | +-----------------+-------------------+---------------------------------+ | Field Name | Type / Length | Description | +-----------------+-------------------+---------------------------------+ | version | uint8 | Version of the format (e.g. 1) | | message-id | uint32 | Unique ID for tracking/dedup | | observation-time| timestamp | Time event occurred (PTP/NTP) | | subscription-id | uint32 | ID defined in RFC 8639/8641 | | message-priority| uint8 | 0 (Low) to 7 (High) | +-----------------+-------------------+---------------------------------+ | Payload Section | +-----------------------------------------------------------------------+ | encoding | enum | CBOR, JSON, XML, etc. | | data-model-inst | path | YANG path to the notification | | payload-content | opaque | Encoded YANG data | +-----------------------------------------------------------------------+
【技術的な特徴と比較】
従来のNETCONF/RESTCONFベースのPush配信と、新しいメッセージブローカー統合モデルの比較です。
| 特徴項目 | NETCONF-Push (RFC 8641) | Message Broker Push (Draft) |
|---|---|---|
| 接続形態 | P2P (Point-to-Point) | N:M (Broker-mediated) |
| トランスポート | SSH / HTTP/2 (TLS) | MQTT / Kafka / UDP |
| スケーラビリティ | 低（機器毎にSession維持が必要） | 高（ブローカーがファンアウトを担当） |
| 疎結合性 | 密（送信元が宛先IPを保持） | 疎（トピックによる抽象化） |
| オーバーヘッド | 高 (Keep-alive/Persistent) | 低 (MQTT等の軽量ヘッダー) |
HOL Blockingの解消: メッセージブローカー統合により、特定のレシーバーの遅延がパブリッシャー（機器）に直接影響しなくなります。
マルチプロトコル対応: 共通ヘッダーの導入により、トランスポートがMQTTであってもKafkaであっても、中身のYANGデータを共通のロジックで解析可能です。
【セキュリティ考慮事項】
トランスポート層の保護: MQTT統合（draft-ietf-netconf-yang-notifications-mqtt）では、TLS 1.2/1.3の使用を必須（MUST）としており、ブローカーとの相互認証を推奨しています。
認可制御の委譲: NETCONFではNACM（RFC 8341）で制御しますが、ブローカー経由では「どのトピックにPublish/Subscribeできるか」の権限管理をブローカー側のACLと同期させる必要があります。
完全性と機密性: ブローカーが信頼境界の外にある場合、Payloadレベルでの暗号化（Object Security）の検討が必要になるケースがあります。
【まとめと実装への影響】
ネットワークエンジニアおよび開発者は、以下の3点に留意して設計・実装を進める必要があります。
「セッション管理」から「トピック管理」へのマインドセット移行: 機器のIPアドレスを管理するのではなく、どのデータがどのトピック（例:
ietf-notif/status/interface）に流れるかを設計する重要性が増します。エンコーディングの選定（CBOR vs JSON）: 高頻度のテレメトリでは、共通ヘッダーをCBORでバイナリ化することで帯域を節約しつつ、YANGのセマンティクスを維持する構成が主流になります。
既存のコレクタ（受信機）のアップデート: RFC 8639直結のレシーバーは、新しい「Notification Message」の共通ヘッダーを解釈するラッパー層の実装が必要になります。これにより、異機種混在環境でのテレメトリ統合が容易になります。
