[要約] RFC 4850は、iSCSIノードアーキテクチャのための宣言的な公開拡張キーに関する規格です。このRFCの目的は、iSCSIノードの機能を拡張するための一貫性のある方法を提供することです。
Network Working Group D. Wysochanski
Request for Comments: 4850 Network Appliance, Inc.
Updates: 3720 April 2007
Category: Standards Track
Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture
インターネット小規模コンピューターシステムインターフェイス（ISCSI）ノードアーキテクチャの宣言的パブリックエクステンションキー
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 (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs.
RFC 3720で説明されているインターネットSmall Computer Systems Interface（ISCSI）プロトコルは、プライベートまたはパブリックエクステンションキーの形でプロトコルに拡張アイテムを可能にします。このドキュメントでは、ISCSIのサポート性を高める目的で、パブリックエクステンションキーについて説明しています。キーは、ISCSIログインシーケンス中にISCSIノードがアーキテクチャの詳細を通信できるようにすることにより、この目的を達成します。受信ノードは、この情報を使用して、ロギングとサポートを強化することができます。このドキュメントは、RFC 3720を更新して、ISCSI拡張項目を、情報RFCに加えてRFCと実験RFCを追跡する標準トラックで定義できるようにします。
This document describes a declarative Public Extension Key, as defined by Section 12.22 of RFC 3720 [2], that may be used to communicate additional iSCSI node information to the peer node in a session. The information carried in the described key has been found to be valuable in real iSCSI customer environments as initiator and target vendors collaborate to resolve technical issues and better understand the interaction of iSCSI implementations.
このドキュメントでは、RFC 3720 [2]のセクション12.22で定義されている宣言的なパブリックエクステンションキーについて説明します。これは、セッションで追加のISCSIノード情報をピアノードに通信するために使用できます。設計者とターゲットベンダーがコラボレーションして技術的な問題を解決し、ISCSIの実装の相互作用をよりよく理解するために、記載されているキーにある情報は、実際のISCSI顧客環境で価値があることがわかりました。
The key has been modeled after the HTTP "Server" and "User-Agent" header fields as specified in Sections 14.38 and 14.43 of RFC 2616 [3], with the text-value(s) of the key roughly equivalent to Product Tokens in Section 3.8 of RFC 2616 [3]. Note, however, that the text-value(s) in the key's list-of-values MUST conform to the Text Format as specified in Section 5.1 of RFC 3720 [2].
キーは、RFC 2616 [3]のセクション14.38および14.43で指定されているHTTP「サーバー」および「ユーザーエージェント」ヘッダーフィールドをモデルにしており、キーのテキスト値は製品トークンとほぼ同等のものであり、RFC 2616のセクション3.8 [3]。ただし、キーの値のリストのテキスト値は、RFC 3720 [2]のセクション5.1で指定されているように、テキスト形式に準拠する必要があることに注意してください。
The key is sent during operational parameter negotiation of an iSCSI session's login phase. The intended use of this key is to provide enhanced logging and support capabilities, and to enable collection of iSCSI implementation and usage information.
キーは、ISCSIセッションのログインフェーズの運用パラメーターネゴシエーション中に送信されます。このキーの意図された使用は、強化されたロギングとサポート機能を提供し、ISCSIの実装と使用情報の収集を可能にすることです。
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 [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [1]に記載されているように解釈される。
The definition of the key is as follows, conforming to Sections 11 and 12 of RFC 3720 [2], with example list-of-values conforming to Section 5.1 of RFC 3720 [2].
キーの定義は次のとおりであり、RFC 3720 [2]のセクション11および12に準拠しており、RFC 3720 [2]のセクション5.1に準拠したリストの例があります。
The key is defined with a use of "LO", making it a Leading Only key, and does not modify Sections 11 or 12 of RFC 3720 [2]. Thus, the key MUST only be sent on the leading connection, MUST NOT be changed after the leading connection login, and MUST only be sent after the security negotiation login stage has completed (during operational negotiation login stage). The key may be sent during normal or discovery sessions.
キーは「lo」を使用して定義され、リーディングのみのキーになり、RFC 3720のセクション11または12を変更しません[2]。したがって、キーは主要な接続でのみ送信する必要があり、主要な接続ログイン後に変更する必要はなく、セキュリティネゴシエーションログイン段階が完了した後にのみ送信する必要があります（運用交渉ログイン段階で）。キーは、通常または発見セッション中に送信できます。
Use: LO, Declarative Senders: Initiator and Target Scope: SW
使用：LO、宣言送信者：イニシエーターとターゲットスコープ：SW
X#NodeArchitecture=<list-of-values>
Examples:
例：
X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a
X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5
X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686
The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture.
イニシエーターまたはターゲットは、ISCSIノードアーキテクチャの詳細をリモートエンドポイントに宣言します。これらの詳細には、ISCSIベンダーソフトウェア、ファームウェア、またはハードウェアバージョン、OSバージョン、またはハードウェアアーキテクチャが含まれる場合がありますが、これらに限定されません。
The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes.
キー値の長さ（価値のリストの全長）は、255バイトを超えてはなりません。
X#NodeArchitecture MUST NOT be redeclared.
X＃nodearchitectureを再宣言してはなりません。
Functional behavior of the iSCSI node (this includes the iSCSI protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT depend on the presence, absence, or content of the key. The key MUST NOT be used by iSCSI nodes for interoperability, or exclusion of other nodes. To ensure proper use, key values SHOULD be set by the node itself, and there SHOULD NOT be provisions for the key values to contain user-defined text.
ISCSIノードの機能的動作（これには、ISCSIプロトコルロジック - SCSI、ISCSI、およびTCP/IPプロトコルが含まれます）は、キーの存在、不在、または内容に依存してはなりません。キーは、相互運用性、または他のノードの除外のためにISCSIノードで使用してはなりません。適切な使用を確保するには、ノード自体によってキー値を設定する必要があり、ユーザー定義のテキストを含む重要な値が規定されるべきではありません。
Nodes implementing this key MUST choose one of the following implementation options:
このキーを実装するノードは、次の実装オプションのいずれかを選択する必要があります。
o only transmit the key, o only log the key values received from other nodes, or o both transmit and log the key values.
o キーのみを送信し、o他のノードから受信したキー値をログのみログするか、oキー値を送信してログに記録します。
Each node choosing to implement transmission of the key values MUST be prepared to handle the response of RFC 3720 [2] compliant nodes that do not understand the key (RFC 3720 [2] states that compliant nodes MUST respond with X#NodeArchitecture=NotUnderstood).
キー値の送信を実装することを選択する各ノードは、キーを理解していないRFC 3720 [2]準拠ノードの応答を処理するために準備する必要があります（RFC 3720 [2]準拠ノードはx＃nodearchitecture = notunderstoodで応答しなければならないと述べています）。
Nodes that implement transmission and/or logging of the key values may also implement administrative mechanisms that disable and/or change the logging and key transmission detail (see Security Considerations). Thus, a valid behavior for this key may be that a node is completely silent (the node does not transmit any key value, and simply discards any key values it receives without issuing a NotUnderstood response).
キー値の送信および/またはロギングを実装するノードは、ロギングおよびキー送信の詳細を無効および/または変更する管理メカニズムを実装する場合もあります（セキュリティ上の考慮事項を参照）。したがって、このキーの有効な動作は、ノードが完全に沈黙していることです（ノードはキー値を送信せず、notuntoundの応答を発行せずに受信するキー値を単純に破棄します）。
This extension key transmits specific implementation details about the node that sends it; such details may be considered sensitive in some environments. For example, if a certain software or firmware version is known to contain security weaknesses, announcing the presence of that version via this key may not be desirable. The countermeasures for this security concern are:
この拡張キーは、それを送信するノードに関する特定の実装の詳細を送信します。このような詳細は、一部の環境で敏感であると見なされる場合があります。たとえば、特定のソフトウェアまたはファームウェアバージョンにセキュリティの弱点が含まれていることが知られている場合、このキーを介してそのバージョンの存在を発表することは望ましくない場合があります。このセキュリティ上の懸念の対策は次のとおりです。
o sending less detailed information in the key values,
o 重要な値であまり詳細な情報を送信し、
o not sending the extension key, or
o 拡張キーを送信しない、または
o using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 [2] and RFC 3723 [4]).
o IPSECを使用して、キーが送信されるISCSI接続の機密性を提供します（RFC 3720 [2]およびRFC 3723 [4]を参照）。
To support the first and second countermeasures, all implementations of this extension key MUST provide an administrative mechanism to disable sending the key. In addition, all implementations SHOULD provide an administrative mechanism to configure a verbosity level of the key value, thereby controlling the amount of information sent. For example, a lower verbosity might enable transmission of node architecture component names only, but no version numbers.
第1および2番目の対策をサポートするには、この拡張キーのすべての実装は、キーの送信を無効にする管理メカニズムを提供する必要があります。さらに、すべての実装は、主要な値の冗長レベルを構成するための管理メカニズムを提供し、それによって送信される情報の量を制御する必要があります。たとえば、冗長性が低いと、ノードアーキテクチャコンポーネント名のみの送信のみが可能になりますが、バージョン番号はありません。
The choice of which countermeasure is most appropriate depends on the environment. However, sending less detailed information in the key values may be an acceptable countermeasure in many environments, since it provides a compromise between sending too much information and the other more complete countermeasures of not sending the key at all or using IPsec.
どの対策が最も適切であるかの選択は、環境によって異なります。ただし、キー値にあまり詳細な情報を送信することは、多くの環境で受け入れられる対策である可能性があります。これは、あまりにも多くの情報を送信し、キーを送信しないか、IPSECを使用しないという他のより完全な対策との妥協を提供するからです。
In addition to security considerations involving transmission of the key contents, any logging method(s) used for the key values MUST keep the information secure from intruders. For all implementations, the requirements to address this security concern are:
キーコンテンツの送信を含むセキュリティ上の考慮事項に加えて、キー値に使用されるロギング方法は、侵入者から情報を安全に保つ必要があります。すべての実装について、このセキュリティの懸念に対処するための要件は次のとおりです。
o Display of the log MUST only be possible with administrative rights to the node.
o ログの表示は、ノードの管理権を使用することでのみ可能です。
o Options to disable logging to disk and to keep logs for a fixed duration SHOULD be provided.
o ロギングをディスクに無効にし、固定期間のログを保持するオプションを提供する必要があります。
Finally, it is important to note that different nodes may have different levels of risk, and these differences may affect the implementation. The components of risk include assets, threats, and vulnerabilities. Consider the following example iSCSI nodes, which demonstrate differences in assets and vulnerabilities of the nodes, and as a result, differences in implementation:
最後に、異なるノードにはリスクのレベルが異なる場合があり、これらの違いが実装に影響を与える可能性があることに注意することが重要です。リスクの要素には、資産、脅威、脆弱性が含まれます。次の例を考えてみましょう。これは、ノードの資産と脆弱性の違い、およびその結果、実装の違いを示しています。
o One iSCSI target based on a special-purpose operating system. Since the iSCSI target controls access to the data storage containing company assets, the asset level is seen as very high. Also, because of the special-purpose operating system, in which vulnerabilities are less well-known, the vulnerability level is viewed as low.
o 特殊な目的のオペレーティングシステムに基づく1つのISCSIターゲット。ISCSIターゲットは、会社の資産を含むデータストレージへのアクセスを制御するため、資産レベルは非常に高いと見なされます。また、脆弱性があまり知られていない特別な目的のオペレーティングシステムのため、脆弱性レベルは低いと見なされます。
o Multiple iSCSI initiators in a blade farm, each running a general-purpose operating system. The asset level of each node is viewed as low, since blades are replaceable and low cost. However, the vulnerability level is viewed as high, since there are many well-known vulnerabilities to the general-purpose operating system.
o それぞれが汎用オペレーティングシステムを運営しているブレードファームの複数のISCSIイニシエーター。ブレードは交換可能で低コストであるため、各ノードの資産レベルは低いと見なされます。ただし、汎用オペレーティングシステムに対して多くのよく知られている脆弱性があるため、脆弱性レベルは高いと見なされます。
For the above target, an appropriate implementation might be logging of received key values, but no transmission of the key. For the initiators, an appropriate implementation might be transmission of the key, but no logging of received key values.
上記のターゲットの場合、適切な実装は、受信したキー値のロギングである可能性がありますが、キーの送信はありません。イニシエーターの場合、適切な実装はキーの送信である可能性がありますが、受信キー値のログはありません。
The standards action of this document updates RFC 3720 to allow any iSCSI extension item, specifically X# extension text keys, Y# digest algorithms, and Z# authentication methods, to be defined by a standards track, experimental, or informational RFC. This document is a standards track RFC that defines an X# extension text key.
このドキュメントの標準アクションは、RFC 3720を更新し、任意のISCSI拡張アイテム、特にX＃拡張テキストキー、Y＃ダイジェストアルゴリズム、およびZ＃認証方法を許可し、標準トラック、実験、または情報RFCによって定義されます。このドキュメントは、X＃拡張テキストキーを定義する標準トラックRFCです。
IANA registered this key as follows:
IANAは次のようにこのキーを登録しました：
o Key Name: X#NodeArchitecture
o キー名：x＃nodearchitecture
o Description: Node architecture details
o 説明：ノードアーキテクチャの詳細
o Reference: [RFC4850]
o 参照：[RFC4850]
The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
RFC 3720の更新は、ISCSI拡張アイテムの追加タイプのRFCSを許可するための更新は、RFC 3720のテキスト（RFCテキストを公開後に変更できない）に次の変更が加えられた場合と同じ効果があります：1）セクション11.1、要件そのz＃認証方法は、「情報RFCによって記述する必要があります。」「RFC、実験RFC、または情報RFCの標準トラックで説明する必要があります。」に変更されます。
2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
2) セクション12.1では、Y＃ダイジェストアルゴリズムが「情報RFCによって説明する必要がある」という要件があります。「RFC、実験RFC、または情報RFCの標準トラックで説明する必要があります。」に変更されます。
3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
3) セクション12.22では、X＃テキストキーが「情報RFCによって記述する必要がある」という要件があります。「RFC、実験RFC、または情報RFCの標準トラックで説明する必要があります。」に変更されます。
4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental, or informational,"
4) セクション13.3では、拡張項目の許可されたRFCタイプの説明は、「RFCが標準トラックではなく情報的なものである可能性がある」、「RFCは標準の追跡、実験、または情報が必要である」まで変更されます。
5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed."
5) セクション13.5.2では、「標準トラック」というフレーズは、最初の段落の最後の文で「標準トラックまたは実験的」に変更されるため、文は次のように説明されます。このような文書のIETF手順に従ってください。」
The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720.
ISCSI拡張アイテムのレジストリは、これらの変更がRFC 3720のテキストに行われたかのように管理する必要があります。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[2] Satran、J.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M。、およびE. Zeidner、「Internet Small Computer Systems Interface（ISCSI）」、RFC 3720、2004年4月。
[3] 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.
[3] 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月。
[4] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[4] Aboba、B.、Tseng、J.、Walker、J.、Rangan、V。、およびF. Travostino、「IPを介したブロックストレージプロトコルの保護」、RFC 3723、2004年4月。
The IP Storage (ips) Working Group in the Transport Area of IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The author acknowledges the contributions of the entire working group.
IETFのトランスポートエリアにあるIPストレージ（IPS）ワーキンググループは、ISCSIプロトコルの定義を担当しています（他の多くの関連するIPストレージプロトコルを除く）。著者は、ワーキンググループ全体の貢献を認めています。
The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues found in this document: David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, John Forte, Jim Yuill, William Studenmund, and Ken Sandars. This document benefited from all these contributions.
次の個人は、この文書で見つかった問題に対する問題の特定や解決策の提案に直接貢献しました：デイビッドブラック、マリカルジュンチャダラパカ、ポールコニング、ジュリアンサトラン、ジョンハファード、クレアクラフト、ランガサンカール、ジョセフピットマン、グレッグバーグ、ジョンフォルテ、ジム・ユイル、ウィリアム・スタデンマンド、ケン・サンダース。この文書は、これらすべての貢献の恩恵を受けました。
Finally, the author recognizes Network Appliance, Inc. for sponsorship and support during the development of this work.
最後に、著者は、この作業の開発中にスポンサーシップとサポートについてNetwork Appliance、Inc。を認識しています。
Author's Address
著者の連絡先
Dave Wysochanski 8311 Brier Creek Parkway Suite 105-296 Raleigh, NC 27617 US
Dave Wysochanski 8311 Brier Creek Parkway Suite 105-296 NC 27617 US
Phone: +1 919 696 8130
EMail: wysochanski@pobox.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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エディター機能の資金は現在、インターネット協会によって提供されています。