[要約] RFC 3254は、ディレクトリに関する用語の定義を提供するためのものであり、ディレクトリに関するコミュニケーションを容易にすることを目的としています。
Network Working Group H. Alvestrand
Request for Comments: 3254 Cisco Systems
Category: Informational April 2002
Definitions for talking about directories
ディレクトリについて話すための定義
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use.
標準化された方法でインターネットを介して情報にアクセスできるようにするためのシステムについて議論するとき、それを議論している人々が彼らが使用する用語について共通の理解を持っていると役立つ場合があります。
For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability.
たとえば、このドキュメントへの参照は、DNS（ドメインネームシステム）が、境界整合性と緩やかで収束する一貫性を備えたグローバルルックアップリポジトリであることを認める力を与えます。一方、LDAP（Lightweight Directory Access Protocol）ディレクトリサーバーは、ローカルの集中リポジトリであり、検索機能と検索機能の両方を備えています。
This document discusses one group of such systems which is known under the term, "directories".
このドキュメントでは、「ディレクトリ」という用語で知られているそのようなシステムの1つのグループについて説明します。
We suggest using the following terms for the remainder of this document:
このドキュメントの残りの部分では、次の用語を使用することをお勧めします。
- Information: Facts and ideas which can be represented (encoded) as data in various forms.
- 情報：さまざまな形式のデータとして表現（エンコード）できる事実とアイデア。
- Data: Information in a specific physical representation, usually a sequence of symbols that have meaning; especially a representation of information that can be processed or produced by a computer. (From [SEC].)
- データ：特定の物理的表現での情報。通常は意味を持つ一連のシンボル。特に、コンピュータで処理または生成できる情報の表現。 （[SEC]から。）
- Repository: An amount of data that is accessible through one or more access methods.
- リポジトリ：1つ以上のアクセス方法でアクセスできるデータの量。
- Requester: Entity that may (try to) access data in a repository. Note that no assumption is made that the requester is animal, vegetable, or mineral.
- リクエスタ：リポジトリ内のデータにアクセスする（試行する）エンティティ。要求者が動物、野菜、またはミネラルであるとは想定されていないことに注意してください。
- Maintainer: Entity that causes changes to the data in the repository. Usually, all maintainers are requesters, since they need to look at the data too, however, the roles are distinct.
- メンテナ：リポジトリ内のデータを変更するエンティティ。通常、すべてのメンテナーはリクエスターです。データも調べる必要があるためですが、役割は異なります。
- Access method: Well-defined series of operations that will cause data available from a repository to be obtained by the requester.
- アクセス方法：リポジトリから利用可能なデータを要求者が取得できるようにする明確に定義された一連の操作。
- Site: Entity that hosts all or part of a repository, and makes it available through one or more access methods. A site may in various contexts be a machine, a datacenter, a network of datacenters, or a single device.
- サイト：リポジトリのすべてまたは一部をホストし、1つ以上のアクセス方法でそれを使用可能にするエンティティー。サイトは、さまざまなコンテキストで、マシン、データセンター、データセンターのネットワーク、または単一のデバイスです。
This document is not intended to be either comprehensive or definitive, but is intended to give some aid in mutual comprehension when discussing information access methods to be incorporated into Internet Standards-Track documents.
このドキュメントは、包括的または決定的なものではなく、インターネット標準トラックドキュメントに組み込まれる情報アクセス方法について議論する際に相互理解を助けるためのものです。
Some information systems are global, in the sense that only one can sensibly exist in the world.
一部の情報システムは、1つだけが世界に賢く存在できるという意味で、グローバルです。
Others are inherently local, in that each locality, site or even box will run its own information store, independent of all others.
他のものは本質的にローカルであり、各地域、サイト、またはボックスでさえ、他のすべてから独立して独自の情報ストアを実行します。
The following terms are suggested:
以下の用語が推奨されます。
- Global repository: A repository that there can be only one of in the world. The world itself is a prime example; the public telephone system's number assignments according to E.164 is another.
- グローバルリポジトリ：世界に1つだけ存在できるリポジトリ。世界自体が最も良い例です。 E.164に基づく公衆電話システムの番号割り当ては別のものです。
- Local repository: A class of repository of which multiple instances can exist, each with information relevant to that particular repository, with no need for coordination between them.
- ローカルリポジトリ：複数のインスタンスが存在できるリポジトリのクラス。それぞれに特定のリポジトリに関連する情報があり、それらの間の調整は必要ありません。
- Centralized repository: A repository where all access to data has to pass through some single site.
- 集中リポジトリ：データへのすべてのアクセスが単一のサイトを通過する必要があるリポジトリ。
- Distributed repository: A repository that is not centralized; that is, access to data can occur through multiple sites.
- 分散リポジトリ：集中管理されていないリポジトリ。つまり、データへのアクセスは複数のサイトを通じて発生する可能性があります。
- Replicated repository: A distributed repository where all sites have the same information.
- 複製されたリポジトリ：すべてのサイトが同じ情報を持つ分散リポジトリ。
- Cooperative repository: A distributed repository where not all sites have all the information, but where mechanisms exist to get the info to the requester, even when it is not available to the site originally asked.
- 協調リポジトリ：すべてのサイトにすべての情報があるわけではありませんが、最初に要求されたサイトで利用できない場合でも、情報を要求者に取得するメカニズムが存在する分散リポジトリ。
Note: The term "global" is often a matter of social or legal context; for instance, the E.164 telephone numbering system is global by international treaty, while the debate about whether the Domain Name System is global in fact or just a local repository with ambitions has proved bait for too many discussions to enumerate.
注：「グローバル」という用語は、多くの場合、社会的または法的状況の問題です。たとえば、E.164電話番号付けシステムは国際条約によってグローバルですが、ドメインネームシステムが実際にグローバルであるか、野心のあるローカルリポジトリだけであるかについての議論は、あまりにも多くの議論を列挙するための餌となりました。
Some claim that globality is in the eye of the beholder; "everything is local to some context". When discussing technology, it may be wise to use "very widely deployed" instead.
グローバル化は見る人の目にあると主張する人もいます。 「すべてが特定のコンテキストに対してローカルです」。テクノロジーについて議論するときは、代わりに「非常に広く展開されている」を使用するのが賢明かもしれません。
Note: Locating the repositories changes with the scale of consideration. For instance, the global DNS system is considered a distributed cooperative repository, built out of zone repositories that themselves may be distributed, and are always replicated when distributed.
注：リポジトリーの配置は、考慮の規模によって異なります。たとえば、グローバルDNSシステムは分散協調リポジトリと見なされ、それ自体が分散されるゾーンリポジトリから構築され、分散時に常に複製されます。
A different consideration when describing repositories is the types of method they offer to find information.
リポジトリを説明する際の別の考慮事項は、リポジトリが情報を見つけるために提供する方法のタイプです。
The chief classifications are:
主な分類は次のとおりです。
- Lookup methods require the user to know or guess some exact value before asking for information, sometimes called a "lookup key" or "identifier" and sometimes called a "name". The word "name" is NOT recommended, since it conflicts with other uses of that word The response to a successful lookup is a single group of information, often called "information about the identified entity". A lookup method is binary (yes/no) in recall: It either returns one result or no result; if it returns a result, that result is the right result for that lookup key, so it is also of binary precision (no info or completely relevant info).
- ルックアップメソッドでは、情報を要求する前にユーザーが正確な値を知っているか推測する必要があります。これは、「ルックアップキー」または「識別子」と呼ばれ、「名前」と呼ばれることもあります。 「名前」という単語は、その単語の他の使用法と競合するため、お勧めできません。検索が成功すると、「識別されたエンティティに関する情報」と呼ばれる単一の情報グループが返されます。ルックアップメソッドはリコールでバイナリ（yes / no）です。1つの結果を返すか、結果を返さないかのどちらかです。結果を返す場合、その結果はそのルックアップキーの正しい結果であるため、バイナリ精度でもあります（情報がないか、完全に関連する情報）。
- Search methods require the user to know some approximate value of some information. They usually return zero, one, or more responses that match the information supplied according to some algorithm. Where the repository is structured around "entities", the information can be about zero, one, or many entities.
- 検索方法では、ユーザーがいくつかの情報のおおよその値を知っている必要があります。それらは通常、いくつかのアルゴリズムに従って提供された情報と一致する0、1、またはそれ以上の応答を返します。リポジトリが「エンティティ」を中心に構成されている場合、情報は約0、1、または多くのエンティティになる可能性があります。
In database terms, a lookup method corresponds to a query exactly matching a unique key on a table; all other database queries would be classified as "search" methods.
データベースの用語では、ルックアップメソッドは、テーブルの一意のキーと完全に一致するクエリに対応します。他のすべてのデータベースクエリは、「検索」メソッドとして分類されます。
In general, repositories that offer more flexible search methods may also give room for ad-hoc queries, refinements from a previous query, approximate matching and other aids; this may lead to many different combinations of precision and recall.
一般に、より柔軟な検索方法を提供するリポジトリは、アドホッククエリ、以前のクエリからの絞り込み、おおよそのマッチング、およびその他の補助機能の余地を与えることもあります。これにより、精度と再現率のさまざまな組み合わせが可能になります。
One may define terms to enumerate what one gets out of these repositories:
これらのリポジトリから得られるものを列挙する用語を定義できます。
. Precision is the degree to which what you asked for is what you wanted (no extraneous information)
。精度とは、あなたが求めているものがあなたが望んでいるものの程度です（無関係な情報はありません）
. Recall is the ability to assure oneself that all relevant data from the repository is returned
。リコールは、リポジトリからすべての関連データが返されることを自分で保証する機能です
. Type I errors occurs when relevant data exists in the repository, but is not returned
。タイプIエラーは、関連データがリポジトリに存在するが、返されない場合に発生します
. Type II errors occur when irrelevant data is returned with a query result
。タイプIIエラーは、無関係なデータがクエリ結果とともに返されるときに発生します
Note that these concepts can only be applied when the property "relevance" is well defined; that is, it depends on what the repository is used for. A further discussion of these topics is found in [KORFHAGE].
これらの概念は、プロパティ「関連性」が明確に定義されている場合にのみ適用できることに注意してください。つまり、リポジトリの用途によって異なります。これらのトピックの詳細については、[KORFHAGE]をご覧ください。
An orthogonal dimension has to do with time:
直交次元は時間と関係があります：
- Query repositories will answer a request with a response, and once that is over with, will do nothing more.
- クエリリポジトリは、応答で要求に応答し、それが終了すると、それ以上何もしません。
- Notify repositories will get a request from a user to have information returned at some later time when it becomes available, current or whatever, and will respond at that time with a notification that information is available.
- Notifyリポジトリーは、ユーザーから最新の情報が利用可能になったときに情報が返されるように要求を受け取り、そのときに情報が利用可能であるという通知で応答します。
- Subscription repositories are like notify repositories, but will transfer the actual information when available.
- サブスクリプションリポジトリは通知リポジトリに似ていますが、利用可能な場合は実際の情報を転送します。
Consistency (or the lack thereof) is a property of distributed repositories; for this particular discussion, we ignore the subject of semantically inconsistent data (such as occurrences of pregnant men), and focus on the problem of consistency where inconsistency is defined as having the same request, using the same credentials, be answered with different data at different sites.
整合性（またはその欠如）は、分散リポジトリの特性です。この特定の議論では、意味的に一貫性のないデータ（妊娠中の男性の発生など）の主題を無視し、一貫性の問題に焦点を当てます。この一貫性の問題は、同じ要求を持ち、同じ資格情報を使用し、異なるデータで回答されると定義されています。別のサイト。
Distributed repositories may have:
分散リポジトリには次のものがあります。
- Strict consistency, where the problem above never arises. This is quite difficult; repositories that exhibit this property are usually quite constrained and/or quite expensive.
- 上記の問題が発生しない厳密な一貫性。これは非常に困難です。この特性を示すリポジトリは通常、非常に制約されているか、非常に高価です。
- Strict internal consistency, where the replies always reflect a consistent picture of the total repository, but some sites may reflect an earlier version of the repository than others.
- 厳密な内部整合性。ここでは、応答は常にリポジトリ全体の一貫した全体像を反映していますが、サイトによっては、他のバージョンよりも古いバージョンのリポジトリを反映している場合があります。
- Loose, converging consistency, where different parts of the repository may be updated at different times as seen from a single site, but the process is designed in such a way that if one stops making changes to the repository, all sites will sooner or later present the same information.
- 緩やかな収束の一貫性。単一のサイトから見た場合、リポジトリのさまざまな部分が異なるタイミングで更新される可能性がありますが、プロセスは、リポジトリへの変更を停止するとすべてのサイトが遅かれ早かれ存在するように設計されています同じ情報。
- Inconsistency, where no guarantee can be made whatsoever
- 不整合、いかなる保証もできない
One interesting variant is subset consistency, where the system is consistent (according to one of the definitions above), but not all questions will be answered at all sites; possibly because different sites have different policies on what they make available (NetNews), or because different sites only need different subsets of the "whole picture" (BGP).
興味深い変法の1つは、システムが一貫している（上記の定義の1つに従って）サブセットの一貫性ですが、すべてのサイトですべての質問に答えられるわけではありません。おそらく、サイトごとに利用できるポリシー（NetNews）が異なるか、サイトごとに「全体像」（BGP）のサブセットのみが必要なためです。
Its harder to describe security models in a few sentences than other properties of information systems. There also exists a large specialized literature on terminology for security, including [SEC].
セキュリティモデルを数文で説明することは、情報システムの他の特性よりも困難です。 [SEC]を含む、セキュリティの用語に関する大規模な専門文献も存在します。
Some thoughts, though:
しかし、いくつかの考え：
On trust in data: Why do we trust a piece of data to be correct?
データの信頼について：データの一部が正しいと信頼するのはなぜですか？
- Because it's in the repository (and therefore must have been authorized).
- リポジトリにあるため（したがって、承認されている必要があります）。
This is perimeter (or Eggshell) integrity.
これは、境界（またはEggshell）の整合性です。
- Because it contains internal integrity checks, usually involving digital signatures by verifiable identities. This is item integrity; the granularity of the integrity and the ability to do integrity checks on the relationships between objects is extremely important and extremely hard to get right, as is establishing the roots of the trust chains.
-内部の整合性チェックが含まれているため、通常は検証可能なIDによるデジタル署名が含まれます。これはアイテムの整合性です。整合性の細分性と、オブジェクト間の関係について整合性チェックを実行する機能は、信頼チェーンのルートを確立する場合と同様に、非常に重要であり、正しく理解することが非常に困難です。
- Because it fits other available information, and causes the right things to happen when I use it.
- それは他の利用可能な情報に適合し、私がそれを使用するときに正しいことが起こるようにするからです。
This is hopeful integrity.
これは希望に満ちた誠実さです。
Which integrity model to choose is a matter of evaluating the cost of implementing the integrity (cost), the value to you of integrity of the resource being protected (value), and the impact of cost on doing business (risk).
どの整合性モデルを選択するかは、整合性の実装コスト（コスト）、保護されているリソースの整合性の価値（価値）、ビジネスの実行に対するコストの影響（リスク）を評価することです。
On access to information, the usual categories apply:
情報へのアクセスには、通常のカテゴリが適用されます。
- Open access: Anyone can get the information.
- オープンアクセス：誰でも情報を入手できます。
- Property-based access: Access because of what you are, or where you are. For example limited to "same network", "physically present", or "resolvable DNS name"
- プロパティベースのアクセス：自分が何者であるか、どこにいるかによるアクセス。たとえば、「同じネットワーク」、「物理的に存在」、または「解決可能なDNS名」に限定されます
- Identity-based access: Access because of who you are (or successfully claim to be). (I.e., username/password, personal certificates or other verifiable information.)
- IDベースのアクセス：あなたが誰であるか（または成功したと主張するため）のアクセス。 （つまり、ユーザー名/パスワード、個人証明書、またはその他の検証可能な情報）。
These are then backed up by a layer specifying what the identity you have proven yourself to be has access to.
これらは、あなたが自分であると証明したアイデンティティーがアクセスできるものを指定するレイヤーによってバックアップされます。
- Token-based access: Access because of what you have. Hardware tokens, smartcards, certificates, or capability keys.
- トークンベースのアクセス：自分が持っているものによるアクセス。ハードウェアトークン、スマートカード、証明書、または機能キー。
In this case, access is given to all who can present that credential, without caring about their identity.
この場合、身元を気にすることなく、その資格を提示できるすべての人にアクセス権が与えられます。
The most common approaches are identity-based and open access; however, "what you have" access is commonly used informally in, for example, password-protected FTP or Web sites where the password is shared between all members of a group.
最も一般的なアプローチは、IDベースのオープンアクセスです。ただし、「何を持っている」アクセスは、たとえば、パスワードで保護されたFTPサイトやグループのすべてのメンバー間でパスワードが共有されるWebサイトなどで非公式に使用されます。
A few examples:
いくつかの例：
- Read-only repositories have no standard means of changing the information in them. This is usually accomplished through some other interface than the standard interface.
- 読み取り専用リポジトリには、それらの情報を変更する標準的な手段はありません。これは通常、標準インターフェース以外のインターフェースを介して行われます。
- Read-mostly repositories are designed based on a theory that reads will greatly outnumber updates; this may, for instance, be reflected in relatively slow consistency-updating protocols.
- Read-mostlyリポジトリは、読み取りが更新を大幅に上回るという理論に基づいて設計されています。これは、たとえば、比較的遅い整合性更新プロトコルに反映される場合があります。
- Read-write repositories assume that the updates and the read operations are of the same order of magnitude.
- 読み書きリポジトリは、更新と読み取り操作が同じ桁数であると想定しています。
- Write-mostly repositories are designed to store an incoming stream of data, and when needed reproduce a relevant piece of data from the stream. Typical examples are insurance company databases and audit logs.
- ほとんどが書き込みリポジトリは、着信データストリームを格納し、必要に応じて、ストリームから関連するデータを複製するように設計されています。典型的な例は、保険会社のデータベースと監査ログです。
The definitions above never used the term "Directory".
上記の定義では、「ディレクトリ」という用語は使用されていません。
In most common usages, the properties that a repository must have in order to be worthy of being called a directory are:
最も一般的な使用法では、ディレクトリと呼ばれるに値するためにリポジトリに必要なプロパティは次のとおりです。
- Search
- 探す
- Convergent consistency
- 収束一貫性
All the other terms above may vary across the set of things that are called "directories".
上記の他のすべての用語は、「ディレクトリ」と呼ばれるもののセットによって異なる場合があります。
The DNS [DNS] is a global cooperative lookup repository with loose, converging consistency and query capability only.
DNS [DNS]は、緩やかな収束の一貫性とクエリ機能のみを備えたグローバルな協調ルックアップリポジトリです。
It is either strictly read-only or read-mostly (with Dynamic DNS), has an open access model, and mainly perimeter integrity (some would say hopeful integrity). DNSSEC [DNSSEC] aims to give it item integrity.
厳密に読み取り専用または読み取り専用（動的DNSを使用）のいずれかであり、オープンアクセスモデルがあり、主に境界整合性があります（期待される整合性と言う人もいます）。 DNSSEC [DNSSEC]は、アイテムに整合性を与えることを目的としています。
The DNS is built out of zone repositories that themselves may be distributed, and are always replicated when distributed.
DNSは、それ自体が配布される可能性があるゾーンリポジトリから構築され、配布時に常に複製されます。
Note that like many other systems, the DNS has some features that do not fit neatly in the classification; for instance, there is a (deprecated and not widely used) function called IQUERY, which allows a very limited query capability.
他の多くのシステムと同様に、DNSには分類に完全に適合しないいくつかの機能があることに注意してください。たとえば、非常に限定されたクエリ機能を許可するIQUERYと呼ばれる（非推奨で広くは使用されていない）関数があります。
If one opens up the box and looks at the relationship between primary and secondary nameservers, that can be seen as a limited form of notify capability, but this is not available to end-users of the total system.
箱を開けてプライマリネームサーバーとセカンダリネームサーバーの関係を見ると、それは通知機能の制限された形式と見なすことができますが、これはシステム全体のエンドユーザーには利用できません。
X.500 [X500] was intended to be a global search repository with loose, converging consistency.
X.500 [X500]は、緩やかに収束する一貫性を備えたグローバル検索リポジトリになることを目的としていました。
It was intended to be read-mostly, perimeter secure and query-capable.
これは、主に読み取り、境界で安全、クエリ対応であることを目的としています。
The Global or top-level BGP routing information database [BGP1] is often viewed as a global read-write repository with loose, converging subset consistency (not all routes are carried everywhere) and very limited integrity control, mostly intended to be perimeter integrity based on, "access control based on what you are".
グローバルまたはトップレベルのBGPルーティング情報データベース[BGP1]は、緩やかに収束するサブセットの一貫性（すべてのルートがどこでも実行されるわけではありません）と非常に限定された整合性制御を備えたグローバルな読み取り/書き込みリポジトリと見なされることが多く、境界の整合性に基づいていますオン、「自分に基づいたアクセス制御」。
One can argue that BGP [BGP2] is better viewed as a global mechanism for updating a set of local read/write repositories, since far from all routing information is carried everywhere, and the decision on what routes to accept is always considered a local policy matter. But from a security model perspective, a lot of the controls are applied at the periphery of the routing system, not at each local repository; this still makes it interesting to consider properties that apply to the BGP system as a whole.
BGP [BGP2]は、すべてのルーティング情報がどこにでも運ばれ、受け入れるルートの決定は常にローカルポリシーと見なされるため、ローカルの読み取り/書き込みリポジトリのセットを更新するためのグローバルメカニズムとして見た方がよいと主張できます。案件。しかし、セキュリティモデルの観点からすると、多くの制御はルーティングシステムの周辺に適用され、各ローカルリポジトリには適用されません。このため、BGPシステム全体に適用されるプロパティを検討することは興味深いことです。
NetNews [NEWS] is a global read-write repository with loose (non-converging) subset consistency (not all sites carry all articles, and article retention times differ). Between sites it offers subscription capability; to users it offers both search and lookup functionality.
NetNews [ニュース]は、緩やかな（収束しない）サブセット整合性を備えたグローバルな読み書きリポジトリです（すべてのサイトがすべての記事を運ぶわけではなく、記事の保持期間は異なります）。サイト間でサブスクリプション機能を提供します。ユーザーに検索とルックアップの両方の機能を提供します。
An SNMP [SNMP] agent can be thought of as a local, centralized repository offering lookup functionality.
SNMP [SNMP]エージェントは、ルックアップ機能を提供するローカルの集中リポジトリと考えることができます。
With SNMPv3, it offers all kinds of access models, but mostly, "access because of what you have", seems popular.
SNMPv3を使用すると、あらゆる種類のアクセスモデルが提供されますが、ほとんどの場合、「自分が持っているものによるアクセス」が人気があるようです。
Security is a very relevant question when considering information access systems.
情報アクセスシステムを検討する場合、セキュリティは非常に重要な問題です。
Some issues to consider are:
考慮すべき問題は次のとおりです。
- Controlled access to information
- 情報へのアクセスの制御
- Controlled rights to update information
- 情報を更新するための制御された権利
- Protection of the information path from provider to consumer
- プロバイダーからコンシューマーへの情報パスの保護
- With personal information, privacy issues
- 個人情報、プライバシー問題
- Interactions between multiple ways to access the same information
- 同じ情報にアクセスするための複数の方法間の相互作用
It is probably a Good Thing to consider carefully the security models from section 2.4 when designing repositories or repository access protocols.
リポジトリまたはリポジトリアクセスプロトコルを設計するときは、セクション2.4のセキュリティモデルを慎重に検討することをお勧めします。
The author wishes to thank all who contributed to this document, including Patrik Faltstrom, Eric A. Hall, James Benedict, Ted Hardie, Urs Eppenberger, John Klensin, and many others.
著者は、Patrik Faltstrom、Eric A. Hall、James Benedict、Ted Hardie、Urs Eppenberger、John Klensinなど、このドキュメントに貢献したすべての人に感謝します。
[SEC] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[SEC] Shirey、R。、「インターネットセキュリティ用語集」、FYI 36、RFC 2828、2000年5月。
[DNS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC] Eastlake、D。、「Domain Name System Security Extensions」、RFC 2535、1999年3月。
[E164] ITU-T Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997.
[E164] ITU-T勧告E.164 / I.331（05/97）：国際公衆電気通信番号計画。 1997年
[BGP1] "Analyzing the Internet's BGP Routing Table", published in
"The Internet Protocol Journal", Volume 4, No 1, April
2001. At the time of writing, available at
http://www.telstra.net/gih/papers/ipj/4-1-bgp.pdf
[BGP2] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP2] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[NEWS] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[ニュース] Kantor、B。およびP. Lapsley、「Network News Transfer Protocol」、RFC 977、1986年2月。
[SNMP] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[SNMP] Case、J.、Mundy、R.、Partain、D. and B. Stewart、 "Introduction to Version 3 of the Internet-standard Network Management Framework"、RFC 2570、April 1999。
[X500] Weider, C. and J. Reynolds, "Executive Introduction to Directory Services Using the X.500 Protocol", FYI 13, RFC 1308, March 1992.
[X500] Weider、C。およびJ. Reynolds、「X.500プロトコルを使用したディレクトリサービスのエグゼクティブイントロダクション」、FYI 13、RFC 1308、1992年3月。
[KORFHAGE] "Information Storage and Retrieval", Robert R. Korfhage, Wiley 1997. See page 194 for "precision" and "recall" definitions.
[KORFHAGE]「情報の保存と検索」、Robert R. Korfhage、Wiley1997。「精度」と「再現」の定義については、194ページを参照してください。
Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 N-7043 Trondheim NORWAY
Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 N-7043 Trondheim NORWAY
Phone: +47 41 44 29 94
EMail: Harald@alvestrand.no
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、この文書自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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機能への資金提供は、現在Internet Societyから提供されています。