Network Working Group W. Zhao
Request for Comments: 3832 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
C. Bisdikian
W. Jerome
IBM
July 2004
Remote Service Discovery in the
Service Location Protocol (SLP) via DNS SRV
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains.
リモートサービス発見は、特定のリモート（すなわち、非ローカル）DNSドメインで所望のサービスを発見することをいいます。この文書では、DNS SRVを経由してサービスロケーションプロトコル（SLP）で、リモートサービスの発見を説明します。それは、SLPディレクトリエージェントサービスのためにDNS SRVリソースレコードを定義するリモートサービスの発見のために一緒にSLPとDNS SRVを使用して、さまざまな問題について説明し、リモートDNSドメインで必要なサービスを発見するための手順を示します。
This document describes remote service discovery in the Service Location Protocol (SLP) [RFC2608] via DNS SRV [RFC2782]. We consider remote service discovery as discovering desired services in given remote DNS domains, and local service discovery as discovering desired services within the local administrative domain.
この文書では、DNS SRV [RFC2782]を経由してサービスロケーションプロトコル（SLP）[RFC2608]でリモートサービス発見を説明します。私たちは、ローカル管理ドメイン内の所望のサービスを発見するとして与えられたリモートDNSドメイン、およびローカルサービスの発見に必要なサービスを発見すると、リモートサービスの発見を考えます。
SLP provides a scalable framework for local service discovery and selection. In SLP, User Agents (UAs) discover desired services in the local administrative domain by querying all Service Agents (SAs) via multicast or querying a Directory Agent (DA) via unicast. To query a DA using unicast, a UA needs to first learn about the DA via DHCP, static configuration or multicast (listening for DAAdvert multicast or issuing DA discovery SrvRqst multicast).
SLPは、ローカルサービス発見と選択のためのスケーラブルなフレームワークを提供します。 SLPでは、ユーザーエージェント（UAは）マルチキャストを経由して、すべてのサービスエージェント（SA）を照会またはユニキャスト経由でディレクトリエージェント（DA）を照会することにより、ローカル管理ドメインに必要なサービスを発見します。ユニキャストを使用してDAを照会するには、UAは、最初に（DAAdvertマルチキャストをリッスンまたはDAディスカバリSrvRqstマルチキャストを発行する）DHCP、静的な構成またはマルチキャスト経由DAについて学習する必要があります。
DNS SRV provides good support for remote service discovery. However, if multiple servers are discovered via DNS SRV for a service, only priority and weight can be used to make a selection. If additional service properties (such as cost, speed and service quality) need to be considered in the selection process, DNS SRV becomes insufficient.
DNS SRVは、リモートサービス発見のための優れたサポートを提供します。複数のサーバがサービスのDNS SRVを経由して発見された場合は、唯一の優先順位および重量は、選択を行うために使用することができます。 （例えば、コスト、速度及びサービス品質のような）追加のサービス特性が選択プロセスにおいて考慮される必要がある場合、DNS SRVが不十分となります。
We propose that using SLP and DNS SRV together can provide better support for remote service discovery. First, a UA uses DNS SRV to find SLP DAs at a remote DNS domain. Then, the UA uses SLP to query one of those DAs to discover desired services. In this way, we can avoid the limitations in using SLP and DNS SRV separately. On one hand, without DNS SRV, an SLP UA needs to depend on static configuration to learn about remote DAs because DHCP and multicast DA discovery are not generally applicable beyond the local administrative domain. On the other hand, without SLP, DNS SRV has limited support for service selection.
私たちは一緒にSLPとDNS SRVを使用してリモートサービス発見のためのより良いサポートを提供できることを提案します。まず、UAは、リモートDNSドメインでSLP DAを見つけるために、DNSのSRVを使用しています。その後、UAは、必要なサービスを発見するために、これらのDAのいずれかを照会するSLPを使用しています。このように、我々は、別途SLPとDNS SRVを使用して制限を回避することができます。一方では、DNSのSRVせずに、SLP UAは、DHCPおよびマルチキャストDAの発見は、一般的にローカル管理ドメインを越えて適用されないため、リモートDAを学ぶために静的な構成に依存する必要があります。一方、SLPせずに、DNSのSRVは、サービス選択のための限定的なサポートを持っています。
In this document, we first define the DNS SRV Resource Records (RRs) for SLP DA services, which are used to map a given DNS domain to remotely accessible (i.e., accessible from the Internet) DAs in that domain. Then, we discuss various issues in using SLP and DNS SRV together for remote service discovery. Finally, we give the steps for discovering services in remote DNS domains.
この文書では、まず、そのドメイン内に（インターネットからすなわち、アクセス）リモートアクセスがDAを与えられたDNSドメインをマッピングするために使用されているSLP DAサービスのためのDNS SRVリソースレコード（RR）を定義します。その後、我々は、リモートサービスの発見のために一緒にSLPとDNS SRVを使用して様々な問題を議論します。最後に、我々は、リモートDNSドメインでサービスを発見するための手順を与えます。
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
According to RFC 2782 [RFC2782], the DNS SRV RRs for SLP DA services are defined as follows:
次のようにRFC 2782 [RFC2782]によれば、SLP DAサービスのDNS SRV資源レコードが定義されています。
_slpda._Proto.Name TTL Class SRV Priority Weight Port Target
_slpda._Proto.Name TTLクラスSRV優先重ポートターゲット
where "slpda" is the symbolic name for SLP DA services, the Proto field is either "tcp" or "udp", and the Target field is the domain name of an SLP DA. Please refer to [RFC2782] for detailed explanation of each field in DNS SRV RRs.
「slpdaは」SLP DAサービスのシンボリック名です、プロトフィールドは、「TCP」または「UDP」のいずれかで、ターゲットフィールドは、SLP DAのドメイン名です。 DNSのSRV RRを各フィールドの詳しい説明については、[RFC2782]を参照してください。
Next we show an example of using DNS SRV RRs to map a given DNS domain to remotely accessible DAs in that domain. To discover remotely accessible DAs in a remote domain (say, example.com), a UA makes a DNS query [RFC1034,RFC1035] for QNAME=_slpda._tcp.example.com (or QNAME=_slpda._udp.example.com), QCLASS=IN, and QTYPE=SRV. Then the UA will receive a list of DNS SRV RRs in a DNS reply, which gives all remotely accessible DAs in the domain example.com, such as:
次に、私たちは、与えられたDNSドメインそのドメイン内にリモートからアクセスDAをマッピングするためのDNS SRVのRRを使用した例を示しました。リモートドメイン（たとえば、example.com）にリモートからアクセスDAを検出するには、UAはQNAME = _slpda._tcp.example.com（またはQNAME = _slpda._udp.example.com）のためのDNSクエリ[RFC1034、RFC1035]を作ります、QCLASS =では、とQTYPE = SRV。 ：その後、UAは、次のような、すべてのリモートでドメインexample.comでアクセスDAを与えDNS応答にDNS SRV RRのリストを受け取ります
;; Priority Weight Port Target _slpda._tcp.example.com IN SRV 0 0 427 da1.example.com _slpda._tcp.example.com IN SRV 0 0 427 da2.example.com
;;優先順位重ポートSRV内のターゲット・_slpda._tcp.example.com 0 0 427 da1.example.com _slpda._tcp.example.com SRV 0 0 427 da2.example.com
SLP DAs can be discovered in two ways: (1) using the mechanisms described in RFC 2608, and (2) using DNS SRV RRs as described in this document. The second approach is useful for UAs to acquire service information for remote DNS domains. For example, a mobile node visiting a network (without the use of mobile IP) may want to obtain information about services in its home network.
SLPのDAは、2つの方法で発見することができる：（1）RFC 2608で説明されたメカニズムを使用して、この文書に記載されているように（2）のDNS SRVのRRを使用します。 UAがリモートDNSドメインのサービス情報を取得するための第2のアプローチは、有用です。例えば、（モバイルIPを使用せずに）ネットワークを訪問し、移動ノードは、そのホームネットワークにおけるサービスに関する情報を取得することができます。
Using DNS SRV RRs to discover SLP DAs requires knowledge of the domain where SLP DAs are registered. For remote service discovery, it is assumed that the DNS domain of interest is known via a priori knowledge. For example, a UA is configured with a domain name or the user provides the domain name manually.
SLP DAを発見するためのDNS SRVのRRを使用すると、SLP DAには登録されているドメインの知識が必要です。リモートサービスの発見のためには、関心のDNSドメインが先験的知識を経由して知られているものとします。例えば、UAは、ドメイン名またはユーザー手動でドメイン名を提供して設定されています。
Note that there is no implied "search order" of DNS domains in finding remote DAs. For instance, if a UA is looking for remote DAs in the domain foo.bar.example.com, it SHOULD only look for _slp._tcp.foo.bar.example.com (or _slp._udp.foo.bar.example.com), and MUST NOT fall back to look for _slp._tcp.bar.example.com, _slp._tcp.example.com, and so on.
リモートDAを見つけることにDNSドメインのない暗黙の「検索順序」が存在しないことに注意してください。 UAは、ドメインfoo.bar.example.comでリモートDAを探している場合たとえば、それだけ_slp._tcp.foo.bar.example.com（または_slp._udp.foo.bar.exampleを探してください。 comなど）など_slp._tcp.bar.example.com、_slp._tcp.example.comを探すためにフォールバック、およびてはなりません。
A UA discovers desired services in a given remote DNS domain by unicasting requests to DAs in that domain. The UA uses remote DAs according to these prioritized rules: (1) using DAs which it has been configured with, and (2) using DAs which it has discovered via DNS SRV.
UAは、そのドメイン内のDAのに要求をユニキャストによって与えられたリモートDNSドメインで必要なサービスを発見します。 UAは、これらの優先順位のルールに従ってリモートDAを使用する：（1）それはで構成されているDAを使用して、そして（2）それがDNS SRVを介して発見したDAを使用します。
As SLP scopes are intended to be used only within one administrative domain, they are likely incomprehensible to users outside of the administrative domain. Thus, any remotely accessible service MUST be registered in the "default" scope, but it MAY be registered in other scopes at the same time. Similarly, all DAs advertised via DNS SRV MUST serve the "default" scope, but they MAY serve other scopes at the same time. As a result, users wishing to discover services at a remote DNS domain SHOULD only search the "default" scope.
SLPスコープが一つだけの管理ドメイン内で使用されることを意図しているとして、彼らは、管理ドメイン外のユーザーに理解できない可能性があります。このように、任意のリモートからアクセス可能なサービスは、「デフォルト」のスコープに登録する必要がありますが、それは同時に、他のスコープに登録しておいてもよいです。同様に、DNSのSRVを経由して宣伝すべてのDAは、「デフォルト」の範囲を提供しなければならないが、彼らは、同時に他のスコープを果たすことができます。その結果、リモートDNSドメインでサービスを発見したいユーザーは、唯一の「デフォルト」範囲を検索する必要があります。
The steps for a User Agent U to discover desired services in a remote DNS domain D are as follows.
次のようにリモートDNSドメインDに必要なサービスを発見するためのユーザエージェントUのための手順は次のとおりです。
(1) U makes a DNS query for QNAME=_slpda._tcp.D (or QNAME=_slpda._udp.D), QCLASS=IN, and QTYPE=SRV. Then, U gets a list of DNS SRV RRs (referred to as L) in a DNS reply, which gives all remotely accessible DAs in D.
（1）Uは、QNAME = _slpda._tcp.D（またはQNAME = _slpda._udp.D）、QCLASS = IN、およびQTYPE = SRVのDNSクエリを行います。その後、Uは全てリモートD.でアクセスDAを与えるDNS応答にDNS SRV RRの（Lと呼ばれる）のリストを取得します
(2) U selects a DA X from L based on the priority and weight information per RFC 2782.
（2）Uは、RFC 2782ごとの優先度と重み情報に基づいて、LからDA Xを選択します。
(3) U queries X in the "default" scope to discover desired services in D.
（3）UはDに所望のサービスを発見するために、「デフォルト」の範囲にXを照会します
Note that the services discovered in the above steps may not necessarily be remotely accessible.
上記の手順で発見されたサービスは、必ずしもリモートからアクセスできないことに注意してください。
To support remote service discovery, a domain exposes its service information to the Internet. Standard SLP authentication SHOULD be used to protect valuable service information. First, there is a risk that any SA could advertise any service on a DA accessible from the Internet. Such a DA SHOULD reject all registrations and deregistrations that cannot be authenticated. Secondly, to avoid disclosing unintended service information to remote users, a DA accessible from the Internet SHOULD at least authenticate service queries that are not in the "default" scope. In addition, the security considerations for DNS SRV [RFC2782] apply to this document. Also, the DNS security extensions [RFC 2535] SHOULD be used to provide origin authentication and integrity protection for DNS data.
リモートサービスの発見をサポートするために、ドメインは、インターネットへのサービス情報を公開します。標準SLP認証は貴重なサービス情報を保護するために使用されるべきです。まず、任意のSAは、インターネットからアクセス可能DA上の任意のサービスを宣伝することができ、リスクがあります。このようなDAは認証できないすべての登録と登録解除を拒否すべきです。第二に、リモートユーザーへの意図しないサービス情報の開示を避けるために、インターネットからアクセス可能DAは、少なくとも、「デフォルト」の範囲にないサービスのクエリを認証する必要があります。また、DNSのSRV [RFC2782]のためのセキュリティの考慮事項は、この文書に適用されます。また、DNSセキュリティ拡張[RFC 2535]はDNSデータの発信元の認証と完全性保護を提供するために使用されるべきです。
This specification describes remote service discovery in SLP via DNS SRV. It facilitates discovering services at a remote DNS domain if the domain name is known via a priori knowledge. However, it does not intend to solve the problem of Internet-wide service discovery.
この仕様は、DNS SRVを経由してSLPでのリモートサービス発見を説明します。ドメイン名が事前知識を経由して知られている場合は、リモートDNSドメインでサービスを発見することを容易にします。しかし、それはインターネット全体のサービス・ディスカバリの問題を解決するつもりはありません。
Users should be aware of two constraints in using DNS SRV to discover SLP DAs: (1) they SHOULD only use DNS SRV to discover DAs in the "default" scope, and (2) an administrator may choose to register only a subset of all DAs in the "default" scope via DNS SRV. Thus, to discover local DAs, implementations MUST use the standard SLP mechanisms per RFC 2608. In addition, implementations supporting this specification MAY use DNS SRV to discover local DAs in the "default" scope.
ユーザーは、SLP DAを発見するためのDNS SRVを使用して2つの制約に注意する必要があります：（1）彼らは唯一の「デフォルト」範囲にDAを発見するためのDNS SRVを使用すべきである、と（2）管理者は、すべてのサブセットのみを登録することもできますDNSのSRVを経由して「デフォルト」のスコープでDAを。したがって、ローカルDAを発見するために、実装は、この仕様をサポートする実装が「デフォルト」の範囲内にローカルDAを発見するためのDNS SRVを使用することができるが、また、RFC 2608あたりの標準SLPメカニズムを使用しなければなりません。
As SLP scopes are not intended to be used outside the local administrative domain, all remote service discovery in SLP SHOULD be carried only in the "default" scope.
SLPスコープがローカル管理ドメインの外で使用することを意図していないため、SLPのすべてのリモートサービスの発見は、「デフォルト」の範囲で実施しなければなりません。
Note that the services discovered via DNS SRV and remote SLP DAs may not necessarily be remotely accessible.
DNSのSRVとリモートSLP DAを経て発見されたサービスは、必ずしもリモートからアクセスできないことに注意してください。
In the DNS SRV RRs for SLP DA services, the symbolic name for the Service field is "slpda", supported protocols are "tcp" and "udp". The following values have been registered with IANA:
SLP DAサービスのDNS SRV RRをでは、サービス分野のシンボリック名は「slpda」で、サポートされているプロトコルは「TCP」および「UDP」です。次の値は、IANAに登録されています：
Service Field Protocol Field Reference
------------- -------------- ---------
slpda tcp [RFC3832]
slpda udp [RFC3832]
The authors would like to thank Bernard Aboba, Kevin Arnold, Steven Bellovin, Ted Hardie, James Kempf, Thomas Narten, Erik Nordmark, and Jon Peterson for their valuable comments.
作者は彼らの貴重なコメントのためにバーナードAboba、ケビン・アーノルド、スティーブンBellovin氏、テッドハーディー、ジェームズ・ケンプ、トーマスNarten氏、エリックNordmarkと、およびジョンピーターソンに感謝したいと思います。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2 ", RFC 2608, June 1999.
[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.及びL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]イーストレーク第3、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
コンピュータサイエンスコロンビア大学のWeibin趙省1214アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027から7003
EMail: zwb@cs.columbia.edu
メールアドレス：zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
コンピュータサイエンスコロンビア大学のヘニングSchulzrinneと学科1214アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027から7003
EMail: hgs@cs.columbia.edu
メールアドレス：hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
エリック・グットマンSun MicrosystemsのEichhoelzelstr。 7 74915ヴァイプシュタットドイツ
EMail: Erik.Guttman@sun.com
メールアドレス：Erik.Guttman@sun.com
Dr. Chatschik Bisdikian IBM T. J. Watson Research Center 30 Saw Mill River Road, M/S 3S-B34 Hawthorne, NY 10532, USA
博士Chatschik Bisdikian IBM T. J.ワトソン研究所30ソウミルリバーロード、M / S 3S-B34ホーソーン、NY 10532、USA
Phone: +1 914 784 7439 Fax: +1 914 784 6225 EMail: bisdik@us.ibm.com
電話：+1 914 784 7439ファックス：+1 914 784 6225 Eメール：bisdik@us.ibm.com
William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA
ウィリアム・F.ジェロームIBM社トーマス・J・ワトソン研究所19スカイラインドライブホーソーン、NY 10532、USA
EMail: wfj@us.ibm.com
メールアドレス：wfj@us.ibm.com
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、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 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。