[要約] RFC 4743は、NETCONFをSOAPプロトコル上で使用するための仕様です。目的は、NETCONFをSOAPに統合することで、既存のSOAPベースのシステムとの相互運用性を実現することです。
Network Working Group T. Goddard
Request for Comments: 4743 ICEsoft Technologies Inc.
Category: Standards Track December 2006
Using NETCONF over the Simple Object Access Protocol (SOAP)
Simple Object Accessプロトコル（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
ネットワーク構成プロトコル（NetConf）は、さまざまな環境で幅広いデバイスに適用できます。Webサービスはそのような環境の1つであり、現在、Simple Object Accessプロトコル（SOAP）の使用によって特徴付けられています。NetConfは、この環境で多くの利点を見つけます。既存の標準の再利用、ソフトウェア開発の容易さ、展開されたシステムとの統合まで。ここでは、NetConf用のHTTP上のSOAPおよびSOAP Over Blocks Exchange Extensible Protocol（Beep）バインディングについて説明します。
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
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]およびリモート手順コール特性の使用を考えると、SOAP [3]アプリケーションプロトコルへのNetConf [1]操作の結合を考慮することは自然です。このドキュメントは、このフォームの拘束力を提案しています。
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.
一般に、SOAPは、本質的には両方のリモートプロシージャコール文字のために、NetConfの自然なメッセージングスキームです。ただし、HTTPは本質的に同期し、クライアント駆動型であるため、SOAPを使用すると注意が必要です。ソープオーバービープ[11]は技術的に優れていますが、それほど広く採用されていません。
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 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.
4つの基本的なトピックが提示されています。NetConfのSOAP詳細、SOAPベースのWebサービスとしてNetConfを実装する詳細、セキュリティに関する考慮事項、および機能的なWebサービス説明言語（WSDL）定義。ある意味では、ドキュメントの最も重要な部分は、セクション3.7に示されている簡単なWSDLドキュメントです。適切なツールを備えたWSDLは、ベースNetConf XMLスキーマと組み合わせて、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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [8]に記載されているように解釈される。
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をもう1つのラッパーとして紹介するのは、すでにリモートプロシージャコールメッセージとなっているのですか？実際、技術的および実用的な理由があります。技術的な理由はおそらくそれほど説得力がありませんが、最初にそれらを調べてみましょう。
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は基本的にXMLメッセージングスキーム（リモートプロシージャコールをサポートできる）であり、「ヘッダー」と「エンベロープ」に含まれる「ボディ」で構成される単純なメッセージ形式を定義します。「ヘッダー」には、メッセージに関連するメタ情報が含まれており、ストアアンドフォワードの動作やトランザクション特性などのことを示すために使用できます。さらに、SOAPは、メッセージの「ボディ」のオプションのエンコードを指定します。ただし、目標の1つは非常に読みやすいXMLを持つことであり、SOAPエンコードが自動化された脱線化を容易にするために最適化されるため、このエンコードはNetConfには適用できません。石鹸メッセージ構造のこれらの利点は簡単ですが、すでに標準化されているため価値があります。
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をデバイス管理にとって本当に興味深い選択肢とする実際的な理由です。TCPを介してXMLメッセージを交換するメカニズムを発明することは難しくありませんが、困難なのは、さまざまなツールやオペレーティングシステムでサポートされているメカニズムを得て、非常に多くの開発者がそのメカニズムを理解することです。HTTPを介したSOAP（WSDLを使用）はこれに大きな成功を収めています。これは、これらのテクノロジーを利用するデバイス管理プロトコルが実装および採用されることに利点があることを意味します。確かに、SOAPとWSDLには相互運用性の問題がありますが、そのような問題は幅広い注意を払っており、解決することが期待できます。
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.
マシン読み取り可能な形式（Webサービスの説明言語（WSDL）[16]やXMLスキーマ[4]など）を使用することの利点の1つは、ソフトウェア開発プロセスで自動的に使用できることです。適切なツールを使用すると、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" />
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タイプと要素の定義をインポートします。理想的には、スキーマがスキーマを定義した標準団体の権限の下でWebサーバーでホストされているファイルを含むファイル。このようにして、従属標準は時間の経過とともに構築でき、すべてが標準を順守する自動化されたソフトウェアツールにアクセスできます。この目的のためのIANAメントレジストリは、「IETF XMLレジストリ」[13]で説明されています。
Note that WSDL declarations for SOAP over BEEP bindings are not yet standardized.
ビープ音のバインディング上の石鹸のWSDL宣言はまだ標準化されていないことに注意してください。
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は接続開始によって非常に明確なクライアントとサーバーの役割を割り当てるため、HTTP以外のプロトコルよりもSOAPを検討することには多くの利点があります。これにより、非同期通知をサポートすることが困難を引き起こし、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 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.
HTTPはメッセージングの理想的な輸送ではありませんが、「リモートプロシージャコール」の最も基本的な解釈には適しています。HTTPは、クライアント（TCP接続を開始する）がサーバーに「リクエスト」する通信パターンに基づいています。サーバーは「応答」を返し、このプロセスは継続されます（以下に説明するように、おそらく永続的な接続を超えて）。これは、発信者がリモートサーバーで手順を呼び出して返品値を待つというリモート手順コールの基本的なアイデアと一致します。
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の設計における特定の妥協点に向けられています。そのため、考慮することが重要ですが、デバイス管理プロトコルの致命的な欠点をもたらすことは明らかではありません。
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:
Best Current Practice 56 [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をNetConfに適用するのではなく、HTTPを介したSOAPの一般的な使用法に直接存在します。BCP 56が示すように、HTTPがSOAPに適したプロトコルであるかどうかは議論の余地があり、BEEPはほとんどのSOAPアプリケーションにとって優れたプロトコルである可能性があります。残念ながら、HTTPを介した石鹸は一般的に使用されており、石鹸の実際的な利点を実現する場合はサポートする必要があります。石鹸の冗長性は、石鹸メッセージを処理するために設計されたファイアウォールではありますが、実際にはファイアウォールによってより容易に処理されることに注意してください。
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:
NetConfセッションの状態は基礎となる輸送接続の状態に結び付けられているため、NetConfマネージャーとエージェントの間にHTTPキャッシュを挿入しないでください。3つの防御行動をとることができます。
o Caching MUST be prohibited through the use of HTTP headers Cache-Control and Pragma: no-cache.
o HTTPヘッダーのキャッシュコントロールとプラグマ：ノーキャッシュを使用して、キャッシュを禁止する必要があります。
o HTTP proxies SHOULD NOT be deployed within the management network.
o HTTPプロキシは、管理ネットワーク内に展開しないでください。
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の再利用に関する懸念にも対応することも可能です。NetConfSoapサービスは、SOAPを介したNetConfの新しい標準ポートで常にサポートする必要があり、すべての適合実装は、NetConfのこの新しい標準ポートを介した接続を試みることをデフォルトする必要があります。。このドキュメントのIANAの考慮事項には、SOAP（HTTP上）上のNetConfの標準ポートが割り当てられています。
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".
HTTP 1.1 [5]には、SOAPメッセージの比較的効率的な輸送を提供する2つの重要な機能が含まれています。これらの機能は、「永続的な接続」と「チャンクされた転送コード」です。
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.
永続的な接続により、複数のHTTP要求で単一のTCP接続を使用できます。これにより、各リクエストの新しいTCP接続を作成するオーバーヘッドなしで、複数のSOAP要求/応答メッセージペアを交換できます。リクエストと応答の両方に単一のストリームが使用されていることを考えると、何らかの形のフレーミングが必要であることは明らかです。長さが事前に知られているメッセージの場合、これはHTTPヘッダー「Content-Length」によって処理されます。動的な長さのメッセージには、「チャンク」が必要です。
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「チャンキング」または「チャンキングトランスファーコード」により、送信者は無期限の量のバイナリデータを送信できます。これは、チャンクが送信される前に各「チャンク」（データのサブストリング）のサイズを受信者に通知することによって達成されます。最後のチャンクは、ゼロの長さのチャンクで示されます。チャンクは、メモリ内の非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 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.
SOAPメッセージ交換への適用に関しては、パフォーマンス上の理由で永続的な接続が明らかに重要であり、認証された接続の持続性が危機にatしている場合に特に重要です。動的長さのメッセージが石鹸メッセージの例外ではなくルールであると考えると、チャンクが非常に便利であることも明らかです。場合によっては、SOAP応答を緩衝して送信する前にその長さを決定することができますが、これのストレージ要件は多くのデバイスでは法外なものです。一緒に、これらの2つの機能は、HTTPを介してSOAPを使用したデバイス管理のための優れた基盤を提供します。HTTPチャンキングと永続的な接続[5]を使用する必要があります。
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]。特に、どちらかのビープピアによって開始されたリクエスト/応答メッセージ交換を提供し、応答メッセージの数を任意（ゼロを含む）にすることができます。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]の仕様を詳細にカバーすることは、このドキュメントの目標ではありません。代わりに、SOAPを介したNetConfの実装者にとって興味深いかもしれないいくつかのコメントを提供します。
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.
NetConf over Soapは、SOAP機能を広範囲に使用していません。たとえば、NetConf操作はSoapメッセージパーツに分割されず、SOAPヘッダーは<RPC>メタデータを伝達するために使用されません。これは、実装者がこれらの異なる基板上のメッセージを一般的に処理しながら、複数の基板上にNetConfを簡単に提供できるようにするため、意図的な設計上の決定です。
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の実装者は、SOAPヘッダーの次の特性を認識する必要があります。SOAPヘッダーには「必須」属性がある場合があります。代わりに障害を生成します。「マストラスト」ヘッダーを静かに捨ててはなりません。
In general, however, SOAP headers are intended for application-specific uses. The NETCONF SOAP binding does not make use of SOAP headers.
ただし、一般に、石鹸ヘッダーはアプリケーション固有の使用を目的としています。NetConf Soap Bindingは、ソープヘッダーを使用しません。
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-Error>の場合、SOAP障害が返されます。基本的に<RPC-Error>のラッパーとして構築されていますが、SOAPプロセッサは、言語に適した例外メカニズムを使用して<RPC-Error>をアプリケーションコードに伝播することができます。
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断層は、次のように<rpc-error>から構築されます：石鹸障害コード値は石鹸エンベロープ名の「受信機」であり、石鹸障害理由テキストはNetConf <RPC-Error> "エラータグのコンテンツです「そして、石鹸断層の詳細は、元の<RPC-Error>構造です。
For instance, given the following <rpc-error>,
たとえば、次の<rpc-error>を考えると、
<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>
the associated SOAP Fault message is
関連する石鹸障害メッセージはです
<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>
<bad-element>rpc</bad-element>
</error-info>
</rpc-error>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
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.
NetConf over Soapの基本的なユースケースは、NetConfエージェント（「エージェント」ロール）を実行する1つ以上のデバイスを管理する管理コンソール（「マネージャー」ロール）のそれです。マネージャーは、エージェントへのHTTPまたはビープの接続を開始し、一連のSOAPメッセージを介してNetConfセッションを駆動します。マネージャーが接続を閉じると、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セッションを介したネットコンは、基礎となる基板上の最初のメッセージ交換によって確立されます。HTTPの場合、SOAPメッセージがNetConf WebアプリケーションURIに投稿されると、NetConfセッションが確立されます。ビープ音のために、石鹸握手のビーププロファイルが石鹸チャネルを確立すると、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の確立は、<hello>メッセージの交換を通じて実行されます。HTTPを介したSOAPの場合、HTTPクライアントは最初の<hello>メッセージを送信する必要があります。ビープ音を介した石鹸の場合は、順序付けの制約を課しません。たとえば、次の例は<hello>メッセージの交換を示し、セッションID値を確立します。管理クライアントがExchangeを開始し、サーバーエージェントがセッションIDを割り当てることを確認します。
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>
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接続によってサポートされます。ソープオーバービープの場合、ネットコンセッションは、石鹸のビーププロファイルに従って動作するビープチャネルによってサポートされています[12]。
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の場合）またはチャネル（ビープ音の場合）が閉じられているときに、ソープセッションの断片的なネットコンが行われます。このような分解の根本原因は、場合によってはHTTPまたはビープ音のいずれかでTCP接続の閉鎖である可能性があることに注意してください。NetConfマネージャーとエージェントは、<Close-Session>操作に応じて、NetConfセッションに関連する輸送接続をプログラム的に閉じることができなければなりません。したがって、HTTPまたはビープ基板の実装は、これを適切に公開する必要があります。
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）はドキュメント/リテラルエンコーディングを使用しているため、石鹸ヘッダーとボディの使用はNetConf操作の表現にほとんど影響を与えません。この例は、簡単にするためのHTTP/1.1を示しています。ビープ音の例は似ています。
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>
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: <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>
<?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">
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/
schema/netconf.xsd" />
<message name="helloRequest">
<part name="in" element="netb:hello"/>
</message>
<message name="helloResponse">
<part name="out" element="netb:hello"/>
</message>
<message name="rpcRequest">
<part name="in" element="netb:rpc"/>
</message>
<message name="rpcResponse">
<part name="out" element="netb:rpc-reply"/>
</message>
<portType name="netconfPortType">
<operation name="rpc">
<input message="tns:rpcRequest"/>
<output message="tns:rpcResponse"/>
</operation>
<operation name="hello">
<input message="tns:helloRequest"/>
<output message="tns:helloResponse"/>
</operation>
</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>
</definitions>
</定義>
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ドキュメントでは、SOAP WSDL定義を介したNetConfのローカル場所を想定しています。NetConfを介してSOAPを介して管理可能なデバイスの典型的な展開は、デバイスのアドレスを識別するために、以下と同様のサービス定義を提供します。
<?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"
targetNamespace="urn:myNetconfService"
name="myNetconfService.wsdl">
<import namespace="urn:ietf:params:xml:ns:netconf:soap:1.0"
location="http://localhost:8080/netconf/
schema/netconf-soap_1.0.wsdl"/>
<service name="netconf">
<port name="netconfPort" binding="nets:netconfBinding">
<SOAP:address location="http://localhost:8080/netconf"/>
</port>
</service>
</definitions>
</定義>
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.
構成情報は両方向に送信されるため、クライアントまたはユーザーだけがサーバーで認証されるだけでは不十分です。サーバーのIDは、クライアントにも認証される必要があります。
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.
IANAが割り当てられたポートを使用する必要があります。これは、サービス拒否攻撃中に効率的なファイアウォールフィルタリングの手段を提供するためです。
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): o within the transport (such as with TLS client certificates)
NetConf Soap Bindingは、整合性とプライバシーのために、基礎となる安全な輸送に依存しています。このような輸送には、TLS [9]（HTTPと組み合わせるとHTTPSと呼ばれる）およびIPSECが含まれると予想されます。認証にはいくつかのオプションがあります（いくつかは展開固有です）：oトランスポート内（TLSクライアント証明書など）
o within HTTP (such as Digest Access Authentication [7])
o HTTP内（Digest Access Authentication [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.
HTTP、ビープ音、SOAPレベル認証は、リモート認証ダイヤルインユーザーサービス（RADIUS）[10]と統合して、リモート認証データベースをサポートできます。
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.
ミニウムでは、石鹸の実装に適合するすべてのネットコンはTLSをサポートする必要があります。具体的には、HTTPを介したSOAPを介したNetConfは、HTTPを介したSOAPを介してNetConfをサポートする必要があり、NetConfはBEEP上で石鹸を介してTLS上のビープ音を介してネットコンフをサポートする必要があります。
The above protocols may have various vulnerabilities, and these may be inherited by NETCONF over 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の場合、デバイス管理が（石鹸に加えて）複数の基板上で行われている可能性があることを考慮することが重要であり、異なる基質に共通の認証モデルを持つことが重要です。
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が管理するデバイスは、他のプロトコルによって管理されたデバイスと、すべての異なるセキュリティのデバイスと相互作用する場合があります。エントリの各ポイントは、潜在的な脆弱性をもたらします。
IANA assigned TCP port (833) for NETCONF over SOAP over BEEP, and TCP port (832) for NETCONF over SOAP over HTTPS.
IANAは、ビープ音を介してNetConf用のTCPポート（833）をNetConfに割り当て、HTTPS上の石鹸上のNetConf（832）にTCPポート（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 Namespace "URN：IETF：PARAMS：XML：NS：NetConf"のSOAP WSDL定義のXML名前空間を割り当てることを可能にします。RFC 2434 [14]で概説されているポリシーに続いて、この下位の名前空間に割り当てられた値は、「必要な仕様」ポリシーに従って割り当てられるように要求されます。
URI: urn:ietf:params:xml:ns:netconf:soap
[1] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[1] Enns、R.、ed。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[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] Bray、T.、Paoli、J.、Sperberg-Mcqueen、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] Gudgin、M.、Hadley、M.、Moreau、JJ。、およびH. Nielsen、「SOAPバージョン1.2パート1：メッセージングフレームワーク」、W3C推奨REC-SOAP12-PART1-20030624、2002年6月、<http：// wwww.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] Thompson、H.、Beech、D.、Maloney、M.、およびN. Mendelsohn、「XML Schema Part 1：Structures」、W3C推奨REC-XMLSCHEMA-1-20010502、2001年5月、<http：//www.w33.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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[6] Moore, K., "On the use of HTTP as a Substrate", RFC 3205, February 2002.
[6] ムーア、K。、「基質としてのHTTPの使用について」、RFC 3205、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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Leach、P.、Luotonen、A.、Sink、E。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[8] Bradner、S。、「要件レベルを示すためのRFCで使用するためのキーワード」、RFC 2119、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. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[10] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[10] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[11] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[11] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、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. Rose、「ブロック拡張可能な交換プロトコル（BEEP）のSimple Object Access Protocol（SOAP）を使用」、RFC 4227、2006年1月。
[13] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[13] Mealling、M。、「IETF XMLレジストリ」、RFC 3688、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考慮事項セクションを書くためのガイドライン」、RFC 2434、1998年10月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[15] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、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] Christensen、E.、Curbera、F.、Meredith、G。、およびS. Weerawarana、「Web Services説明言語（WSDL）1.1」、W3C Note-WSDL-20010315、2001年3月、<http：//www.w33.org/tr/2001/note-wsdl-20010315>。
[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] Brown、A.、Fox、B.、Hada、S.、Lamacchia、B。、およびH. Maruyama、「Soap Security Extensions：Digital Signature」、Note-Soap-DSIG-20010206、2001年2月、<http：//www.w3.org/tr/soap-dsig/>。
Author's Address
著者の連絡先
Ted Goddard ICEsoft Technologies Inc. Suite 300, 1717 10th St. NW Calgary, AB T2M 4S2 Canada
Ted Goddard Icesoft Technologies Inc. Suite 300、1717 10th St. NW Calgary、AB T2M 4S2カナダ
Phone: (403) 663-3322
EMail: ted.goddard@icesoft.com
URI: http://www.icesoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は現在、インターネット協会によって提供されています。