RFC4243 日本語訳
4243 Vendor-Specific Information Suboption for the Dynamic HostConfiguration Protocol (DHCP) Relay Agent Option. M. Stapp, R.Johnson, T. Palaniappan. December 2005. (Format: TXT=14342 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Stapp
Request for Comments: 4243 R. Johnson
Category: Standards Track T. Palaniappan
Cisco Systems, Inc.
December 2005
コメントを求めるワーキンググループM.スタップ要求をネットワークでつないでください: 4243年のR・ジョンソンCategory: 標準化過程T.PalaniappanシスコシステムズInc.2005年12月
Vendor-Specific Information Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
Dynamic Host Configuration Protocol(DHCP)中継エージェントオプションのためのベンダー特殊情報Suboption
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 Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor- specific information in the DHCP messages it forwards, as configured by its administrator.
このメモはDynamic Host Configuration Protocol(DHCP)の中継エージェント情報オプションのために新しいVendor特有の情報「副-オプション」を定義します。 「副-オプション」はDHCP中継エージェントにそれが転送するDHCPメッセージでベンダー特殊情報を入れさせます、管理者によって構成されるように。
Table of Contents
目次
1. Introduction ....................................................2 2. Requirements Terminology ........................................2 3. The Vendor-Specific Suboption ...................................2 4. Relay Agent Behavior ............................................4 5. DHCP Server Behavior ............................................4 6. Security Considerations .........................................4 7. IANA Considerations .............................................5 8. Acknowledgements ................................................5 Normative References ...............................................5 Informative References .............................................5
1. 序論…2 2. 要件用語…2 3. ベンダー特有のSuboption…2 4. エージェントの振舞いをリレーしてください…4 5. DHCPサーバの振舞い…4 6. セキュリティ問題…4 7. IANA問題…5 8. 承認…5 標準の参照…5 有益な参照…5
Stapp, et al. Standards Track [Page 1] RFC 4243 Vendor-Specific Relay Suboption December 2005
スタップ、他 リレーSuboption2005年12月にベンダー特有の標準化過程[1ページ]RFC4243
1. Introduction
1. 序論
DHCP (RFC 2131 [2]) provides IP addresses and configuration information for IPv4 clients. It includes a relay agent capability, in which processes within the network infrastructure receive broadcast messages from clients and forward them to DHCP servers as unicast messages. In network environments like DOCSIS data-over- cable and xDSL, for example, it has proven useful for the relay agent to add information to the DHCP message before forwarding it, using the relay agent information option (RFC 3046 [3]).
DHCP、(RFC2131[2])はIPアドレスと設定情報をIPv4クライアントに提供します。 それは中継エージェント能力を含んでいます。(ネットワークインフラの中のプロセスは、それでクライアントから同報メッセージを受け取って、ユニキャストメッセージとしてDHCPサーバに彼らを送ります)。 例えば、DOCSISデータ過剰ケーブルとxDSLのようなネットワーク環境で、それを進める前に中継エージェントがDHCPメッセージに情報を追加するのが役に立つと判明しました、中継エージェント情報オプションを使用して。(RFC3046[3])。
Servers that recognize the relay agent option echo it back in their replies, and some of the information that relays add may be used to help an edge device efficiently return replies to clients. The information that relays supply can also be used in the server's decision making about the addresses and configuration parameters that the client should receive.
中継エージェントオプションを認識するサーバが彼らの回答でそれをecho backです、そして、リレーがエッジデバイスが効率的に戻るのを助けるのに使用されるかもしれないと言い足す情報のいくつかがクライアントに答えます。 また、クライアントが受け取るべきであるアドレスと設定パラメータに関してサーバの意志決定に供給をリレーする情報は使用できます。
In many environments, it's desirable to associate some vendor- or provider-specific information with the clients' DHCP messages. This is often done using the relay agent information option. RFC 3046 defines Remote-ID and Circuit-ID sub-options that are used to carry such information. The values of those suboptions, however, are usually based on some network resource, such as an IP address of a network access device, an ATM Virtual Circuit identifier, or a DOCSIS cable-modem identifier. As a result, the values carried in these suboptions are dependent on the physical network configuration. The Vendor-Specific suboption allows administrators to associate other useful data with relayed DHCP messages.
多くの環境で、何らかのベンダーかプロバイダー特殊情報をクライアントのDHCPメッセージに関連づけるのは望ましいです。 これは中継エージェント情報オプションを使用ししばしば終わっています。 RFC3046はそのような情報を運ぶのに使用されるRemote-IDとCircuit-IDサブオプションを定義します。 しかしながら、通常、それらの「副-オプション」の値はあるネットワーク資源に基づいています、ネットワークアクセスデバイス、ATM Virtual Circuit識別子、またはDOCSISケーブルモデム識別子のIPアドレスのように。 その結果、これらの「副-オプション」で運ばれた値は物理ネットワーク構成に依存しています。 Vendor特有の「副-オプション」は管理者に他の役に立つデータをリレーされたDHCPメッセージに関連づけさせます。
2. Requirements Terminology
2. 要件用語
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
3. The Vendor-Specific Suboption
3. ベンダー特有のSuboption
This memo defines a new DHCP relay agent option suboption that carries vendor-defined data. The suboption takes a form similar to the Vendor-Identifying, Vendor-Specific Option [7].
このメモはベンダーによって定義されたデータを運ぶ新しいDHCP中継エージェントオプション「副-オプション」を定義します。 「副-オプション」はVendorを特定していて、Vendor特有のOption[7]と同様の形を取ります。
Stapp, et al. Standards Track [Page 2] RFC 4243 Vendor-Specific Relay Suboption December 2005
スタップ、他 リレーSuboption2005年12月にベンダー特有の標準化過程[2ページ]RFC4243
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Enterprise Number1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | DataLen1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
\ Suboption Data1 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DataLen2 | Suboption Data2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 長さ| エンタープライズNumber1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | DataLen1| | ++++++++++++++++++++++++++\Suboption Data1\+++++++++++++++++++++++++++++++++| エンタープライズNumber2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataLen2| Suboption Data2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Code for the suboption is 9.
「副-オプション」のためのCodeは9歳です。
The one-byte Length field is the length of the data carried in the suboption, in bytes. The length includes the length of the first Enterprise Number; the minimum length is 4 bytes.
1バイトのLength分野は「副-オプション」、バイトで運ばれたデータの長さです。 長さは最初のエンタープライズNumberの長さを含んでいます。 最小の長さは4バイトです。
"Enterprise NumberN" is a vendor's Enterprise Number as registered with IANA [4]. It is a four-byte integer value in network byte- order.
「エンタープライズNumberN」は登録されるとしてIANA[4]とベンダーのエンタープライズNumberです。 それはネットワークバイトオーダーで4バイトの整数値です。
DataLenN is the length of the data associated with the Enterprise Number.
DataLenNはエンタープライズNumberに関連しているデータの長さです。
The Suboption Data is an opaque sequence of bytes.
Suboption Dataはバイトの不明瞭な系列です。
The Vendor-Specific suboption includes at least one Enterprise Number and carries opaque data defined by the organization identified by the Enterprise Number. A relay may include data associated with more than one vendor's Enterprise Number within a single instance of the Suboption.
Vendor特有の「副-オプション」は、少なくとも1エンタープライズNumberを含んで、エンタープライズNumberによって特定された組織によって定義された不明瞭なデータを運びます。 リレーはSuboptionのただ一つのインスタンスの中で1つ以上のベンダーのエンタープライズNumberに関連しているデータを含むかもしれません。
Of course, the Vendor-Specific data are vendor-specific. This specification does not establish any requirements on the data in the suboption. Vendors who make use of this suboption are encouraged to document their usage in order to make interoperability possible.
もちろん、Vendor特有のデータはベンダー特有です。 この仕様は「副-オプション」のデータに関するどんな要件も確立しません。 この「副-オプション」を利用するベンダーが相互運用性を可能にするようにそれらの用法を記録するよう奨励されます。
Stapp, et al. Standards Track [Page 3] RFC 4243 Vendor-Specific Relay Suboption December 2005
スタップ、他 リレーSuboption2005年12月にベンダー特有の標準化過程[3ページ]RFC4243
4. Relay Agent Behavior
4. 中継エージェントの振舞い
DHCP relay agents MAY be configured to include Vendor-Specific suboptions if they include a relay agent information option in relayed DHCP messages. The suboptions' types and data are assigned and configured through mechanisms that are outside the scope of this memo.
彼らがリレーされたDHCPメッセージに中継エージェント情報オプションを含んでいるなら、DHCP中継エージェントは、Vendor特有の「副-オプション」を含むように構成されるかもしれません。 「副-オプション」のタイプとデータは、このメモの範囲の外にあるメカニズムを通して割り当てられて、構成されます。
Relay implementors are encouraged to offer their administrators a means of configuring what data can be included in this suboption, and to document what they are capable of.
リレー作成者は、この「副-オプション」にどんなデータを含むことができるかを構成する手段を彼らの管理者に提供して、それらが何であることができるかを記録するよう奨励されます。
5. DHCP Server Behavior
5. DHCPサーバの振舞い
This suboption provides additional information to the DHCP server. The DHCP server, if it is configured to support this suboption, may use this information, in addition to other relay agent option data and other options included in the DHCP client messages, in order to assign an IP address and/or other configuration parameters to the client. There is no special additional processing for this suboption.
この「副-オプション」はDHCPサーバに追加情報を提供します。この「副-オプション」をサポートするのが構成されているなら、DHCPサーバはこの情報を使用するかもしれません、他の中継エージェントオプションデータとDHCPクライアントメッセージに含まれていた他のオプションに加えて、IPアドレス、そして/または、他の設定パラメータをクライアントに割り当てるために。 どんなこの「副-オプション」に、特別な追加処理もありません。
6. Security Considerations
6. セキュリティ問題
Message authentication in DHCP for intradomain use, where the out- of-band exchange of a shared secret is feasible, is defined in RFC 3118 [5]. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [2].
intradomain使用のためのDHCPの通報認証は共有秘密キーバンドの出ている交換が可能であるところでRFC3118[5]で定義されます。 RFC2131[2]でDHCPプロトコル仕様のセクション7で攻撃する潜在被曝について議論します。
The DHCP relay agent option depends on a trusted relationship between the DHCP relay agent and the server, as described in section 5 of RFC 3046. Fraudulent relay agent option data could potentially lead to theft-of-service or exhaustion of limited resources (like IP addresses) by unauthorized clients. A host that tampered with relay agent data associated with another host's DHCP messages could deny service to that host, or interfere with its operation by leading the DHCP server to assign it inappropriate configuration parameters.
DHCP中継エージェントオプションはDHCP中継エージェントとサーバとの信じられた関係によります、RFC3046のセクション5で説明されるように。 詐欺的な中継エージェントオプションデータは潜在的にサービスの窃盗か疲れきるのに権限のないクライアントが限りある資源(IPアドレスのような)についてつながるかもしれません。 DHCPサーバが不適当な設定パラメータをそれに割り当てるように導くことによって、別のホストのDHCPメッセージに関連している中継エージェントデータをいじったホストは、そのホストに対するサービスを否定するか、または操作を妨げることができるでしょう。
While the introduction of fraudulent relay agent options can be prevented by a perimeter defense that blocks these options unless the relay agent is trusted, a deeper defense using authentication for relay agent options via the Authentication Suboption [6] SHOULD be deployed as well.
詐欺的な中継エージェントオプションの導入を防ぐことができる間、また、より深いディフェンスが中継エージェントオプションにAuthentication Suboption[6]SHOULDを通して認証を使用して、中継エージェントが信じられない場合これらのオプションを妨げる規定の防衛線内での防衛で、配布されてください。
There are several data in a DHCP message that convey information that may identify an individual host on the network. These include the chaddr, the client-id option, and the hostname and client-fqdn options. Depending on the type of data included, the Vendor-Specific suboption may also convey information that identifies a specific host or a specific user on the network. In practice, this information isn't exposed outside the internal service-provider network, where DHCP messages are usually confined. Administrators who configure data that will be used in DHCP Vendor-Specific suboptions should be careful to use data that are appropriate for the types of networks
DHCPメッセージのネットワークで個々のホストを特定するかもしれない情報を伝えるいくつかのデータがあります。 これらはchaddr、クライアントイドオプション、ホスト名、およびクライアント-fqdnオプションを含んでいます。 データを含むタイプに頼っていて、また、Vendor特有の「副-オプション」はネットワークで特定のホストか特定のユーザを特定する情報を伝えるかもしれません。 実際には、この情報は内部のサービスプロバイダーネットワークの外で暴露されません。そこでは、通常、DHCPメッセージが限定されます。 DHCP Vendor特有の「副-オプション」で使用されるデータを構成する管理者はネットワークのタイプに、適切なデータを使用するのに慎重であるはずです。
Stapp, et al. Standards Track [Page 4] RFC 4243 Vendor-Specific Relay Suboption December 2005
スタップ、他 リレーSuboption2005年12月にベンダー特有の標準化過程[4ページ]RFC4243
they administer. If DHCP messages travel outside the service- provider's own network, or if the suboption values may become visible to other users, it may raise privacy concerns for the access provider or service provider.
彼らは管理します。 DHCPメッセージがサービスプロバイダーの自身のネットワークの外を移動するか、または「副-オプション」値が他のユーザにとって目に見えるようになるかもしれないなら、それはアクセスプロバイダかサービスプロバイダーのためにプライバシーの問題を提起するかもしれません。
7. IANA Considerations
7. IANA問題
The IANA has assigned the suboption number 9 for the Vendor-Specific Information Suboption from the DHCP Relay Agent Information Option [3] suboption number space.
IANAはDHCP Relayエージェント情報Option[3]「副-オプション」数のスペースからVendor特有の情報Suboptionの「副-オプション」No.9を割り当てました。
8. Acknowledgements
8. 承認
The authors are grateful to Andy Sudduth, Josh Littlefield, and Kim Kinnear for their review and comments.
作者はアンディSudduth、ジョッシュ・リトルフィールド、およびキム・キネアに彼らのレビューとコメントに感謝しています。
Normative References
引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[2]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[3] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、2001年1月。
[4] IANA, "Private Enterprise Numbers (http://www.iana.org/
assignments/enterprise-numbers.html)".
[4]IANA、「個人的なエンタープライズ民数記( http://www.iana.org/ 企業課題/numbers.html)。」
Informative References
有益な参照
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[5]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。
[6] Stapp, M. and T. Lemon, "The Authentication Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent Option",
RFC 4030, March 2005.
[6] スタップとM.とT.レモン、「Dynamic Host Configuration Protocol(DHCP)中継エージェントオプションのための認証Suboption」、RFC4030、2005年3月。
[7] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic
Host Configuration Protocol version 4 (DHCPv4)", RFC 3925,
October 2004.
2004年10月の[7] リトルフィールド、J.、「Dynamic Host Configuration Protocolバージョン4(DHCPv4)のためのベンダーを特定するVendor Options」RFC3925。
Stapp, et al. Standards Track [Page 5] RFC 4243 Vendor-Specific Relay Suboption December 2005
スタップ、他 リレーSuboption2005年12月にベンダー特有の標準化過程[5ページ]RFC4243
Authors' Addresses
作者のアドレス
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
スタップシスコシステムズInc.1414マサチューセッツAveをマークしてください。 Boxborough、MA01719米国
Phone: 978.936.0000 EMail: mjs@cisco.com
以下に電話をしてください。 978.936.0000 メールしてください: mjs@cisco.com
Richard Johnson Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
リチャードペニスシスコシステムズInc.170W.タスマンサンノゼ博士、カリフォルニア95134米国
Phone: 408.526.4000 EMail: raj@cisco.com
以下に電話をしてください。 408.526.4000 メールしてください: raj@cisco.com
Theyn Palaniappan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Theyn PalaniappanシスコシステムズInc.170W.タスマンサンノゼ博士、カリフォルニア95134米国
Phone: 408.526.4000 EMail: athenmoz@cisco.com
以下に電話をしてください。 408.526.4000 メールしてください: athenmoz@cisco.com
Stapp, et al. Standards Track [Page 6] RFC 4243 Vendor-Specific Relay Suboption December 2005
スタップ、他 リレーSuboption2005年12月にベンダー特有の標準化過程[6ページ]RFC4243
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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機能のための基金は現在、インターネット協会によって提供されます。
Stapp, et al. Standards Track [Page 7]
スタップ、他 標準化過程[7ページ]
一覧
スポンサーリンク
