RFC4743 日本語訳
4743 Using NETCONF over the Simple Object Access Protocol (SOAP). T.Goddard. December 2006. (Format: TXT=39734 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Goddard Request for Comments: 4743 ICEsoft Technologies Inc. Category: Standards Track December 2006
コメントを求めるワーキンググループT.ゴダード要求をネットワークでつないでください: 4743年のICEsoft技術株式会社カテゴリ: 標準化過程2006年12月
Using NETCONF over the Simple Object Access Protocol (SOAP)
Simple Object Access Protocolの上でNETCONFを使用します。(SOAP)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF.
Network Configurationプロトコル(NETCONF)はさまざまな環境でさまざまなデバイスに適切です。 Webサービスは、そのような環境の1つであり、現在、Simple Object Access Protocol(SOAP)の使用で特徴付けられます。 NETCONFはこの環境における多くの利益を見つけます: 配布しているシステムによる統合にソフトウェア開発を軽くならせてください。既存の規格の再利用から説明する、ここに、私たちはNETCONFのためにBlocks Exchange Extensibleプロトコル(BEEP)結合の上でHTTPとSOAPの上でSOAPについて説明します。
Goddard Standards Track [Page 1] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
2. SOAP Background for NETCONF .....................................3
2.1. Use and Storage of WSDL and XSD ............................4
2.2. SOAP over HTTP .............................................4
2.3. HTTP Drawbacks .............................................4
2.4. BCP56: On the Use of HTTP as a Substrate ...................5
2.5. Important HTTP 1.1 Features ................................6
2.6. SOAP over BEEP .............................................7
2.7. SOAP Implementation Considerations .........................7
2.7.1. SOAP Feature Exploitation ...........................7
2.7.2. SOAP Headers ........................................7
2.7.3. SOAP Faults .........................................8
3. A SOAP Service for NETCONF ......................................9
3.1. Fundamental Use Case .......................................9
3.2. NETCONF Session Establishment ..............................9
3.3. NETCONF Capabilities Exchange ..............................9
3.4. NETCONF Session Usage .....................................11
3.5. NETCONF Session Teardown ..................................11
3.6. A NETCONF over SOAP Example ...............................11
3.7. NETCONF SOAP WSDL .........................................13
3.8. Sample Service Definition WSDL ............................14
4. Security Considerations ........................................15
4.1. Integrity, Privacy, and Authentication ....................15
4.2. Vulnerabilities ...........................................16
4.3. Environmental Specifics ...................................16
5. IANA Considerations ............................................17
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................18
1. 序論…2 2. NETCONFのためのSOAPバックグラウンド…3 2.1. WSDLとXSDの使用とストレージ…4 2.2. HTTPの上のSOAP…4 2.3. HTTP欠点…4 2.4. BCP56: 基板としてのHTTPの使用に関して…5 2.5. 重要なHTTP1.1機能…6 2.6. ビープ音の上のSOAP…7 2.7. SOAP実装問題…7 2.7.1. SOAP特徴攻略…7 2.7.2. SOAPヘッダー…7 2.7.3. SOAP欠点…8 3. NETCONFのためのSOAPサービス…9 3.1. 基本的はケースを使用します…9 3.2. NETCONFセッション設立…9 3.3. NETCONF能力交換…9 3.4. NETCONFセッション用法…11 3.5. NETCONFセッション分解…11 3.6. SOAPの例の上のNETCONF…11 3.7. NETCONF SOAP WSDL…13 3.8. サービス定義WSDLを抽出してください…14 4. セキュリティ問題…15 4.1. 保全、プライバシー、および認証…15 4.2. 脆弱性…16 4.3. 環境詳細…16 5. IANA問題…17 6. 参照…17 6.1. 標準の参照…17 6.2. 有益な参照…18
1. Introduction
1. 序論
Given the use of Extensible Markup Language (XML) [2] and the remote procedure call characteristics, it is natural to consider a binding of the NETCONF [1] operations to a SOAP [3] application protocol. This document proposes a binding of this form.
拡張マークアップ言語(XML)[2]の使用と遠隔手続き呼び出しの特性を考えて、NETCONF[1]操作の結合をSOAP[3]アプリケーション・プロトコルと考えるのは当然です。 このドキュメントはこの形式の結合を提案します。
In general, SOAP is a natural messaging scheme for NETCONF, essentially because of the remote procedure call character of both. However, care must be taken with SOAP over HTTP as it is inherently synchronous and client-driven. SOAP over BEEP [11] is technically superior, but is not as widely adopted.
一般に、NETCONFと、本質的には両方の遠隔手続き呼び出しキャラクタのためにSOAPは自然なメッセージング体系です。 しかしながら、それが本来同時であって、クライアントが駆動であるので、SOAPと共にHTTPの上に注意しなければなりません。 BEEP[11]の上のSOAPは、技術的に優れていますが、同じくらい広く採用されません。
Four basic topics are presented: SOAP specifics of interest to NETCONF, specifics on implementing NETCONF as a SOAP-based web service, security considerations, and functional Web Services
4つの基本的な話題が提示されます: NETCONFに興味があるSOAP詳細、SOAPベースのウェブサービスとしてNETCONFを実装するときの詳細、セキュリティ問題、および機能的なWebサービス
Goddard Standards Track [Page 2] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[2ページ]。
Description Language (WSDL) definitions. In some sense, the most important part of the document is the brief WSDL document presented in Section 3.7. With the right tools, the WSDL combined with the base NETCONF XML Schemas provides machine-readable descriptions sufficient for the development of software applications using NETCONF.
記述Language(WSDL)定義。 何らかの意味で、ドキュメントの最も重要な部分はセクション3.7に提示された簡潔なWSDLドキュメントです。 正しいツールに、ベースNETCONF XML Schemasに結合されたWSDLは、NETCONFを使用することでソフトウェアアプリケーションの開発に十分な機械可読な記述を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[8]で説明されるように本書では解釈されることであるべきですか?
2. SOAP Background for NETCONF
2. NETCONFのためのSOAPバックグラウンド
Why introduce SOAP as yet another wrapper around what is already a remote procedure call message? There are, in fact, both technical and practical reasons. The technical reasons are perhaps less compelling, but let's examine them first.
なぜさらに別のラッパーとして既に遠隔手続き呼び出しメッセージであることに周りにSOAPを取り入れますか? 事実上、技術的なものと同様に実際的な理由があります。 技術的な理由は恐らくそれほど無視できなくはありませんが、最初に、それらを調べましょう。
The use of SOAP does offer a few technical advantages. SOAP is fundamentally an XML messaging scheme (which is capable of supporting remote procedure call), and it defines a simple message format composed of a "header" and a "body" contained within an "envelope". The "header" contains meta-information relating to the message and can be used to indicate such things as store-and-forward behaviour or transactional characteristics. In addition, SOAP specifies an optional encoding for the "body" of the message. However, this encoding is not applicable to NETCONF as one of the goals is to have highly readable XML, and SOAP-encoding is optimized instead for ease of automated de-serialization. These benefits of the SOAP message structure are simple, but worthwhile because they are already standardized.
SOAPの使用はいくつかの技術的な利点を示します。 SOAPは基本的にXMLメッセージング体系(遠隔手続き呼び出しをサポートすることができる)です、そして、それは「封筒」の中に含まれた「ヘッダー」と「ボディー」で構成された簡単なメッセージ・フォーマットを定義します。 「ヘッダー」は、メッセージに関連しながらメタ情報を含んでいて、ふるまいか取引の特性を保存して、進めるようなことを示すのに使用できます。 さらに、SOAPはメッセージの「ボディー」のための任意のコード化を指定します。 しかしながら、このコード化は目標の1つが非常に読み込み可能なXMLを持つことであるので、NETCONFに適切ではありません、そして、SOAP-コード化は自動化されたデシリアライゼーションの容易さのために代わりに最適化されます。 SOAPメッセージ構造のこれらの利益、簡単ですが、それらが既に標準化されるので、価値があります。
It is the practical reasons that truly make SOAP an interesting choice for device management. It is not difficult to invent a mechanism for exchanging XML messages over TCP, but what is difficult is getting that mechanism supported in a wide variety of tools and operating systems and having that mechanism understood by a great many developers. SOAP over HTTP (with WSDL) is seeing good success at this, and this means that a device management protocol making use of these technologies has advantages in being implemented and adopted. Admittedly, there are interoperability problems with SOAP and WSDL, but such problems have wide attention and can be expected to be resolved.
それはデバイス管理のために本当にSOAPをおもしろい選択にする実際的な理由です。 XMLメッセージをTCPの上と交換するためにメカニズムを発明するのが難しくはありませんが、難しいことで、さまざまな道具とオペレーティングシステムでそのメカニズムをサポートさせて、多くの開発者にそのメカニズムを解釈しています。 HTTP(WSDLと)の上のSOAPはこれに良い成功が見えています、そして、これはこれらの技術を利用するデバイス管理プロトコルが実装されて、採用される際にうま味があることを意味します。 明白に、SOAPとWSDLに関する相互運用性問題がありますが、そのような問題を、広い注意を持って、決議されると予想できます。
Goddard Standards Track [Page 3] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[3ページ]。
2.1. Use and Storage of WSDL and XSD
2.1. WSDLとXSDの使用とストレージ
One of the advantages of using machine-readable formats (such as Web Services Description Language (WSDL) [16] and XML Schemas [4]) is that they can be used automatically in the software development process. With appropriate tools, WSDL and XSD can be used to generate classes that act as remote interfaces or application-specific data structures. Other uses, such as document generation and service location, are also common. A great innovation found with many XML-based definition languages is the use of hyperlinks for referring to documents containing supporting definitions.
機械可読フォーマットを使用する利点の1つ、(ウェブサービス記述言語としてそのような(WSDL)[16]とXML Schemas[4])によるソフトウェア開発プロセスで自動的に彼らを使用できるということです。 適切なツールと共に、インタフェースかアプリケーション特有のデータ構造をリモートであるとして機能するクラスに生成するのにWSDLとXSDを使用できます。 また、ドキュメント生成やサービス位置などの他の用途も一般的です。 多くのXMLベースの定義言語で見つけられたすばらしい革新はハイパーリンクのサポート定義を含むドキュメントを参照する使用です。
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/
schema/netconf.xsd" />
<輸入名前空間=「つぼ:ietf:params:xml:ナノ秒:netconf:ベース: 1インチの位置の=「 http://www.iana.org/assignments/xml-registry/ 図式/netconf.xsd」/>」
For instance, in WSDL, the above import statement imports the definitions of XML types and elements from the base NETCONF schema. Ideally, the file containing that schema is hosted on a web server under the authority of the standards body that defined the schema. In this way, dependent standards can be built up over time, and all are accessible to automated software tools that ensure adherence to the standards. The IANA-maintained registry for this purpose is described in "The IETF XML Registry" [13].
例えば、WSDLでは、上の輸入声明はベースNETCONF図式からXMLタイプと要素の定義を意味します。 理想的に、その図式を含むファイルはウェブサーバーで図式を定義した標準化団体の権威の下でホスティングされます。 このように、時間がたつにつれて依存する規格を確立できます、そして、すべてが規格に固守を確実にする自動化されたソフトウェアツールにアクセスしやすいです。 IANAによって維持された登録は「IETF XML登録」[13]でこのために説明されます。
Note that WSDL declarations for SOAP over BEEP bindings are not yet standardized.
BEEP結合の上のSOAPのためのWSDL宣言がまだ標準化されていないことに注意してください。
2.2. SOAP over HTTP
2.2. HTTPの上のSOAP
Although SOAP focuses on messages and can be bound to different underlying protocols such as HTTP, SMTP, or BEEP, most existing SOAP implementations support only HTTP or HTTP/TLS.
SOAPは、メッセージに焦点を合わせて、HTTP、SMTP、またはBEEPなどの異なった基本的なプロトコルに縛ることができますが、ほとんどの既存のSOAP実装がHTTPかHTTP/TLSだけをサポートします。
There are a number of advantages to considering SOAP over protocols other than HTTP, as HTTP assigns the very distinct client and server roles by connection initiation. This causes difficulties in supporting asynchronous notification and can be relieved in many ways by replacing HTTP with BEEP.
HTTP以外のプロトコルの上でSOAPを考える多くの利点があります、HTTPが接続開始で非常に異なったクライアントとサーバーの役割を選任するとき。 これは、非同期な通知をサポートする際に困難を引き起こして、様々な意味でHTTPをBEEPに取り替えることによって、救うことができます。
2.3. HTTP Drawbacks
2.3. HTTP欠点
HTTP is not the ideal transport for messaging, but it is adequate for the most basic interpretation of "remote procedure call". HTTP is based on a communication pattern whereby the client (which initiates the TCP connection) makes a "request" to the server. The server returns a "response", and this process is continued (possibly over a
HTTPはメッセージングのための理想的な輸送ではありませんが、「遠隔手続き呼び出し」の最も基本的な解釈に、それは適切です。 HTTPはクライアント(TCP接続を開始する)が「要求」をサーバにするコミュニケーションパターンに基づいています。サーバが「応答」を返して、このプロセスが持続する、(ことによるとa
Goddard Standards Track [Page 4] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[4ページ]。
persistent connection, as described below). This matches the basic idea of a remote procedure call where the caller invokes a procedure on a remote server and waits for the return value.
以下で説明されるようなパーシステントコネクション これは訪問者がリモートサーバに手順を呼び出して、リターン値を待つ遠隔手続き呼び出しの基本的な考え方に合っています。
Potential criticisms of HTTP could include the following:
HTTPの潜在的批評は以下を含むかもしれません:
o Server-initiated data flow is awkward to provide.
o サーバで開始しているデータフローは、提供するためにまずいです。
o Headers are verbose and text-based
o ヘッダーは、冗長であって、テキストベースです。
o Idle connections may be closed by intermediate proxies
o 中間的プロキシは無駄な接続を閉店させるかもしれません。
o Data encapsulation must adhere to Multipurpose Internet Mail
Extensions (MIME) [15].
o データカプセル化はマルチパーパスインターネットメールエクステンション(MIME)[15]を固く守らなければなりません。
o Bulk transfer relies on stream-based ordering.
o バルク転送はストリームベースの注文を当てにします。
In many ways, these criticisms are directed at particular compromises in the design of HTTP. As such, they are important to consider, but it is not clear that they result in fatal drawbacks for a device management protocol.
様々な意味で、HTTPのデザインにおける特定の感染はこれらの批評に向けられます。 そういうものとして、それらは考えるために重要ですが、彼らがデバイス管理プロトコルのための致命的な欠点をもたらすのは、明確ではありません。
2.4. BCP56: On the Use of HTTP as a Substrate
2.4. BCP56: 基板としてのHTTPの使用に関して
Best Current Practice 56 [6] presents a number of important considerations on the use of HTTP in application protocols. In particular, it raises the following concerns:
最も良いCurrent Practice56[6]はアプリケーション・プロトコルにおけるHTTPの使用での多くの重要な問題を提示します。 特に、以下の関心を高めます:
o HTTP may be more complex than is necessary for the application.
o HTTPはアプリケーションに必要とするより多くの複合体であるかもしれません。
o The use of HTTP may mask the application from some firewalls.
o HTTPの使用はいくつかのファイアウォールからのアプリケーションにマスクをかけるかもしれません。
o A substantially new service should not reuse port 80 as assigned
to HTTP.
o 実質的に新しいサービスはHTTPに割り当てられるようにポート80を再利用するべきではありません。
o HTTP caching may mask connection state.
o HTTPキャッシュは接続状態にマスクをかけるかもしれません。
Fundamentally, these concerns lie directly with common usage of SOAP over HTTP, rather than the application of SOAP over HTTP to NETCONF. As BCP 56 indicates, it is debatable whether HTTP is an appropriate protocol for SOAP at all, and it is likely that BEEP would be a superior protocol for most SOAP applications. Unfortunately, SOAP over HTTP is in common use and must be supported if the practical benefits of SOAP are to be realized. Note that the verbose nature of SOAP actually makes it more readily processed by firewalls, albeit firewalls designed to process SOAP messages.
基本的に、HTTPの上にSOAPのアプリケーションよりむしろHTTPの上にNETCONFにはこれらの関心が直接SOAPの一般的な用法であります。 BCP56が示すように、それはHTTPが全くSOAPのための適切なプロトコルであるか否かに関係なく、論争の余地があります、そして、BEEPはほとんどのSOAPアプリケーションのための優れたプロトコルでありそうでしょう。 残念ながら、HTTPの上のSOAPを共用であり、SOAPの実益が実感されることであるならサポートしなければなりません。 SOAPの冗長な本質が実際にそれを作るというメモはファイアウォールのそばで、より容易に処理されました、ファイアウォールがSOAPメッセージをプロセスに設計しましたが。
Goddard Standards Track [Page 5] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[5ページ]。
HTTP caches SHOULD NOT be inserted between NETCONF managers and agents as NETCONF session state is tied to the state of the underlying transport connection. Three defensive actions can be taken:
HTTPはSHOULD NOTをキャッシュします。NETCONFセッション状態が基本的な輸送接続の状態に結ばれるので、NETCONFマネージャとエージェントの間に挿入されてください。 3つの防衛措置を取ることができます:
o Caching MUST be prohibited through the use of HTTP headers Cache-
Control and Pragma: no-cache.
o HTTPヘッダCacheのコントロールとPragmaの使用でキャッシュを禁止しなければなりません: キャッシュしません。
o HTTP proxies SHOULD NOT be deployed within the management network.
o HTTPプロキシSHOULD NOT、マネジメント・ネットワークの中で配布されてください。
o Use HTTPS.
o HTTPSを使用してください。
It is also possible to respond to the concern on the reuse of port 80. Any NETCONF SOAP service MUST always be supported over the new standard port for NETCONF over SOAP, and all conforming implementations MUST default to attempting connections over this new standard port for NETCONF. A standard port for NETCONF over SOAP (over HTTP) has been assigned in the IANA considerations of this document.
また、ポート80の再利用のときに関心に応じるのも可能です。 NETCONFのためにSOAPの上で新しい標準のポートの上でいつもどんなNETCONF SOAPサービスもサポートしなければなりません、そして、実装をすべて従わせるのはNETCONFのためにこの新しい標準のポートの上で接続を試みるのをデフォルトとしなければなりません。 SOAP(HTTPの上の)の上のNETCONFのための標準のポートはこのドキュメントのIANA問題で割り当てられました。
2.5. Important HTTP 1.1 Features
2.5. 重要なHTTP1.1機能
HTTP 1.1 [5] includes two important features that provide for relatively efficient transport of SOAP messages. These features are "persistent connections" and "chunked transfer-coding".
HTTP1.1[5]はSOAPメッセージの比較的効率的な輸送に備える2つの重要な特徴を含んでいます。 これらの特徴は、「パーシステントコネクション」であり、「転送コード化をchunkedしました」。
Persistent connections allow a single TCP connection to be used across multiple HTTP requests. This permits multiple SOAP request/ response message pairs to be exchanged without the overhead of creating a new TCP connection for each request. Given that a single stream is used for both requests and responses, it is clear that some form of framing is necessary. For messages whose length is known in advance, this is handled by the HTTP header "Content-length". For messages of dynamic length, "Chunking" is required.
パーシステントコネクションは、単独のTCP接続が複数のHTTP要求の向こう側に使用されるのを許容します。 これは、複数のSOAP要求/応答メッセージ組が各要求のための新しいTCP接続を創造するオーバーヘッドなしで交換されることを許可します。 ただ一つのストリームが要求と応答の両方に使用されるなら、何らかの形式の縁どりが必要であることは、明確です。 長さがあらかじめ知られているメッセージに関しては、これはHTTPヘッダ「コンテンツの長さ」によって扱われます。 ダイナミックな長さのメッセージに関しては、「分魂化」が必要です。
HTTP "Chunking" or "chunked transfer-coding" allows the sender to send an indefinite amount of binary data. This is accomplished by informing the receiver of the size of each "chunk" (substring of the data) before the chunk is transmitted. The last chunk is indicated by a chunk of zero length. Chunking can be effectively used to transfer a large XML document where the document is generated on-line from a non-XML form in memory.
HTTP「分魂化」か「chunked転送コード化」で、送付者は無期量のバイナリ・データを送ることができます。 これは、塊が伝えられる前にそれぞれの「塊」(データに関するサブストリング)のサイズの受信機を知らせることによって、達成されます。 最後の塊はゼロ・レングスの塊によって示されます。 事実上、ドキュメントがメモリの非XMLフォームからオンラインで作られるところに大きいXMLドキュメントを移すのに分魂化を使用できます。
In terms of its application to SOAP message exchanges, persistent connections are clearly important for performance reasons and are particularly important when the persistence of authenticated connections is at stake. When one considers that messages of dynamic length are the rule rather than the exception for SOAP messages, it
SOAP交換処理へのアプリケーションでは、パーシステントコネクションは、性能理由で明確に重要であり、認証された接続の固執が危機にひんしているとき、特に重要です。 人が、ダイナミックな長さに関するメッセージがSOAPメッセージのための例外よりむしろ規則であると考えるときそれ
Goddard Standards Track [Page 6] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[6ページ]。
is also clear that Chunking is very useful. In some cases, it is possible to buffer a SOAP response and determine its length before sending, but the storage requirements for this are prohibitive for many devices. Together, these two features provide a good foundation for device management using SOAP over HTTP. HTTP chunking and persistent connections [5] SHOULD be used.
はっきりとも、そのChunkingは非常に役に立ちます。 いくつかの場合、SOAP応答をバッファリングして、発信する前に長さを測定するのが可能ですが、多くのデバイスにおいて、これのためのストレージ要件は禁止です。 これらの2つの特徴が、HTTPの上でSOAPを使用することでデバイス管理の良い基礎を一緒に、提供します。 HTTP分魂化とパーシステントコネクション[5]SHOULD、使用されてください。
2.6. SOAP over BEEP
2.6. ビープ音の上のSOAP
Although not widely adopted by the Web Services community, BEEP is an excellent substrate for SOAP [12]. In particular, it provides for request/response message exchanges initiated by either BEEP peer and allows the number of response messages to be arbitrary (including zero). The BEEP profile for SOAP simply makes use of a single BEEP channel for exchanging SOAP messages and benefits from BEEP's inherent strengths for message exchange over a single transport connection.
Webサービス共同体によって広く採用されませんが、BEEPはSOAP[12]のための素晴らしい基板です。 それは、特に、どちらのBEEP同輩によっても起こされた要求/応答メッセージ交換に備えて、応答メッセージの数が任意であることを許容します(ゼロを含んでいて)。 SOAPのためのBEEPプロフィールは単に単独の輸送接続の上でBEEPの固有の強さからSOAPメッセージと利益を交換処理と交換するための単独のBEEPチャンネルを利用します。
2.7. SOAP Implementation Considerations
2.7. SOAP実装問題
It is not the goal of this document to cover the SOAP [3] specification in detail. Instead, we provide a few comments that may be of interest to an implementor of NETCONF over SOAP.
それは詳細にSOAP[3]仕様をカバーするこのドキュメントの目標ではありません。 代わりに、私たちはいくつかのNETCONFの作成者にとって、興味深いかもしれないコメントをSOAPの上に提供します。
2.7.1. SOAP Feature Exploitation
2.7.1. SOAP特徴攻略
NETCONF over SOAP does not make extensive use of SOAP features. For instance, NETCONF operations are not broken into SOAP message parts, and the SOAP header is not used to convey <rpc> metadata. This is a deliberate design decision as it allows the implementor to provide NETCONF over multiple substrates easily while handling the messages over those different substrates in a common way.
SOAPの上のNETCONFはSOAPの大規模な使用を特徴にしません。 例えば、SOAPメッセージの部品はNETCONF操作に細かく分けられません、そして、SOAPヘッダーは、<rpc>メタデータを伝えるのに使用されません。 作成者がそれらの異なった基板の上で一般的な方法でメッセージを扱っている間それで容易に複数の基板の上にNETCONFを提供できるとき、これは慎重なデザイン決定です。
2.7.2. SOAP Headers
2.7.2. SOAPヘッダー
Implementers of NETCONF over SOAP should be aware of the following characteristic of SOAP headers: a SOAP header may have the attribute "mustUnderstand", and, if it does, the recipient must either process the header block or not process the SOAP message at all, and instead generate a fault. A "mustUnderstand" header must not be silently discarded.
SOAPの上のNETCONFのImplementersはSOAPヘッダーの以下の特性を知っているべきです: SOAPヘッダーには属性"mustUnderstand"があるかもしれなくて、そうするなら、受取人は、ヘッダーブロックを処理してはいけませんし、SOAPメッセージを全く処理して、また代わりに欠点を生成してはいけません。 静かに"mustUnderstand"ヘッダーを捨ててはいけません。
In general, however, SOAP headers are intended for application- specific uses. The NETCONF SOAP binding does not make use of SOAP headers.
一般に、しかしながら、SOAPヘッダーはアプリケーションの特定の用途のために意図します。 NETCONF SOAP結合はSOAPヘッダーを利用しません。
Goddard Standards Track [Page 7] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[7ページ]。
2.7.3. SOAP Faults
2.7.3. SOAP欠点
A SOAP Fault is returned in the event of a NETCONF <rpc-error>. It is constructed essentially as a wrapper for the <rpc-error>, but it allows SOAP processors to propagate the <rpc-error> to application code using a language-appropriate exception mechanism.
NETCONFの<のrpc誤りの>の場合、SOAP Faultを返します。 それは本質的には<rpc-誤り>のためのラッパーとして組み立てられますが、それで、SOAPプロセッサは、言語適切な例外メカニズムを使用することで<rpc-誤り>を応用コードに伝播できます。
A SOAP Fault is constructed from an <rpc-error> as follows: the SOAP Fault Code Value is "Receiver" in the SOAP envelope namespace, the SOAP Fault Reason Text is the contents of the NETCONF <rpc-error> "error-tag", and the SOAP Fault detail is the original <rpc-error> structure.
SOAP Faultは以下の<のrpc誤りの>から組み立てられます: SOAP Fault Code ValueはSOAP封筒名前空間で「受信機」です、そして、SOAP Fault Reason Textは>「誤りタグ」というNETCONF<rpc-誤りの内容です、そして、SOAP Faultの詳細は>が構造化するオリジナルの<rpc-誤りです。
For instance, given the following <rpc-error>,
<rpc-誤りの例えば、与えられた以下>。
<rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
<rpc-誤りxmlnsは「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチの><誤りタイプ>rpc</誤り-タイプ><は>MISSING_ATTRIBUTE誤り</タグ><誤り厳しさ>誤りの</誤り-厳しさ><誤りインフォメーション>の<の悪い属性の>メッセージイド悪い</属性の<の悪い要素の>rpc悪い></要素></誤り-インフォメーション></rpc-誤り>に誤りでタグ付けをすること」と等しいです。
the associated SOAP Fault message is
関連SOAP Faultメッセージはそうです。
<soapenv:Envelope
xmlns:soapenv=
"http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>env:Receiver</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text
xml:lang="en">MISSING_ATTRIBUTE</soapenv:Text>
</soapenv:Reason>
<detail>
<rpc-error xmlns=
"urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity>
<error-info>
<bad-attribute>message-id</bad-attribute>
><soapenv: ボディー><soapenv: 欠点><soapenv: ><soapenvをコード化してください: >envを評価してください: 受信機</soapenv: ></soapenvを評価してください: ><soapenvをコード化してください: ><soapenvを推論してください: テキストxml: ラングは」 アンと等しいです。xmlns: <soapenv: 封筒soapenvが" http://www.w3.org/2003/05/soap-envelope "xmlns: xml=と等しい、「 http://www.w3.org/XML/1998/namespace 、「「>のなくなった_は</soapenvを結果と考えます」; テキスト></soapenv: ><詳細><rpc-誤りxmlnsが「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチの><誤りタイプ>rpc</誤り-タイプ><誤りタグ>MISSING_ATTRIBUTE誤り</タグ><誤り厳しさ>誤りの</誤り-厳しさ><誤りインフォメーション>の<の悪い属性の>メッセージイド悪い</属性>」と等しい理由
Goddard Standards Track [Page 8] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[8ページ]。
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
<の悪い要素の>rpc悪い</要素></誤り-インフォメーション></rpc-誤り>の</詳細></soapenv: 欠点></soapenv: ボディー></soapenv: 封筒>。
3. A SOAP Service for NETCONF
3. NETCONFのためのSOAPサービス
3.1. Fundamental Use Case
3.1. 基本的はケースを使用します。
The fundamental use case for NETCONF over SOAP is that of a
management console ("manager" role) managing one or more devices
running NETCONF agents ("agent" role). The manager initiates an HTTP
or BEEP connection to an agent and drives the NETCONF session via a
sequence of SOAP messages. When the manager closes the connection,
the NETCONF session is also closed.
原理は、SOAPの上のNETCONFがマネージメントコンソール(「マネージャ」の役割)のものであるので、NETCONFエージェント(「エージェント」の役割)を車で送る1台以上のデバイスを管理しながら、ケースを使用します。 マネージャは、HTTPかBEEP接続をエージェントに開始して、SOAPメッセージの系列でNETCONFセッションを動かします。 また、マネージャが接続を終えると、NETCONFセッションは終えられます。
3.2. NETCONF Session Establishment
3.2. NETCONFセッション設立
A NETCONF over SOAP session is established by the initial message exchange on the underlying substrate. For HTTP, a NETCONF session is established once a SOAP message is POSTed to the NETCONF web application URI. For BEEP, a NETCONF session is established once the BEEP profile for SOAP handshake establishes the SOAP channel.
SOAPセッションの間のNETCONFは基本的な基板の初期の交換処理で設立されます。 HTTPにおいて、SOAPメッセージがいったんNETCONFウェブアプリケーションURIへのPOSTedになると、NETCONFセッションは確立されます。 BEEPに関しては、SOAP握手のためのBEEPプロフィールがいったんSOAPチャンネルを確立すると、NETCONFセッションは確立されます。
3.3. NETCONF Capabilities Exchange
3.3. NETCONF能力交換
Capabilities exchange and session ID establishment are performed through the exchange of <hello> messages. In the case of SOAP over HTTP, the HTTP client MUST send the first <hello> message. The case of SOAP over BEEP imposes no ordering constraints. For instance, the following example shows the exchange of <hello> messages and establishes a session ID value of 4. Observe that the management client initiates the exchange and the server agent assigns the session ID.
能力交換とセッションID設立はこんにちは、>が通信させる<の交換を通して実行されます。 HTTPの上のSOAPの場合では、HTTPクライアントはこんにちは、>が通信させる最初の<を送らなければなりません。 BEEPの上のSOAPに関するケースは注文していない規制を課します。 例えば、以下の例は、こんにちは、>が通信させる<の交換を示していて、4のセッションID価値を確立します。 管理クライアントが交換を起こして、サーバエージェントがIDをセッションに割り当てるのを観測してください。
Goddard Standards Track [Page 9] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[9ページ]。
C: POST /netconf HTTP/1.1 C: Host: netconfdevice C: Content-Type: text/xml; charset=utf-8 C: Accept: application/soap+xml, text/* C: Cache-Control: no-cache C: Pragma: no-cache C: Content-Length: 376 C: C: <?xml version="1.0" encoding="UTF-8"?> C: <soapenv:Envelope C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> C: <soapenv:Body> C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> C: <capabilities> C: <capability> C: urn:ietf:params:netconf:base:1.0 C: </capability> C: </capabilities> C: </hello> C: </soapenv:Body> C: </soapenv:Envelope> S: HTTP/1.1 200 OK S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Length: 600 S: S: <?xml version="1.0" encoding="UTF-8"?> S: <soapenv:Envelope S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: <soapenv:Body> S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> S: <capabilities> S: <capability> S: urn:ietf:params:netconf:base:1.0 S: </capability> S: <capability> S: urn:ietf:params:netconf:capability:startup:1.0 S: </capability> S: <capability> S: http:/example.net/router/2.3/myfeature S: </capability> S: </capabilities> S: <session-id>4</session-id> S: </hello> S: </soapenv:Body> S: </soapenv:Envelope>
C: ポスト/netconf HTTP/1.1C: 以下を接待してください。 netconfdevice C: コンテントタイプ: テキスト/xml。 charset=utf-8C: 受け入れます: アプリケーション/石鹸+xml、テキスト/*C: キャッシュ制御: Cをキャッシュしないでください: Pragma: Cをキャッシュしないでください: コンテンツの長さ: 376C: C: <?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>C: <soapenv: 封筒C: xmlns: soapenvが等しい、「 http://www.w3.org/2003/05/soap-envelope 、「>C:」 <soapenv: ボディー>C: <、こんにちは、xmlns、= 「つぼ:ietf:params: xml:ナノ秒:netconf: : 1インチの>Cを基礎づけてください」 <能力>C: <能力>C: つぼ:ietf:params: netconf:ベース:1.0C: </能力>C: </能力>C: こんにちは、</>C: </soapenv: ボディー>C: </soapenv: 封筒>S: HTTP/1.1 200はSを承認します: コンテントタイプ: + アプリケーション/石鹸xml。 charset=utf-8秒間: コンテンツの長さ: 600秒間: S: <?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>S: <soapenv: 封筒S: xmlns: soapenvが等しい、「 http://www.w3.org/2003/05/soap-envelope 、「>S:」 <soapenv: ボディー>S: <、こんにちは、xmlns、= 「つぼ:ietf:params: xml:ナノ秒:netconf: : 1インチの>Sを基礎づけてください」 <能力>S: <能力>S: つぼ:ietf:params: netconf:ベース:1.0秒間: </能力>S: <能力>S: つぼ:ietf:params:netconf:能力:始動:1.0秒間: </能力>S: <能力>S: http: /example.net/router/2.3/myfeature S: </能力>S: </能力>S: <セッションイド>4</セッション-イド>S: こんにちは、</>S: </soapenv: ボディー>S: </soapenv: 封筒>。
Goddard Standards Track [Page 10] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[10ページ]。
3.4. NETCONF Session Usage
3.4. NETCONFセッション用法
NETCONF sessions are persistent for both performance and semantic reasons. NETCONF session state contains the following:
性能と意味理由の両方に、NETCONFセッションは永続的です。 NETCONFセッション状態は以下を含んでいます:
1. Authentication Information
1. 認証情報
2. Capability Information
2. 能力情報
3. Locks
3. 錠
4. Pending Operations
4. 未定の操作
5. Operation Sequence Numbers
5. 操作一連番号
Authentication must be maintained throughout a session due to the fact that it is expensive to establish. Capability Information is maintained so that appropriate operations can be applied during a session. Locks are released upon termination of a session as this makes the protocol more robust. Pending operations come and go from existence during the normal course of remote procedure call (RPC) operations. Operation sequence numbers provide the small but necessary state information to refer to operations during the session.
それが証明するために高価であるという事実によるセッションの間中ときの認証を維持しなければなりません。 能力情報は、セッションの間、適切な操作を適用できるように維持されます。 プロトコルがこれで、より強健になるとき、錠はセッションの終了のときにリリースされます。 未定の操作は、遠隔手続き呼び出し(RPC)操作の常軌の間、存在から来て、行きます。 操作一連番号は、セッションの間、操作について言及するために小さい、しかし、必要な州の情報を提供します。
In the case of SOAP over HTTP, a NETCONF session is supported by an HTTP connection with an authenticated user. For SOAP over BEEP, a NETCONF session is supported by a BEEP channel operating according to the BEEP profile for SOAP [12].
HTTPの上のSOAPの場合では、NETCONFセッションは認証されたユーザとのHTTP接続によってサポートされます。 BEEPの上のSOAPに関しては、NETCONFセッションはSOAP[12]のためのBEEPプロフィールによると、働いているBEEPチャンネルによってサポートされます。
3.5. NETCONF Session Teardown
3.5. NETCONFセッション分解
To allow automated cleanup, NETCONF over SOAP session teardown takes place when the underlying connection (in the case of HTTP) or channel (in the case of BEEP) is closed. Note that the root cause of such teardown may be the closure of the TCP connection under either HTTP or BEEP as the case may be. NETCONF managers and agents must be capable of programatically closing the transport connections associated with NETCONF sessions, such as in response to a <close-session> operation; thus, the HTTP or BEEP substrate implementation must expose this appropriately.
基本的な接続(HTTPの場合における)かチャンネル(BEEPの場合における)が閉じられるとき、自動化されたクリーンアップを許容するために、SOAPセッション分解の上のNETCONFは行われます。 そのような分解の根本的原因が場合によってHTTPかBEEPのどちらかの下のTCP接続の閉鎖であるかもしれないことに注意してください。 NETCONFマネージャとエージェントはprogramaticallyにNETCONFセッションに関連している輸送の接続を終えることができなければなりません、<の厳密なセッションの>操作に対応してなど。 したがって、HTTPかBEEP基板実装が適切にこれを暴露しなければなりません。
3.6. A NETCONF over SOAP Example
3.6. SOAPの例の上のNETCONF
Since the proposed WSDL (in Section 3.7) uses document/literal encoding, the use of a SOAP header and body has little impact on the representation of a NETCONF operation. This example shows HTTP/1.1 for simplicity. An example for BEEP would be similar.
提案されたWSDL(セクション3.7における)がドキュメント/文字通りのコード化を使用するので、SOAPヘッダーとボディーの使用はNETCONF操作の表現のときに少ししか影響を与えさせません。 この例は簡単さのためにHTTP/1.1を示しています。 BEEPのための例は同様でしょう。
Goddard Standards Track [Page 11] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[11ページ]。
C: POST /netconf HTTP/1.1 C: Host: netconfdevice C: Content-Type: text/xml; charset=utf-8 C: Accept: application/soap+xml, text/* C: Cache-Control: no-cache C: Pragma: no-cache C: Content-Length: 465 C: C: <?xml version="1.0" encoding="UTF-8"?> C: <soapenv:Envelope C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> C: <soapenv:Body> C: <rpc message-id="101" C: xmlns="xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> C: <get-config> C: <filter type="subtree"> C: <top xmlns="http://example.com/schema/1.2/config"> C: <users/> C: </top> C: </filter> C: </get-config> C: </rpc> C: </soapenv:Body> C: </soapenv:Envelope>
C: ポスト/netconf HTTP/1.1C: 以下を接待してください。 netconfdevice C: コンテントタイプ: テキスト/xml。 charset=utf-8C: 受け入れます: アプリケーション/石鹸+xml、テキスト/*C: キャッシュ制御: Cをキャッシュしないでください: Pragma: Cをキャッシュしないでください: コンテンツの長さ: 465C: C: <?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>C: <soapenv: 封筒C: xmlns: soapenvが等しい、「 http://www.w3.org/2003/05/soap-envelope 、「>C:」 <soapenv: ボディー>C: <rpcメッセージイドは「101」Cと等しいです: xmlnsは「xmlns=」つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチの>Cと等しいです: <、コンフィグ>Cを得ます: <フィルタタイプが等しい、「下位木、「>C:」 <の最高xmlnsが等しい、「 http://example.com/schema/1.2/config 、「>C:」 <ユーザ/>C: </先端>C: </フィルタ>C: コンフィグ>Cを</得ます: </rpc>C: </soapenv: ボディー>C: </soapenv: 封筒>。
The HTTP/1.1 response is also straightforward:
また、HTTP/1.1応答も簡単です:
S: HTTP/1.1 200 OK S: Content-Type: application/soap+xml; charset=utf-8 S: Content-Length: 917 S: S: <?xml version="1.0" encoding="UTF-8"?> S: <soapenv:Envelope S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> S: <soapenv:Body> S: <rpc-reply message-id="101" S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> S: <data> S: <top xmlns="http://example.com/schema/1.2/config"> S: <users> S: <user> S: <name>root</name> S: <type>superuser</type> S: <full-name>Charlie Root</full-name> S: <dept>1</dept> S: <id>1</id> S: </company-info> S: </user>
S: HTTP/1.1 200はSを承認します: コンテントタイプ: + アプリケーション/石鹸xml。 charset=utf-8秒間: コンテンツの長さ: 917秒間: S: <?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>S: <soapenv: 封筒S: xmlns: soapenvが等しい、「 http://www.w3.org/2003/05/soap-envelope 、「>S:」 <soapenv: ボディー>S: <rpc-応答メッセージイドは「101」Sと等しいです: xmlns、= 「つぼ:ietf:params: xml:ナノ秒:netconf: : 1インチの>Sを基礎づけてください」 <データ>S: <の最高xmlnsが等しい、「 http://example.com/schema/1.2/config 、「>S:」 <ユーザ>S: <ユーザ>S: <名前>根の</名の>S: <タイプ>「スーパー-ユーザ」</タイプ>S: <フルネームの>ばか根の</フルネームの>S: <のdeptの>の1</deptの>S: <イド>1つの</イド>S: </会社-インフォメーション>S: </ユーザ>。
Goddard Standards Track [Page 12] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[12ページ]。
S: <user> S: <name>fred</name> S: <type>admin</type> S: <full-name>Fred Flintstone</full-name> S: <dept>2</dept> S: <id>2</id> S: </company-info> S: </user> S: </users> S: </top> S: </data> S: </rpc-reply> S: </soapenv:Body> S: </soapenv:Envelope>
S: <ユーザ>S: <名前>fred</名の>S: <タイプ>アドミン</タイプ>S: <フルネームの>フレッドFlintstone</フルネームの>S: <dept>2</dept>S: <イド>2</イド>S: </会社-インフォメーション>S: </ユーザ>S: </ユーザ>S: </先端>S: </データ>S: rpc</回答>S: </soapenv: ボディー>S: </soapenv: 封筒>。
3.7. NETCONF SOAP WSDL
3.7. NETCONF SOAP WSDL
<?xml version="1.0" encoding="UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0"
xmlns:netb="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:soap:1.0"
name="netconf-soap_1.0.wsdl">
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><定義xmlnsが" http://schemas.xmlsoap.org/wsdl/soap/ "" http://schemas.xmlsoap.org/wsdl/ "xmlns: SOAP=xmlns: tns=「つぼ:ietf:params:xml:ナノ秒:netconf:石鹸: 1インチのxmlns: netb=」つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチのtargetNamespace=と等しい、「つぼ:ietf:params:xml:ナノ秒:netconf:石鹸: 1インチが=を命名する、「_netconf-石鹸1.0.wsdl">"
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/
schema/netconf.xsd" />
<輸入名前空間=「つぼ:ietf:params:xml:ナノ秒:netconf:ベース: 1インチの位置の=「 http://www.iana.org/assignments/xml-registry/ 図式/netconf.xsd」/>」
<message name="helloRequest">
<part name="in" element="netb:hello"/>
</message>
<message name="helloResponse">
<part name="out" element="netb:hello"/>
</message>
<メッセージ名=、「helloRequest、「><部分名前="in"要素=、「netb: こんにちは、><が名前=を通信させるという」 /></メッセージ、「helloResponse、「><部分名義の="out"要素=「netb: 」 こんにちは、/></メッセージ>」
<message name="rpcRequest">
<part name="in" element="netb:rpc"/>
</message>
<message name="rpcResponse">
<part name="out" element="netb:rpc-reply"/>
</message>
<メッセージ名=、「rpcRequest、「><部分名義の=要素=「netb: rpc」/>"in"</メッセージ><メッセージ名=、「rpcResponse「><部分名前="out"要素=「netb: rpc回答」/></メッセージ>」
<portType name="netconfPortType">
<operation name="rpc">
<input message="tns:rpcRequest"/>
<output message="tns:rpcResponse"/>
<portTypeが=を命名する、「netconfPortType、「><操作名=、「「><入力メッセージ=「tns: rpcRequest」/><出力メッセージ=「tns: rpcResponse」/>」をrpcします。
Goddard Standards Track [Page 13] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[13ページ]。
</operation>
<operation name="hello">
<input message="tns:helloRequest"/>
<output message="tns:helloResponse"/>
</operation>
</portType>
</操作><操作名=、「こんにちは、「><入力メッセージ=「tns: helloRequest」/><出力メッセージ=「tns: helloResponse」/></操作></portType>」
<binding name="netconfBinding" type="tns:netconfPortType">
<SOAP:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="hello">
<SOAP:operation/>
<input>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"/>
</input>
<output>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"/>
</output>
</operation>
<operation name="rpc">
<SOAP:operation/>
<input>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:base:1.0"/>
</input>
<output>
<SOAP:body use="literal"
namespace="urn:ietf:params:xml:ns:netconf:base:1.0"/>
</output>
</operation>
</binding>
<拘束力がある名前="netconfBinding"が=「tns: 「><SOAP: 付いて、=を流行に合わせてください」というnetconfPortTypeドキュメント」輸送=" http://schemas.xmlsoap.org/soap/http "/><操作名=をタイプする、「こんにちは、「><SOAP: 操作/><は><SOAPを入力しました: ボディー使用は」 リテラルと等しい」という名前空間、= 「つぼ:ietf:params:xml:ナノ秒:netconf:石鹸: 1インチ/>の</入力><は><SOAPを出力しました」; ボディー使用が「文字通り」の名前空間=と等しい、「つぼ:ietf:params:xml:ナノ秒:netconf:石鹸: 1インチ/>の</出力></操作><操作名=、「rpcに、「><SOAP: 操作/><は><SOAPを入力しました」; 「「文字通り」のボディー使用=名前空間は「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチ/>の</入力><は><SOAP: ボディー使用=を出力した」というリテラルと等しく」名前空間=「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチ/>の</出力></操作></拘束力がある>」
</definitions>
</定義>。
3.8. Sample Service Definition WSDL
3.8. サンプルサービス定義WSDL
The following WSDL document assumes a local location for the NETCONF over SOAP WSDL definitions. A typical deployment of a device manageable via NETCONF over SOAP would provide a service definition similar to the following to identify the address of the device.
以下のWSDLドキュメントはNETCONFのためにSOAP WSDL定義に関して地方の位置を仮定します。 SOAPの上のNETCONFを通して処理しやすいデバイスの典型的な展開は、デバイスのアドレスを特定するために以下と同様のサービス定義を提供するでしょう。
<?xml version="1.0" encoding="UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:nets="urn:ietf:params:xml:ns:netconf:soap:1.0"
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><定義xmlnsは" http://schemas.xmlsoap.org/wsdl/ "xmlnsと等しいです: SOAPは" http://schemas.xmlsoap.org/wsdl/soap/ "xmlnsと等しいです: = 「つぼ:ietf:params:xml:ナノ秒:netconf:石鹸: 1インチ」網状になります。
Goddard Standards Track [Page 14] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[14ページ]。
targetNamespace="urn:myNetconfService"
name="myNetconfService.wsdl">
targetNamespaceが「つぼ: myNetconfService」名=と等しい、「myNetconfService.wsdl">"
<import namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"
location="http://localhost:8080/netconf/
schema/netconf-soap_1.0.wsdl"/>
<輸入名前空間は「つぼ:ietf:params:xml:ナノ秒:netconf:石鹸: 1インチの位置は「 http://localhost:8080/netconf/ 図式/netconf石鹸_1.0.wsdl」/>と等しいこと」と等しいです。
<service name="netconf">
<port name="netconfPort" binding="nets:netconfBinding">
<SOAP:address location="http://localhost:8080/netconf"/>
</port>
</service>
<サービス名が等しい、「netconf、「><ポート名前="netconfPort"結合が等しい、「ネット: netconfBinding「><SOAP: アドレスの位置=" http://localhost:8080/netconf "/></ポート></サービス>」
</definitions>
</定義>。
4. Security Considerations
4. セキュリティ問題
NETCONF is used to access and modify configuration information, so the ability to access this protocol should be limited to users and systems that are authorized to view or modify the agent's configuration data.
NETCONFが設定情報にアクセスして、変更するのに使用されるので、このプロトコルにアクセスする能力はエージェントのコンフィギュレーション・データを見るか、または変更するのに権限を与えられるユーザとシステムに制限されるべきです。
Because configuration information is sent in both directions, it is not sufficient for just the client or user to be authenticated with the server. The identity of the server should also be authenticated with the client.
両方の方向に設定情報を送るので、まさしくクライアントかユーザがサーバで認証されるのは、十分ではありません。また、サーバのアイデンティティはクライアントと共に認証されるべきです。
Configuration data may include sensitive information, such as user names or security keys. So, NETCONF should only be used over communications channels that provide strong encryption for data privacy.
コンフィギュレーション・データはユーザ名かセキュリティキーなどの機密情報を含むかもしれません。 それで、NETCONFはデータプライバシーのための強い暗号化を提供するコミュニケーションチャンネルの上に使用されるだけであるべきです。
If the NETCONF server provides remote access through insecure protocols, such as HTTP, care should be taken to prevent execution of the NETCONF program when strong user authentication or data privacy is not available.
強いユーザー認証かデータプライバシーが利用可能でないときに、NETCONFサーバが遠隔アクセスを提供するなら、HTTPなどの不安定なプロトコルを通して、NETCONFプログラムの実行を防ぐために注意するべきです。
The IANA assigned port SHOULD be used, as this provides a means for efficient firewall filtering during possible denial-of-service attacks.
ポートSHOULDが割り当てられたIANAが使用されて、これが提供されるとき、aは可能なサービス不能攻撃の間、効率的なファイアウォールにフィルタリングを意味します。
4.1. Integrity, Privacy, and Authentication
4.1. 保全、プライバシー、および認証
The NETCONF SOAP binding relies on an underlying secure transport for integrity and privacy. Such transports are expected to include TLS [9] (which, when combined with HTTP, is referred to as HTTPS) and IPsec. There are a number of options for authentication (some of which are deployment-specific):
NETCONF SOAP結合は保全とプライバシーのための基本的な安全な輸送に依存します。 そのような輸送がTLS[9](HTTPに結合されると、HTTPSと呼ばれます)とIPsecを含んでいると予想されます。 認証(それの或るものは展開特有である)のための多くのオプションがあります:
Goddard Standards Track [Page 15] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[15ページ]。
o within the transport (such as with TLS client certificates)
o 輸送の中で(TLSクライアント証明書などの)
o within HTTP (such as Digest Access Authentication [7])
o HTTPの中で(ダイジェストアクセス認証[7])など
o within SOAP (such as a digital signature in the header [17])
o SOAPの中で(ヘッダー[17])のデジタル署名
HTTP, BEEP, and SOAP level authentication can be integrated with Remote Authentication Dial-In User Service (RADIUS) [10] to support remote authentication databases.
リモート認証がデータベースであるとサポートするために中のRemote Authentication Dial User Service(RADIUS)[10]とHTTP、BEEP、およびSOAPレベル認証を統合できます。
At a miniumum, all conforming NETCONF over SOAP implementations MUST support TLS. Specifically, NETCONF over SOAP over HTTP MUST support NETCONF over SOAP over HTTPS, and NETCONF over SOAP over BEEP MUST support NETCONF over SOAP over BEEP over TLS.
miniumumでは、SOAP実装の上でNETCONFをすべて従わせると、TLSはサポートしなければなりません。 明確に、HTTPの上のSOAPの上のNETCONFはHTTPSの上のSOAPの上でNETCONFをサポートしなければなりません、そして、BEEP MUSTの上のSOAPの上のNETCONFはTLSの上でBEEPの上のSOAPの上でNETCONFをサポートします。
4.2. Vulnerabilities
4.2. 脆弱性
The above protocols may have various vulnerabilities, and these may be inherited by NETCONF over SOAP.
上のプロトコルには、様々な脆弱性があるかもしれません、そして、これらはSOAPの上でNETCONFによって引き継がれるかもしれません。
NETCONF itself may have vulnerabilities because an authorization model is not currently specified.
承認モデルが現在指定されないので、NETCONF自身には、脆弱性があるかもしれません。
It is important that device capabilities and authorization remain constant for the duration of any outstanding NETCONF session. In the case of NETCONF, it is important to consider that device management may be taking place over multiple substrates (in addition to SOAP), and it is important that the different substrates have a common authentication model.
デバイス能力と承認がどんな傑出しているNETCONFセッションの持続時間にも一定のままで残っているのは、重要です。 NETCONFの場合では、デバイス管理が複数の基板(SOAPに加えた)の上で行われているかもしれないと考えるのが重要であり、異なった基板には一般的な認証モデルがあるのは、重要です。
4.3. Environmental Specifics
4.3. 環境詳細
Some deployments of NETCONF over SOAP may choose to use transports without encryption. This presents vulnerabilities but may be selected for deployments involving closed networks or debugging scenarios.
SOAPの上のNETCONFのいくつかの展開が、暗号化なしで輸送を使用するのを選ぶかもしれません。 これは、脆弱性を提示しますが、閉じているネットワークにかかわるか、またはシナリオをデバッグする展開のために選択されるかもしれません。
A device managed by NETCONF may interact (over protocols besides NETCONF) with devices managed by other protocols, all of differing security. Each point of entry brings with it a potential vulnerability.
NETCONFによって管理されたデバイスは他のプロトコル(異なったセキュリティのすべて)によって管理されたデバイスで相互作用するかもしれません(NETCONF以外にプロトコルの上で)。 各ポイントのエントリーはそれと共に潜在的脆弱性をもたらします。
Goddard Standards Track [Page 16] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[16ページ]。
5. IANA Considerations
5. IANA問題
IANA assigned TCP port (833) for NETCONF over SOAP over BEEP, and TCP port (832) for NETCONF over SOAP over HTTPS.
IANAはBEEPの上のSOAPの上のNETCONFのためにポート(833)をTCPに割り当てました、そして、TCPはHTTPSの上のSOAPの上にNETCONFのための(832)を移植します。
IANA will allow for the assignment of an XML namespace within the NETCONF namespace "urn:ietf:params:xml:ns:netconf" for the NETCONF over SOAP WSDL definitions. Following the policies outlined in RFC 2434 [14], assigned values in this subordinate namespace are requested to be allocated according to the "Specification Required" policy.
IANAはNETCONF名前空間「つぼ:ietf:params:xml:ナノ秒: netconf」の中でNETCONFに関してSOAP WSDL定義に関してXML名前空間の課題を考慮するでしょう。 RFC2434[14]に概説された方針に従って、「仕様が必要である」という方針に応じてこの下位の名前空間における割り当てられた値が割り当てられるよう要求されています。
URI: urn:ietf:params:xml:ns:netconf:soap
URI: つぼ:ietf:params:xml:ナノ秒:netconf:石鹸
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[1] エンス、R.、エド、「NETCONF構成プロトコル」、RFC4741、12月2006日
[2] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[2] T.、パオリ、J.、Sperberg-マックィーン、C.、およびE.Maler、「拡張マークアップ言語(XML)1.0(第2版)」をいななかせてください、W3C REC REC-xml-20001006、2000年10月、<http://www.w3.org/TR/2000/REC-xml-20001006>。
[3] Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, "SOAP
Version 1.2 Part 1: Messaging Framework", W3C
Recommendation REC-soap12-part1-20030624, June 2002,
<http://www.w3.org/TR/soap12-part1/>.
[3] JJ M.、ハドリー、M.、モロー、H.ニールセン、Gudginに、「バージョン1.2第1部を石けんでこすってください」 「メッセージングフレームワーク」、W3C推薦REC-soap12-part1-20030624、2002年6月、<http://www.w3.org/TR/soap12-part1/>。
[4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C Recommendation REC-xmlschema-
1-20010502, May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[4] トンプソン、H.、ぶな、D.、マローニー、M.、およびN.メンデルゾーン、「XML図式第1部:」 「構造」(W3C推薦REC-xmlschema1-20010502)は2001、<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>がそうするかもしれません。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[6] Moore, K., "On the use of HTTP as a Substrate", RFC 3205,
February 2002.
[6] ムーア、K. 「SubstrateとしてのHTTPの使用」のRFC3205、2002年2月。
[7] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[7] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、流し台、E.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
Goddard Standards Track [Page 17] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[17ページ]。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[8] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[9] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[10] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[10]Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[11] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[11] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[12] O'Tuathail, E. and M. Rose, "Using the Simple Object Access
Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)",
RFC 4227, January 2006.
[12] O'Tuathail、E.、およびM.ローズ、「ブロックの広げることができるSimple Object Access Protocol(SOAP)を使用して、プロトコルを交換してください(鳴ってください)」、RFC4227、2006年1月。
[13] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[13] 食事、M.、「IETF XML登録」、RFC3688、2004年1月。
[14] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[14]AlvestrandとH.とT.Narten、「RFCsにIANA問題部に書くためのガイドライン」、RFC2434、1998年10月。
6.2. Informative References
6.2. 有益な参照
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[15]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[16] Christensen, E., Curbera, F., Meredith, G., and S. Weerawarana,
"Web Services Description Language (WSDL) 1.1", W3C Note NOTE-
wsdl-20010315, March 2001,
<http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.
[16] クリステンセン、E.、Curbera(F.、メレディス、G.、およびS.Weerawarana)は「wsdl-20010315、2001年3月、<注意http://www.w3.org/TR/2001/wsdl-20010315>に注意ウェブサービス記述言語(WSDL)1.1インチ、W3Cが注意するします」。
[17] Brown, A., Fox, B., Hada, S., LaMacchia, B., and H. Maruyama,
"SOAP Security Extensions: Digital Signature", W3C Note NOTE-
SOAP-dsig-20010206, Feb 2001,
<http://www.w3.org/TR/SOAP-dsig/>.
[17] ブラウン、A.、フォックス、B.、ハダ、S.、LaMacchia、B.、およびH.丸山、「セキュリティ拡大を石けんでこすってください」 「デジタル署名」、W3C注意注意SOAP-dsig-20010206、2001年2月、<SOAP http://www.w3.org/TR/dsig/>。
Goddard Standards Track [Page 18] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[18ページ]。
Author's Address
作者のアドレス
Ted Goddard ICEsoft Technologies Inc. Suite 300, 1717 10th St. NW Calgary, AB T2M 4S2 Canada
テッドゴダードICEsoft Technologies株式会社スイート300、1717第10NWの聖AB T2M 4S2カルガリー(カナダ)
Phone: (403) 663-3322 EMail: ted.goddard@icesoft.com URI: http://www.icesoft.com
以下に電話をしてください。 (403) 663-3322 メールしてください: ted.goddard@icesoft.com ユリ: http://www.icesoft.com
Goddard Standards Track [Page 19] RFC 4743 NETCONF over SOAP December 2006
ゴダードStandardsはSOAP2006年12月の間、RFC4743NETCONFを追跡します[19ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信頼、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Goddard Standards Track [Page 20]
ゴダード標準化過程[20ページ]
一覧
スポンサーリンク
