[要約] RFC 9968は、2024年12月に開催された「次期ネットワーク管理運用（NEMOPS）」に関するIABワークショップの報告書です。YANGやNETCONFの開発につながった2002年のワークショップ（RFC 3535）を基盤に、ネットワーク管理技術の進化、実装上の課題や障壁を分析し、IETFおよびIRTFに向けた今後の行動計画や推奨事項をまとめています。
Internet Architecture Board (IAB) W. Hardaker
Request for Comments: 9968
Category: Informational D. Dhody
ISSN: 2070-1721 May 2026
The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024 as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535, identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet's operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Building on RFC 3535, this document provides the report of the follow-up IAB workshop on network management.
「Next Era of Network Management Operations (NEMOPS)」ワークショップは、Internet Architecture Board (IAB) によって、2024 年 12 月 3 日から 5 日まで 3 日間のオンライン会議として開催されました。これは、前回の 2002 年のワークショップに基づいており、その結果は RFC 3535 に文書化されており、IETF へのいくつかの推奨事項とともに、将来のネットワーク管理プロトコル設計および関連データ モデルで考慮すべき 14 のオペレーター要件が特定されています。それ以来、インターネットの運用と技術基盤は大きく変わりました。NEMOPS ワークショップでは、過去の成果をレビューし、これらのテクノロジーの広範な実装を妨げる運用上の障壁について議論しました。このワークショップでは、業界、ネットワーク オペレーター、プロトコル エンジニアが協力して、IETF と IRTF 向けに提案された行動計画とネットワーク管理に関する推奨事項を作成しました。この文書は RFC 3535 に基づいて構築されており、ネットワーク管理に関するフォローアップ IAB ワークショップのレポートを提供します。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
なお、本書はワークショップの議事録です。この報告書に記載されている見解と立場はワークショップ参加者の見解であり、必ずしも IAB の見解と立場を反映しているわけではありません。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書はインターネット アーキテクチャ委員会 (IAB) の成果物であり、IAB が永続的な記録として提供することが価値があると判断した情報を表しています。これは Internet Architecture Board (IAB) のコンセンサスを表しています。IAB によって公開が承認された文書は、どのレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9968.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9968 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。
1. Introduction
1.1. About the Content of This Workshop Report
2. Outreach and Survey
3. Workshop Scope and Discussion
3.1. Session I: Past - Lookback and Analysis
3.1.1. Reflections
3.1.2. Lessons to be Learned
3.1.3. Discussion
3.2. Session II: Present - Identified Problems and Requirements
3.2.1. Operator Feedback
3.2.2. Survey
3.2.3. Discussion
3.3. Session III: Future - Possible Solutions, Recommendations,
and Next Steps
3.3.1. Suggestions on Future Directions
3.3.2. Discussion
3.4. Key Takeaways
3.4.1. Ecosystem Conclusions
3.4.2. Protocol Conclusions
3.4.3. Modeling Conclusions
3.4.4. Standardization Conclusions
3.4.5. Conclusions That Did Not Reach Consensus During the
Takeaways Discussion
4. Not Covered in the Workshop
5. Security Considerations
6. IANA Considerations
7. Informative References
Appendix A. Operator Feedback
A.1. General
A.2. Data Models
Appendix B. Key Recommendations from Operator Feedback
Appendix C. Position Papers
Appendix D. Workshop Participants
Appendix E. Workshop Program Committee
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF).
Internet Architecture Board (IAB) は、インターネットの長期的な問題と戦略を検討し、インターネット アーキテクチャの将来の方向性を提案することを目的としたワークショップを不定期に開催します。IAB のこの長期計画機能は、インターネット エンジニアリング タスク フォース (IETF) のワーキング グループによって実行されている継続的なエンジニアリングの取り組みを補完するものです。
The IAB organized a workshop in 2002 to establish a dialog between network operators and protocol developers and to guide the IETF's work on network management protocols. The outcome of that workshop was documented in the "Overview of the 2002 IAB Network Management Workshop" [RFC3535], which identified 14 operator requirements and 11 recommendations for consideration in future network management protocol design and related data models within the IETF.
IAB は、ネットワーク オペレータとプロトコル開発者との間の対話を確立し、ネットワーク管理プロトコルに関する IETF の作業を指導するために、2002 年にワークショップを開催しました。そのワークショップの結果は、「2002 IAB ネットワーク管理ワークショップの概要」[RFC3535] に文書化されており、IETF 内の将来のネットワーク管理プロトコル設計および関連データ モデルで考慮すべき 14 のオペレーター要件と 11 の推奨事項が特定されています。
Those requirements were instrumental in developing the Network Configuration Protocol (NETCONF) (in the NETCONF Working Group) [RFC6241], the associated YANG data modeling language (in the NETMOD Working Group) [RFC7950], RESTCONF [RFC8040], and most recently the CoAP Management Interface (CORECONF) [CORECONF].
これらの要件は、Network Configuration Protocol (NETCONF) (NETCONF Working Group 内) [RFC6241]、関連する YANG データ モデリング言語 (NETMOD Working Group 内) [RFC7950]、RESTCONF [RFC8040]、そして最近では CoAP Management Interface (CORECONF) [CORECONF] の開発に役立ちました。
The recent NEMOPS IAB workshop focused on the following key tasks:
最近の NEMOPS IAB ワークショップでは、次の主要なタスクに焦点を当てました。
* Review the outcomes and results of the 2002 workshop (current deployments and state of the art) and identify any operational barriers that prevent these technologies from being widely implemented (limitations and hurdles).
* 2002 年のワークショップの成果と結果 (現在の展開と最先端技術) をレビューし、これらのテクノロジの広範な実装を妨げる運用上の障壁 (制限とハードル) を特定します。
* Sketch new requirements for future network management operations in a collaborative manner with the industry, network operators, and protocol engineers.
* 業界、ネットワーク オペレータ、プロトコル エンジニアと協力して、将来のネットワーク管理運用のための新しい要件をスケッチします。
* Develop a plan of action and recommendations for the IETF.
* IETF に対する行動計画と推奨事項を作成します。
This document builds on RFC 3535 with new information gathered from the second IAB workshop on the future of network management. The goal of the second workshop was not to invalidate or replace the first but to extend the discussion with lessons learned since then. Together, both documents capture a snapshot of the evolving needs of network management over time.
この文書は、ネットワーク管理の将来に関する第 2 回 IAB ワークショップから収集された新しい情報を使用して、RFC 3535 に基づいて構築されています。2 回目のワークショップの目標は、1 回目のワークショップを無効にしたり置き換えたりすることではなく、それ以降に学んだ教訓をもとに議論を拡張することでした。両方のドキュメントを合わせると、時間の経過とともに進化するネットワーク管理のニーズのスナップショットが得られます。
This document is a report on the proceedings of the workshop. The views and positions documented in this report are expressed during the workshop by participants and do not necessarily reflect the IAB's views and positions.
本書はワークショップの議事録です。この報告書に記載された見解および立場は、ワークショップ中に参加者によって表明されたものであり、必ずしも IAB の見解および立場を反映するものではありません。
Furthermore, the content of the report comes from presentations given by workshop participants and notes taken during the discussions, without interpretation or validation. Thus, the content of this report follows the flow and dialogue of the workshop but does not necessarily attempt to capture a consensus, unless stated otherwise.
さらに、報告書の内容は、ワークショップ参加者によるプレゼンテーションやディスカッション中に取られたメモに基づくものであり、解釈や検証は行われていません。したがって、この報告書の内容はワークショップの流れと対話に従っていますが、特に明記されていない限り、必ずしもコンセンサスを得ようとするものではありません。
The IAB workshop's Program Committee (PC) planned outreach initiatives to foster discussions and gather interest by engaging with operators at various operational venues (Réseaux IP Européens (RIPE), North American Network Operators Group (NANOG), Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), Latin American and Caribbean Internet Addresses Registry (LACNIC), AutoConn, etc.) and conducting information-/requirement-gathering sessions. Participants were encouraged to submit "position papers" or "expressions of interest" to join the workshop. Additionally, a [SURVEY] was conducted to collect valuable insights to inform the workshop.
IAB ワークショップのプログラム委員会 (PC) は、さまざまな運営会場 (Réseaux IP Européens (RIPE)、North American Network Operators Group (NANOG)、Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT)、Latin American and Caribbean Internet Addresses Registry (LACNIC)、AutoConn など) のオペレーターと関わり、情報/要件収集セッションを実施することで、議論を促進し関心を集めるためのアウトリーチ活動を計画しました。参加者はワークショップに参加するために「意見書」または「関心表明」を提出することが奨励されました。さらに、ワークショップに情報を提供するための貴重な洞察を収集するために [アンケート] が実施されました。
After the workshop, some PC members continued to engage with network operators at operational venues to facilitate information sharing and gather their feedback on the workshop, thereby helping to shape the next steps and outcomes.
ワークショップ終了後も、一部の PC メンバーは、情報共有を促進し、ワークショップに関するフィードバックを収集するために、運用会場でネットワーク オペレーターとの関わりを続け、それによって次のステップと成果の形成に役立ちました。
The workshop was organized across three days, with all participants contributing to one discussion per day. The workshop was organized around three topic areas: "Session I: Past - Lookback and Analysis" (Section 3.1), "Session II: Present - Identified Problems and Requirements" (Section 3.2), and "Session III: Future - Possible Solutions, Recommendations, and Next Steps" (Section 3.3). The program committee organized the paper submissions to fit these three main themes in order to drive discussion during each of the slots. During each discussion, the papers were presented sequentially, and an open discussion was held afterwards. On the last day, an additional discussion took place on the key takeaways from the workshop and possible next steps (Section 3.4).
ワークショップは 3 日間にわたって開催され、参加者全員が 1 日あたり 1 つのディスカッションに参加しました。このワークショップは、「セッション I: 過去 - 振り返りと分析」(セクション 3.1)、「セッション II: 現在 - 特定された問題と要件」(セクション 3.2)、「セッション III: 将来 - 考えられる解決策、推奨事項、次のステップ」(セクション 3.3) の 3 つのトピック領域を中心に構成されました。プログラム委員会は、各枠での議論を促進するために、これら 3 つの主要テーマに合わせて提出論文を整理しました。各議論では論文が順次発表され、その後自由討議が行われました。最終日には、ワークショップからの重要なポイントと考えられる次のステップについて追加の議論が行われました (セクション 3.4)。
The workshop agenda for each day can be viewed at "Past (Session 1)" <https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-01-sessa/>, "Present (Session II)" <https://datatracker.ietf.org/doc/ agenda-interim-2024-nemopsws-02-sessa/>, and "Future (Session III)" <https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-03-sessa/>. All workshop papers and slides can be viewed at "materials" <https://datatracker.ietf.org/group/nemopsws/materials/>.
各日のワークショップの議題は、「過去 (セッション 1)」<https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-01-sessa/>、「現在 (セッション II)」<https://datatracker.ietf.org/doc/ agenda-interim-2024-nemopsws-02-sessa/> で確認できます。「将来 (セッション III)」<https://datatracker.ietf.org/doc/agenda-interim-2024-nemopsws-03-sessa/>。すべてのワークショップの文書とスライドは、「資料」<https://datatracker.ietf.org/group/nemopsws/materials/> でご覧いただけます。
The first day of the workshop focused on reflecting on the past by reviewing the evolution of network management since the 2002 workshop, analyzing both the successes and the challenges encountered along the way. The presentations covered a range of topics, including reflections on the history of network management, lessons learned from widely used tools, practices in constrained networks, and the need to reconsider how network management models and protocols are standardized within the IETF.
ワークショップの初日は、2002 年のワークショップ以来のネットワーク管理の進化を振り返り、その過程で遭遇した成功と課題の両方を分析することで、過去を振り返ることに焦点を当てました。プレゼンテーションでは、ネットワーク管理の歴史の考察、広く使用されているツールから学んだ教訓、制約のあるネットワークでの実践、IETF 内でネットワーク管理モデルとプロトコルがどのように標準化されているかを再検討する必要性など、さまざまなトピックが取り上げられました。
The workshop began by reflecting on the IAB's role in shaping the evolution of network management away from Command-Line Interface (CLI), SNMP, and MIB technologies, focusing on the context and key outcomes of the previous workshop, an assessment of the current state of network management as a whole, and an acknowledgement of some regrets in how network management technologies developed in the last two decades (such as XML as the data representation format). [SCHONWALDER] emphasized the need to shift the focus from device-level configuration to network and service-level configuration. Key properties highlighted for effective network and service configurations included being Composable (assembled out of modular configurations), Declarative (define state while systems themselves determine how to implement those goals), Reproducible (reliably and consistently recreated), and Verifiable (asserting that the correct changes have been applied).
このワークショップは、コマンドライン インターフェイス (CLI)、SNMP、および MIB テクノロジからネットワーク管理の進化を形成する上での IAB の役割を振り返ることから始まり、前回のワークショップの背景と主要な成果、ネットワーク管理全体の現状の評価、過去 20 年間のネットワーク管理テクノロジの発展方法 (データ表現形式としての XML など) におけるいくつかの後悔の認識に焦点を当てました。[SCHONWALDER] は、デバイスレベルの構成からネットワークおよびサービスレベルの構成に焦点を移す必要性を強調した。効果的なネットワークおよびサービス構成で強調されている主要なプロパティには、構成可能 (モジュール構成から組み立てられる)、宣言的 (システム自体がそれらの目標を実装する方法を決定しながら状態を定義する)、再現可能 (確実かつ一貫して再作成される)、および検証可能 (正しい変更が適用されたことを保証する) が含まれます。
An operator's perspective highlighted that the recommendations of [RFC3535] (which led to the development of YANG and NETCONF) have been successful in addressing device configuration in many, but not all, environments. In certain areas, the advancements in semantics and protocols for streaming telemetry have even surpassed the original scope of [RFC3535]. [FARRER] cautioned against making changes that could disrupt the ecosystem. The presentation emphasized the need to prioritize service modeling in the IETF and addressed the challenges of mapping to the Business Support Systems (BSS) domain. It also stressed the importance of including the operational state in service models to enable closed-loop automation for end-to-end (E2E) services. Revisiting [RFC8309], which asserts that the operational state of a service is not part of a customer service model but can be achieved through extensions, was suggested. Additionally, the lack of open-source Network Management System (NMS) implementations, tools, and device model implementations was identified as a significant barrier to advancing standardization efforts. The IETF could play a key role in fostering and enabling collaborations to address these challenges. While the IETF does not itself build tools, it was suggested that having a translation tool that runs outside the network device to map IETF device models to vendor-specific ones would be beneficial.
オペレータの観点からは、[RFC3535] の推奨事項 (YANG と NETCONF の開発につながった) が、すべてではないが多くの環境でデバイス構成に対処することに成功していることが強調されました。特定の領域では、ストリーミング テレメトリのセマンティクスとプロトコルの進歩により、[RFC3535] の本来の範囲を超えています。[FARRER] は、エコシステムを破壊する可能性のある変更を加えないよう警告しました。このプレゼンテーションでは、IETF におけるサービス モデリングを優先する必要性が強調され、ビジネス サポート システム (BSS) ドメインへのマッピングの課題が取り上げられました。また、エンドツーエンド（E2E）サービスのクローズドループ自動化を可能にするために、サービスモデルに運用状態を含めることの重要性も強調した。サービスの運用状態は顧客サービス モデルの一部ではなく、拡張機能を通じて実現できると主張する [RFC8309] を再検討することが提案されました。さらに、オープンソースのネットワーク管理システム (NMS) の実装、ツール、デバイス モデルの実装が欠如していることが、標準化の取り組みを進める上での大きな障壁であることが判明しました。IETF は、これらの課題に対処するためのコラボレーションを促進し、可能にする上で重要な役割を果たす可能性があります。IETF 自体はツールを構築していませんが、IETF デバイス モデルをベンダー固有のモデルにマッピングするために、ネットワーク デバイスの外部で実行される変換ツールがあると有益であることが示唆されました。
[HARDAKER] emphasized that the success of Net-SNMP [NET-SNMP] was driven by empowering users through simplicity, stressing that the focus should remain on ensuring ease of use and adaptability of the protocols. Emphasis was placed on the two distinct audiences for standardized network management protocols: toolkit vendors and system operators. Their requirements for protocol simplicity differ, and it is essential to address the needs of both to ensure success. [BORMANN] presented an overview of the CORECONF architecture, showcasing how model-driven network management techniques can be applied to manage Internet of Things (IoT) devices (which is different from other network management scenarios), with a focus on the unique characteristics of constrained nodes. Some participants noted that the binary encoding of Concise Binary Object Representation (CBOR) has applications that extend beyond the IoT networks.
[HARDAKER] は、Net-SNMP [NET-SNMP] の成功は、シンプルさによってユーザーに権限を与えることによってもたらされたと強調し、プロトコルの使いやすさと適応性を確保することに焦点を当て続ける必要があると強調しました。標準化されたネットワーク管理プロトコルを対象とする 2 つの異なる対象者、つまりツールキット ベンダーとシステム オペレータに重点が置かれました。プロトコルの単純さに対する要件は異なり、確実に成功するには両方のニーズに対処することが不可欠です。[BORMANN] は、CORECONF アーキテクチャの概要を提示し、制約されたノードの固有の特性に焦点を当てながら、モデル駆動型のネットワーク管理技術をモノのインターネット (IoT) デバイスの管理にどのように適用できるかを示しました (これは他のネットワーク管理シナリオとは異なります)。一部の参加者は、Concise Binary Object Representation (CBOR) のバイナリ エンコーディングには IoT ネットワークを超えて応用できると指摘しました。
Drawing from the experience of OpenConfig [OPENCONFIG], [SHAKIR] emphasized that protocol definition and data models cannot be done in isolation; instead, they must integrate lessons learned from implementation and large-scale deployment. Thus, highlighting the importance of enabling quick iterations, shipping rapidly, embracing open source, readily available tools, adopting systems thinking driven by business outcomes, and reusing existing technologies rather than developing solutions exclusively for operator network management. A call was made for the IETF to rethink the approach to standardize data models and the associated network management protocols under this guidance.
OpenConfig [OPENCONFIG] の経験に基づいて、[SHAKIR] は、プロトコル定義とデータ モデルは分離して実行できないことを強調しました。代わりに、実装と大規模な展開から学んだ教訓を統合する必要があります。したがって、事業者ネットワーク管理専用のソリューションを開発するのではなく、迅速なイテレーションの実現、迅速な出荷、オープンソースのすぐに利用できるツールの採用、ビジネス成果に基づいたシステム思考の採用、既存テクノロジーの再利用の重要性を強調しています。このガイダンスに基づいて、データ モデルと関連するネットワーク管理プロトコルを標準化するアプローチを再考するよう IETF に求められました。
The Session I open discussion highlighted the divergence between vendor implementations of YANG models and what is accessible via the models, particularly when compared to CLI. Questions were raised about how to incorporate fast iteration and rapid changes within the established IETF process and culture, especially in contrast to the approach used by OpenConfig. Common challenges identified included a lack of tooling, performance issues at scale, the steep learning curve for network management protocols/models/tools, initial difficulty in moving away from CLI, and the backward compatibility of models (versioning). Some participants suggested that the IETF should focus on system-level APIs that address specific problems. Additionally, the lack of simple tools for smaller networks operating under tight timelines and budgets was emphasized. A key question raised was whether the proliferation of protocols and languages complicates adoption and if converging on a single approach would improve adoption. The existence of multiple schemas and protocols beyond NETCONF, such as the BGP Monitoring Protocol (BMP) and IP Flow Information Export (IPFIX), to address network management challenges beyond configuration is an established reality. One conclusion was that a mechanism was needed to interconnect and harmonize these schemas to provide a cohesive and comprehensive understanding of the data.
セッション I の開始ディスカッションでは、特に CLI と比較した場合に、YANG モデルのベンダー実装とモデル経由でアクセスできるものとの間の相違が強調されました。特に OpenConfig で使用されているアプローチとは対照的に、確立された IETF のプロセスと文化内に高速の反復と急速な変更をどのように組み込むかについて疑問が生じました。特定された一般的な課題には、ツールの不足、大規模なパフォーマンスの問題、ネットワーク管理プロトコル/モデル/ツールの学習曲線が急峻であること、CLI から移行する際の最初の難しさ、モデルの下位互換性 (バージョン管理) などが含まれます。一部の参加者は、IETF は特定の問題に対処するシステムレベルの API に焦点を当てるべきだと提案しました。さらに、厳しいスケジュールと予算の下で運用されている小規模ネットワーク向けのシンプルなツールが不足していることも強調されました。提起された重要な疑問は、プロトコルと言語の急増により導入が複雑になるのか、また単一のアプローチに収束することで導入が改善されるのかということでした。構成を超えたネットワーク管理の課題に対処するために、BGP モニタリング プロトコル (BMP) や IP フロー情報エクスポート (IPFIX) など、NETCONF を超えた複数のスキーマとプロトコルが存在することは、確立された現実です。結論の 1 つは、データの一貫した包括的な理解を提供するために、これらのスキーマを相互接続して調和させるメカニズムが必要であるということでした。
The second day of the workshop concentrated on challenges and emerging requirements for future network management operations. The presentation emphasized the importance of validation, observability, automation, and the need for agile, incremental development of both network models and management protocols. A compilation of new requirements from operators was presented; they are being maintained in [OP-REQ-NM]. The final presentation of the day provided a summary of the survey results and operator feedback gathered from outreach events.
ワークショップの 2 日目は、将来のネットワーク管理運用における課題と新たな要件に焦点を当てました。このプレゼンテーションでは、検証、可観測性、自動化の重要性と、ネットワーク モデルと管理プロトコルの両方の機敏で段階的な開発の必要性が強調されました。事業者からの新しい要件をまとめたものが提示されました。それらは [OP-REQ-NM] で維持されています。この日の最後のプレゼンテーションでは、調査結果の概要と、アウトリーチイベントから収集したオペレーターのフィードバックが提供されました。
[KELLER] shared Deutsche Telekom's perspective, emphasizing that while YANG models perform well for provisioning, they currently fall short in providing the operational stability required for validation. In their experience, the IETF service models (where available) were considered stable and in good condition, whereas the OpenConfig device models were noted as lacking feature richness and stability. In contrast, vendor YANG models are often more flexible and available in a more timely manner. Achieving fully closed-loop automated and autonomous networking will require a greater focus on observability, particularly through advancements in streaming telemetry with the "on-change" feature [RFC9196].
[KELLER] はドイツテレコムの見解を共有し、YANG モデルはプロビジョニングには優れた性能を発揮するものの、検証に必要な運用安定性を提供するという点では現時点では不十分であると強調しました。彼らの経験では、IETF サービス モデル (利用可能な場合) は安定していて良好な状態であると考えられていましたが、OpenConfig デバイス モデルは豊富な機能と安定性に欠けていると指摘されました。対照的に、ベンダーの YANG モデルは多くの場合、より柔軟で、よりタイムリーに利用可能です。完全に閉ループの自動化および自律的なネットワーキングを実現するには、特に「on-change」機能 [RFC9196] を備えたストリーミング テレメトリの進歩を通じて、可観測性をさらに重視する必要があります。
[JIMENEZ] discussed the challenges associated with the Software Defined Networking (SDN) Transport Automation Platform, including observability and analytics requirements, issues with data streaming, scalability, diverse models in heterogeneous multi-vendor environments, and mechanisms to secure the network management protocols. The presentation also emphasized how advancements in AI and machine learning, along with the potential adaptation of protocols designed for constrained environments, could drive the next evolution in network management.
[JIMENEZ] は、可観測性と分析の要件、データ ストリーミングの問題、スケーラビリティ、異種マルチベンダー環境における多様なモデル、ネットワーク管理プロトコルを保護するメカニズムなど、Software Defined Networking (SDN) トランスポート オートメーション プラットフォームに関連する課題について議論しました。このプレゼンテーションでは、AI と機械学習の進歩が、制約のある環境向けに設計されたプロトコルの適応の可能性とともに、ネットワーク管理の次の進化をどのように推進できるかについても強調しました。
Using YANG-Push as an example, [GRAF] highlighted how standards development often fails to align with the needs of network operators, the constraints of network vendors, and integration requirements. Most critically, it lacks an agile, incremental development process. The presentation advocated for adopting an iterative approach to standards development, focusing on delivering minimal viable products as part of the process.
YANG-Push を例として、[GRAF] は、標準開発がネットワーク オペレータのニーズ、ネットワーク ベンダーの制約、統合要件とどのように一致しないことが多いかを強調しました。最も重要なのは、アジャイルで段階的な開発プロセスが欠けていることです。このプレゼンテーションでは、プロセスの一部として実行可能な最小限の製品を提供することに重点を置き、標準開発に反復的なアプローチを採用することを提唱しました。
[CONTRERAS] emphasized reassessing deployment assumptions and incorporating updated operator requirements. The authors are addressing these aspects through [OP-REQ-NM], leveraging feedback and discussions from the workshop. Some key requirements, suggestions, and observations that were highlighted in the workshop:
[CONTRERAS]は、配備の前提条件を再評価し、最新のオペレータ要件を組み込むことを強調した。著者らは、ワークショップからのフィードバックと議論を活用し、[OP-REQ-NM] を通じてこれらの側面に取り組んでいます。ワークショップで強調されたいくつかの重要な要件、提案、観察:
* Network software implementations can only happen with a strong, committed standardization effort, complemented by active involvement in open-source projects that facilitate access to code.
* ネットワーク ソフトウェアの実装は、コードへのアクセスを容易にするオープンソース プロジェクトへの積極的な関与によって補完された、強力で熱心な標準化の取り組みによってのみ実現できます。
* Need to rationalize the device model space and avoid redundant efforts. Unlike service and network models, IETF-defined device models are not widely implemented.
* デバイス モデル空間を合理化し、冗長な作業を回避する必要があります。サービス モデルやネットワーク モデルとは異なり、IETF 定義のデバイス モデルは広く実装されていません。
* Define a reference approach/process for service exposure discovery (API discovery).
* サービス公開ディスカバリー (API ディスカバリー) の参照アプローチ/プロセスを定義します。
* Outline a set of recommendations for core/key features, along with appropriate justifications, that will help foster more implementations that meet operators' needs.
* 事業者のニーズを満たすより多くの実装を促進するのに役立つ、適切な根拠とともに、コア/主要機能に関する一連の推奨事項の概要を説明します。
* Reassess the value of some IETF proposals, including comparison to competing or emerging solutions (e.g., gRPC Network Management Interface (gNMI) vs. YANG-Push)
* 競合するソリューションや新興ソリューションとの比較を含め、一部の IETF 提案の価値を再評価します (gRPC ネットワーク管理インターフェイス (gNMI) と YANG-Push など)。
* Need for a more agile process for the development and maintenance of YANG modules in the IETF. RFCs might not be suited for documenting YANG modules.
* IETF における YANG モジュールの開発と保守には、より機敏なプロセスが必要です。RFC は、YANG モジュールの文書化には適していない可能性があります。
* Consider approaches to ease integration by design (e.g., protocols and data models).
* 設計によって統合を容易にするアプローチを検討します (プロトコルやデータ モデルなど)。
* Need for a reference specification to translate YANG-based data into the knowledge graph (KG).
* YANG ベースのデータをナレッジ グラフ (KG) に変換するための参照仕様が必要です。
* Consider approaches to help YANG models scale.
* YANG モデルの拡張を支援するアプローチを検討してください。
* Consider programmatic approaches to ensure lossless mappings between service/network/device data models.
* サービス/ネットワーク/デバイスのデータ モデル間のロスレス マッピングを確保するためのプログラムによるアプローチを検討してください。
* Consider approaches to ensure reuse of / consistent data structure across various network management segments.
* さまざまなネットワーク管理セグメントにわたってデータ構造の再利用と一貫性を確保するためのアプローチを検討します。
* Some networks have specific network management requirements, such as the need for asynchronous operations or constraints on data compactness.
* 一部のネットワークには、非同期操作の必要性やデータのコンパクトさの制約など、特定のネットワーク管理要件があります。
* Necessity to handle the heterogeneity of data, configuration, and network management/requirements. Resolving such issues could draw on insights from parallel technical fields such as knowledge engineering practices and concepts associated with Linked Data in the Semantic Web, areas where it is common to manage problems of heterogeneity and data reconciliation across various application domains.
* データ、構成、ネットワーク管理/要件の異種混合に対処する必要性。このような問題を解決するには、ナレッジ エンジニアリングの実践やセマンティック Web のリンク データに関連する概念など、並行する技術分野からの洞察を活用することができます。これらの分野では、さまざまなアプリケーション ドメインにわたる異質性やデータ調整の問題を管理するのが一般的です。
* Consider having YANG as part of the protocol specification/change where possible, or have the YANG document progress in parallel.
* 可能であれば、プロトコル仕様/変更の一部として YANG を含めることを検討するか、YANG 文書を並行して進めるようにしてください。
* Need to ease the integration of low-level/network-oriented solutions with common "IT tooling".
* 低レベル/ネットワーク指向のソリューションと一般的な「IT ツール」の統合を容易にする必要がある。
* Ease exposure of libraries and host tools (e.g., yangkit) to ease integration.
* ライブラリとホスト ツール (yangkit など) の公開を容易にして、統合を容易にします。
* Focus on tooling is needed, especially on the client side.
* 特にクライアント側では、ツールに焦点を当てる必要があります。
* Create an ecosystem where data and networking engineers can collaborate.
* データ エンジニアとネットワーキング エンジニアがコラボレーションできるエコシステムを作成します。
* Distinct approaches are followed in both the compute and the network environments to define suitable mechanisms for enabling an efficient interplay, while highly automating the overall service delivery procedure.
* コンピューティング環境とネットワーク環境の両方で独自のアプローチが採用され、サービス提供手順全体を高度に自動化しながら、効率的な相互作用を可能にする適切なメカニズムが定義されます。
* The target application/applicability of a network management approach should be documented.
* ネットワーク管理アプローチの対象アプリケーション/適用可能性を文書化する必要があります。
* Readily available API specifications could be generalized from YANG modules for fast development, prototyping, and validation.
* すぐに利用できる API 仕様は、迅速な開発、プロトタイピング、検証のために YANG モジュールから一般化できます。
As outlined in Section 2, the workshop program committee organized outreach initiatives to gather direct feedback and conducted a survey. [SURVEY-INSIGHTS] provided an overview of the respondents' backgrounds, as well as insights into the most widely used tools, protocols, and APIs for configuration, monitoring, and other network operations. Notably, the survey revealed that Ansible and CLI are the most popular configuration tools, NETCONF is the preferred configuration protocol, and Prometheus and SNMP are widely used for monitoring. The survey also captured feedback on network automation and streaming telemetry. Issues and future requirements such as scalability, performance, the need for easier mapping of various models, tooling, management of legacy devices, collaboration with open source, and vendor-specific issues were highlighted. Additionally, valuable insights from direct operator feedback were presented (see Appendix A).
セクション 2 で概説したように、ワークショップ プログラム委員会は、直接のフィードバックを収集するためにアウトリーチ活動を組織し、調査を実施しました。[SURVEY-INSIGHTS] では、回答者の背景の概要と、構成、監視、その他のネットワーク操作に最も広く使用されているツール、プロトコル、API についての洞察が提供されました。特に、この調査では、Ansible と CLI が最も人気のある構成ツールであり、NETCONF が推奨される構成プロトコルであり、Prometheus と SNMP が監視に広く使用されていることが明らかになりました。この調査では、ネットワークの自動化とストリーミング テレメトリに関するフィードバックも収集しました。スケーラビリティ、パフォーマンス、さまざまなモデルのマッピングを容易にする必要性、ツール、レガシー デバイスの管理、オープン ソースとのコラボレーション、ベンダー固有の問題などの問題と将来の要件が強調されました。さらに、オペレーターからの直接のフィードバックから得た貴重な洞察も提供されました (付録 A を参照)。
The Session II open discussion featured feedback from implementers, highlighting the difficulty in moving to YANG and mapping to vendor implementations and how divergence in implementations creates complexity and necessitates workarounds. Implementations need to support standard models alongside vendor-specific models, which adds complexity and leads to confusion. Challenges were highlighted in mapping standard models to internal device models and legacy devices, with some cases where mapping is not feasible at all (device-specific knobs). The conversation also emphasized the importance of developing open-source reference implementations, compliance and interoperability testing for vendors with real data, and better quality of vendor implementation and documentation. The implementation and support of multiple models (IETF, OpenConfig, and vendor-specific models) is an unavoidable reality in network management. Additionally, since the services offered by operators vary significantly, reaching a consensus on a common service model within the IETF can be a challenging task. It was also noted that the IETF should expedite the publication of standards as well as consider gating them with multiple interoperable implementations.
セッション II の公開ディスカッションでは、実装者からのフィードバックが取り上げられ、YANG への移行とベンダー実装へのマッピングの難しさ、実装の相違がどのように複雑さを生み出し、回避策が必要になるかが強調されました。実装では標準モデルとベンダー固有のモデルをサポートする必要がありますが、これにより複雑さが増し、混乱が生じます。標準モデルを内部デバイス モデルおよびレガシー デバイスにマッピングする際の課題が浮き彫りになり、マッピングがまったく不可能な場合もあります (デバイス固有のノブ)。この会話では、オープンソースのリファレンス実装の開発、実際のデータを使用したベンダー向けのコンプライアンスと相互運用性のテスト、ベンダーの実装とドキュメントの品質の向上の重要性も強調されました。複数のモデル (IETF、OpenConfig、およびベンダー固有のモデル) の実装とサポートは、ネットワーク管理において避けられない現実です。さらに、通信事業者によって提供されるサービスは大きく異なるため、IETF 内で共通のサービス モデルについて合意に達することは困難な作業になる可能性があります。また、IETF は標準の発行を迅速化するとともに、複数の相互運用可能な実装による標準のゲート制御を検討する必要があることも指摘されました。
The final day of the workshop centered on exploring potential future solutions and identifying key takeaways, recommendations, and next steps. At the end of day three, to conclude the workshop, the chairs worked to summarize the key takeaways (see Section 3.4) that garnered consensus among the participants.
ワークショップの最終日は、将来のソリューションの可能性を探り、重要なポイント、推奨事項、次のステップを特定することが中心でした。3 日目の終わりに、ワークショップを締めくくるために、議長は参加者の間で合意を得た重要な要点 (セクション 3.4 を参照) を要約することに取り組みました。
[CLAISE] highlighted the challenges of integrating data models across different silos, protocols, and data structures, emphasizing the need for a machine-readable approach to expose semantics. Additionally, the related tools being developed and showcased in the IETF Hackathons, along with the various challenges in mapping across protocols and models, were discussed. A potential solution was proposed that uses a knowledge graph based on the Semantic Web Stack, along with the need to define a basic ontology for the networking domain in an iterative manner (outside of RFCs).
[CLAISE]は、異なるサイロ、プロトコル、データ構造にわたるデータモデルの統合の課題を強調し、セマンティクスを公開するための機械可読アプローチの必要性を強調しました。さらに、IETF ハッカソンで開発および展示されている関連ツールと、プロトコルやモデル間のマッピングにおけるさまざまな課題についても議論されました。潜在的なソリューションとしては、セマンティック Web スタックに基づくナレッジ グラフを使用するとともに、ネットワーキング ドメインの基本オントロジーを反復的に (RFC の外で) 定義する必要性が提案されました。
[WATSEN] recommended prioritizing the following into four areas: (1) using RESTCONF+JSON (including YANG-Push Lite) as a single protocol beyond network management, (2) utilizing Network Management Datastore Architecture (NMDA) model, (3) creating data model adapters (off-box so that common standard models can be developed in parallel to the required device vendor-specific models), and (4) defining device protocol adapters (with RESTCONF-like Northbound Interface (NBI) for a common shared-by-all repository).
[WATSEN] は、次の 4 つの領域に優先順位を付けることを推奨しました: (1) ネットワーク管理を超えた単一プロトコルとして RESTCONF+JSON (YANG-Push Lite を含む) を使用する、(2) ネットワーク管理データストア アーキテクチャ (NMDA) モデルを利用する、(3) データ モデル アダプターを作成する (必要なデバイス ベンダー固有のモデルと並行して共通の標準モデルを開発できるオフボックス)、(4) デバイス プロトコル アダプターを定義する (RESTCONF のような Northbound インターフェイスを使用)(NBI) 共通の全員共有リポジトリの場合)。
[WILTON] recommended reducing unnecessary complexity, delivering timely solutions, fostering open collaboration between vendors and operators, prioritizing simplicity, and converging to a single model/ protocol (though this was discussed as difficult to accomplish). Practical suggestions include focusing on YANG-Push Lite, introducing YANG 2.0 through incremental updates, developing NETCONFv2, and managing IETF YANG models as code or APIs rather than embedding them within RFCs.
[WILTON] は、不必要な複雑さを軽減し、タイムリーなソリューションを提供し、ベンダーとオペレーター間のオープンなコラボレーションを促進し、シンプルさを優先し、単一のモデル/プロトコルに収束することを推奨しました (ただし、これは達成が難しいと議論されました)。実践的な提案には、YANG-Push Lite に焦点を当てること、増分アップデートによる YANG 2.0 の導入、NETCONFv2 の開発、IETF YANG モデルを RFC 内に埋め込むのではなくコードまたは API として管理することが含まれます。
The open discussion in Session III explored a range of topics. These included the absence of NMDA in OpenConfig and debate over whether its complexity is justified; the historical context of gNMI's introduction in the IETF and whether RESTCONF offers advantages over it; and the broader challenges of building consensus, with participants noting that while the process takes time, it should not be short-circuited. The discussion also addressed the practicality of converging on a single protocol and concluded that such convergence is, in fact, feasible.
セッション III の公開討論では、さまざまなトピックが検討されました。これらには、OpenConfig に NMDA が存在しないことや、その複雑さが正当化されるかどうかについての議論が含まれます。IETF への gNMI 導入の歴史的背景と、RESTCONF が gNMI に比べて利点があるかどうか。参加者は、プロセスには時間がかかるものの、短絡的なものであってはいけないと指摘しています。この議論では、単一プロトコルに収束することの実用性についても言及され、そのような収束は実際に実現可能であると結論づけられました。
The discussion emphasized off-box adapters, which allow vendors to continue innovating and developing vendor-specific models rapidly. One suggestion that attracted a lot of discussion centered on developing a standard model mapping to vendor-specific models that could be maintained in a common repository, enabling the community to assess coverage and alignment.
ディスカッションでは、ベンダーがベンダー固有のモデルを迅速に革新および開発し続けることを可能にするオフボックス アダプターが強調されました。多くの議論を集めた提案の 1 つは、共通のリポジトリで保守できるベンダー固有のモデルにマッピングする標準モデルの開発に集中し、コミュニティがカバレッジと調整を評価できるようにすることでした。
Further, the discussion explored alternative approaches to YANG models within the IETF but outside of RFCs, such as leveraging GitHub to accelerate the process (along with the challenges associated with it), living documents within the WG charter, and supporting academia to take up the open source efforts, such as device adapters. The discussion emphasized the need for process experimentation, particularly at the working group or area level, where we could have consensus among the YANG/OPS community on how we iterate in WGs without IETF-/RFC-wide changes, but making sure the operators are involved in the process.
さらに、議論では、GitHub を活用してプロセスを加速する (それに関連する課題とともに)、WG 憲章内の生きた文書、デバイス アダプタなどのオープン ソースの取り組みに取り組む学界の支援など、IETF 内ではあるが RFC の外で YANG モデルに対する代替アプローチが検討されました。議論では、特に作業グループまたはエリアレベルでのプロセス実験の必要性が強調されました。そこでは、IETF/RFC 全体の変更を行わずに、WG でどのように反復するかについて、YANG/OPS コミュニティ間で合意を得ることができますが、オペレーターがプロセスに確実に関与するようにする必要があります。
Conversations ensued around questions asked, such as "Is YANG applicable beyond network management?" and "Can applications adopt YANG as a modeling language to define their services?"
「YANG はネットワーク管理以外にも適用可能ですか?」などの質問を中心に会話が続きました。「アプリケーションはサービスを定義するためのモデリング言語として YANG を採用できますか?」
Some key recommendations made by operators during outreach (Section 2) are listed in Appendix B.
アウトリーチ中にオペレーターが行ったいくつかの重要な推奨事項 (セクション 2) を付録 B に示します。
At the end of the third day, the discussion turned to key takeaways that have a high-level consensus. These were edited live during the last discussion of the workshop, and anything that did not reach a wide consensus was moved into a "future considerations" list (Section 3.4.5).
3 日目の終わりに、議論は高レベルの合意を得た重要なポイントに移りました。これらはワークショップの最後の議論中にライブで編集され、広範な合意に達しなかったものはすべて「将来の検討事項」リストに移されました（セクション 3.4.5）。
The following takeaways try to document the general thinking of the participants with respect to the entire network management ecosystem as it exists today.
以下の要点は、今日存在するネットワーク管理エコシステム全体に関する参加者の一般的な考え方を文書化することを目的としています。
1. The current network management protocols, models, and tools still fail the 'ease of use' requirement. Participants noted that the tools almost matter more than the protocols.
1. 現在のネットワーク管理プロトコル、モデル、ツールは依然として「使いやすさ」の要件を満たしていません。参加者は、プロトコルよりもツールの方が重要であると指摘しました。
2. The overall ecosystem is still fragmented for both protocols and data models. SNMP is still used extensively for monitoring, and the CLI is still heavily relied on for configuration in many networks. Popular protocols include SNMP, NETCONF, RESTCONF, and gNMI.
2. エコシステム全体は、プロトコルとデータ モデルの両方で依然として断片化されています。SNMP は今でもモニタリングに広く使用されており、多くのネットワークでは設定に CLI に大きく依存しています。一般的なプロトコルには、SNMP、NETCONF、RESTCONF、gNMI などがあります。
3. Documentation about the architecture and usage of the network management ecosystem is lacking. More work is needed to create general architecture documentation, deployment guides, tutorials, training material, and getting-started guides.
3. ネットワーク管理エコシステムのアーキテクチャと使用法に関するドキュメントが不足しています。一般的なアーキテクチャのドキュメント、導入ガイド、チュートリアル、トレーニング資料、入門ガイドを作成するには、さらに多くの作業が必要です。
4. Transitioning between network management frameworks is challenging, just like it is for transitioning between other protocols like IPv4 to IPv6.
4. ネットワーク管理フレームワーク間の移行は、IPv4 から IPv6 などの他のプロトコル間の移行と同様に困難です。
5. Model-driven network management is generally a success where it has been implemented and is possible to use.
5. モデル駆動型ネットワーク管理は、実装されて使用できる場合には通常成功します。
6. More easily usable network management tools for the operators are needed. The lack of open-source tools is seen as a barrier to adoption. Tools need good use cases, example flows, and better analysis of when and how they work and have been successful.
6. オペレータにとって、より簡単に使用できるネットワーク管理ツールが必要です。オープンソース ツールの不足が導入の障壁になっていると考えられています。ツールには、優れた使用例、フロー例、ツールがいつどのように機能し、成功したかについてのより適切な分析が必要です。
The following conclusions were reached while discussing network management protocols, more specifically.
ネットワーク管理プロトコルをより具体的に議論する中で、次の結論に達しました。
1. NETCONF and YANG are not used much for monitoring tasks.
1. NETCONF と YANG はタスクの監視にはあまり使用されません。
2. NETCONF and YANG do not have full coverage on many devices.
2. NETCONF と YANG は、多くのデバイスを完全にはカバーしていません。
3. Polling-based solutions are still frequently deployed. Push-based solutions are often desired but are not yet widely available.
3. ポーリングベースのソリューションは依然として頻繁に導入されています。プッシュベースのソリューションが望まれることがよくありますが、まだ広く利用可能ではありません。
The following conclusions were reached while discussing network management modeling, more specifically.
ネットワーク管理モデリングをより具体的に議論する中で、次の結論に達しました。
1. Some YANG models can become complex due to the underlying features they represent, not due to the language itself.
1. 一部の YANG モデルは、言語自体が原因ではなく、YANG モデルが表す基礎的な機能が原因で複雑になる可能性があります。
2. Multi-vendor compatibility support is required.
2. マルチベンダー互換性サポートが必要です。
3. Even vendor-specific features, not just standardized protocol features, need to be exposed through network management models and protocols for a network management ecosystem to be viable.
3. ネットワーク管理エコシステムを実現するには、標準化されたプロトコル機能だけでなく、ベンダー固有の機能もネットワーク管理モデルとプロトコルを通じて公開する必要があります。
4. Greater support for service-level modeling is needed. Device-level modeling can be a building block to achieve a sufficient service-level model, but it is not a complete solution by itself.
4. サービスレベルモデリングのサポートを強化する必要があります。デバイス レベルのモデリングは、十分なサービス レベル モデルを実現するための構成要素にはなり得ますが、それ自体では完全なソリューションではありません。
5. Network configuration needs to be verifiable to ensure any potential changes can be accepted by devices. Model translation adapters (likely performed on the management station, not the end device) may be the best path forward to simultaneously achieve this and the goal of supporting one configuration set across a diversity of devices with different internal models.
5. 潜在的な変更がデバイスで受け入れられることを確認するには、ネットワーク構成を検証できる必要があります。モデル変換アダプター (エンド デバイスではなく管理ステーションで実行される可能性が高い) は、これと、異なる内部モデルを持つ多様なデバイス間で 1 つの構成セットをサポートするという目標を同時に達成するための最良の方法である可能性があります。
The following conclusions were reached while discussing the best ways to standardize network management protocols and associated models.
ネットワーク管理プロトコルと関連モデルを標準化する最良の方法を議論する中で、次の結論に達しました。
1. A methodology of rapid model development procedures is needed to ensure model deployment can keep pace with new feature deployment. We need a solution that significantly increases the speed and predictable timeline for developing and publishing models within the IETF. New approaches and methods to make models live outside of published RFCs should be explored. An experiment should be started to test a new rapid development approach.
1. モデルの展開が新機能の展開に遅れないようにするためには、迅速なモデル開発手順の方法論が必要です。IETF 内でのモデルの開発と公開の速度と予測可能なタイムラインを大幅に向上させるソリューションが必要です。公開された RFC の外でモデルを稼働させるための新しいアプローチと方法を検討する必要があります。新しい迅速な開発アプローチをテストするために実験を開始する必要があります。
2. Protocol and model complexity should be reduced to keep additions and changes to a minimal set of agreed-upon core features.
2. 合意されたコア機能の最小限のセットへの追加と変更を維持するには、プロトコルとモデルの複雑さを軽減する必要があります。
3. More standardization focus is needed on the scalability of the different roles of network management: monitoring, configuration, and notifications.
3. ネットワーク管理のさまざまな役割 (監視、構成、通知) のスケーラビリティにさらに焦点を当てた標準化が必要です。
4. Enhancements to network management protocols and models need to be backed by real-world operator use cases and expected adoption by vendors. Vendors and operators will need to work together to ensure these goals are appropriately met.
4. ネットワーク管理プロトコルとモデルの機能強化は、実際の通信事業者の使用事例とベンダーによる予想される採用に裏付けられる必要があります。これらの目標が適切に達成されるように、ベンダーとオペレーターは協力する必要があります。
Here, we list the things that the group realized needed significantly more attention in order to come to a conclusion, while updating the key takeaways in real time.
ここでは、グループが結論を出すためにさらに多くの注意が必要であると認識した事項をリストし、重要なポイントをリアルタイムで更新します。
1. Some, but not all, saw NETCONF for configuration as being successful in some larger-scale deployments. Although this statement is true in some contexts, many operators indicated their need to rely on other forms of access to manage their networks, such as CLIs, Expect scripts, and other protocols.
1. すべてではありませんが、一部の大規模な展開では、構成に NETCONF が成功していると考えられていました。この意見は一部の状況では当てはまりますが、多くの事業者は、ネットワークを管理するために、CLI、Expect スクリプト、その他のプロトコルなど、他の形式のアクセスに依存する必要があると指摘しています。
2. Many hope that NETCONF, and RESTCONF more specifically, will continue to move to a long-term configuration management solution. However, some participants doubted whether the protocol and its data models can ever be truly ubiquitous and keep pace with the device deployment pace.
2. 多くの人は、NETCONF、より具体的には RESTCONF が長期的な構成管理ソリューションに移行し続けることを期待しています。しかし、一部の参加者は、プロトコルとそのデータ モデルが本当にユビキタスになり、デバイスの導入ペースに追いつくことができるかどうかを疑問視していました。
While many other items also need further discussion, this list specifically includes those that were actively discussed during the live editing session in the workshop.
他の多くの項目もさらなる議論が必要ですが、このリストには特にワークショップのライブ編集セッション中に活発に議論された項目が含まれています。
Some topics absent from the workshop discussions included tooling (what is currently missing) and strategies to support tool development (who pays, who develops, and who maintains). The primary focus of the discussion was on YANG and NETCONF/RESTCONF, while several other network management protocols and techniques currently used received less attention. During the workshop, the discussion on possible future directions prioritized improving existing solutions rather than introducing entirely new ones (such as enabling intelligence in network management).
ワークショップのディスカッションに含まれていないトピックには、ツール (現在不足しているもの) やツール開発をサポートする戦略 (誰が支払い、誰が開発し、誰が保守するか) が含まれていました。議論の主な焦点は YANG と NETCONF/RESTCONF でしたが、現在使用されている他のいくつかのネットワーク管理プロトコルや技術はそれほど注目されていませんでした。ワークショップでは、考えられる将来の方向性についての議論では、まったく新しいソリューション (ネットワーク管理におけるインテリジェンスの有効化など) の導入ではなく、既存のソリューションの改善を優先しました。
This document is a workshop report and does not impact the security of the Internet.
この文書はワークショップの報告書であり、インターネットのセキュリティには影響しません。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[BLESS] Bless, R., "An Invariant for Future Resilient Network
Management Operations", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper-an-
invariant-for-future-resilient-network-management-
operations-00.pdf>.
[BORMANN] Bormann, C., "CORECONF: Managing IoT Devices with YANG
Models", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-coreconf-managing-iot-devices-with-
yang-models-00.pdf>.
[CLAISE] Claise, B., Graf, T., Keller, H., Voyer, D., Lucente, P.,
Lopez, D., Martinez-Casanueva, I. D., Peters, B., Fasano,
P., Ran, P., Cheng, W., and M. Mackey, "Knowledge Graph
Framework for Network Operations", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper-
knowledge-graph-framework-for-network-operations-00.pdf>.
[CONTRERAS]
Boucadair, M., Contreras, LM., Gonzalez de Dios, O., Graf,
T., Rahman, R., and L. Tailhardat, "RFC 3535, 20 Years
Later: An Update of Operators Requirements on Network
Management Protocols and Modelling", October 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper-
rfc3535-years-later-an-update-of-operators-requirements-
on-network-management-protocols-and-modelling-00.pdf>.
[CORECONF] Veillette, M., Ed., Van der Stok, P., Ed., Pelov, A., Ed.,
Bierman, A., and C. Bormann, Ed., "CoAP Management
Interface (CORECONF)", Work in Progress, Internet-Draft,
draft-ietf-core-comi-21, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
comi-21>.
[ECKERT] Eckert, T. and M. Richardson, "Resilient Remote
Manageability of Wide-Area Network Infrastructures",
November 2024, <https://www.ietf.org/slides/slides-
nemopsws-paper-resilient-remote-managability-of-wide-area-
network-infrastructures-00.pdf>.
[FARRER] Larsson, K., Lambrechts, K., and I. Farrer, "RFC3535, 20
Years Later from an Operator's Perspective (Deutsche
Telekom)", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-rfc3535-years-later-from-an-
operators-perspective-deutsche-telekom-00.pdf>.
[FOROUGHI] Foroughi, P. and L. Ciavaglia, "Projecting Data Mesh to
Model-driven Telemetry: A Path to Data Ecosystem's
Management Operations", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper-
projecting-data-mesh-to-model-driven-telemetry-a-path-to-
data-ecosystems-management-operations-00.pdf>.
[GIRALT] Contreras, LM., Schott, R., Randriamasy, S., Yang, R., and
J. Ros-Giralt, "Towards a Unified Compute and
Communication Infrastructure for Application and Network
Management", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-towards-a-unified-compute-and-
communication-infrastructure-for-application-and-network-
management-00.pdf>.
[GRAF] Graf, T., Keller, H., Voyer, D., Lucente, P., Claise, B.,
Wilton, R., Huang-Feng, A., and P. Francois, "Agile
Incremental Driven Development for Network Management",
November 2024, <https://www.ietf.org/slides/slides-
nemopsws-paper-agile-incremental-driven-development-for-
network-management-01.pdf>.
[GUDI] Gudi, M., Pelov, A., Toutain, L., and J. M. Bonnin,
"Evolving Network Management Architecture: Integrating
CORECONF with NETCONF for Efficient Telemetry and
Management", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-evolving-network-management-
architecture-integrating-coreconf-with-netconf-for-
efficient-telemetry-and-management-00.pdf>.
[HARDAKER] Hardaker, W., "Lessons Learned from 30 Years of Net-SNMP",
November 2024, <https://www.ietf.org/slides/slides-
nemopsws-paper-lessons-learned-from-30-years-of-net-snmp-
00.pdf>.
[JIMENEZ] Jiménez, J., Mansfield, S., Rodriguez A, R., Pesonen, M.,
Torvinen, V., and J. Karvonen, "Evolving Challenges and
Solutions in Network Management", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper-
evolving-challenges-and-solutions-in-network-management-
00.pdf>.
[JIMENEZ-2]
Jiménez, J., "Managing IoT Devices with LwM2M", November
2024, <https://www.ietf.org/slides/slides-nemopsws-paper-
managing-iot-devices-with-lwmm-00.pdf>.
[KELLER] Warnke, N., Geib, R., Horneffer, M., and H. Keller,
"NEMOPS: RFC3535 and the forgotten word - Or Provisioning
is only a subset of Network Management", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-nemops-
rfc3535-and-the-forgotten-word-00.pdf>.
[MARTINEZ] Martinez-Casanueva, I. D., "IAB NEMOPS Position Paper -
Telefonica", November 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-iab-nemops-position-paper-
telefonica-00.pdf>.
[NET-SNMP] "Net-SNMP", <http://www.net-snmp.org/>.
[OP-REQ-NM]
Boucadair, M., Contreras, L. M., Gonzalez de Dios, O.,
Graf, T., and R. Rahman, "An Update of Operators
Requirements on Network Management Protocols and
Modelling", Work in Progress, Internet-Draft, draft-ietf-
nmop-rfc3535-20years-later-04, 6 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
rfc3535-20years-later-04>.
[OPENCONFIG]
"OpenConfig", <https://www.openconfig.net/>.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, DOI 10.17487/RFC3535, May
2003, <https://www.rfc-editor.org/info/rfc3535>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules
Describing Capabilities for Systems and Datastore Update
Notifications", RFC 9196, DOI 10.17487/RFC9196, February
2022, <https://www.rfc-editor.org/info/rfc9196>.
[SCHARF] Scharf, M., "Network Management Challenges for IP-based
Cyber-Physical Networks", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-paper-
network-management-challenges-for-ip-based-cyber-physical-
networks-00.pdf>.
[SCHONWALDER]
Schönwälder, J., "Composable, Declarative, Reproducible,
Verifiable Network and Service Configurations", November
2024, <https://www.ietf.org/slides/slides-nemopsws-paper-
composable-declarative-reproducible-verifiable-network-
and-service-configurations-00.pdf>.
[SHAKIR] Shakir, R., "Rethinking Standardisation of Network
Management", September 2024, <https://www.ietf.org/slides/
slides-nemopsws-paper-rethinking-standardisation-of-
network-management-00.pdf>.
[SURVEY] "Next Era of Network Management Operations (NEMOPS)
workshop survey", October 2024,
<https://ietf.iad1.qualtrics.com/jfe/form/
SV_9vQxBRiZqDntarc>.
[SURVEY-INSIGHTS]
"Insights from Operator Survey & Outreach", December 2024,
<https://datatracker.ietf.org/meeting/interim-2024-
nemopsws-02/materials/slides-interim-2024-nemopsws-02-
sessa-6-insights-from-operator-outreach-survey-03.pdf>.
[WATSEN] Watsen, K., "Four Thoughts for How to Improve Network
Management for Operators", November 2024,
<https://www.ietf.org/slides/slides-nemopsws-nemops-
position-paper-kent-watsen-00.pdf>.
[WILTON] Wilton, R. and N. Corran, "Device Network Management -
Current Status, and Future Direction", November 2024,
<https://datatracker.ietf.org/doc/slides-nemopsws-paper-
device-network-management-current-status-and-future-
direction/>.
This section compiles the operator feedback gathered through outreach and information gathering at various operational venues (RIPE, NANOG, APRICOT, LACNIC, AutoConn, etc.). The PC synthesized this input and presented it during the workshop (see Section 3.2.2).
このセクションでは、さまざまな運用会場 (RIPE、NANOG、APRICOT、LACNIC、AutoConn など) でのアウトリーチおよび情報収集を通じて収集されたオペレーターのフィードバックをまとめます。PC はこの入力を合成し、ワークショップ中に提示しました (セクション 3.2.2 を参照)。
1. In network deployments, operations are typically at the bottom of the ladder. It's the most squeezed for time and resources. Network engineers are not typically seasoned developers. The development of needed in-house tools often takes years to develop. There is a need for tools that are easy to use and just work.
1. ネットワーク展開では、通常、操作ははしごの一番下にあります。時間とリソースが最も圧迫されています。ネットワーク エンジニアは通常、経験豊富な開発者ではありません。必要な社内ツールの開発には、多くの場合何年もかかります。使いやすく、すぐに機能するツールが必要です。
2. The vast majority of smaller operators use CLI and open source to manage their networks.
2. 小規模事業者の大多数は、CLI とオープンソースを使用してネットワークを管理しています。
3. There is debate fatigue. The protocol/model debate is a recurring conversation. The problem isn't going away.
3. 議論疲れがある。プロトコルとモデルの議論は繰り返される会話です。問題は解決していません。
4. It was suggested that other domains (e.g., Kubernetes (K8s) / automation) are years ahead of the current network engineering stack.
4. 他のドメイン (Kubernetes (K8s) / 自動化など) は、現在のネットワーク エンジニアリング スタックよりも何年も進んでいることが示唆されました。
5. Support for multiple friendly, stable, and feature-rich libraries for programming languages is needed. Many DevOps routines use shell scripts, while others use a high-level programming language. In any case, on the client side, multiple programming languages are used.
5. プログラミング言語用の、フレンドリーで安定した機能が豊富な複数のライブラリのサポートが必要です。多くの DevOps ルーチンはシェル スクリプトを使用しますが、その他のルーチンは高級プログラミング言語を使用します。いずれにしても、クライアント側では複数のプログラミング言語が使用されます。
6. Screen scraping is unfortunately necessary and painful. This most often occurs when interacting with a device that only has a CLI.
6. 残念ながら、画面のスクレイピングは必要であり、苦痛を伴います。これは、CLI のみを備えたデバイスと対話するときに最もよく発生します。
7. It was noted that there could be an outreach to Academia to establish programs to teach lessons using modern management stacks, and then a new generation of engineers could help to improve tooling and automation, with university (and/or IETF) hackathons.
7. 最新の管理スタックを使用してレッスンを教えるプログラムを確立するために学界への働きかけがあり、その後、大学 (および/または IETF) のハッカソンを通じて新世代のエンジニアがツールと自動化の改善に貢献する可能性があることが注目されました。
1. In some network deployments, the focus is solely on service-level models, such that device-level protocols and device-level models are unimportant. This assumes the existence of a device adaptation layer to transcode service-level models to device-level models and conform to the device-specific protocol.
1. 一部のネットワーク展開では、サービス レベル モデルのみに重点が置かれているため、デバイス レベルのプロトコルやデバイス レベルのモデルは重要ではありません。これは、サービス レベル モデルをデバイス レベル モデルにトランスコードし、デバイス固有のプロトコルに準拠するデバイス アダプテーション レイヤーの存在を前提としています。
2. There is a need for solutions to not hide vendor-specific parameters. Currently, vendors compete by differentiating their offerings in unique ways. The reason why an operator may choose a particular vendor is because of its differentiating features. Whilst standard models enable conformance, they must not hide the vendor-specific parameters. YANG deviations are a partial solution to not hiding vendor knobs.
2. ベンダー固有のパラメータを隠さないソリューションが必要です。現在、ベンダーは独自の方法で自社の製品を差別化することで競争しています。通信事業者が特定のベンダーを選択する理由は、その差別化機能のためです。標準モデルは準拠を可能にしますが、ベンダー固有のパラメータを隠してはなりません。YANG の偏差は、ベンダー ノブを非表示にしないための部分的な解決策です。
3. It was emphasized that streaming telemetry requires picking a model and sticking with it. It is quite a commitment, and the current environment makes the decision harder.
3. ストリーミング テレメトリではモデルを選択し、それを使い続ける必要があることが強調されました。これはかなりの覚悟が必要ですが、現在の環境ではその決断が難しくなります。
4. It was noted that IETF's focus should be on defining abstract/ service-level data models since it is the only thing the community may ever agree on.
4. IETF は抽象/サービスレベルのデータ モデルの定義に重点を置くべきであると指摘されました。なぜなら、それがコミュニティが同意する唯一のものであるからです。
5. It was noted that navigating standard models can be difficult. A network engineer knows the vendor CLI commands but has trouble locating the corresponding leaves in the standard YANG models defined by Standards Development Organizations (SDOs).
5. 標準モデルの操作は難しい場合があることに注意してください。ネットワーク エンジニアは、ベンダーの CLI コマンドについては知っていますが、標準開発組織 (SDO) によって定義された標準 YANG モデル内の対応するリーフを見つけるのに苦労しています。
6. There was a wish that the IETF and OpenConfig models would merge.
6. IETF モデルと OpenConfig モデルが統合されることが望まれていました。
Various recommendations were made by the operators during the outreach events. The key ones presented during the workshop were (note that there were a lot more collected):
アウトリーチイベント中にオペレーターからさまざまな推奨事項が作成されました。ワークショップ中に発表された主なものは次のとおりです (さらに多くのものが収集されたことに注意してください)。
* Everyone: Continue to focus on model-driven management as a means to achieve automation.
* 全員: 自動化を実現する手段として、モデル駆動型管理に引き続き注力してください。
* SDOs: Re-introduce "running code" as part of the specification verification process.
* SDO: 仕様検証プロセスの一環として「実行コード」を再導入します。
* Operators: Be actively involved with the "running code" efforts.
* オペレーター: 「コードの実行」作業に積極的に参加してください。
* IETF: Recommend a solution stack for common use cases.
* IETF: 一般的なユースケース向けのソリューション スタックを推奨します。
* Technology Ambassadors: Evangelize the recommended solution stack for common cases.
* テクノロジー アンバサダー: 一般的なケースに対して推奨されるソリューション スタックを宣伝します。
* Vendors: Support the recommended approach to the solution stack for common cases.
* ベンダー: 一般的なケースに対するソリューション スタックへの推奨アプローチをサポートします。
20 position papers were submitted to the workshop call for papers. All papers are available at <https://datatracker.ietf.org/group/nemopsws/materials/>.
ワークショップの論文募集には 20 件のポジションペーパーが提出されました。すべての論文は <https://datatracker.ietf.org/group/nemopsws/materials/> で入手できます。
This is the list of all papers:
これはすべての論文のリストです。
* J. Schönwälder: Composable, Declarative, Reproducible, Verifiable Network and Service Configurations [SCHONWALDER]
* J. Schönwälder: 構成可能、宣言的、再現可能、検証可能なネットワークとサービスの構成 [SCHONWALDER]
* K. Larsson, K. Lambrechts, and I. Farrer: RFC3535, 20 Years Later from an Operator's Perspective (Deutsche Telekom) [FARRER]
* K. Larsson、K. Lambrechts、および I. Farrer: RFC3535、オペレーターの観点から 20 年後 (ドイツテレコム) [FARRER]
* W. Hardaker: Lessons Learned from 30 Years of Net-SNMP [HARDAKER]
* W. Hardaker: 30 年間の Net-SNMP から学んだ教訓 [HARDAKER]
* C. Bormann: CORECONF: Managing IoT Devices with YANG Models [BORMANN]
* C. ボーマン: CORECONF: YANG モデルを使用した IoT デバイスの管理 [BORMANN]
* R. Shakir: Rethinking Standardisation of Network Management [SHAKIR]
* R. シャキール: ネットワーク管理の標準化を再考する [SHAKIR]
* N. Warnke, R. Geib, M. Horneffer, and H. Keller: NEMOPS: RFC3535 and the forgotten word - Or Provisioning is only a subset of Network Management [KELLER]
* N. Warnke、R. Geib、M. Horneffer、および H. Keller: NEMOPS: RFC3535 と忘れ去られた言葉 - または、プロビジョニングはネットワーク管理のサブセットにすぎません [KELLER]
* J. Jiménez, S. Mansfield, R. Rodriguez A., M. Pesonen, V. Torvinen, and J. Karvonen: Evolving Challenges and Solutions in Network Management [JIMENEZ]
* J. Jiménez、S. Mansfield、R. Rodriguez A.、M. Pesonen、V. Torvinen、および J. Karvonen: ネットワーク管理における進化する課題と解決策 [JIMENEZ]
* M. Boucadair, LM. Contreras, O. Gonzalez de Dios, T. Graf, R. Rahman, and L. Tailhardat: RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling [CONTRERAS]
* M.ブーカデア、LM。Contreras、O. Gonzalez de Dios、T. Graf、R. Rahman、L. Tailhardat: RFC 3535、20 年後: ネットワーク管理プロトコルとモデリングに関するオペレーター要件の更新 [CONTRERAS]
* T. Graf, H. Keller, D. Voyer, P. Lucente, B. Claise, R. Wilton, A. Huang-Feng, and P. Francois: Agile Incremental Driven Development for Network Management [GRAF]
* T. Graf、H. Keller、D. Voyer、P. Lucente、B. Claise、R. Wilton、A. Huang-Feng、および P. Francois: ネットワーク管理のためのアジャイル増分駆動開発 [GRAF]
* B. Claise, T. Graf, H. Keller, D. Voyer, P. Lucente, D. Lopez, I. D. Martinez-Casanueva, B. Peters, P. Fasano, P. Ran, W. Cheng, and M. Mackey: Knowledge Graph Framework for Network Operations [CLAISE]
* B. Claise、T. Graf、H. Keller、D. Voyer、P. Lucente、D. Lopez、I. D. Martinez-Casanueva、B. Peters、P. Fasano、P. Ran、W. Cheng、M. Mackey: ネットワーク運用のためのナレッジ グラフ フレームワーク [CLAISE]
* K. Watsen: Four Thoughts for How to Improve Network Management for Operators [WATSEN]
* K. Watsen: オペレータのネットワーク管理を改善するための 4 つの考え [WATSEN]
* R. Wilton and N. Corran: Device Network Management: Current Status and Future Direction [WILTON]
* R. Wilton および N. Corran: デバイス ネットワーク管理: 現状と将来の方向性 [WILTON]
* M. Gudi, A. Pelov, L. Toutain, and J. M. Bonnin: Evolving Network Management Architecture: Integrating CORECONF with NETCONF for Efficient Telemetry and Management [GUDI]
* M. Gudi、A. Pelov、L. Toutain、J. M. Bonnin: 進化するネットワーク管理アーキテクチャ: 効率的なテレメトリと管理のための CORECONF と NETCONF の統合 [GUDI]
* P. Foroughi and L. Ciavaglia: Projecting Data Mesh to Model-driven Telemetry: A Path to Data Ecosystem's Management Operations [FOROUGHI]
* P. Foroughi と L. Ciavaglia: データ メッシュをモデル駆動型テレメトリに投影: データ エコシステムの管理操作への道 [FOROUGHI]
* I. D. Martinez-Casanueva: IAB NEMOPS Position Paper - Telefonica [MARTINEZ]
* I. D. マルティネス-カサヌエバ: IAB NEMOPS ポジション ペーパー - Telefonica [MARTINEZ]
* J. Jiménez: Managing IoT Devices with LwM2M [JIMENEZ-2]
* J. Jiménez: LwM2M を使用した IoT デバイスの管理 [JIMENEZ-2]
* LM. Contreras, R. Schott, S. Randriamasy, R. Yang, and J. Ros-Giralt: Towards a Unified Compute and Communication Infrastructure for Application and Network Management [GIRALT]
* LM.Contreras、R. Schott、S. Randriamasy、R. Yang、および J. Ros-Giralt: アプリケーションおよびネットワーク管理のための統合コンピューティングおよび通信インフラストラクチャに向けて [GIRALT]
* T. Eckert and M. Richardson: Resilient Remote Manageability of Wide-Area Network Infrastructures [ECKERT]
* T. エッカートと M. リチャードソン: 広域ネットワーク インフラストラクチャの回復力のあるリモート管理性 [ECKERT]
* R. Bless: An Invariant for Future Resilient Network Management Operations [BLESS]
* R. Bless: 将来の回復力のあるネットワーク管理運用のための不変式 [BLESS]
* M. Scharf: Network Management Challenges for IP-based Cyber-Physical Networks [SCHARF]
* M. シャーフ: IP ベースのサイバーフィジカル ネットワークのネットワーク管理の課題 [SCHARF]
The workshop participants were Alex Huang, Alexander Clemm, Alexander Pelov, Benoît Claise, Boris Khasanov, Brad Peters, Carsten Bormann, Chongfeng Xie, Cindy Morgan, Dan Voyer, Darren Loher, Dean Bogdanovic, Dean Bogdanović, Dhruv Dhody, Diego Lopez, Ebben Aries, Frank (Chong Feng), Holger Keller, Ian Farrer, Jaime Jimenez, James Cumming, Janne Karvonen, Jason Sterne, Jiaming Ye, Jinming Li, John Carson, Julien Maisonneuve, Jürgen Schönwälder, Kent Watsen, Kris Lambrechts, Kristian Larsson, Laurent Ciavaglia, Laurent Toutain, Liz Flynn, Luis M. Contreras, Mahesh Jethanandani, Manoj Gudi, Martin Horneffer, Matthew Bocci, Med Boucadair, Michael Mackey, Michael Richardson, Michael Scharf, Mikko Pesonen, Nacho Dominguez, Naveen Achyuta, Nick Corran, Nils Warnke, Oscar Gonzalez de Dios, Paolo Lucente, Parisa Foroughi, Per Andersson, Phil Shafer, Qin Wu, Qiufang Ma, Raquel Rodriguez, Reshad Rahman, Rob Shakir, Rob Wilton, Roland Bless, Roland Schott, Rüdiger Geib, Rui Zhuang, Ruibo Han, Sabine Randriamasy, Scott Mansfield, Scott Robohn, Shengnan Yue, Suresh Krishnan, Thomas Graf, Toerless Eckert, Wangbo, Warren Kumari, Wes Hardaker, Wim Henderickx, Xue Yang, Y. Richard Yang, Yangbo, Yisong Liu, and Zhenqiang Li.
ワークショップ参加者は、Alex Huang、Alexander Clemm、Alexander Pelov、Benoit Claise、Boris Khasanov、Brad Peters、Carsten Bormann、Chongfeng Xie、Cindy Morgan、Dan Voyer、Darren Loher、Dean Bogdanovic、Dean Bogdanović、Dhruv Dhody、Diego Lopez、Ebben Aries、Frank (Chong Feng)、Holger です。ケラー、イアン・ファーラー、ハイメ・ヒメネス、ジェームズ・カミング、ヤンネ・カルヴォネン、ジェイソン・スターン、ジアミン・イェ、ジンミン・リー、ジョン・カーソン、ジュリアン・メゾンヌーヴ、ユルゲン・シェーンヴェルダー、ケント・ワッツェン、クリス・ランブレヒト、クリスチャン・ラーソン、ローラン・シアバリア、ローラン・トゥタン、リズ・フリン、ルイス・M・コントレラス、マヘシュジェサナンダニ、マノージ・グディ、マーティン・ホーネファー、マシュー・ボッチ、メッド・ブーカデア、マイケル・マッキー、マイケル・リチャードソン、マイケル・シャーフ、ミッコ・ペゾネン、ナチョ・ドミンゲス、ナヴィーン・アチュタ、ニック・コラン、ニルス・ヴァルンケ、オスカー・ゴンザレス・デ・ディオス、パオロ・ルセンテ、パリサ・フォロギ、パー・アンダーソン、フィル・シェイファー、チン・ウー、キウファン・マー、ラケルロドリゲス、レシャド・ラーマン、ロブ・シャキール、ロブ・ウィルトン、ローランド・ブレス、ローランド・ショット、リュディガー・ガイブ、ルイ・チアン、ルイボー・ハン、サビーヌ・ランドリアマシー、スコット・マンスフィールド、スコット・ロボーン、シェンナン・ユエ、スレシュ・クリシュナン、トーマス・グラフ、トーレス・エッカート、ワンボ、ウォーレン・クマリ、ウェス・ハーデイカー、ヴィム・ヘンデリクス、シュエYang、Y. Richard Yang、Yangbo、Yisong Liu、および Zhenqiang Li。
The workshop program committee members were Wes Hardaker (co-chair), Dhruv Dhody (co-chair), Qin Wu, Suresh Krishnan, Benoît Claise, Mohamed Boucadair, Mahesh Jethanandani, Kent Watsen, and Warren Kumari.
ワークショッププログラム委員会のメンバーは、ウェス・ハーダカー氏（共同議長）、ドゥルブ・ドーディ氏（共同議長）、チン・ウー氏、スレシュ・クリシュナン氏、ブノワ・クレイズ氏、モハメド・ブーカデア氏、マヘシュ・ジェサナンダニ氏、ケント・ワッセン氏、ウォーレン・クマリ氏でした。
Internet Architecture Board members at the time this document was approved for publication were:
この文書の発行が承認された時点のインターネット アーキテクチャ委員会のメンバーは次のとおりです。
* Matthew Bocci
* マシュー・ボッチ
* Roman Danyliw
* ローマン・ダニリュー
* Dhruv Dhody
* ドゥルブ・ドーディ
* Jana Iyengar
* ヤナ・アイアンガー
* Cullen Jennings
* カレン・ジェニングス
* Suresh Krishnan
* スレシュ・クリシュナン
* Mirja Kühlewind
* ミルヤ・キューレヴィント
* Warren Kumari
* ウォーレン・クマリ
* Jason Livingood
* ジェイソン・リヴィングッド
* Mark Nottingham
* マーク・ノッティンガム
* Tommy Pauly
* トミー・ポーリー
* Alvaro Retana
* アルバロ・レタナ
* Qin Wu
* 秦呉
Thanks to Benoît Claise, Jürgen Schönwälder, Kristian Larsson, Jaime Jiménez, Michael Richardson, Phil Shafer, Mirja Kühlewind, and Roman Danyliw for helpful suggestions to improve this report.
このレポートを改善するための有益な提案をくださった Benoit Claise、Jürgen Schönwälder、Kristian Larsson、Jaime Jiménez、Michael Richardson、Phil Shafer、Mirja Kühlewind、Roman Danyliw に感謝します。
Thanks to Alvaro Retana for shepherding this document.
この文書を導いてくださった Alvaro Retana に感謝します。
Wes Hardaker
Email: hardaker@isi.edu
Dhruv Dhody
Email: dd@dhruvdhody.com