Network Working Group O. Kolkman
Request for Comments: 3757 RIPE NCC
Updates: 3755, 2535 J. Schlyter
Category: Standards Track NIC-SE
E. Lewis
ARIN
April 2004
Domain Name System KEY (DNSKEY) Resource Record (RR)
Secure Entry Point (SEP) Flag
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 Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755.
委任署名者（DS）リソースレコード（RR）では、安全なエントリーポイント（SEP）として動作する公開鍵の概念が導入されました。親と公開鍵の交換時にはドメインネームシステムKEY（DNSKEY）リソースレコードセット内の他の公開鍵から9月のキーを区別する必要があります。 DNSKEYのRRのフラグビットはDNSKEY 09月として使用されることを示すために定義されています。フラグビットが正しくDSリソースレコードを生成するために、操作手順を支援するために、またはDNSKEYsは静的設定のために意図されているものを示すことを意図しています。フラグビットは、DNS検証プロトコルで使用されるべきではありません。このドキュメントの更新RFC 2535およびRFC 3755。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
7. Internationalization Considerations. . . . . . . . . . . . . . 6
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
"All keys are equal but some keys are more equal than others" [6].
[6]「すべてのキーが同じであるが、一部のキーが他よりも等しいです」。
With the definition of the Delegation Signer Resource Record (DS RR) [5], it has become important to differentiate between the keys in the DNSKEY RR set that are (to be) pointed to by parental DS RRs and the other keys in the DNSKEY RR set. We refer to these public keys as Secure Entry Point (SEP) keys. A SEP key either used to generate a DS RR or is distributed to resolvers that use the key as the root of a trusted subtree [3].
委任署名者リソースレコード（DS RR）[5]の定義と、それは（あると）DNSKEYにおける親のDS資源レコードと他のキーによって指し示されるDNSKEYのRRセット内のキーを区別することが重要になってきていますRRセット。私たちは、セキュアエントリーポイント（SEP）をキーとして、これらの公開鍵を参照してください。 SEP鍵DS RRを生成するために使用されるか、または[3]信頼サブツリーのルートとしてキーを使用しリゾルバに配布されますか。
In early deployment tests, the use of two (kinds of) key pairs for each zone has been prevalent. For one kind of key pair the private key is used to sign just the zone's DNSKEY resource record (RR) set. Its public key is intended to be referenced by a DS RR at the parent or configured statically in a resolver. The private key of the other kind of key pair is used to sign the rest of the zone's data sets. The former key pair is called a key-signing key (KSK) and the latter is called a zone-signing key (ZSK). In practice there have been usually one of each kind of key pair, but there will be multiples of each at times.
初期の展開のテストでは、各ゾーンの鍵ペア2（の種類）の使用が普及してきました。鍵ペアの一種のために秘密鍵は、単にゾーンのDNSKEYリソースレコード（RR）セットに署名するために使用されます。その公開鍵は、親にDS RRが参照するか、リゾルバで静的に構成されることを意図しています。鍵ペアの他の種類の秘密鍵は、ゾーンのデータセットの残りの部分に署名するために使用されます。前者の鍵ペアを鍵署名鍵（KSK）と呼ばれ、後者はゾーン署名鍵（ZSK）と呼ばれています。実際には通常、鍵ペアの種類ごとの1があったが、時には各の倍数があるでしょう。
It should be noted that division of keys pairs into KSK's and ZSK's is not mandatory in any definition of DNSSEC, not even with the introduction of the DS RR. But, in testing, this distinction has been helpful when designing key roll over (key super-cession) schemes. Given that the distinction has proven helpful, the labels KSK and ZSK have begun to stick.
KSKさんとZSKのに鍵ペアの部門がいなくてもDS RRの導入により、DNSSECのいずれかの定義では必須ではないことに留意すべきです。 （キー超譲渡）方式をオーバーキーロールを設計する場合でも、テストでは、この区別は参考にされています。区別が参考に証明していることを考えると、ラベルKSKとZSKは固執し始めています。
There is a need to differentiate the public keys for the key pairs that are used for key signing from keys that are not used key signing (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to be sent for generating DS RRs, which DNSKEYs are to be distributed to resolvers, and which keys are fed to the signer application at the appropriate time.
鍵署名（ZSKs対KSKs）が使用されていないキーからキー署名に使用されている鍵ペアの公開鍵を区別する必要があります。この必要性はDNSKEYsがレゾルバに配布される、どのキーが適切な時間に署名アプリケーションに供給されるDS RRを生成するために送信されるべきDNSKEYs知ることによって駆動されます。
In other words, the SEP bit provides an in-band method to communicate a DNSKEY RR's intended use to third parties. As an example we present 3 use cases in which the bit is useful:
換言すれば、9月ビットが第三者にDNSKEYのRRの使用目的を通信するために、バンドの方法を提供します。例として、我々は、ビットが有用である3ユースケースを提示します。
The parent is a registry, the parent and the child use secured DNS queries and responses, with a preexisting trust-relation, or plain DNS over a secured channel to exchange the child's DNSKEY RR sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP bit can be used to isolate the DNSKEYs for which a DS RR needs to be created.
親は、レジストリ、親と子の子のDNSKEYのRRセットを交換するセキュアなチャネルを介して既存の信頼関係、またはプレーンDNSで、セキュアなDNSクエリと応答を使用しています。 DNSKEYのRRセットが含まれていますので、完全なDNSKEYは、9月のビットはDS RRを作成する必要があるためDNSKEYsを単離することができるRRセット。
An administrator has configured a DNSKEY as root for a trusted subtree into security aware resolver. Using a special purpose tool that queries for the KEY RRs from that domain's apex, the administrator will be able to notice the roll over of the trusted anchor by a change of the subset of KEY RRs with the DS flag set.
管理者は、セキュリティ対応リゾルバへの信頼されたサブツリーのルートとしてDNSKEYを設定しています。そのドメインの頂点からKEYのRRを照会特別な目的のツールを使用して、管理者がDSフラグが設定されたKEY RRのサブセットの変化により、信頼できるアンカーのロールオーバーに気づくことができるようになります。
A signer might use the SEP bit on the public key to determine which private key to use to exclusively sign the DNSKEY RRset and which private key to use to sign the other RRsets in the zone.
署名者は、排他的ゾーン内の他のRRセットに署名するために使用するDNSKEY RRセットと秘密鍵の署名に使用するプライベートどのキーかを決定するために、公開鍵で9月のビットを使用する場合があります。
As demonstrated in the above examples it is important to be able to differentiate the SEP keys from the other keys in a DNSKEY RR set in the flow between signer and (parental) key-collector and in the flow between the signer and the resolver configuration. The SEP flag is to be of no interest to the flow between the verifier and the authoritative data store.
上記の例で実証されるように、署名者と（親の）キー・コレクタ間と署名者とリゾルバの設定との間の流れのフローでDNSKEYのRRセット内の他のキーからのSEP鍵を区別できることが重要です。 SEPフラグは、検証および信頼できるデータストアとの間の流れのない興味のあることです。
The reason for the term "SEP" is a result of the observation that the distinction between KSK and ZSK key pairs is made by the signer, a key pair could be used as both a KSK and a ZSK at the same time. To be clear, the term SEP was coined to lessen the confusion caused by the overlap. (Once this label was applied, it had the side effect of removing the temptation to have both a KSK flag bit and a ZSK flag bit.)
用語理由は、「SEPが」KSKとZSK鍵ペアの間の区別は、鍵のペアを同時にKSKとZSKの両方として使用することができる署名者によって行われる観察の結果です。明確にするために、用語9月には、オーバーラップによって引き起こされる混乱を軽減するために鋳造されました。 （このラベルが適用された後、それはKSKフラグビットとZSKフラグビットの両方を有するように誘惑を除去するの副作用を有していました。）
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
キー、 "推奨" 言葉 "MAY"、 "ないかもしれない"、 "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、および本文書にBCP 14に記載されているように解釈されるべきであり、 "すべきではありません" 、RFC 2119 [1]。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |S| protocol | algorithm |
| |E| | |
| |P| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DNSKEY RR Format This document assigns the 15th bit in the flags field as the secure entry point (SEP) bit. If the bit is set to 1 the key is intended to be used as secure entry point key. One SHOULD NOT assign special meaning to the key if the bit is set to 0. Operators can recognize the secure entry point key by the even or odd-ness of the decimal representation of the flag field.
DNSKEYのRRフォーマットは、このドキュメントでは、セキュアエントリーポイント（SEP）ビットのようなフラグフィールドに15ビットを割り当てます。ビットが1に設定されている場合、キーは、セキュアエントリーポイントキーとして使用されることが意図されています。ビットが0オペレータに設定されている場合、一つのキーに特別な意味を割り当てないでくださいフラグフィールドの10進表現の偶数または奇数らしによってセキュアエントリーポイントキーを認識することができます。
The bit MUST NOT be used during the resolving and verification process. The SEP flag is only used to provide a hint about the different administrative properties of the key and therefore the use of the SEP flag does not change the DNS resolution protocol or the resolution process.
ビットは解決し、検証プロセス中に使用してはいけません。 SEPフラグは、キーのみの異なる管理特性、したがってDNS解決プロトコルまたは解決プロセスを変更しないのSEPフラグの使用に関するヒントを提供するために使用されます。
The SEP bit is set by the key-pair-generator and MAY be used by the zone signer to decide whether the public part of the key pair is to be prepared for input to a DS RR generation function. The SEP bit is recommended to be set (to 1) whenever the public key of the key pair will be distributed to the parent zone to build the authentication chain or if the public key is to be distributed for static configuration in verifiers.
SEPビットは、鍵ペアジェネレータによって設定され、鍵のペアの公開部分はDS RR生成関数への入力のために準備されるべきかどうかを決定するために、ゾーンの署名者によって使用されてもよいです。鍵ペアの公開鍵は、認証チェーンを構築するために、親ゾーンに分配されるたびに、または公開鍵をベリファイアに静的な設定のために配布される場合のSEPビットが（1に）設定することが推奨されます。
When a key pair is created, the operator needs to indicate whether the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within the data that is used to compute the 'key tag field' in the SIG RR, changing the SEP bit will change the identity of the key within DNS. In other words, once a key is used to generate signatures, the setting of the SEP bit is to remain constant. If not, a verifier will not be able to find the relevant KEY RR.
鍵ペアが作成されると、オペレータは、9月ビットはDNSKEYのRRに設定すべきかどうかを示す必要があります。 SEPビットは、DNS内のキーのアイデンティティを変化させるのSEPビットを変更する、SIG RRの「キータグフィールド」を計算するために使用されているデータの範囲内であるように。鍵が署名を生成するために使用されると、つまり、のSEPビットの設定は、一定のままです。そうでない場合、検証は、関連するKEY RRを見つけることができません。
When signing a zone, it is intended that the key(s) with the SEP bit set (if such keys exist) are used to sign the KEY RR set of the zone. The same key can be used to sign the rest of the zone data too. It is conceivable that not all keys with a SEP bit set will sign the DNSKEY RR set, such keys might be pending retirement or not yet in use.
ゾーンに署名するとき（例えば、キーが存在する場合）、それのSEPビットが設定された鍵（単数または複数）が意図されているゾーンのKEY RRセットに署名するために使用されます。同じキーがあまりにもゾーンデータの残りの部分に署名するために使用することができます。これは、9月のビットがセットされたではないすべてのキーがDNSKEYのRRセットに署名することが考えられる、そのようなキーが使用されていない、まだ退職または保留される可能性があります。
When verifying a RR set, the SEP bit is not intended to play a role. How the key is used by the verifier is not intended to be a consideration at key creation time.
RRセットを検証する際に、9月のビットが役割を果たしていることを意図していません。どのようにキーを検証で使用されていることは、キーの作成時に考慮することを意図されていません。
Although the SEP flag provides a hint on which public key is to be used as trusted root, administrators can choose to ignore the fact that a DNSKEY has its SEP bit set or not when configuring a trusted root for their resolvers.
9月のフラグは、公開鍵は信頼されたルートとして使用されるべきでヒントを提供しますが、管理者はリゾルバのために信頼されたルートを設定する際DNSKEYが、その9月のビットが設定されたりしていないという事実を無視することを選択することができます。
Using the SEP flag a key roll over can be automated. The parent can use an existing trust relation to verify DNSKEY RR sets in which a new DNSKEY RR with the SEP flag appears.
キーロールオーバーを自動化することができるのSEPフラグを使用します。親は9月フラグを使用して新しいDNSKEYのRRが出現するDNSKEYのRRセットを確認するために、既存の信頼関係を使用することができます。
As stated in Section 3 the flag is not to be used in the resolution protocol or to determine the security status of a key. The flag is to be used for administrative purposes only.
第3節で述べたようにフラグが解決プロトコルまたはキーのセキュリティ状態を決定するために使用されるべきではありません。フラグは、管理目的のためにのみ使用されるべきです。
No trust in a key should be inferred from this flag - trust MUST be inferred from an existing chain of trust or an out-of-band exchange.
キーでNO信頼がこのフラグから推測されるべきではない - 信頼は信頼の既存のチェーンまたはアウトオブバンドの交換から推測されなければなりません。
Since this flag might be used for automating public key exchanges, we think the following consideration is in place.
このフラグは、公開鍵の交換を自動化するために使用される可能性がありますので、我々は以下の配慮が所定の位置にあると思います。
Automated mechanisms for roll over of the DS RR might be vulnerable to a class of replay attacks. This might happen after a public key exchange where a DNSKEY RR set, containing two DNSKEY RRs with the SEP flag set, is sent to the parent. The parent verifies the DNSKEY RR set with the existing trust relation and creates the new DS RR from the DNSKEY RR that the current DS RR is not pointing to. This key exchange might be replayed. Parents are encouraged to implement a replay defense. A simple defense can be based on a registry of keys that have been used to generate DS RRs during the most recent roll over. These same considerations apply to entities that configure keys in resolvers.
DS RRのロールオーバーのための自動化メカニズムは、リプレイ攻撃のクラスに対して脆弱であるかもしれません。これは、9月のフラグが設定された2つのDNSKEY RRを含むDNSKEYのRRセットは、親に送信され、公開鍵の交換後に起こるかもしれません。親は、既存の信頼関係を持つDNSKEYのRRセットを確認し、現在のDS RRが指していないDNSKEYのRRから新しいDS RRを作成します。この鍵交換が再生される可能性があります。両親はリプレイ防御を実装することをお勧めします。シンプルな防衛は、最新のロールオーバー時にDS RRを生成するために使用されているキーのレジストリに基づくことができます。これらの同じ考慮事項がリゾルバのキーを設定するエンティティに適用されます。
IANA has assigned the 15th bit in the DNSKEY Flags Registry (see Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
IANAは、セキュアエントリーポイント（SEP）ビットとして（[4]のセクション4.3を参照）DNSKEYフラグレジストリに15ビットが割り当てられています。
Although SEP is a popular acronym in many different languages, there are no internationalization considerations.
9月には、多くの異なる言語で人気の頭字語ですが、何の国際化の考慮事項はありません。
The ideas documented in this document are inspired by communications we had with numerous people and ideas published by other folk. Among others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler have contributed ideas and provided feedback.
この文書に記載のアイデアは、我々は他の民族によって公開され、多くの人とアイデアを持っていた通信に触発されています。なかでもマーク・アンドリュース、ロブAusteinと、Miek Gieben、オラフルグドムンソン、ダニエルKarrenberg、ダン・マッセイ、スコット・ローズ、マルコスサンスとサム・ワイラーは、アイデアを拠出し、フィードバックを提供しています。
This document saw the light during a workshop on DNSSEC operations hosted by USC/ISI in August 2002.
この文書は、2002年8月にUSC / ISIが主催DNSSECの運用に関するワークショップ中に光を見ました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[2]イーストレイク、D.、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2535、1999年3月。
[3] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001.
[3]ルイス、E.、RFC 3090 "ゾーンのステータスのDNSセキュリティ拡張の明確化"、2001年3月。
[4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, April 2004.
[4]ワイラー、S.、 "委任署名者のためのレガシーレゾルバの互換性（DS）"、RFC 3755、2004年4月。
[5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[5]グドムンソン、O.、 "委任署名者（DS）リソースレコード（RR）"、RFC 3658、2003年12月。
[6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy Story", ISBN 0151002177 (50th anniversary edition), April 1996.
[6]オーウェル、G.およびR.ステッドマン（イラスト）、 "動物農場;妖精ストーリー"、ISBN 0151002177（50周年記念版）、1996年4月。
Olaf M. Kolkman RIPE NCC Singel 256 Amsterdam 1016 AB NL
オラフ・M. Kolkman RIPE NCCシンゲル256アムステルダム1016 AB NL
Phone: +31 20 535 4444 EMail: olaf@ripe.net URI: http://www.ripe.net/
電話：+31 20 535 4444 Eメール：olaf@ripe.net URI：http://www.ripe.net/
Jakob Schlyter NIC-SE Box 5774 SE-114 87 Stockholm Sweden
ヤコブSchlyter NIC-SEボックス5774 SE-114 87ストックホルムスウェーデン
EMail: jakob@nic.se URI: http://www.nic.se/
電子メール：jakob@nic.se URI：http://www.nic.se/
Edward P. Lewis ARIN 3635 Concorde Parkway Suite 200 Chantilly, VA 20151 US
エドワード・P.ルイスARIN 3635コンコルドパークウェイスイート200シャンティイ、VA 20151米国
Phone: +1 703 227 9854 EMail: edlewis@arin.net URI: http://www.arin.net/
電話：+1 703 227 9854 Eメール：edlewis@arin.net URI：http://www.arin.net/
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機能のための基金は現在、インターネット協会によって提供されます。