[要約] RFC 6244は、NETCONFとYANGを使用したネットワーク管理のためのアーキテクチャについての要約です。このRFCの目的は、ネットワーク管理の効率性と柔軟性を向上させるために、NETCONFとYANGを組み合わせたアプローチを提案することです。
Internet Engineering Task Force (IETF) P. Shafer
Request for Comments: 6244 Juniper Networks
Category: Informational June 2011
ISSN: 2070-1721
An Architecture for Network Management Using NETCONF and YANG
NetConfとYangを使用したネットワーク管理のアーキテクチャ
Abstract
概要
The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.
ネットワーク構成プロトコル（NetConf）は、ネットワーク内のデバイスのネイティブ機能へのアクセスを提供し、構成データベースを操作し、運用データの取得、特定の操作を呼び出す方法を定義します。Yangは、データと操作の両方でNetConfを介して運ばれるコンテンツを定義する手段を提供します。両方のテクノロジーを使用して、標準モジュールを定義して、デバイスに相互運用性と共通性を提供し、デバイスが独自の機能を表現できるようにします。
This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators.
このドキュメントでは、NetConfとYangがネットワークオペレーターのニーズを満たすネットワーク管理アプリケーションの構築に役立つ方法について説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6244.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6244で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . . . 4
2. Elements of the Architecture . . . . . . . . . . . . . . . . . 5
2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 7
2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12
2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13
2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. DSDL (RELAX NG) . . . . . . . . . . . . . . . . . . . 14
2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 14
3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Building NETCONF- and YANG-Based Solutions . . . . . . . . 14
3.2. Addressing Operator Requirements . . . . . . . . . . . . . 16
3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 18
3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 19
3.3.4. Application Developer . . . . . . . . . . . . . . . . 20
4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 22
4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 24
4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27
4.4. Direction . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . . 28
6.2. Informative References . . . . . . . . . . . . . . . . . . 29
Networks are increasing in complexity and capacity, as well as the density of the services deployed upon them. Uptime, reliability, and predictable latency requirements drive the need for automation. The problems with network management are not simple. They are complex and intricate. But these problems must be solved for networks to meet the stability needs of existing services while incorporating new services in a world where the growth of networks is exhausting the supply of qualified networking engineers.
ネットワークは、複雑さと容量が増加しており、それらに展開されたサービスの密度が増加しています。稼働時間、信頼性、予測可能なレイテンシー要件は、自動化の必要性を促進します。ネットワーク管理の問題は単純ではありません。それらは複雑で複雑です。しかし、これらの問題は、ネットワークの成長が資格のあるネットワークエンジニアの供給を使い果たしている世界に新しいサービスを組み込む一方で、既存のサービスの安定性のニーズを満たすためにネットワークのために解決する必要があります。
In June of 2002, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535]. The members of this workshop made a number of observations and recommendations for the IETF's consideration concerning the issues operators were facing in their network management-related work as well as issues they were having with the direction of the IETF activities in this area.
2002年6月、インターネットアーキテクチャ委員会（IAB）は、ネットワーク管理に関するワークショップを開催しました[RFC3535]。このワークショップのメンバーは、オペレーターがネットワーク管理関連の作業で直面している問題と、この分野でのIETF活動の方向性に伴う問題に関するIETFの考慮事項について、多くの観察と推奨事項を作成しました。
The output of this workshop was focused on current problems. The observations were reasonable and straightforward, including the need for transactions, rollback, low implementation costs, and the ability to save and restore the device's configuration data. Many of the observations give insight into the problems operators were having with existing network management solutions, such as the lack of full coverage of device capabilities and the ability to distinguish between configuration data and other types of data.
このワークショップの出力は、現在の問題に焦点を当てていました。観測は、トランザクションの必要性、ロールバック、実装コストの低さ、デバイスの構成データを保存および復元する機能など、合理的で簡単でした。観察結果の多くは、デバイス機能の完全なカバレッジの欠如や構成データと他のタイプのデータを区別する能力など、オペレーターが既存のネットワーク管理ソリューションで抱えている問題について洞察を与えています。
Based on these directions, the NETCONF working group was formed and the Network Configuration (NETCONF) protocol was created. This protocol defines a simple mechanism where network management applications, acting as clients, can invoke operations on the devices, which act as servers. The NETCONF specification [RFC4741] defines a small set of operations, but goes out of its way to avoid making any requirements on the data carried in those operations, preferring to allow the protocol to carry any data. This "data model agnostic" approach allows data models to be defined independently.
これらの方向に基づいて、NetConfワーキンググループが形成され、ネットワーク構成（NetConf）プロトコルが作成されました。このプロトコルは、クライアントとして機能するネットワーク管理アプリケーションが、サーバーとして機能するデバイスの操作を呼び出すことができる単純なメカニズムを定義します。NetConf仕様[RFC4741]は、少数の操作セットを定義しますが、それらの操作で伝えられるデータに要件を避けるために邪魔にならないようにし、プロトコルがデータを運ぶことを許可します。この「データモデル不可欠な」アプローチにより、データモデルを独立して定義することができます。
But lacking a means of defining data models, the NETCONF protocol was not usable for standards-based work. Existing data modeling languages such as the XML Schema Definition (XSD) [W3CXSD] and the Document Schema Definition Languages (DSDL) [ISODSDL] were considered, but were rejected because of the problem that domains have little natural overlap. Defining a data model or protocol that is encoded in XML is a distinct problem from defining an XML document. The use of NETCONF operations places requirements on the data content that are not shared with the static document problem domain addressed by schema languages like XSD or RELAX NG.
しかし、データモデルを定義する手段がないため、NetConfプロトコルは標準ベースの作業では使用できませんでした。XMLスキーマ定義（XSD）[W3CXSD]やドキュメントスキーマ定義言語（DSDL）[ISODSDL]などの既存のデータモデリング言語は考慮されましたが、ドメインにはほとんど自然な重複がないという問題のために拒否されました。XMLでエンコードされたデータモデルまたはプロトコルを定義することは、XMLドキュメントの定義とは明確な問題です。NetConf操作を使用すると、XSDやRelax Ngなどのスキーマ言語でアドレス指定された静的ドキュメント問題ドメインと共有されていないデータコンテンツに要件があります。
In 2007 and 2008, the issue of a data modeling language for NETCONF was discussed in the OPS and APP areas of IETF 70 and 71, and a design team was tasked with creating a requirements document [RCDML]. After discussing the available options at the CANMOD BoF at IETF 71, the community wrote a charter for the NETMOD working group. An excellent description of this time period is available at <http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html>.
2007年と2008年に、NetConfのデータモデリング言語の問題がIETF 70および71のOPSおよびAPP領域で議論され、設計チームは要件ドキュメント[RCDML]の作成を任されました。IETF 71のCanmod BOFで利用可能なオプションについて議論した後、コミュニティはNetModワーキンググループのチャーターを書きました。この期間の優れた説明は、<http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html>で入手できます。
In 2008 and 2009, the NETMOD working group produced a specification for YANG [RFC6020] as a means for defining data models for NETCONF, allowing both standard and proprietary data models to be published in a form that is easily digestible by human readers and satisfies many of the issues raised in the IAB NM workshop. This brings NETCONF to a point where is can be used to develop standard data models within the IETF.
2008年と2009年に、NetModワーキンググループは、NetConfのデータモデルを定義する手段としてYang [RFC6020]の仕様を作成し、標準データモデルと独自のデータモデルの両方を、人間の読者が簡単に消化できる形式で公開できるようにしました。IAB NMワークショップで提起された問題の。これにより、NetConfはISを使用してIETF内の標準データモデルを開発できるポイントになります。
YANG allows a modeler to create a data model, to define the organization of the data in that model, and to define constraints on that data. Once published, the YANG module acts as a contract between the client and server, with both parties understanding how their peer will expect them to behave. A client knows how to create valid data for the server, and knows what data will be sent from the server. A server knows the rules that govern the data and how it should behave.
Yangを使用すると、モデラーがデータモデルを作成し、そのモデルのデータの構成を定義し、そのデータの制約を定義できます。Yangモジュールは公開されると、クライアントとサーバー間の契約として機能し、両当事者はピアがどのように振る舞うことを期待するかを理解します。クライアントは、サーバーの有効なデータを作成する方法を知っており、サーバーからどのデータが送信されるかを知っています。サーバーは、データを管理するルールとその動作方法を知っています。
YANG also incorporates a level of extensibility and flexibility not present in other model languages. New modules can augment the data hierarchies defined in other modules, seamlessly adding data at appropriate places in the existing data organization. YANG also allows new statements to be defined, allowing the language itself to be expanded in a consistent way.
Yangには、他のモデル言語には存在しないレベルの拡張性と柔軟性も組み込まれています。新しいモジュールは、他のモジュールで定義されているデータ階層を強化し、既存のデータ組織内の適切な場所にデータをシームレスに追加できます。Yangはまた、新しいステートメントを定義することを許可し、言語自体を一貫した方法で拡張できるようにします。
This document presents an architecture for YANG, describing how YANG-related technologies work and how solutions built on them can address the network management problem domain.
このドキュメントでは、Yangのアーキテクチャを提示し、Yang関連のテクノロジーがどのように機能し、それらに基づいて構築されたソリューションがネットワーク管理の問題ドメインにどのように対処できるかを説明しています。
NETCONF defines an XML-based remote procedure call (RPC) mechanism that leverages the simplicity and availability of high-quality XML parsers. XML gives a rich, flexible, hierarchical, standard representation of data that matches the needs of networking devices. NETCONF carries configuration data and operations as requests and replies using RPCs encoded in XML over a connection-oriented transport.
NetConfは、高品質のXMLパーサーのシンプルさと可用性を活用するXMLベースのリモートプロシージャコール（RPC）メカニズムを定義します。XMLは、ネットワーキングデバイスのニーズに合ったデータのリッチで柔軟な階層的な標準表現を提供します。NetConfは、接続指向のトランスポートを介してXMLでエンコードされたRPCを使用して、リクエストと返信として構成データと操作を搭載しています。
XML's hierarchical data representation allows complex networking data to be rendered in a natural way. For example, the following configuration places interfaces in OSPF areas. The <ospf> element contains a list of <area> elements, each of which contain a list of <interface> elements. The <name> element identifies the specific area or interface. Additional configuration for each area or interface appears directly inside the appropriate element.
XMLの階層データ表現により、複雑なネットワークデータを自然な方法でレンダリングできます。たとえば、次の構成は、OSPFエリアにインターフェイスを配置します。<ospf>要素には、<arie>要素のリストが含まれており、それぞれに<interface>要素のリストが含まれています。<name>要素は、特定の領域またはインターフェイスを識別します。各エリアまたはインターフェイスの追加の構成は、適切な要素内に直接表示されます。
<ospf xmlns="http://example.org/netconf/ospf">
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<!-- The priority for this interface -->
<priority>30</priority>
<metric>100</metric>
<dead-interval>120</dead-interval>
</interface>
<interface>
<name>ge-0/0/1.0</name>
<metric>140</metric>
</interface>
</area>
<area>
<name>10.1.2.0</name>
<interface>
<name>ge-0/0/2.0</name>
<metric>100</metric>
</interface>
<interface>
<name>ge-0/0/3.0</name>
<metric>140</metric>
<dead-interval>120</dead-interval>
</interface>
</area>
</ospf>
NETCONF includes mechanisms for controlling configuration datastores. Each datastore is a specific collection of configuration data that can be used as source or target of the configuration-related operations. The device can indicate whether it has a distinct "startup" configuration datastore, whether the current or "running" datastore is directly writable, or whether there is a "candidate" configuration datastore where configuration changes can be made that will not affect the device until a "commit-configuration" operation is invoked.
NetConfには、構成データストアを制御するためのメカニズムが含まれています。各データストアは、構成関連操作のソースまたはターゲットとして使用できる構成データの特定のコレクションです。デバイスは、明確な「起動」構成データストアを備えているか、現在または「実行中」のデータストアが直接書き込みできるかどうか、または、デバイスに影響を与えない構成変更を行うことができる「候補」構成データストアがあるかどうかを示すことができます。「コミット構成」操作が呼び出されます。
NETCONF defines operations that are invoked as RPCs from the client (the application) to the server (running on the device). The following table lists some of these operations:
NetConfは、クライアント（アプリケーション）からサーバー（デバイスで実行されている）にRPCとして呼び出される操作を定義します。次の表には、これらの操作の一部を示します。
+---------------+---------------------------------------------------+
| Operation | Description |
+---------------+---------------------------------------------------+
| commit | Commit the "candidate" configuration to "running" |
| copy-config | Copy one configuration datastore to another |
| delete-config | Delete a configuration datastore |
| edit-config | Change the contents of a configuration datastore |
| get-config | Retrieve all or part of a configuration datastore |
| lock | Prevent changes to a datastore from another party |
| unlock | Release a lock on a datastore |
+---------------+---------------------------------------------------+
NETCONF's "capability" mechanism allows the device to announce the set of capabilities that the device supports, including protocol operations, datastores, data models, and other abilities. These are announced during session establishment as part of the <hello> message. A client can inspect the hello message to determine what the device is capable of and how to interact with the device to perform the desired tasks.
NetConfの「機能」メカニズムにより、プロトコル操作、データストア、データモデル、その他の能力など、デバイスがサポートする一連の機能をデバイスが発表できます。これらは、<hello>メッセージの一部としてセッション設立中に発表されます。クライアントは、ハローメッセージを検査して、デバイスが何ができるか、デバイスと対話して目的のタスクを実行する方法を判断できます。
NETCONF also defines a means of sending asynchronous notifications from the server to the client, described in [RFC5277].
NetConfは、[RFC5277]に記載されているサーバーからクライアントに非同期通知を送信する手段も定義しています。
In addition, NETCONF can fetch state data, receive notifications, and invoke additional RPC methods defined as part of a capability. Complete information about NETCONF can be found in [RFC4741].
さらに、NetConfは状態データを取得し、通知を受信し、機能の一部として定義された追加のRPCメソッドを呼び出すことができます。NetConfに関する完全な情報は、[RFC4741]に記載されています。
NETCONF can run over any transport protocol that meets the requirements defined in RFC 4741, including
NetConfは、RFC 4741で定義されている要件を満たす任意の輸送プロトコルを介して実行できます。
o connection-oriented operation
o 接続指向操作
o authentication
o 認証
o integrity
o 威厳
o confidentiality
o 機密性
[RFC4742] defines a mapping for the Secure Shell (SSH) [RFC4251] protocol, which is the mandatory transport protocol. Others include SOAP [RFC4743], the Blocks Extensible Exchange Protocol (BEEP) [RFC4744], and Transport Layer Security (TLS) [RFC5539].
[RFC4742]は、Secure Shell（SSH）[RFC4251]プロトコルのマッピングを定義します。これは、必須の輸送プロトコルです。その他には、SOAP [RFC4743]、ブロック拡張可能な交換プロトコル（BEEP）[RFC4744]、および輸送層セキュリティ（TLS）[RFC5539]が含まれます。
YANG is a data modeling language for NETCONF. It allows the description of hierarchies of data nodes ("nodes") and the constraints that exist among them. YANG defines data models and how to manipulate those models via NETCONF protocol operations.
Yangは、NetConfのデータモデリング言語です。これにより、データノードの階層（「ノード」）の階層とそれらの間に存在する制約の説明が可能になります。Yangは、NetConfプロトコル操作を介してデータモデルとそれらのモデルを操作する方法を定義します。
Each YANG module defines a data model, uniquely identified by a namespace URI. These data models are extensible in a manner that allows tight integration of standard data models and proprietary data models. Models are built from organizational containers, lists of data nodes, and data-node-forming leafs of the data tree.
各Yangモジュールは、名前空間URIによって一意に識別されるデータモデルを定義します。これらのデータモデルは、標準のデータモデルと独自のデータモデルを緊密に統合できる方法で拡張可能です。モデルは、組織コンテナ、データノードのリスト、およびデータツリーのデータノード形成リーフから構築されています。
module example-ospf { namespace "http://example.org/netconf/ospf"; prefix ospf;
モジュールexample-ospf {namespace "http://example.org/netconf/ospf";プレフィックスOSPF;
import network-types { // Access another module's def'ns prefix nett; }
ネットワークタイプをインポート{//別のモジュールのdef'nsプレフィックスネットにアクセスします。}
container ospf { // Declare the top-level tag
list area { // Declare a list of "area" nodes
key name; // The key "name" identifies list members
leaf name {
type nett:area-id;
}
list interface {
key name;
leaf name {
type nett:interface-name;
}
leaf priority {
description "Designated router priority";
type uint8; // The type is a constraint on
// valid values for "priority".
}
leaf metric {
type uint16 {
range 1..65535;
}
}
leaf dead-interval {
units seconds;
type uint16 {
range 1..65535;
}
}
}
}
}
}
A YANG module defines a data model in terms of the data, its hierarchical organization, and the constraints on that data. YANG defines how this data is represented in XML and how that data is used in NETCONF operations.
Yangモジュールは、データ、その階層構成、およびそのデータの制約に関してデータモデルを定義します。Yangは、このデータがXMLでどのように表現されるか、およびそのデータがNetConf操作でどのように使用されるかを定義します。
The following table briefly describes some common YANG statements:
次の表では、いくつかの一般的なヤンステートメントについて簡単に説明しています。
+--------------+----------------------------------------------------+
| Statement | Description |
+--------------+----------------------------------------------------+
| augment | Extends existing data hierarchies |
| choice | Defines mutually exclusive alternatives |
| container | Defines a layer of the data hierarchy |
| extension | Allows new statements to be added to YANG |
| feature | Indicates parts of the model that are optional |
| grouping | Groups data definitions into reusable sets |
| key | Defines the key leafs for lists |
| leaf | Defines a leaf node in the data hierarchy |
| leaf-list | A leaf node that can appear multiple times |
| list | A hierarchy that can appear multiple times |
| notification | Defines notification |
| rpc | Defines input and output parameters for an RPC |
| | operation |
| typedef | Defines a new type |
| uses | Incorporates the contents of a "grouping" |
+--------------+----------------------------------------------------+
YANG allows the modeler to add constraints to the data model to prevent impossible or illogical data. These constraints give clients information about the data being sent from the device, and also allow the client to know as much as possible about the data the device will accept, so the client can send correct data. These constraints apply to configuration data, but can also be used for rpc and notification data.
Yangを使用すると、モデラーがデータモデルに制約を追加して、不可能または非論理的なデータを防ぐことができます。これらの制約により、クライアントはデバイスから送信されているデータに関する情報を提供し、クライアントがデバイスが受け入れるデータについて可能な限り知ることができるため、クライアントは正しいデータを送信できます。これらの制約は構成データに適用されますが、RPCおよび通知データにも使用できます。
The principal constraint is the "type" statement, which limits the contents of a leaf node to that of the named type. The following table briefly describes some other common YANG constraints:
主な制約は「タイプ」ステートメントであり、葉のノードの内容を指定されたタイプの内容に制限します。次の表は、他のいくつかの一般的なヤンの制約について簡単に説明しています。
+--------------+----------------------------------------------------+
| Statement | Description |
+--------------+----------------------------------------------------+
| length | Limits the length of a string |
| mandatory | Requires the node appear |
| max-elements | Limits the number of instances in a list |
| min-elements | Limits the number of instances in a list |
| must | XPath expression must be true |
| pattern | Regular expression must be satisfied |
| range | Value must appear in range |
| reference | Value must appear elsewhere in the data |
| unique | Value must be unique within the data |
| when | Node is only present when XPath expression is true |
+--------------+----------------------------------------------------+
The "must" and "when" statements use XPath [W3CXPATH] expressions to specify conditions that are semantically evaluated against the data hierarchy, but neither the client nor the server are required to implement the XPath specification. Instead they can use any means to ensure these conditions are met.
「必須」と「とき」のステートメントは、XPath [W3CXPath]式を使用して、データ階層に対して意味的に評価される条件を指定しますが、クライアントもサーバーもXPath仕様を実装する必要はありません。代わりに、あらゆる手段を使用して、これらの条件が満たされるようにすることができます。
YANG uses the "union" type and the "choice" and "feature" statements to give modelers flexibility in defining their data models. The "union" type allows a single leaf to accept multiple types, like an integer or the word "unbounded":
Yangは「ユニオン」タイプと「選択」と「機能」ステートメントを使用して、モデラーがデータモデルを定義する柔軟性を提供します。「ユニオン」タイプにより、単一の葉が整数や「無制限」という言葉など、複数のタイプを受け入れることができます。
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
The "choice" statement lists a set of mutually exclusive nodes, so a valid configuration can choose any one node (or case). The "feature" statement allows the modeler to identify parts of the model that can be optional, and allows the device to indicate whether it implements these optional portions.
「選択」ステートメントには、相互に排他的なノードのセットがリストされているため、有効な構成は任意の1つのノード（またはケース）を選択できます。「機能」ステートメントにより、モデラーはオプションになる可能性のあるモデルの部分を識別でき、デバイスがこれらのオプションの部分を実装するかどうかを示すことができます。
The "deviation" statement allows the device to indicate parts of a YANG module that the device does not faithfully implement. While devices are encouraged to fully abide according to the contract presented in the YANG module, real-world situations may force the device to break the contract. Deviations give a means of declaring this limitation, rather than leaving it to be discovered via run-time errors.
「偏差」ステートメントにより、デバイスは、デバイスが忠実に実装していないYangモジュールの一部を示すことができます。デバイスはYangモジュールで提示された契約に従って完全に順守することを奨励されていますが、実際の状況により、デバイスが契約を破らせることができます。逸脱は、ランタイムエラーを介して発見されるようにするのではなく、この制限を宣言する手段を与えます。
XML includes the concept of namespaces, allowing XML elements from different sources to be combined in the same hierarchy without risking collision. YANG modules define content for specific namespaces, but one module may augment the definition of another module, introducing elements from that module's namespace into the first module's hierarchy.
XMLには、名前空間の概念が含まれており、衝突を危険にさらすことなく、異なるソースのXML要素を同じ階層に組み合わせることができます。Yangモジュールは特定の名前空間のコンテンツを定義しますが、1つのモジュールは別のモジュールの定義を拡張し、そのモジュールの名前空間から最初のモジュールの階層に要素を導入する場合があります。
Since one module can augment another module's definition, hierarchies of definitions are allowed to grow, as definitions from multiple sources are added to the base hierarchy. These augmentations are qualified using the namespace of the source module, helping to avoid issues with name conflicts as the modules change over time.
あるモジュールは別のモジュールの定義を補強できるため、複数のソースからの定義がベース階層に追加されるため、定義の階層が成長することができます。これらの増強は、ソースモジュールの名前空間を使用して適格であり、モジュールが時間とともに変化するにつれて、名前の競合の問題を回避するのに役立ちます。
For example, if the above OSPF configuration were the standard, a vendor module may augment this with vendor-specific extensions.
たとえば、上記のOSPF構成が標準である場合、ベンダーモジュールはベンダー固有の拡張機能でこれを補強する場合があります。
module vendorx-ospf { namespace "http://vendorx.example.com/ospf"; prefix vendorx;
モジュールvendorx-ospf {namespace "http://vendorx.example.com/ospf";接頭辞Vendorx;
import example-ospf {
prefix ospf;
}
augment /ospf:ospf/ospf:area/ospf:interfaces {
leaf no-neighbor-down-notification {
type empty;
description "Don't inform other protocols about"
+ " neighbor down events";
}
}
}
The <no-neighbor-down-notification> element is then placed in the vendorx namespace:
<no-neighbor-down-notification>要素は、Vendorxの名前空間に配置されます。
<ospf xmlns="http://example.org/netconf/ospf"
xmlns:vendorx="http://vendorx.example.com/ospf">
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<priority>30</priority>
<vendorx:no-neighbor-down-notification/>
</interface>
</area>
</ospf>
Augmentations are seamlessly integrated with base modules, allowing them to be fetched, archived, loaded, and deleted within their natural hierarchy. If a client application asks for the configuration for a specific OSPF area, it will receive the sub-hierarchy for that area, complete with any augmented data.
拡張はベースモジュールとシームレスに統合されているため、自然階層内でフェッチ、アーカイブ、ロード、削除できます。クライアントアプリケーションが特定のOSPF領域の構成を要求した場合、その領域のサブヒーラルキーを受け取り、補強データを備えています。
The YANG data modeling language is the central piece of a group of related technologies. The YANG language itself, described in [RFC6020], defines the syntax of the language and its statements, the meaning of those statements, and how to combine them to build the hierarchy of nodes that describe a data model.
Yangデータモデリング言語は、関連するテクノロジーのグループの中心的な部分です。[RFC6020]に記載されているYang言語自体は、言語とそのステートメントの構文、それらのステートメントの意味、およびそれらを組み合わせてデータモデルを説明するノードの階層を構築する方法を定義します。
That document also defines the "on the wire" XML content for NETCONF operations on data models defined in YANG modules. This includes the basic mapping between YANG data tree nodes and XML elements, as well as mechanisms used in <edit-config> content to manipulate that data, such as arranging the order of nodes within a list.
このドキュメントでは、Yangモジュールで定義されたデータモデルのNetConf操作の「On the Wire」XMLコンテンツも定義しています。これには、YangデータツリーノードとXML要素間の基本マッピング、および<edit-config>コンテンツで使用されるメカニズムが含まれ、リスト内のノードの順序を配置するなど、そのデータを操作します。
YANG uses a syntax that is regular and easily described, primarily designed for human readability. YANG's syntax is friendly to email, diff, patch, and the constraints of RFC formatting.
Yangは、主に人間の読みやすさのために設計された定期的で簡単に説明できる構文を使用します。Yangの構文は、電子メール、diff、パッチ、およびRFCフォーマットの制約に優しいです。
In some environments, incorporating a YANG parser may not be an acceptable option. For those scenarios, an XML grammar for YANG is defined as YIN (YANG Independent Notation). YIN allows the use of XML parsers that are readily available in both open source and commercial versions. Conversion between YANG and YIN is direct, loss-less, and reversible. YANG statements are converted to XML elements, preserving the structure and content of YANG, but enabling the use of off-the-shelf XML parsers rather than requiring the integration of a YANG parser. YIN maintains complete semantic equivalence with YANG.
一部の環境では、ヤンパーサーを組み込むことは許容可能な選択肢ではない場合があります。これらのシナリオでは、YangのXML文法はYin（Yang Independent Notation）として定義されます。YINでは、オープンソースと商業バージョンの両方で容易に利用できるXMLパーサーの使用が許可されています。ヤンと陰の間の変換は直接的で、損失がなく、可逆的です。YangステートメントはXML要素に変換され、Yangの構造と内容を保存しますが、Yangパーサーの統合を必要とするのではなく、既製のXMLパーサーの使用を可能にします。Yinは、Yangとの完全なセマンティックの同等性を維持しています。
Since NETCONF content is encoded in XML, it is natural to use XML schema languages for their validation. To facilitate this, YANG offers a standardized mapping of YANG modules into Document Schema Definition Languages [RFC6110], of which RELAX NG is a major component.
NetConfコンテンツはXMLでエンコードされているため、検証にXMLスキーマ言語を使用することは自然です。これを容易にするために、YangはYangモジュールの標準化されたマッピングをドキュメントスキーマ定義言語[RFC6110]に提供します。
DSDL is considered to be the best choice as a standard schema language because it addresses not only grammar and datatypes of XML documents but also semantic constraints and rules for modifying the information set of the document.
DSDLは、XMLドキュメントの文法とデータ型だけでなく、ドキュメントの情報セットを変更するためのセマンティックな制約とルールにも対処するため、標準スキーマ言語として最良の選択であると考えられています。
In addition, DSDL offers formal means for coordinating multiple independent schemas and specifying how to apply the schemas to the various parts of the document. This is useful since YANG content is typically composed of multiple vocabularies.
さらに、DSDLは、複数の独立したスキーマを調整し、ドキュメントのさまざまな部分にスキーマを適用する方法を指定するための正式な手段を提供します。ヤン含有量は通常、複数の語彙で構成されているため、これは便利です。
YANG supports a number of builtin types, and allows additional types to be derived from those types in an extensible manner. New types can add additional restrictions to allowable data values.
Yangは多くのビルトインタイプをサポートしており、追加のタイプを拡張可能な方法でそれらのタイプから導出できるようにします。新しいタイプは、許容データ値に追加の制限を追加できます。
A standard type library for use by YANG is available [RFC6021]. These YANG modules define commonly used data types for IETF-related standards.
Yangが使用する標準タイプライブラリが利用可能です[RFC6021]。これらのYangモジュールは、IETF関連標準の一般的に使用されるデータ型を定義します。
A set of additional guidelines is defined that indicate desirable usage for authors and reviewers of Standards-Track specifications containing YANG data model modules [RFC6087]. These guidelines should be used as a basis for reviews of other YANG data model documents.
Yangデータモデルモジュール[RFC6087]を含む標準トラック仕様の著者とレビューアの望ましい使用法を示す追加のガイドラインのセットが定義されています。これらのガイドラインは、他のヤンデータモデルドキュメントのレビューの基礎として使用する必要があります。
In the typical YANG-based solution, the client and server are driven by the content of YANG modules. The server includes the definitions of the modules as meta-data that is available to the NETCONF engine. This engine processes incoming requests, uses the meta-data to parse and verify the request, performs the requested operation, and returns the results to the client.
典型的なヤンベースのソリューションでは、クライアントとサーバーはYangモジュールのコンテンツによって駆動されます。サーバーには、NetConfエンジンが利用できるメタデータとしてのモジュールの定義が含まれています。このエンジンは、着信要求を処理し、メタデータを使用して要求を解析および検証し、要求された操作を実行し、結果をクライアントに返します。
+----------------------------+
|Server (device) |
| +--------------------+ |
| | configuration | |
+----+ | | ---------------| |
|YANG|+ | | m d state data | |
|mods||+ | | e a ---------------| |
+----+|| -----> | t t notifications | |
+----+| | | a a ---------------| |
+----+ | | operations | |
| +--------------------+ |
| ^ |
| | |
| v |
+------+ | +-------------+ |
| | -------------> | | |
|Client| <rpc> | | NETCONF | |
| (app)| | | engine | |
| | <------------ | | |
+------+ <rpc-reply> +-------------+ |
| / \ |
| / \ |
| / \ |
| +--------+ +---------+ |
| | config | |system |+ |
| | data- | |software ||+ |
| | base | |component||| |
| +--------+ +---------+|| |
| +---------+| |
| +---------+ |
+----------------------------+
To use YANG, YANG modules must be defined to model the specific problem domain. These modules are then loaded, compiled, or coded into the server.
Yangを使用するには、特定の問題ドメインをモデル化するためにYangモジュールを定義する必要があります。これらのモジュールは、サーバーにロード、コンパイル、またはコーディングされます。
The sequence of events for the typical client/server interaction may be as follows:
典型的なクライアント/サーバーの相互作用のための一連のイベントは次のとおりです。
o A client application ([C]) opens a NETCONF session to the server (device) ([S])
o クライアントアプリケーション（[c]）がサーバー（デバイス）（[s]）にネットコンセッションを開きます
o [C] and [S] exchange <hello> messages containing the list of capabilities supported by each side, allowing [C] to learn the modules supported by [S]
o [c]および[s] Exchange <こんにちは>各側がサポートする機能のリストを含むメッセージ。
o [C] builds and sends an operation defined in the YANG module, encoded in XML, within NETCONF's <rpc> element
o [c] NetConfの<RPC>要素内でXMLでエンコードされたYangモジュールで定義された操作を構築および送信します
o [S] receives and parses the <rpc> element
o [s] <rpc>要素を受信して解析する
o [S] verifies the contents of the request against the data model defined in the YANG module
o [S] Yangモジュールで定義されているデータモデルに対する要求の内容を検証します
o [S] performs the requested operation, possibly changing the configuration datastore
o [s]要求された操作を実行し、おそらく構成データストアを変更する
o [S] builds the response, containing the response, any requested data, and any errors
o [s]応答、要求されたデータ、およびエラーを含む応答を構築します
o [S] sends the response, encoded in XML, within NETCONF's <rpc-reply> element
o [s] netconfの<rpc-reply>要素内でXMLでエンコードされた応答を送信します
o [C] receives and parses the <rpc-reply> element
o [c] <rpc-reply>要素を受信して解析する
o [C] inspects the response and processes it as needed
o [c]応答を検査し、必要に応じて処理します
Note that there is no requirement for the client or server to process the YANG modules in this way. The server may hard code the contents of the data model, rather than handle the content via a generic engine. Or the client may be targeted at the specific YANG model, rather than being driven generically. Such a client might be a simple shell script that stuffs arguments into an XML payload template and sends it to the server.
クライアントまたはサーバーがこの方法でYangモジュールを処理する必要はないことに注意してください。サーバーは、一般的なエンジンを介してコンテンツを処理するのではなく、データモデルのコンテンツをハードコードする場合があります。または、クライアントは、一般的に運転されるのではなく、特定のヤンモデルをターゲットにすることができます。このようなクライアントは、引数をXMLペイロードテンプレートに詰めてサーバーに送信する単純なシェルスクリプトである可能性があります。
NETCONF and YANG address many of the issues raised in the IAB NM workshop.
NetConfとYangは、IAB NMワークショップで提起された多くの問題に取り組んでいます。
o Ease of use: YANG is designed to be human friendly, simple, and readable. Many tricky issues remain due to the complexity of the problem domain, but YANG strives to make them more visible and easier to deal with.
o 使いやすさ：Yangは、人間に優しく、シンプルで、読みやすいように設計されています。多くのトリッキーな問題は、問題ドメインの複雑さのために残っていますが、ヤンはそれらをより目立たせ、対処しやすくするよう努めています。
o Configuration and state data: YANG clearly divides configuration data from other types of data.
o 構成と状態データ：Yangは、構成データを他のタイプのデータから明らかに分割します。
o Transactions: NETCONF provides a simple transaction mechanism.
o トランザクション：NetConfは簡単なトランザクションメカニズムを提供します。
o Generation of deltas: A YANG module gives enough information to generate the delta needed to change between two configuration data sets.
o Deltasの生成：Yangモジュールは、2つの構成データセット間で変更するために必要なデルタを生成するのに十分な情報を提供します。
o Dump and restore: NETCONF gives the ability to save and restore configuration data. This can also be performed for a specific YANG module.
o ダンプと復元：NetConfは、構成データを保存および復元する機能を提供します。これは、特定のYangモジュールに対しても実行できます。
o Network-wide configuration: NETCONF supports robust network-wide configuration transactions via the commit and confirmed-commit capabilities. When a change is attempted that affects multiple devices, these capabilities simplify the management of failure scenarios, resulting in the ability to have transactions that will dependably succeed or fail atomically.
o ネットワーク全体の構成：NetConfは、コミットおよび確認されたコミット機能を介した堅牢なネットワーク全体の構成トランザクションをサポートします。複数のデバイスに影響を与える変更が試行されると、これらの機能は障害シナリオの管理を簡素化し、結果として確実に成功または原子的に成功または失敗するトランザクションを持つ機能をもたらします。
o Text-friendly: YANG modules are very text friendly, as is the data they define.
o テキストフレンドリー：Yangモジュールは、それらが定義するデータと同様に非常にテキストに優しいです。
o Configuration handling: NETCONF addresses the ability to distinguish between distributing configuration data and activating it.
o 構成処理：NetConfは、構成データの分散データを区別し、それをアクティブ化する機能に対応します。
o Task-oriented: A YANG module can define specific tasks as RPC operations. A client can choose to invoke the RPC operation or to access any underlying data directly.
o タスク指向：Yangモジュールは、特定のタスクをRPC操作として定義できます。クライアントは、RPC操作を呼び出すか、基礎となるデータに直接アクセスすることを選択できます。
o Full coverage: YANG modules can be defined that give full coverage to all the native abilities of the device. Giving this access avoids the need to resort to the command line interface (CLI) using tools such as Expect [SWEXPECT].
o 完全なカバレッジ：デバイスのすべてのネイティブ能力を完全にカバーするYangモジュールを定義できます。このアクセスを提供することで、[Swexpect]などのツールを使用して、コマンドラインインターフェイス（CLI）に頼る必要性が回避されます。
o Timeliness: YANG modules can be tied to CLI operations, so all native operations and data are immediately available.
o 適時性：YangモジュールはCLI操作に結び付けることができるため、すべてのネイティブ操作とデータがすぐに利用可能になります。
o Implementation difficulty: YANG's flexibility enables modules that can be more easily implemented. Adding "features" and replacing "third normal form" with a natural data hierarchy should reduce complexity.
o 実装の難易度：Yangの柔軟性により、より簡単に実装できるモジュールが可能になります。「機能」を追加し、「3番目の通常のフォーム」を自然なデータ階層に置き換えると、複雑さが軽減されるはずです。
o Simple data modeling language: YANG has sufficient power to be usable in other situations. In particular, on-box API and native CLI can be integrated to achieve simplification of the infrastructure.
o 単純なデータモデリング言語：Yangには、他の状況で使用可能になるのに十分な力があります。特に、オンボックスAPIとネイティブCLIを統合して、インフラストラクチャの簡素化を実現できます。
o Internationalization: YANG uses UTF-8 [RFC3629] encoded Unicode characters.
o 国際化：YangはUTF-8 [RFC3629]エンコードされたUnicode文字を使用します。
o Event correlation: YANG integrates RPC operations, notification, configuration, and state data, enabling internal references. For example, a field in a notification can be tagged as pointing to a BGP peer, and the client application can easily find that peer in the configuration data.
o イベント相関：Yangは、RPC操作、通知、構成、および状態データを統合し、内部参照を可能にします。たとえば、通知のフィールドはBGPピアを指すようにタグ付けでき、クライアントアプリケーションは構成データでそのピアを簡単に見つけることができます。
o Implementation costs: Significant effort has been made to keep implementation costs as low as possible.
o 実装コスト：実装コストを可能な限り低く抑えるために多大な努力が払われています。
o Human-friendly syntax: YANG's syntax is optimized for the reader, specifically the reviewer on the basis that this is the most common human interaction.
o 人間に優しい構文：Yangの構文は、これが最も一般的な人間の相互作用であることに基づいて、読者、特にレビュー担当者向けに最適化されています。
o Post-processing: Use of XML will maximize the opportunities for post-processing of data, possibly using XML-based technologies like XPath [W3CXPATH], XQuery [W3CXQUERY], and XSLT [W3CXSLT].
o 後処理：XMLの使用は、XPath [W3CXPath]、XQuery [W3CXQuery]、XSLT [W3CXSLT]などのXMLベースのテクノロジーを使用して、データの後処理の機会を最大化します。
o Semantic mismatch: Richer, more descriptive data models will reduce the possibility of semantic mismatch. With the ability to define new primitives, YANG modules will be more specific in content, allowing more enforcement of rules and constraints.
o セマンティックミスマッチ：より豊かで説明的なデータモデルは、セマンティックミスマッチの可能性を減らします。新しいプリミティブを定義する機能により、Yangモジュールはコンテンツがより具体的になり、ルールと制約の施行が増えます。
o Security: NETCONF runs over transport protocols secured by SSH or TLS, allowing secure communications and authentication using well-trusted technology. The secure transport can use existing key and credential management infrastructure, reducing deployment costs.
o セキュリティ：NetConfは、SSHまたはTLSによって保護された輸送プロトコルを介して実行され、適切に信頼されたテクノロジーを使用して安全な通信と認証が可能になります。安全なトランスポートは、既存のキーおよび資格管理インフラストラクチャを使用して、展開コストを削減できます。
o Reliable: NETCONF and YANG are solid and reliable technologies. NETCONF is connection based, and includes automatic recovery mechanisms when the connection is lost.
o 信頼性：NetConfとYangは、堅実で信頼できる技術です。NetConfは接続ベースであり、接続が失われたときに自動回復メカニズムが含まれます。
o Delta friendly: YANG-based models support operations that are delta friendly. Add, change, insert, and delete operations are all well defined.
o デルタフレンドリー：ヤンベースのモデルは、デルタフレンドリーの操作をサポートしています。追加、変更、挿入、および削除操作はすべて明確に定義されています。
o Method-oriented: YANG allows new RPC operations to be defined, including an operation name, which is essentially a method. The input and output parameters of the RPC operations are also defined in the YANG module.
o 方法指向：Yangは、本質的にメソッドである操作名を含む新しいRPC操作を定義することを許可します。RPC操作の入力パラメーターと出力パラメーターは、Yangモジュールでも定義されています。
Building NETCONF- and YANG-based solutions requires interacting with many distinct groups. Modelers must understand how to build useful models that give structure and meaning to data while maximizing the flexibility of that data to "future proof" their work. Reviewers need to quickly determine if that structure is accurate. Device developers need to code that data model into their devices, and application developers need to code their applications to take advantage of that data model. There are a variety of strategies for performing each piece of this work. This section discusses some of those strategies.
NetConfおよびYangベースのソリューションを構築するには、多くの異なるグループとの相互作用が必要です。モデラーは、データに構造と意味を提供する有用なモデルを構築する方法を理解し、そのデータの柔軟性を最大化して作業を「将来の証明」に最大化する必要があります。レビュー担当者は、その構造が正確かどうかを迅速に判断する必要があります。デバイス開発者は、そのデータモデルをデバイスにコーディングする必要があり、アプリケーション開発者はそのデータモデルを活用するためにアプリケーションをコーディングする必要があります。この作品の各部分を実行するためのさまざまな戦略があります。このセクションでは、これらの戦略のいくつかについて説明します。
The modeler defines a data model based on their in-depth knowledge of the problem domain being modeled. This model should be as simple as possible, but should balance complexity with expressiveness. The organization of the model not only should target the current model but also should allow for extensibility from other modules and for adaptability to future changes.
モデラーは、モデル化されている問題ドメインに関する詳細な知識に基づいてデータモデルを定義します。このモデルは可能な限り単純でなければなりませんが、複雑さと表現力のバランスをとる必要があります。モデルの構成は、現在のモデルをターゲットにするだけでなく、他のモジュールからの拡張性と将来の変更への適応性を可能にする必要があります。
Additional modeling issues are discussed in Section 4.
追加のモデリングの問題については、セクション4で説明します。
The reviewer role is perhaps the most important and the time reviewers are willing to give is precious. To help the reviewer, YANG stresses readability, with a human-friendly syntax, natural data hierarchy, and simple, concise statements.
レビュアーの役割はおそらく最も重要であり、タイムレビュアーが喜んで与えてくれることは貴重です。レビュアーを支援するために、Yangは人間に優しい構文、自然なデータ階層、および単純な簡潔なステートメントで、読みやすさを強調します。
The YANG model tells the device developer what data is being modeled. The developer reads the YANG models and writes code that supports the model. The model describes the data hierarchy and associated constraints, and the description and reference material helps the developer understand how to transform the model's view into the device's native implementation.
Yangモデルは、デバイス開発者にどのデータがモデル化されているかを伝えます。開発者はYangモデルを読み取り、モデルをサポートするコードを書きます。このモデルは、データの階層と関連する制約を説明し、説明と参照資料は、開発者がモデルのビューをデバイスのネイティブ実装に変換する方法を理解するのに役立ちます。
The YANG model can be compiled into a YANG-based engine for either the client or server side. Incoming data can be validated, as can outgoing data. The complete configuration datastore may be validated in accordance with the constraints described in the data model.
Yangモデルは、クライアント側またはサーバー側のYangベースのエンジンにコンパイルできます。発信データと同様に、着信データを検証できます。完全な構成データストアは、データモデルで説明されている制約に従って検証できます。
Serializers and de-serializers for generating and receiving NETCONF content can be driven by the meta-data in the model. As data is received, the meta-data is consulted to ensure the validity of incoming XML elements.
ネットコンコンテンツを生成および受信するためのシリアル化剤とデジリアル化剤は、モデルのメタデータによって駆動できます。データが受信されると、メタデータが相談され、着信XML要素の有効性が確保されます。
The YANG module dictates the XML encoding for data sent via NETCONF. The rules that define the encoding are fixed, so the YANG module can be used to ascertain whether a specific NETCONF payload is obeying the rules.
Yangモジュールは、NetConfを介して送信されたデータのXMLエンコードを決定します。エンコードを定義するルールは修正されるため、Yangモジュールを使用して、特定のNetConfペイロードがルールに従っているかどうかを確認できます。
The YANG module tells the application developer what data can be modeled. Developers can inspect the modules and take one of three distinct views. In this section, we will consider them and the impact of YANG on their design. In the real world, most applications are a mixture of these approaches.
Yangモジュールは、アプリケーション開発者にどのデータをモデル化できるかを伝えます。開発者は、モジュールを検査し、3つの異なるビューのいずれかを取得できます。このセクションでは、それらとヤンのデザインへの影響を考慮します。現実の世界では、ほとんどのアプリケーションはこれらのアプローチの混合です。
An application can be coded against the specific, well-known contents of YANG modules, implementing their organization, rules, and logic directly with explicit knowledge. For example, a script could be written to change the domain name of a set of devices using a standard YANG module that includes such a leaf node. This script takes the new domain name as an argument and inserts it into a string containing the rest of the XML encoding as required by the YANG module. This content is then sent via NETCONF to each of the devices.
アプリケーションは、Yangモジュールの特定のよく知られたコンテンツに対してコーディングでき、明示的な知識で組織、ルール、ロジックを直接実装できます。たとえば、スクリプトは、そのような葉のノードを含む標準のYangモジュールを使用して、デバイスのセットのドメイン名を変更するために書き込むことができます。このスクリプトは、新しいドメイン名を引数として取得し、Yangモジュールで要求されるようにXMLエンコードの残りを含む文字列に挿入します。このコンテンツは、NetConfを介して各デバイスに送信されます。
This type of application is useful for small, fixed problems where the cost and complexity of flexibility are overwhelmed by the ease of hard coding direct knowledge into the application.
このタイプのアプリケーションは、柔軟性のコストと複雑さがアプリケーションへの直接的な知識の容易さによって圧倒される小さな固定問題に役立ちます。
An application may take a generic, bottom-up approach to configuration, concentrating on the device's data directly and treating that data without specific understanding.
アプリケーションは、構成に対する一般的なボトムアップアプローチをとり、デバイスのデータに直接集中し、具体的な理解なしにそのデータを処理する場合があります。
YANG modules may be used to drive the operation of the YANG equivalent of a "MIB browser". Such an application manipulates the device's configuration data based on the data organization contained in the YANG module. For example, a GUI may present a straightforward visualization where elements of the YANG hierarchy are depicted in a hierarchy of folders or GUI panels. Clicking on a line expands to the contents of the matching XML hierarchy.
Yangモジュールは、「MIBブラウザ」に相当するYangの動作を駆動するために使用できます。このようなアプリケーションは、Yangモジュールに含まれるデータ組織に基づいて、デバイスの構成データを操作します。たとえば、GUIは、ヤン階層の要素がフォルダーまたはGUIパネルの階層に描かれる簡単な視覚化を提示する場合があります。行をクリックすると、一致するXML階層の内容に展開されます。
This type of GUI can easily be built by generating XSLT stylesheets from the YANG data models. An XSLT engine can then be used to turn configuration data into a set of web pages.
このタイプのGUIは、YangデータモデルからXSLTスタイルシートを生成することで簡単に構築できます。XSLTエンジンを使用して、構成データをWebページのセットに変えることができます。
The YANG modules allow the application to enforce a set of constraints without understanding the semantics of the YANG module.
Yangモジュールでは、Yangモジュールのセマンティクスを理解せずに、アプリケーションが一連の制約を実施できます。
In contrast to the bottom-up approach, the top-down approach allows the application to take a view of the configuration data that is distinct from the standard and/or proprietary YANG modules. The application is free to construct its own model for data organization and to present this model to the user. When the application needs to transmit data to a device, the application transforms its data from the problem-oriented view of the world into the data needed for that particular device. This transformation is under the control and maintenance of the application, allowing the transformation to be changed and updated without affecting the device.
ボトムアップアプローチとは対照的に、トップダウンアプローチにより、アプリケーションは標準および/または独自のヤンモジュールとは異なる構成データをビューを取得できます。アプリケーションは、データ組織向けに独自のモデルを自由に構築し、このモデルをユーザーに提示することができます。アプリケーションがデータをデバイスに送信する必要がある場合、アプリケーションはそのデータを、世界の問題指向のビューからその特定のデバイスに必要なデータに変換します。この変換はアプリケーションの制御とメンテナンスの下にあり、デバイスに影響を与えることなく変換を変更および更新することができます。
For example, an application could be written that models VPNs in a network-oriented view. The application would need to transform these high-level VPN definitions into the configuration data that would be handed to any particular device within a VPN.
たとえば、ネットワーク指向のビューでVPNをモデル化するアプリケーションを作成できます。アプリケーションは、これらの高レベルのVPN定義をVPN内の特定のデバイスに渡す構成データに変換する必要があります。
Even in this approach, YANG is useful since it can be used to model the VPN. For example, the following VPN straw-man models a list of VPNs, each with a protocol, a topology, a list of member interfaces, and a list of classifiers.
このアプローチでさえ、YangはVPNのモデル化に使用できるため有用です。たとえば、次のVPNストローマンは、それぞれがプロトコル、トポロジ、メンバーインターフェイスのリスト、および分類子のリストを備えたVPNのリストをモデル化しています。
list example-bgpvpn {
key name;
leaf name { ... }
leaf protocol {
type enumeration {
enum bgpvpn;
enum l2vpn;
}
}
leaf topology {
type enumeration {
enum hub-n-spoke;
enum mesh;
}
}
list members {
key "device interface";
leaf device { ... }
leaf interface { ... }
}
list classifiers {
...
}
}
The application can use such a YANG module to drive its operation, building VPN instances in a database and then pushing the configuration for those VPNs to individual devices either using a standard device model (e.g., example-bgpvpn.yang) or by transforming that standard device content into some proprietary format for devices that do not support that standard.
このようなYangモジュールを使用して操作を駆動し、データベースにVPNインスタンスを構築し、それらのVPNの構成を標準デバイスモデル（例-BGPVPN.YANGなど）を使用して個々のデバイスにプッシュするか、その標準を変換することでプッシュできます。デバイスコンテンツは、その標準をサポートしていないデバイス用の一部の独自の形式になります。
This section discusses considerations the modeler should be aware of while developing models in YANG.
このセクションでは、ヤンでモデルを開発する際にモデラーが認識すべき考慮事項について説明します。
The concept of default values is simple, but their details, representation, and interaction with configuration data can be difficult issues. NETCONF leaves default values as a data model issue, and YANG gives flexibility to the device implementation in terms of how default values are handled. The requirement is that the device "MUST operationally behave as if the leaf was present in the data tree with the default value as its value". This gives the device implementation choices in how default values are handled.
デフォルト値の概念は単純ですが、その詳細、表現、および構成データとの相互作用は難しい問題になる可能性があります。NetConfはデフォルト値をデータモデルの問題として残し、Yangはデフォルト値の処理方法に関してデバイスの実装に柔軟性を与えます。要件は、デバイスが「葉がデータツリーに存在するかのように動作的に動作する必要があることです。これにより、デバイスの実装の選択肢がデフォルト値の処理方法を選択します。
One choice is to view the configuration as a set of instructions for how the device should be configured. If a data value that is given as part of those instructions is the default value, then it should be retained as part of the configuration, but if it is not explicitly given, then the value is not considered to be part of the configuration.
選択の1つは、設定をデバイスの構成方法の一連の指示として表示することです。これらの命令の一部として指定されたデータ値がデフォルト値である場合、構成の一部として保持する必要がありますが、明示的に与えられない場合、値は構成の一部とは見なされません。
Another choice is to trim values that are identical to the default values, implicitly removing them from the configuration datastore. The act of setting a leaf to its default value effectively deletes that leaf.
もう1つの選択は、デフォルト値と同一の値をトリミングし、構成データストアから暗黙的に削除することです。葉をデフォルト値に設定する行為は、その葉を効果的に削除します。
The device could also choose to report all default values, regardless of whether they were explicitly set. This choice eases the work of a client that needs default values, but may significantly increase the size of the configuration data.
デバイスは、明示的に設定されたかどうかに関係なく、すべてのデフォルト値を報告することもできます。この選択により、デフォルト値が必要なクライアントの作業が容易になりますが、構成データのサイズが大幅に増加する可能性があります。
These choices reflect the default handling schemes of widely deployed networking devices and supporting them allows YANG to reduce implementation and deployment costs of YANG-based models.
これらの選択は、広く展開されているネットワークデバイスのデフォルトの処理スキームを反映しており、それらをサポートすることで、YangはYangベースのモデルの実装と展開コストを削減できます。
When the client retrieves data from the device, it must be prepared to handle the absence of leaf nodes with the default value, since the server is not required to send such leaf elements. This permits the device to implement either of the first two default handling schemes given above.
クライアントがデバイスからデータを取得するとき、サーバーはそのような葉要素を送信する必要がないため、デフォルト値で葉のノードの不在を処理する準備をする必要があります。これにより、デバイスは上記の最初の2つのデフォルトの処理スキームのいずれかを実装できます。
Regardless of the implementation choice, the device can support the "with-defaults" capability [RFC6243] and give the client the ability to select the desired handling of default values.
実装の選択に関係なく、デバイスは「デフォルト付き」機能[RFC6243]をサポートし、クライアントにデフォルト値の目的の処理を選択する機能を提供できます。
When evaluating the XPath expressions for constraints like "must" and "when", the evaluation context for the expressions will include any appropriate default values, so the modeler can depend on consistent behavior from all devices.
「必須」や「いつ」などの制約についてXPath式を評価する場合、式の評価コンテキストには適切なデフォルト値が含まれているため、モデラーはすべてのデバイスからの一貫した動作に依存できます。
In developing good data models, there are many conflicting interests the data modeler must keep in mind. Modelers need to be aware of five issues with models and devices:
優れたデータモデルの開発では、データモデラーが心に留めておく必要がある多くの矛盾する関心があります。モデラーは、モデルとデバイスの5つの問題に注意する必要があります。
o usefulness
o 使いやすさ
o compliance
o コンプライアンス
o flexibility
o 柔軟性
o extensibility
o 拡張性
o deviations
o 逸脱
For a model to be interesting, it must be useful, solving a problem in a more direct or more powerful way than can be accomplished without the model. The model should maximize the usefulness of the model within the problem domain.
モデルが興味深いためには、それが有用でなければなりません。モデルなしで達成できるよりも、より直接的またはより強力な方法で問題を解決する必要があります。モデルは、問題ドメイン内のモデルの有用性を最大化する必要があります。
Modelers should build models that maximize the number of devices that can faithfully implement the model. If the model is drawn too narrowly, or includes too many assumptions about the device, then the difficulty and cost of accurately implementing the model will lead to low-quality implementations and interoperability issues, and will reduce the value of the model.
モデラーは、モデルを忠実に実装できるデバイスの数を最大化するモデルを構築する必要があります。モデルがあまりにも狭く描画されている場合、またはデバイスに関する仮定が多すぎる場合、モデルを正確に実装する難しさとコストが低品質の実装と相互運用性の問題につながり、モデルの価値が低下します。
Modelers can use the "feature" statement in their models to give the device some flexibility by partitioning their model and allowing the device to indicate which portions of the model are implemented on the device. For example, if the model includes some "logging" feature, a device with no storage facilities for the log can tell the client that it does not support this feature of the model.
モデラーは、モデルの「機能」ステートメントを使用して、モデルをパーティション化し、デバイスがデバイスにモデルのどの部分を実装されているかをデバイスが示すことにより、デバイスにある程度の柔軟性を提供できます。たとえば、モデルに「ロギング」機能が含まれている場合、ログのストレージ機能を持たないデバイスは、モデルのこの機能をサポートしていないことをクライアントに伝えることができます。
Models can be extended via the "augment" statement, and the modeler should consider how their model is likely to be extended. These augmentations can be defined by vendors, applications, or standards bodies.
モデルは「Augment」ステートメントを介して拡張でき、モデラーはモデルがどのように拡張されるかを検討する必要があります。これらの増強は、ベンダー、アプリケーション、または標準団体によって定義できます。
Deviations are a means of allowing the devices to indicate where its implementation is not in full compliance with the model. For example, once a model is published, an implementer may decide to make a particular node configurable, where the standard model describes it as state data. The implementation reports the value normally and may declare a deviation that this device behaves in a different manner than the standard. Applications capable of discovering this deviation can make allowances, but applications that do not discover the deviation can continue treating the implementation as if it were compliant.
逸脱は、デバイスがその実装がモデルに完全に準拠していない場所を示すことを許可する手段です。たとえば、モデルが公開されると、実装者は特定のノードを構成可能にすることを決定できます。標準モデルはそれを状態データとして記述します。実装は正常に値を報告し、このデバイスが標準とは異なる方法で動作するという偏差を宣言する場合があります。この逸脱を発見できるアプリケーションは、手当を作ることができますが、偏差を発見しないアプリケーションは、実装が準拠しているかのように扱い続けることができます。
Rarely, implementations may make decisions that prevent compliance with the standard. Such occasions are regrettable, but they remain a part of reality, and modelers and application writers ignore them at their own risk. An implementation that emits an integer leaf as "cow" would be difficult to manage, but applications should expect to encounter such misbehaving devices in the field.
まれに、実装は標準の遵守を防ぐ決定を下す可能性があります。そのような機会は残念ですが、それらは現実の一部であり続けており、モデラーとアプリケーションライターは彼ら自身の責任でそれらを無視します。整数の葉を「牛」として放出する実装を管理するのは難しいでしょうが、アプリケーションはこのような誤動作デバイスに現場で遭遇することを期待するはずです。
Despite this, both client and server should view the YANG module as a contract, with both sides agreeing to abide by the terms. The modeler should be explicit about the terms of such a contract, and both client and server implementations should strive to faithfully and accurately implement the data model described in the YANG module.
それにもかかわらず、クライアントとサーバーの両方は、Yangモジュールを契約と見なす必要があり、双方は条件を順守することに同意します。モデラーは、そのような契約の条件について明示的である必要があり、クライアントとサーバーの実装の両方が、Yangモジュールで説明されているデータモデルを忠実かつ正確に実装するよう努力する必要があります。
The distinction between configuration data, operational state data, and statistics is important to understand for data model writers and people who plan to extend the NETCONF protocol. This section first discusses some background and then provides a definition and some examples.
構成データ、運用状態データ、統計の区別は、データモデルライターとNetConfプロトコルを拡張する予定の人々にとって理解するために重要です。このセクションでは、最初にいくつかの背景について説明し、次に定義といくつかの例を提供します。
During the IAB NM workshop, operators did formulate the following two requirements, as listed in [RFC3535]:
IAB NMワークショップ中、オペレーターは[RFC3535]にリストされているように、次の2つの要件を策定しました。
2. It is necessary to make a clear distinction between configuration data, data that describes operational state, and statistics. Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols.
2. 構成データ、運用状態を記述するデータ、および統計を明確に区別する必要があります。一部のデバイスでは、どのパラメーターが管理上構成され、どのパラメーターがルーティングプロトコルなどの他のメカニズムを介して取得されたかを判断することを非常に困難にします。
3. It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices.
3. デバイスから個別の構成データ、動作状態データ、統計を取得し、デバイス間でこれらを比較できるようにする必要があります。
The NETCONF protocol defined in RFC 4741 distinguishes two types of data -- namely, configuration data and state data:
RFC 4741で定義されているNetConfプロトコルは、2種類のデータを区別します。つまり、構成データと状態データ：
Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state.
構成データは、システムを初期のデフォルト状態から現在の状態に変換するために必要な書き込み可能なデータのセットです。
State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics.
状態データは、読み取り専用のステータス情報や収集された統計などの構成データではないシステム上の追加データです。
NETCONF does not follow the distinction formulated by the operators between configuration data, operational state data, and statistical data, since it considers state data to include both statistics and operational state data.
NetConfは、状態データが統計と操作状態データの両方を含めると考慮しているため、構成データ、運用状態データ、および統計データの間で演算子によって定式化された区別に従いません。
Below is a definition for configuration data, operational state data, and statistical data. The definition borrows from previous work.
以下は、構成データ、動作状態データ、統計データの定義です。定義は以前の作品から借りています。
o Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state [RFC4741].
o 構成データは、システムを初期のデフォルト状態から現在の状態[RFC4741]に変換するために必要な書き込み可能なデータのセットです。
o Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols.
o 運用状態データは、実行時にシステムによって取得されたデータのセットであり、構成データと同様のシステムの動作に影響を与えます。構成データとは対照的に、運用状態は一時的であり、特殊なプロトコルを介して内部コンポーネントまたは他のシステムとの相互作用によって変更されます。
o Statistical data is the set of read-only data created by a system itself. It describes the performance of the system and its components.
o 統計データは、システム自体によって作成された読み取り専用データのセットです。システムのパフォーマンスとそのコンポーネントについて説明します。
The following examples help to clarify the difference between configuration data, operational state data, and statistical data.
次の例は、構成データ、動作状態データ、統計データの違いを明確にするのに役立ちます。
IP routing tables can contain entries that are statically configured (configuration data) as well as entries obtained from routing protocols such as OSPF (operational state data). In addition, a routing engine might collect statistics like how often a particular routing table entry has been used.
IPルーティングテーブルには、静的に構成されたエントリ（構成データ）と、OSPF（運用状態データ）などのルーティングプロトコルから取得したエントリを含めることができます。さらに、ルーティングエンジンは、特定のルーティングテーブルエントリが使用されている頻度などの統計を収集する場合があります。
Network interfaces usually come with a large number of attributes that are specific to the interface type and in some cases specific to the cable plugged into an interface. Examples are the maximum transmission unit of an interface or the speed detected by an Ethernet interface.
ネットワークインターフェイスには、通常、インターフェイスタイプに固有の、場合によってはインターフェイスに接続されたケーブルに固有の多数の属性が付属しています。例は、インターフェイスの最大送信ユニットまたはイーサネットインターフェイスによって検出された速度です。
In many deployments, systems use the interface attributes detected when an interface is initialized. As such, these attributes constitute operational state. However, there are usually provisions to overwrite the discovered attributes with static configuration data, like for example configuring the interface MTU to use a specific value or forcing an Ethernet interface to run at a given speed.
多くの展開では、システムはインターフェイスが初期化されたときに検出されたインターフェイス属性を使用します。そのため、これらの属性は運用状態を構成します。ただし、通常、発見された属性を静的構成データで上書きする規定があります。たとえば、インターフェイスMTUを特定の値を使用するように構成したり、特定の速度でイーサネットインターフェイスを強制したりします。
The system will record statistics (counters) measuring the number of packets, bytes, and errors received and transmitted on each interface.
システムは、各インターフェイスで受信および送信されたパケット、バイト、およびエラーの数を測定する統計（カウンター）を記録します。
Systems usually maintain static configuration information about the accounts on the system. In addition, systems can obtain information about accounts from other sources (e.g., Lightweight Directory Access Protocol (LDAP), Network Information Service (NIS)) dynamically, leading to operational state data. Information about account usage is an example of statistical data.
システムは通常、システム上のアカウントに関する静的な構成情報を維持します。さらに、システムは、他のソースからアカウントに関する情報を取得できます（例：LightWeight Directory Access Protocol（LDAP）、Network Information Service（NIS））動的に、運用状態データにつながります。アカウントの使用に関する情報は、統計データの例です。
Note that configuration data supplied to a system in order to create a new account might be supplemented with additional configuration information determined by the system when the account is being created (such as a unique account id). Even though the system might create such information, it usually becomes part of the static configuration of the system since this data is not transient.
新しいアカウントを作成するためにシステムに提供された構成データには、アカウントが作成されているときにシステムによって決定される追加の構成情報が補足される場合があります（一意のアカウントIDなど）。システムがそのような情報を作成する可能性がありますが、通常、このデータは一時的ではないため、システムの静的構成の一部になります。
The primary focus of YANG is configuration data. There is no single mechanism defined for the separation of operational state data and statistics since NETCONF treats them both as state data. This section describes several different options for addressing this issue.
Yangの主な焦点は構成データです。NetConfはそれらを両方のデータとして扱うため、運用状態データと統計の分離のために定義された単一のメカニズムはありません。このセクションでは、この問題に対処するためのいくつかの異なるオプションについて説明します。
The first option is to have data models that explicitly differentiate between configuration data and operational state data. This leads to duplication of data structures and might not scale well from a modeling perspective.
最初のオプションは、構成データと動作状態データを明示的に区別するデータモデルを持つことです。これは、データ構造の重複につながり、モデリングの観点からは十分に拡大しない可能性があります。
For example, the configured duplex value and the operational duplex value would be distinct leafs in the data model.
たとえば、構成された二重値と動作二重値は、データモデルの明確なリーフになります。
The NETCONF protocol can be extended with new protocol operations that specifically allow the retrieval of all operational state, e.g., by introducing a <get-ops> operation (and perhaps also a <get-stats> operation).
NetConfプロトコルは、たとえばA <get-ops>操作（おそらく<get-stats>操作）を導入することにより、すべての動作状態の取得を特に許可する新しいプロトコル操作で拡張できます。
Another option could be to introduce a new "configuration" data store that represents the operational state. A <get-config> operation on the <operational> data store would then return the operational state determining the behavior of the box instead of its static and explicit configuration state.
別のオプションは、運用状態を表す新しい「構成」データストアを導入することです。<Operational> Data Storeでの<get-config>操作は、静的および明示的な構成状態ではなく、ボックスの動作を決定する運用状態を返します。
At this time, the only viable solution is to distinctly model the configuration and operational values. The configuration leaf would indicate the desired value, as given by the user, and the operational leaf would indicate the current value, as observed on the device.
この時点で、唯一の実行可能なソリューションは、構成値と動作値を明確にモデル化することです。構成葉は、ユーザーによって与えられるように、望ましい値を示し、操作葉はデバイスで観察されるように現在の値を示します。
In the duplex example, this would result in two distinct leafs being defined, "duplex" and "op-duplex", one with "config true" and one with "config false".
デュプレックスの例では、これにより、2つの異なる葉が定義されます。「デュプレックス」と「op-duplex」、もう1つは「config true」、もう1つは「config false」を備えています。
In some cases, distinct leafs would be used, but in others, distinct lists might be used. Distinct lists allows the list to be organized in different ways, with different constraints. Keys, sorting, and constraint statements like must, unique, or when may differ between configuration data and operational data.
場合によっては、異なる葉が使用されますが、他の場合は異なるリストを使用する場合があります。異なるリストを使用すると、さまざまな制約を伴うさまざまな方法でリストを整理できます。キー、ソート、およびマスト、一意、またはコンフィギュレーションデータと運用データの間でいつ異なる場合があるような制約ステートメント。
For example, configured static routes might be a distinct list from the operational routing table, since the use of keys and sorting might differ.
たとえば、構成された静的ルートは、キーの使用と並べ替えが異なる可能性があるため、運用ルーティングテーブルからは別個のリストになる可能性があります。
This document discusses an architecture for network management using NETCONF and YANG. It has no security impact on the Internet.
このドキュメントでは、NetConfとYangを使用したネットワーク管理のアーキテクチャについて説明します。インターネットにセキュリティの影響はありません。
[ISODSDL] International Organization for Standardization, "Document Schema Definition Languages (DSDL) - Part 1: Overview", ISO/IEC 19757-1, November 2004.
[ISODSDL]国際標準化機関、「文書スキーマ定義言語（DSDL） - パート1：概要」、ISO/IEC 19757-1、2004年11月。
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC3535] Schoenwaelder、J。、「2002 IAB Network Management Workshopの概要」、RFC 3535、2003年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
[RFC4742] Wasserman、M。およびT. Goddard、「Secure Shell（SSH）を介したNetConf構成プロトコルを使用」、RFC 4742、2006年12月。
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.
[RFC4743] Goddard、T。、「Simple Object Access Protocol（SOAP）でNetConfを使用」、RFC 4743、2006年12月。
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.
[RFC4744] Lear、E。およびK. Crozier、「ブロック拡張可能な交換プロトコル（BEEP）でNetConfプロトコルを使用」、RFC 4744、2006年12月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277] Chisholm、S。およびH. Trevino、「NetConf Event Notifications」、RFC 5277、2008年7月。
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[RFC5539] Badra、M。、「NetConf Over Transport Layer Security（TLS）」、RFC 5539、2009年5月。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020] Bjorklund、M。、「Yang-ネットワーク構成プロトコル（NetConf）のデータモデリング言語」、RFC 6020、2010年10月。
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021] Schoenwaelder、J。、「Common Yangデータ型」、RFC 6021、2010年10月。
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", RFC 6087, January 2011.
[RFC6087] Bierman、A。、「Yang Data Model Documentsの著者およびレビュアーのガイドライン」、RFC 6087、2011年1月。
[RFC6110] Lhotka, L., "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", RFC 6110, February 2011.
[RFC6110] Lhotka、L。、「Yangをマッピングしてスキーマ定義言語を文書化し、NetConfコンテンツの検証」、RFC 6110、2011年2月。
[RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for NETCONF", RFC 6243, June 2011.
[RFC6243] Bierman、A。およびB. Lengyel、「NetConfの能力を備えている」、RFC 6243、2011年6月。
[SWEXPECT] "The Expect Home Page", <http://expect.sourceforge.net/>.
[swexpect]「ホームページを期待する」、<http://expect.sourceforge.net/>。
[W3CXPATH] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3CXPath] Derose、S。およびJ. Clark、「XML Path Language（XPath）バージョン1.0」、World Wide Web Consortiumの推奨REC-XPATH-19991116、1999年11月、<http://www.w3.org/tr/1999/rec-xpath-1991116>。
[W3CXQUERY] Boag, S., "XQuery 1.0: An XML Query Language", W3C WD WD-xquery-20050915, September 2005.
[w3cxquery] Boag、S。、「Xquery 1.0：an XMLクエリ言語」、W3C WD WD-XQuery-20050915、2005年9月。
[W3CXSD] Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-0-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.
[W3CXSD] Walmsley、P。and D. Fallside、「XML Schema Part 0：Primer Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-0-20041028、2004年10月、<http://www.w3.org/TR/2004/REC-XMLSCHEMA-0-20041028>。
[W3CXSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xslt-19991116>.
[w3cxslt]クラーク、J。、「xsl変換（xslt）バージョン1.0」、ワールドワイドウェブコンソーシアムの推奨rec-xslt-19991116、1999年11月、<http://www.w3.org/tr/1999/rec-xslttt-19991116>。
[RCDML] Presuhn, R., Ed., "Requirements for a Configuration Data Modeling Language", Work in Progress, February 2008.
[RCDML] Presuhn、R.、ed。、「構成データモデリング言語の要件」、Progress、2008年2月。
Author's Address
著者の連絡先
Phil Shafer Juniper Networks
Phil Shafer Juniper Networks
EMail: phil@juniper.net