RFC3123 日本語訳
3123 A DNS RR Type for Lists of Address Prefixes (APL RR). P. Koch. June 2001. (Format: TXT=14648 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Koch Request for Comments: 3123 Universitaet Bielefeld Category: Experimental June 2001
コメントを求めるワーキンググループP.コッホ要求をネットワークでつないでください: 3123年のUniversitaetビーレフェルトカテゴリ: 実験的な2001年6月
A DNS RR Type for Lists of Address Prefixes (APL RR)
アドレスに関する繰返し要素の並びが前に置くDNS RRタイプ(APL RR)
Status of this Memo
この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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists.
ドメインネームシステム(DNS)は、IPv4アドレスにドメイン名を翻訳するのにA RRs(リソースRecords)を使用することで主として使用されます。 いくつかのアプローチがネットワークについて説明するために存在しているか、またはアドレスは及びます。 このドキュメントは新しいDNS RRタイプ「APL」をアドレス接頭語リストに指定します。
1. Conventions used in this document
1. 本書では使用されるコンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Domain names herein are for explanatory purposes only and should not be expected to lead to useful information in real life [RFC2606].
ドメイン名は、説明している目的だけのためにここにあって、現実[RFC2606]における役に立つ情報に通じないと予想されるべきです。
2. Background
2. バックグラウンド
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to associate addresses and other Internet infrastructure elements with hierarchically built domain names. Various types of resource records have been defined, especially those for IPv4 and IPv6 [RFC2874] addresses. In [RFC1101] a method is described to publish information about the address space allocated to an organisation. In older BIND versions, a weak form of controlling access to zone data was implemented using TXT RRs describing address ranges.
ドメインネームシステム[RFC1034]、[RFC1035]はアドレスを関連づけるためにメカニズムを提供します、そして、階層的がある他のインターネット基盤要素はドメイン名を築き上げました。 様々なタイプに関するリソース記録は定義されて、IPv4とIPv6[RFC2874]のための特にそれらはアドレスです。 [RFC1101]では、メソッドは、機構に割り当てられたアドレス空間の情報を発表するために説明されます。 より古いBINDバージョンでは、ゾーンデータへのアクセスを制御する弱形は、アドレスの範囲について説明するTXT RRsを使用することで実装されました。
This document specifies a new RR type for address prefix lists.
このドキュメントはアドレス接頭語リストのための新しいRRタイプを指定します。
Koch Experimental [Page 1] RFC 3123 DNS APL RR June 2001
[1ページ]RFC3123DNS APL RR2001年6月に実験的なコッホ
3. APL RR Type
3. APL RRタイプ
An APL record has the DNS type of "APL" and a numeric value of 42 [IANA]. The APL RR is defined in the IN class only. APL RRs cause no additional section processing.
APL記録には、「APL」のDNSタイプと42[IANA]の数値があります。 APL RRはINのクラスだけで定義されます。 APL RRsはどんな追加セクション処理も引き起こしません。
4. APL RDATA format
4. APL RDATA形式
The RDATA section consists of zero or more items (<apitem>) of the form
RDATA部は形式のゼロか、より多くの項目(<apitem>)から成ります。
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ADDRESSFAMILY |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PREFIX | N | AFDLENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AFDPART /
| |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ADDRESSFAMILY| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 接頭語| N| AFDLENGTH| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ / AFDPART /| | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
(see IANA Considerations)
PREFIX 8 bit unsigned binary coded prefix length.
Upper and lower bounds and interpretation of
this value are address family specific.
N negation flag, indicates the presence of the
"!" character in the textual format. It has
the value "1" if the "!" was given, "0" else.
AFDLENGTH length in octets of the following address
family dependent part (7 bit unsigned).
AFDPART address family dependent part. See below.
ADDRESSFAMILY16はIANA(IANA Considerationsを見る)PREFIX8の噛み付いている未署名の2進のコード化された接頭語の長さによって割り当てられるように未署名の値に噛み付きました。 この価値の上下の領域と解釈はアドレスファミリー特有です。 原文の形式の“!"キャラクタの存在は、N否定が弛むのを示します。 それには値がある、「“!"を与えたなら、1インチに、「ほかの0インチ。」 以下のアドレスファミリーに依存する部分(7ビット未署名の)の八重奏におけるAFDLENGTHの長さ。 AFDPARTは依存する部分をファミリーに扱います。 以下を見てください。
This document defines the AFDPARTs for address families 1 (IPv4) and 2 (IPv6). Future revisions may deal with additional address families.
このドキュメントはアドレスファミリー1(IPv4)と2(IPv6)のためにAFDPARTsを定義します。 今後の改正は追加アドレスファミリーと取り引きするかもしれません。
4.1. AFDPART for IPv4
4.1. IPv4のためのAFDPART
The encoding of an IPv4 address (address family 1) follows the encoding specified for the A RR by [RFC1035], section 3.4.1.
IPv4アドレス(アドレスファミリー1)のコード化はA RRに[RFC1035]、セクション3.4.1指定されたコード化に続きます。
PREFIX specifies the number of bits of the IPv4 address starting at the most significant bit. Legal values range from 0 to 32.
PREFIXは最も重要なビットで始まるIPv4アドレスのビットの数を指定します。 正当な値は0〜32まで及びます。
Trailing zero octets do not bear any information (e.g., there is no semantic difference between 10.0.0.0/16 and 10/16) in an address prefix, so the shortest possible AFDLENGTH can be used to encode it. However, for DNSSEC [RFC2535] a single wire encoding must be used by
10.0の間には、どんな意味違いもありません。八重奏がする末尾のゼロが少しの情報も持っていない、(.0 .0/16と10/16) アドレス接頭語では、それをコード化するのに可能な限り短いAFDLENGTHを使用できます。 しかしながら、DNSSEC[RFC2535]のために、a単一のワイヤコード化を使用しなければなりません。
Koch Experimental [Page 2] RFC 3123 DNS APL RR June 2001
[2ページ]RFC3123DNS APL RR2001年6月に実験的なコッホ
all. Therefore the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value of PREFIX. This includes cases in which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits to match a full octet boundary.
すべて。 したがって、送付者は、PREFIXの値にかかわらずAFDPARTで八重奏を全く引きずらないのを入れてはいけません。 これはPREFIXほどどのAFDLENGTH回8の結果で値でケースを含んでいないか。 AFDPARTはゼロ・ビットで水増しされて、完全な八重奏境界を合わせます。
An IPv4 AFDPART has a variable length of 0 to 4 octets.
IPv4 AFDPARTには、0〜4つの八重奏の可変長があります。
4.2. AFDPART for IPv6
4.2. IPv6のためのAFDPART
The 128 bit IPv6 address (address family 2) is encoded in network byte order (high-order byte first).
128ビットのIPv6アドレス(アドレスファミリー2)はネットワークバイトオーダーでコード化されます(バイトに1番目を高値で命令してください)。
PREFIX specifies the number of bits of the IPv6 address starting at the most significant bit. Legal values range from 0 to 128.
PREFIXは最も重要なビットで始まるIPv6アドレスのビットの数を指定します。 正当な値は0〜128まで及びます。
With the same reasoning as in 4.1 above, the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value of PREFIX. This includes cases in which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits to match a full octet boundary.
同じくらいが上の4.1のように推論していて、送付者は、PREFIXの値にかかわらずAFDPARTで八重奏を全く引きずらないのを入れてはいけません。 これはPREFIXほどどのAFDLENGTH回8の結果で値でケースを含んでいないか。 AFDPARTはゼロ・ビットで水増しされて、完全な八重奏境界を合わせます。
An IPv6 AFDPART has a variable length of 0 to 16 octets.
IPv6 AFDPARTには、0〜16の八重奏の可変長があります。
5. Zone File Syntax
5. ゾーンファイル構文
The textual representation of an APL RR in a DNS zone file is as follows:
DNSゾーンファイルにおける、APL RRの原文の表現は以下の通りです:
<owner> IN <TTL> APL {[!]afi:address/prefix}*
[!]afi: アドレス/が前に置く<TTL>APLにおける<の、より自身の>、*
The data consists of zero or more strings of the address family indicator <afi>, immediately followed by a colon ":", an address, immediately followed by the "/" character, immediately followed by a decimal numeric value for the prefix length. Any such string may be preceded by a "!" character. The strings are separated by whitespace. The <afi> is the decimal numeric value of that particular address family.
「データがゼロから成るか、またはアドレスファミリーインディケータ<の、より多くのストリングが>をafiして、すぐに、続いてコロンをafiします」:、」、すぐに従われたアドレス、」 キャラクタであって、a10進数値がすぐに接頭語の長さのためにあとに続く/。 どんなそのようなストリングも“!"キャラクタによって先行されるかもしれません。 ストリングは空白によって分離されます。 <afi>はその特定のアドレスファミリーの10進数値です。
5.1. Textual Representation of IPv4 Addresses
5.1. IPv4アドレスの原文の表現
An IPv4 address in the <address> part of an <apitem> is in dotted quad notation, just as in an A RR. The <prefix> has values from the interval 0..32 (decimal).
<apitem>の<アドレスの>一部のIPv4アドレスが点を打たされた回路記法であります、ちょうどA RRのように。 <接頭語>には、間隔0からの値があります。32 (10進。)
Koch Experimental [Page 3] RFC 3123 DNS APL RR June 2001
[3ページ]RFC3123DNS APL RR2001年6月に実験的なコッホ
5.2. Textual Representation of IPv6 Addresses
5.2. IPv6アドレスの原文の表現
The representation of an IPv6 address in the <address> part of an <apitem> follows [RFC2373], section 2.2. Legal values for <prefix> are from the interval 0..128 (decimal).
<apitem>の<アドレスの>一部のIPv6アドレスの表現は[RFC2373]、セクション2.2に従います。 <接頭語>のための正当な値は間隔0から来ています。128 (10進。)
6. APL RR usage
6. APL RR用法
An APL RR with empty RDATA is valid and implements an empty list. Multiple occurrences of the same <apitem> in a single APL RR are allowed and MUST NOT be merged by a DNS server or resolver. <apitems> MUST be kept in order and MUST NOT be rearranged or aggregated.
空のRDATAとAPL RRは有効であり、空のリストを実装します。 独身のAPL RRでの同じ<apitem>の複数の発生を、許容していて、DNSサーバかレゾルバが合併してはいけません。<apitems>を整然とするように保たなければならなくて、再配列してはいけないか、集めてはいけません。
A single APL RR may contain <apitems> belonging to different address families. The maximum number of <apitems> is upper bounded by the available RDATA space.
独身のAPL RRは異なったアドレスファミリーのものである<apitems>を含むかもしれません。 <apitems>の最大数は利用可能なRDATAスペースのそばで境界があった状態で上側です。
RRSets consisting of more than one APL RR are legal but the interpretation is left to the particular application.
1APL RRから成るRRSetsは法的ですが、解釈は特定用途に残されます。
7. Applicability Statement
7. 適用性証明
The APL RR defines a framework without specifying any particular meaning for the list of prefixes. It is expected that APL RRs will be used in different application scenarios which have to be documented separately. Those scenarios may be distinguished by characteristic prefixes placed in front of the DNS owner name.
どんな特定の意味も接頭語のリストに指定しないで、APL RRはフレームワークを定義します。 APL RRsが別々に記録されなければならない異なったアプリケーションシナリオで使用されると予想されます。 それらのシナリオはDNS所有者名の正面に置かれた独特の接頭語によって区別されるかもしれません。
An APL application specification MUST include information on
仕様が情報を含まなければならないAPLアプリケーション
o the characteristic prefix, if any
o もしあれば独特の接頭語
o how to interpret APL RRSets consisting of more than one RR
o 1RRから成るAPL RRSetsを解釈する方法
o how to interpret an empty APL RR
o 空のAPL RRを解釈する方法
o which address families are expected to appear in the APL RRs for
that application
o どのアドレスファミリーがAPL RRsにそのアプリケーションに関して現れると予想されますか。
o how to deal with APL RR list elements which belong to other
address families, including those not yet defined
o まだ定義されていなかったものを含んでいて、他のアドレスファミリーのものであるAPL RRリスト要素に対処する方法
o the exact semantics of list elements negated by the "!" character
o “!"キャラクタによって否定されたリスト要素の正確な意味論
Koch Experimental [Page 4] RFC 3123 DNS APL RR June 2001
[4ページ]RFC3123DNS APL RR2001年6月に実験的なコッホ
Possible applications include the publication of address ranges similar to [RFC1101], description of zones built following [RFC2317] and in-band access control to limit general access or zone transfer (AXFR) availability for zone data held in DNS servers.
可能なアプリケーションは[RFC1101]と同様のアドレスの範囲の公表を含んでいます、DNSサーバで保持されたゾーンデータのための一般的なアクセスかゾーン転送(AXFR)の有用性を制限するために[RFC2317]とバンドにおけるアクセスコントロールに続くのが建てられたゾーンの記述。
The specification of particular application scenarios is out of the scope of this document.
このドキュメントの範囲の外に特定用途シナリオの仕様があります。
8. Examples
8. 例
The following examples only illustrate some of the possible usages outlined in the previous section. None of those applications are hereby specified nor is it implied that any particular APL RR based application does exist now or will exist in the future.
以下の例は前項で概説された可能な用法のいくつかを例証するだけです。 それらのアプリケーションのいずれは、これにより指定されて、どんな特定のAPL RRベースの利用も現在、存在するか、または将来存在するのを含意したということではありません。
; RFC 1101-like announcement of address ranges for foo.example foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
; アドレスのRFCの1101のような発表はfoo.example foo.exampleのために及びます。 APL1: 192.168.32.0/21!1:192.168、.38、.0/28
; CIDR blocks covered by classless delegation
42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
1:192.168.42.128/25 )
; 階級のない委譲42.168.192.IN-ADDR.ARPAでカバーされたCIDRブロック。 APLで( 1:192.168.42.0/26 1:192.168.42.64/26 1:192.168.42.128/25 )
; Zone transfer restriction _axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
; ゾーン転送制限_axfr.sbo.example。 APL1: 127.0.0.1/32 1:172.16、.64、.0/22
; List of address ranges for multicast multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
; アドレスのリストはマルチキャストmulticast.exampleのために及びます。 APL、1:224.0、.0 .0 /4 2: FF00:、0:、0:0:0、:、0:0:0/8
Note that since trailing zeroes are ignored in the first APL RR the AFDLENGTH of both <apitems> is three.
末尾のゼロが両方の最初のAPL RR AFDLENGTHで無視されるので<apitems>が3であることに注意してください。
9. Security Considerations
9. セキュリティ問題
Any information obtained from the DNS should be regarded as unsafe unless techniques specified in [RFC2535] or [RFC2845] were used. The definition of a new RR type does not introduce security problems into the DNS, but usage of information made available by APL RRs may compromise security. This includes disclosure of network topology information and in particular the use of APL RRs to construct access control lists.
テクニックが[RFC2535]で指定しない場合、DNSから得られたどんな情報も危険であると見なされるだろうにか、または[RFC2845]は使用されました。 新しいRRタイプの定義はDNSに警備上の問題を紹介しませんが、APL RRsによって利用可能にされた情報の用法はセキュリティに感染するかもしれません。 これは、アクセスコントロールリストを構成するためにネットワーク形態情報の公開と特にAPL RRsの使用を含んでいます。
Koch Experimental [Page 5] RFC 3123 DNS APL RR June 2001
[5ページ]RFC3123DNS APL RR2001年6月に実験的なコッホ
10. IANA Considerations
10. IANA問題
This section is to be interpreted as following [RFC2434].
このセクションは次のである[RFC2434]解釈されることになっています。
This document does not define any new namespaces. It uses the 16 bit identifiers for address families maintained by IANA in http://www.iana.org/numbers.html.
このドキュメントはどんな新しい名前空間も定義しません。 それは http://www.iana.org/numbers.html でIANAによって養われたアドレスファミリーに16ビットの識別子を使用します。
The IANA assigned numeric RR type value 42 for APL [IANA].
数値RRが割り当てられたIANAはAPL[IANA]のために値42をタイプします。
11. Acknowledgements
11. 承認
The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review and constructive comments.
作者は彼らのレビューと建設的なコメントについてマーク・アンドリュース、Olafurグドムンソン、Ed Lewis、トーマスNarten、エリックNordmark、およびポールVixieに感謝したがっています。
12. References
12. 参照
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
Types", RFC 1101, April 1989.
[RFC1101] Mockapetris、P.、「ネットワーク名と他のタイプのDNSコード化」、RFC1101、1989年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2317] EidnesとH.とdeグルートとG.とP.Vixie、「階級のないIN ADDR.ARPA委譲」、BCP20、RFC2317、1998年3月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2373] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2535] イーストレーク、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
BCP 32, RFC 2606, June 1999.
[RFC2606] イーストレークとD.とA.パニツ、「予約された最高平らなDNS名」、BCP32、RFC2606、1999年6月。
Koch Experimental [Page 6] RFC 3123 DNS APL RR June 2001
[6ページ]RFC3123DNS APL RR2001年6月に実験的なコッホ
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[RFC2845] Vixie、P.、グドムンソン、O.、イーストレーク、D.、およびB.ウェリントン(「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
[RFC2874] クロフォード、M.、およびC.Huitema、「IPv6をサポートするDNS拡張子は集合と番号を付け替えることを扱う」、RFC2874、7月2000日
[IANA] http://www.iana.org/assignments/dns-parameters
[IANA] http://www.iana.org/assignments/dns-parameters
13. Author's Address
13. 作者のアドレス
Peter Koch Universitaet Bielefeld Technische Fakultaet D-33594 Bielefeld Germany
ピーター・コッホ・UniversitaetビーレフェルトTechnische Fakultaet D-33594ビーレフェルトドイツ
Phone: +49 521 106 2902 EMail: pk@TechFak.Uni-Bielefeld.DE
以下に電話をしてください。 +49 2902年の521 106メール: pk@TechFak.Uni-Bielefeld.DE
Koch Experimental [Page 7] RFC 3123 DNS APL RR June 2001
[7ページ]RFC3123DNS APL RR2001年6月に実験的なコッホ
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Koch Experimental [Page 8]
コッホExperimentalです。[8ページ]
一覧
スポンサーリンク
