RFC1291 日本語訳
1291 Mid-Level Networks Potential Technical Services. V. Aggarwal. December 1991. (Format: TXT=24314, PS=218918 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Aggarwal
Request for Comments: 1291 JvNCnet Computer Network
December 1991
Aggarwalがコメントのために要求するワーキンググループV.をネットワークでつないでください: 1291 JvNCnetコンピュータネットワーク1991年12月
Mid-Level Networks
Potential Technical Services
中間レベルのネットワークの可能性技術的なサービス
Status of this Memo
このMemoの状態
This RFC provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. The term "mid-level" is used as a generic term to represent all regional and similar networks, which, due to continuous evolutions and transitions, can no longer be termed "regional" [MAN]. It discusses the pros and cons of offering these services, as well as areas in which mid-level networks can work together.
このドキュメントはそれぞれのインターネットの中間レベルのネットワークが中間レベルのネットワーク自体以内とそして、その同輩ネットワークに提供できる1セットの技術サービスを提案します。 すべての地方の、そして、同様のネットワークを代表するのに総称として「中間レベルである」という用語を使用します。(連続したevolutionsと変遷のためもう「地方」の[MAN]とネットワークを呼ぶことができません)。 それはこれらのサービスを提供する賛否両論について議論します、中間レベルのネットワークが一緒に働くことができる領域と同様に。
A large portion of the ideas stem from discussions at the IETF Operational Statistics (OPstat), User Connectivity Problems (UCP) and Network Joint Management (NJM) working groups.
IETF Operational Statistics(OPstat)(User Connectivity Problems(UCP)とNetwork Joint Management(NJM)ワーキンググループ)での議論からの考え軸の大半。
Table of Contents
目次
1. Introduction.................................................. 2 2. The Generic Model............................................. 2 3. Technical Services............................................ 3 3.1 Domain Name Service......................................... 3 3.2 Public Domain Software...................................... 4 3.3 Network Time................................................ 5 3.4 Network News................................................ 5 3.5 Mailing Lists............................................... 6 4. Experimental Testbeds......................................... 6 5. Network Information Services.................................. 7 6. Network Operations............................................ 7 7. References.................................................... 8 8. Security Considerations....................................... 9 9. Author's Address.............................................. 9 Appendix A Mailing Lists......................................... 10 Appendix B DNS Architecture Strategy............................. 10
1. 序論… 2 2. ジェネリックモデル… 2 3. 技術的なサービス… 3 3.1 ドメイン名サービス… 3 3.2パブリックドメインソフト… 4 3.3 時間をネットワークでつないでください… 5 3.4のネットニュース… 5 3.5のメーリングリスト… 6 4. 実験的なテストベッド… 6 5. 情報サービスをネットワークでつないでください… 7 6. 操作をネットワークでつないでください… 7 7. 参照… 8 8. セキュリティ問題… 9 9. 作者のアドレス… 9 付録Aメーリングリスト… 10 付録B DNSアーキテクチャ戦略… 10
Aggarwal [Page 1] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[1ページ]RFC1291の可能性
1. Introduction
1. 序論
Over the past few years, the Internet has grown to be a very large entity and its dependability is critical to its users. Furthermore, due to the size and nature of the network, the trend has been to decentralize as many network functions (such as domain name-service, whois, etc.) as possible. Efforts are being made in resource discovery [SHHH90] so that the work of researchers is not lost in the volumes of data that is available on the Internet.
過去数年間にわたって、インターネットは発展して、非常に大きい存在であった、ユーザにとって、信頼性は重要です。 その上、ネットワークのサイズと本質のため、傾向はできるだけ多くのネットワーク機能(ドメイン名サービス、whoisなどの)を分散することです。 取り組みは、研究者の仕事が利用可能なデータのボリュームで失われていないように、インターネットでリソース発見[SHHH90]で作っていることにされます。
A side result of this growth has been the logical structure imposed in the Internet of networks classified by function. Tangible examples in the present state are the NSFnet national backbone, the mid- level/regional networks and campus networks. Each of these can be viewed as hierarchies within an organization, each serving a slightly different function than the other (campus LANs providing access to local resources, mid-level networks providing access to remote resources, etc.). The functions of each hierarchy then become the "services" offered to the organizational layer below it, who in turn depend on these services.
この成長のサイド結果は機能によって分類されたネットワークのインターネットで課された論理構造です。 現状の具体例は、NSFnetの国家のバックボーンと、中間のレベル/地域ネットワークとキャンパスネットワークです。 階層構造として組織の中でそれぞれのこれらを見なすことができます、それぞれわずかに異なった機能を果たしてもう片方(ローカル資源へのアクセスを提供するキャンパスLAN、遠隔資源へのアクセスを提供する中間レベルのネットワークなど)より。 そして、それぞれの階層構造の関数はそれの下の順番にこれらのサービスによる組織的な層に提供された「サービス」になります。
This document proposes a set of basic technical services that could be offered by a mid-level network. These services would not only increase the robustness of the mid-level network itself, but would also serve to structure the distribution of resources and services within the Internet. It also proposes a uniform naming convention for locating the hosts offering these services.
このドキュメントは中間レベルのネットワークが提供できた1セットの基本的な技術サービスを提案します。 これらのサービスは、中間レベルのネットワーク自体の丈夫さを増強するだけではないでしょうが、また、インターネットの中でリソースの、そして、サービスの分配を構造化するのに役立つでしょう。 また、それはコンベンションをこれらのサービスを提供するホストの居場所を見つけるのにちなんで命名するユニフォームを提案します。
2. The Generic Model
2. ジェネリックモデル
The Internet model that is used as the basis for this document is a graph of mid-level networks connected to one another, each in turn connecting the campus/organization networks and with the end users attached to the campus networks. The model assumes that the mid-level networks constitute the highest level of functional division within the Internet hierarchy described above (this could change in the unforeseen future). With this model in perspective, this document addresses the objectives of minimizing unnecessary traffic within the Internet as well as making the entire structure as robust as possible.
このドキュメントの基礎が中間レベルのネットワークのグラフであるので使用されたインターネットモデルはお互い(キャンパスネットワークに順番にキャンパス/組織ネットワークを接続して、エンドユーザと共に付けられたそれぞれ)に接しました。 モデルは、中間レベルのネットワークが上で説明されたインターネット階層構造の中で機能的分割の最高水準を構成すると仮定します(これは予期しない未来に変化できました)。 バランスよく、このモデルと共に、このドキュメントはインターネットの中で不要なトラフィックを最小にして、全体の構造をできるだけ強健にする目的を扱います。
The proposed structure is a derived extension of organizational LANs where certain services are offered within the organizational LAN itself, such as nameservice, mail, shared files, single or hierarchical points of contact for problems, etc.
提案された構造はサービスが組織的なLAN自体の中で提供されるのを確信しているところでの組織的なLANの派生している拡大です、nameservice、メール、共有ファイル、問題のための単一の、または、階層的な連絡先などのように
The following are the services that are discussed as possible functions of a mid-level network:
↓これは中間レベルのネットワークの可能な機能として議論されているサービスです:
Aggarwal [Page 2] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[2ページ]RFC1291の可能性
o Technical services
o 技術サービス
o Experimental sites for testing and dissemination of new
software and technology to end sites on the network
o 新しいソフトウェアのテストと普及のための実験サイトとネットワークに関するサイトを終わらせる技術
In addition, the following services are mentioned briefly which are discussed in detail elsewhere [SSM91, ML91]:
さらに、ほかの場所[SSM91、ML91]で詳細に議論する以下のサービスは簡潔に言及されます:
o Network Operation services and the interaction between
different mid-level networks in this area
o この領域の異なった中間レベルのネットワークの間のネットワークOperationサービスと相互作用
o Network Information services
o ネットワーク情報サービス
3. Technical Services
3. 技術サービス
The Internet has grown to be an essential entity because of the services that it offers to its end users. The list of services is long and growing, but some services are more widely used and deployed than others. This section attempts to list and discuss those technical services that could help a mid-level network provide robust and improved services to its end sites.
インターネットは発展して、それがエンドユーザに提供するサービスによる不可欠の存在でした。 サービスのリストが長くて、増加していますが、いくつかのサービスが、他のものよりさらに広く利用されて、配布されます。 このセクションは、中間レベルのネットワークが強健な状態で提供されるのを助けることができて、端のサイトに対するサービスを改良したそれらの技術サービスについて記載して、議論するのを試みます。
3.1 Domain Name Service
3.1 ドメイン名サービス
According to the NSFnet traffic statistics collected for May 1991, about 7% of the packets on the NSFnet backbone were domain nameserver (DNS) packets. This is a significant amount of traffic, and since most of the other network applications depend on this service, a robust DNS service is critical to any Internet site.
1991年5月に寄付を募られたNSFnetトラフィック統計によると、NSFnetバックボーンのパケットのおよそ7%はドメインネームサーバ(DNS)パケットでした。 これはかなりの量のトラフィックです、そして、他のネットワーク応用の大部分がこのサービスによるので、体力を要しているDNSサービスはどんなインターネット・サイトにも重要です。
Proper location of secondary nameservers so that they are located on different physical networks can increase the reliability of this service to a large extent [MOC87a, MOC87b]. However, the nature of the service requires that the nameservers for the next highest level be available in order to resolve names outline-mode side of one's domain. Thus, for "foo.princeton.edu" to resolve "a.mid.net", the root nameservers which point to mid.net's nameservers have to be reachable.
適切な位置、したがって、セカンダリネームサーバでは、それらが異なった物理ネットワークに位置しているのが大体において[MOC87a、MOC87b]このサービスの信頼性を増強できます。 しかしながら、サービスの本質は、次の最高水準のためのネームサーバが人のドメインのアウトラインモード端が命名すると決議するために利用可能であることを必要とします。 したがって、"foo.princeton.edu"が「a.mid.net」を決議するように、mid.netのネームサーバを示す根のネームサーバは届いていなければなりません。
To make the service more reliable, the mid-level network could have at least one nameserver that is able to resolve nameserver queries for all domains directly connected to it. Thus, in the event that the entire mid-level network becomes isolated from the rest of the Internet, applications can still resolve queries for sites directly connected to the mid-level network. Without this functionality, there is no way of resolving a name if the root (or higher level) nameservers become unreachable, even if the query is for a site that is directly connected and reachable.
サービスをより信頼できるようにするように、中間レベルのネットワークは直接それにつなげられたすべてのドメインのためのネームサーバ質問を決議できる少なくとも1つのネームサーバを持つことができました。 したがって、全体の中間レベルのネットワークがインターネットの残りで孤立するようになる場合、アプリケーションはまだ直接中間レベルのネットワークにつなげられたサイトのための質問を決議できます。 この機能性がなければ、根(または、より高いレベル)のネームサーバが手が届かなくなるなら名前を決議する方法が全くありません、質問が直接つなげられるサイトにはあり、届いても。
Aggarwal [Page 3] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[3ページ]RFC1291の可能性
Strategies for implementing this architecture are discussed in appendix B.
付録Bでこのアーキテクチャを実装するための戦略について議論します。
To locate such a "meta-domain" server within a mid-level network, it is proposed that a nameserver entry for "meta-dns" exist within the mid-level network's domain.
中間レベルのネットワークの中でそのような「メタドメイン」サーバの場所を見つけるように、「メタ-dns」のためのネームサーバエントリーが中間レベルのネットワークのドメインの中に存在するよう提案されます。
3.2 Public Domain Software
3.2 パブリックドメインソフト
File transfer traffic constituted 23% of the NSFnet backbone traffic for May 1991. Public shareware is a very valuable resource within the Internet and a considerable amount of effort is being put into developing applications to track all available resources in the public archives [SHHH90].
ファイル転送トラフィックは1991年5月のためのNSFnetバックボーントラフィックの23%を構成しました。 公共のシェアウェアはインターネットの中の非常に貴重なリソースです、そして、公共のアーカイブ[SHHH90]のすべての利用可能資源を追跡するためにかなりの量の取り組みを展開しているアプリケーションにそそいでいます。
It would be difficult, if not impossible to create an up-to-date repository for every public domain package available on the Internet, simply because of the volume of software and the rate at which new software is being developed every day. Some hosts have gained popularity as good public archives (such as uunet.uu.net, sumex- aim.stanford.edu, wuarchive.wustl.edu) and new developers tend to distribute the software to these sites as distribution points. The economics of maintaining centralized archives is another deterrent to centralization (the UUnet archives at uunet.uu.net take up roughly 1GB of disk storage).
あらゆる公共の場パッケージのための最新の倉庫をインターネットに利用可能な状態で作成するのは、難しいか、または不可能でしょう、単に新しいソフトウェアが毎日開発されているソフトウェアのボリュームとレートのために。 ホストの中には良い公共のアーカイブ(uunet.uu.net、sumex aim.stanford.edu、wuarchive.wustl.eduなどの)と新しい開発者が、分配が指すときこれらのサイトにソフトウェアを分配する傾向があるのに応じて人気を獲得した人もいました。 集結されたアーカイブを維持する経済学は中央集権化への別の抑止力(uunet.uu.netのUUnetアーカイブはおよそ1GBのディスクストレージを始める)です。
Recently however, a number of methods for resource discovery have
been developed and are available on the Internet ("ftp-list" file
compiled by John Granose - odin@pilot.njin.net, Archie at
archie.cs.mcgill.ca and Prospero [NEU]).
最近、しかしながら、リソース発見のための多くのメソッドが、開発されて、インターネット(ジョンGranoseによってコンパイルされた「ftp-リスト」ファイル-- odin@pilot.njin.net 、archie.cs.mcgill.caとプロスペロー[NEU]のアーチー)で利用可能です。
It is desirable that the mid-level networks be able to provide up- to-date pointers to the distribution hosts for available public software archives. Coordinating the distribution of a static list is difficult (though not impossible) and the use of automated resource discovery mechanisms such as Archie and Prospero is recommended. Under ideal conditions, any software that is popular and significant (e.g., X11, TeX, RFC's) could be archived and distributed within the mid-level network, but measuring "popularity" and "significance" are debatable and left for further evaluation. Furthermore, a nameserver entry for host "swdist" within the domain can provide information on the various available alternatives for software distribution and discovery (static file location, pointers to Archie servers, etc.) -- this nameserver entry can be an alias for a CNAME or a TXT entry.
中間レベルのネットワークが利用可能な公共のソフトウェアアーカイブのために日付までの指針を分配ホストに提供できるのは、望ましいです。 静的なリストの分配を調整するのは難しいです、そして、(不可能ではありませんが)アーチーやプロスペローなどの自動化されたリソース発見メカニズムの使用はお勧めです。 中間レベルのネットワークの中でどんなポピュラーで重要なソフトウェア(例えば、X11、TeX、RFCのもの)も格納して、理想的な条件のもとでは、分配できましたが、「人気」を測定して、「意味」は、論争の余地があって、さらなる評価に残されます。 その上、ドメインの中のホスト"swdist"のためのネームサーバエントリーはソフトウェア配布と発見(静的なファイルの位置、アーチーサーバへの指針など)のための様々な利用可能な代替手段の情報を提供できます。 -- このネームサーバエントリーはCNAMEかTXTエントリーへの別名であるかもしれません。
Aggarwal [Page 4] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[4ページ]RFC1291の可能性
3.3 Network Time
3.3ネットワーク時間
An important feature of any computer network providing distributed services is the capability to synchronize the local clocks on the various systems in the network. Ideally, the clocks of all the reference sources would be synchronized to national standards by wire or radio. The importance and immense popularity of this service makes Network Time a very useful potential service that can be provided by a mid-level network. No specific protocol for maintaining time is proposed, and any available protocol that maintains time with reasonable accuracy could be used.
分配されたサービスを提供するどんなコンピュータネットワークの重要な特徴も様々なシステムの上でネットワークで地方の時計を連動させる能力です。 理想的に、すべての照合線源の時計はワイヤかラジオによって国家規格に連動させられるでしょう。 このサービスの重要性と莫大な人気はNetwork Timeを中間レベルのネットワークが提供できる非常に役に立つ潜在的サービスにします。 時間を維持するためのどんな特定のプロトコルも提案しませんでした、そして、まずまず正確に時間を維持するどんな利用可能なプロトコルも使用できました。
Network Time Protocol (NTP) traffic constituted 1% of the NSFnet traffic during May 1991. The traffic might seem insignificant, but there have been instances where a particular stratum-1 timeserver (e.g., one of the stratum-1 servers at University of Delaware) has reached a point of overload with too many different sites trying to peer with it.
ネットワークTimeプロトコル(NTP)トラフィックは1991年5月にNSFnetトラフィックの1%を構成しました。 トラフィックは無意味に見えるかもしれませんが、インスタンスが特定の層-1日和見主義者があまりに多くの異なったサイトがそれでじっと見ていようとするオーバーロードのポイントに着いた(例えば、デラウエア大学の層-1サーバの1つ)ところにありました。
It is proposed that at least one stratum-1 and two stratum-2 servers be located within a mid-level network (the selection of three servers is based on the NTP standards documentation [MIL89]). Note that the servers can be located at any of the directly connected sites in the network as long as they are publicly accessible. All sites connected to the mid-level network can then coordinate their system times with the servers within the mid-level network itself. Besides increasing the reliability of the timekeeping network, this approach would also limit the load on each timeserver.
少なくとも1つの層-1と2層-2サーバが中間レベルのネットワークの中に位置しているよう提案されます(3つのサーバの品揃えはNTP規格ドキュメンテーション[MIL89]に基づいています)。 それらが公的にアクセスしやすい限り、サーバが直接接続されたサイトのどれかにネットワークで位置できることに注意してください。 そして、中間レベルのネットワークにつなげられたすべてのサイトが中間レベルのネットワーク自体の中でサーバで彼らのシステム時代を調整できます。 また、時間保持ネットワークの信頼性を増強すること以外に、このアプローチは各日和見主義者の上で負荷を制限するでしょう。
For locating the network time servers within a domain, nameserver entries for "timekeeper-x" (where x= 1,2,3..) can be made within the domain. The servers are numbered in order of preference and accuracy. Thus, "timekeeper-1.foo.net" would be the primary timekeeper and "timekeeper-2.foo.net" would be additional (possibly secondary) timekeepers within domain "foo.net". If such hosts are not available within a domain, a TXT entry pointing to other recommended time- servers could be provided instead.
ドメインの中でネットワーク時間サーバの場所を見つけるのにおいて、ドメインの中で「タイムキーパーx」(xが1、2と等しいところでは、3である)のためのネームサーバエントリーをすることができます。 サーバは好みと精度の順に付番されます。 したがって、「タイムキーパー-1.foo.net」はプライマリタイムキーパーでしょう、そして、「タイムキーパー-2.foo.net」はドメイン"foo.net"の中の追加している(ことによるとセカンダリの)タイムキーパーでしょう。 そのようなホストがドメインの中に手があかないなら、代わりに他のお勧めの時間サーバを示すTXTエントリーを提供するかもしれません。
3.4 Network News
3.4 ネットニュース
Network News (or Usenet News) constituted 14% of the NSFnet traffic in May 1991. Netnews is an expensive service, both in terms of disk and CPU power, as well as network bandwidth consumed.
ネットワークNews(または、Usenet News)は1991年5月にNSFnetトラフィックの14%を構成しました。 帯域幅が消費したディスク、CPUパワー、およびネットワークでネットニュースは高価なサービスです。
The present structure of Network News consists of several hub sites which are distributed over the Internet. End sites get news feeds from other sites, and an article gets injected into the news stream by sending it to the nearest "upstream" site, which then forwards it
Network Newsの現在の構造はインターネットの上に配布されるいくつかのハブサイトから成ります。 端のサイトは他のサイトからニュース給送を得ます、そして、記事は、最も近い「上流」のサイトにそれを送ることによって、ニュースストリームに注がれます。(次に、サイトはそれを進めます)。
Aggarwal [Page 5] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[5ページ]RFC1291の可能性
to its connected news sites, and so on. There is no preset norm for finding a site willing to provide a news feed, and it usually ends up being a site with whom the site administrator happens to be acquainted. However, this could easily result in some sites not being able to get an economical news feed from within the mid-level network and actually having to derive the feed from a site located on another mid-level network.
その接続ニュースサイトなどに。 通常、ニュース給送、およびそれを提供しても構わないと思っているサイトが終わるのがわかるための標準は、サイトの管理者がたまたま面識があるサイトであるのであらかじめセットされません。 しかしながら、これは容易に中間レベルのネットワークから経済的なニュース給送を得ることができないで、実際に給送に別の中間レベルのネットワークに位置するサイトに由来していなければならないいくつかのサイトをもたらすかもしれません。
A mid-level network could alleviate such occurrences by being able to provide a newsfeed to any or all of its directly connected end sites. Though an expensive resource, some of the costs can be moderated by acting as a transit news feeder so that the news needn't be stored for a long time on disk. The software for providing the news feed is not specific and depends entirely on the newsfeed provider.
中間レベルのネットワークは、直接接続された端のサイトのいずれかすべてにニュースフィードを提供できることによって、そのような発生を軽減できるでしょう。 高価なリソースですが、ニュースが長い間ディスクの上に保存される必要はないようにトランジットニュースフィーダーとして機能することによって、コストのいくつかを加減できます。 ニュース給送を提供するためのソフトウェアは、特定でなく、完全なニュースフィードプロバイダーによります。
3.5 Mailing Lists
3.5 メーリングリスト
Internet mailing lists are another popular source of information in parallel to Network News. However, like public software, there is no central repository of all the possible mailing lists available on the Internet, and it would require considerable effort to compile one (at the time of writing this document, a fairly comprehensive list is available on the Internet and mentioned in appendix A.
インターネットメーリングリストはNetwork Newsに平行な別のポピュラーな情報源です。 しかしながら、インターネットで利用可能なすべての可能なメーリングリストの中央倉庫は全く公共のソフトウェアに似ていません、そして、1つをコンパイルするのがかなりの取り組みを必要とするでしょう。(これを書いている時点でこのドキュメント、かなり包括的なリストは、インターネットで利用可能で付録Aで言及されています。
At this time, there is no clear strategy for distributing or maintaining mailing lists. However, it can be very expensive for a site to distribute mail to all individual end users directly, and if a clear strategy for maintaining a list of mailing-lists can be devised, then mail exploders can be set up at the mid-level networks, each of which forwards the mail to exploders at the end sites. This mechanism would reduce the load on the originating systems, and provides a clean path for tracking down mailer problems. Also, in order to prevent bounced mail from propagating back to the originator of the message, the mailing lists should be set up in a way so that bounced mail goes to the the "owner" of the list and not to the originator of the mail message.
このとき、メーリングリストを分配するか、または維持するためのどんな明確な戦略もありません。 しかしながら、サイトが直接すべての個々のエンドユーザに郵便物を区分けするのは、非常に高価である場合があります、そして、メーリングリストのリストを維持するための明確な戦略を工夫できるなら、中間レベルのネットワークでメール発破器はセットアップできます。それはそれぞれ端のサイトの発破器にメールを転送します。 このメカニズムは、起因するシステムの上で負荷を減少させて、郵送者問題を捜し出すのに清潔な経路を提供します。また、返送されたメールがメッセージの創始者に伝播して戻られるのを防いで、メーリングリストは、返送されたメールがメール・メッセージの創始者ではなく、リストの「所有者」に行くように、方法でセットアップされるべきです。
A list of major mailing lists for the services discussed in this document are listed in appendix A.
本書では議論したサービスのための主要なメーリングリストのリストは付録Aにリストアップされています。
4. Experimental Testbeds
4. 実験的なテストベッド
Due to the working relationships that they have with their end sites and peer networks, the mid-level networks are very good media for distribution of new ideas and technology. Examples of this function are the White Pages pilot project [RS90] established by NYSERnet, the NSAP routing schema for OSI transitioning [CGC91], etc.
彼らが自分達の端のサイトと同輩ネットワークと共に持っている仕事上のお付き合いのために、中間レベルのネットワークは新しいアイデアと技術の分配のための非常に良いメディアです。 この機能に関する例はNYSERnetによって設立されたホワイトページ試験計画[RS90]、OSI移行[CGC91]のためのNSAPルーティング図式ですなど。
Aggarwal [Page 6] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[6ページ]RFC1291の可能性
The mid-level networks could establish cooperative experimental testbeds for testing and deployment of new technologies similar to the ones mentioned above. Besides deployment and testing of new technology, this could also serve to provide a "help" service to the end-sites and to get them started with the new software.
中間レベルのネットワークは前記のようにものと同様の新技術のテストと展開のために協力的な実験的なテストベッドを設立できました。 また、新技術の展開とテスト以外に、これは端サイトに対する「助け」サービスを提供して、新しいソフトウェアでそれらを開始させるのに役立つかもしれません。
The exact interaction between the mid-level networks in this area is not very clear. It is complicated by competition for members between the mid-level networks and needs to be discussed further.
この領域の中間レベルのネットワークの間の正確な相互作用はそれほど明確ではありません。 それは、中間レベルのネットワークの間でメンバーの競争で複雑にされて、さらに議論する必要があります。
5. Network Information Services
5. ネットワーク情報サービス
There are a variety of new and useful user services available on the Internet that are difficult to document and provide a comprehensive list of. Some attempt has been made at documenting such resources [NNS] and a mid-level network can be the initial point of contact for distribution of such information on a wide basis. The information can be disseminated in a more controlled and complete manner using this hierarchical approach if each mid-level network maintains up-to-date information about its directly connected sites. Network Information services (NIC) also make the network easier and more attractive to end users. Examples of these services are:
総覧を記録して、提供するのが難しいインターネットで利用可能なさまざまな新しくて役に立つユーザサービスがあります。 何らかの試みをそのようなリソース[NNS]を記録するようにしました、そして、中間レベルのネットワークは広いベースにおけるそのような情報の分配のための初期の連絡先であるかもしれません。 それぞれの中間レベルのネットワークが直接接続されたサイトに関する最新情報を維持するならこの階層的なアプローチを使用するより制御されて完全な方法で情報を広めることができます。 また、ネットワーク情報サービス(NIC)で、ネットワークはエンドユーザには、より簡単でより魅力的になります。 これらのサービスに関する例は以下の通りです。
o provide information resources
o 情報資源を提供してください。
- security advisory messages
- セキュリティの顧問メッセージ
- list of library catalogs [GL91]
- 蔵書目録のリスト[GL91]
- geographical information servers
- 地理的な情報サーバ
- password generators
- パスワードジェネレータ
o resolve end user problems (user support)
o エンドユーザ問題を解決してください。(ユーザ・サポート)
These services are NIC related and discussed in detail elsewhere [SSM91]. For accessibility information, an entry for "nic" could exist in the DNS for the domain (this could be a TXT entry listing email or phone number information for users or other NIC's).
これらのサービスはほかの場所で詳細に関係づけられて、議論したNIC[SSM91]です。 アクセシビリティ情報に関しては、"nic"のためのエントリーはドメインへのDNSに存在できました(これは、ユーザのためにメールか電話番号情報をリストアップするTXTエントリーかNICの他のものであるかもしれません)。
6. Network Operations
6. ネットワークオペレーション
The Network Operation Center's (NOC's) at the mid-level networks need to cooperate with each other to resolve network problems. In the event of a network problem between two mid-level networks or if an end-site has trouble getting to any host, the mid-level network NOCs can serve to be the initial point of contact. The procedures for interaction among NOCs and the formats for exchange of trouble-
中間レベルのネットワークのセンターの(NOCのもの)が互いと協力するのに決議する必要があるNetwork Operationは問題をネットワークでつなぎます。2つの中間レベルのネットワークの間のネットワーク問題かそれとも端サイトが何かホストに賄賂を送るのに苦労するかどうかの場合、中間レベルのネットワークNOCsは、初期の連絡先であるのに役立つことができます。 NOCsの中の相互作用のための手順と問題の交換のための形式
Aggarwal [Page 7] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[7ページ]RFC1291の可能性
tickets between the NOCs are described elsewhere [JOH91, ML91].
NOCsの間のチケットはほかの場所[JOH91、ML91]で説明されます。
It is important for cooperating NOCs to have contact information for their directly connected campus/organizational sites and also about their peer mid-level networks. A distributed mechanism for maintaining contact information could be implemented by using a nameserver TXT entry for "noc" or by maintaining "finger" information for user "noc@domain" or "noc@noc.domain". A NOC "phonebook" listing the contact information for the various NOCs can be used as a static non-distributed mechanism (it is understood that the phonebook can contain outdated information, but the distributed mechanisms can provide correct and updated NOC information provided that the hosts are reachable at the desired time). If it is undesirable to publish the phone number or email address of the NOC for any reason, an entry saying "unpublished" (or words to that effect) could exist in the nameserver or "finger" entry instead.
協力NOCsには彼らの直接接続されたキャンパス/組織的なサイトとそれらの同輩の中間レベルのネットワークに関しても問い合わせ先があるのは、重要です。 "noc"にネームサーバTXTエントリーを使用するか、またはユーザ" noc@domain "か" noc@noc.domain "のために「指」情報を保守することによって、問い合わせ先を維持するための分配されたメカニズムを実装することができるでしょう。 静的な非分配されたメカニズムとして様々なNOCsのための問い合わせ先をリストアップするNOC"phonebook"は使用できます(phonebookが時代遅れの情報を含むことができるのが理解されていますが、ホストが必要な時に届けば、分配されたメカニズムは正しくてアップデートされたNOC情報を提供できます)。 どんな理由でもNOCの電話番号かEメールアドレスを発表するのが望ましくないなら、「未発表」で言うエントリー(または、その効果に対する単語)は代わりにネームサーバか「指」エントリーに存在するかもしれません。
7. References
7. 参照
[BOG] Dunlap, K., and M. Karels, "Nameserver Operations Guide
for Bind Release 4.8", CSRG, Department of Electrical
Engineering and Computer Sciences, University of
California, Berkeley, California.
[沼沢地]のダンラップ、K.とM.Karels、「ネームサーバ操作はひものリリースのために、4.8インチとCSRGと電気工学の部とカリフォルニア大学バークレイ校コンピューターサイエンシズ(カリフォルニア)を誘導します」。
[CCI88] CCITT Blue Book, "X.500 Series Recommendations", ITU,
1989.
[CCI88]CCITT紳士録、「X.500シリーズ勧告」、ITU、1989。
[CGC91] Collela, R., Gardner, E., and R. Callon, "Guidelines for
OSI NSAP Allocation in the Internet'', RFC 1237,
NIST, Mitre, DEC, July 1991.
[CGC91] Collela、R.、ガードナー、E.、およびR.Callon、「インターネットのオウシNSAP Allocationのためのガイドライン」、RFC1237、NIST、斜め継ぎ、12月(1991年7月)。
[SSM91] Sitzler, D., Smith, P., and A. Marine, "Building a Network
Information Services Infrastructure", RFC in
preparation.
[SSM91] 準備におけるSitzler、D.、スミス、P.、およびA.海兵隊員、「サービスインフラストラクチャをネットワーク情報に築き上げます」、RFC。
[GL91] George, A., and R. Larsen, "Internet Accessible Library
Catalogs & Databases", Aug 1991.
Available via anonymous FTP from ariel.unm.edu.
[GL91] ジョージ、A.とR.ラーセン、「インターネットアクセス可能な蔵書目録とデータベース」、1991年8月。 ariel.unm.eduからの公開FTPで、利用可能です。
[JOH91] Johnson, D., "NOC TT Requirements", RFC in
preparation.
[JOH91] ジョンソン、D.、「NOC TT要件」、準備におけるRFC。
[MAN] Mandelbaum, R., and P. Mandelbaum, "The Strategic Future
of the Mid-Level Networks", University of Rochester,
NY, 1991.
[男性]マンデルバウム、R.、およびP.マンデルバウム、「中間レベルのネットワークの戦略の未来」、ロチェスター大学、ニューヨーク、1991。
[MOC87a] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, USC Information Sciences
[MOC87a]Mockapetris、P.、「ドメイン名--、実装と仕様、」、RFC1035、USC情報科学
Aggarwal [Page 8] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[8ページ]RFC1291の可能性
Institute, November 1987.
1987年11月に、設けます。
[MOC87b] Mockapetris, P., "Domain Names - Concepts and
Facilities", RFC 1034, USC Information Sciences
Institute, November 1987.
[MOC87b]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC1034、科学が設けるUSC情報、11月1987
[MIL89] Mills, D., "Network Time Protocol", RFC 1129, UDel,
October 1989.
[MIL89] 工場、D.、「ネットワーク時間プロトコル」、RFC1129、UDel、1989年10月。
[ML91] Mathis, M., and D. Long, "User Connectivity Problems
Working Group", RFC in preparation.
準備における[ML91]マシス、M.とD.Long、「ユーザ接続性問題作業部会」RFC。
[NEU] Neuman, B., "The Virtual System Model: A Scalable
Approach to Organizing Large Systems", Department of
Computer Science, University of Washington, FR-35,
Seattle, WA, May 1990.
[NEU] ヌーマン、B.、「仮想のシステムは以下をモデル化します」。 「結団大規模システムへのスケーラブルなアプローチ」(コンピュータサイエンス学部、ワシントン大学、FR-35、シアトルワシントン)は1990がそうするかもしれません。
[NNS] NSF Network Service Center, "Internet Resource Guide",
Cambridge, MA.
Available via anonymous FTP from nnsc.nsf.net.
[NNS]NSFはサービスセンター、「インターネット資料ガイド」、ケンブリッジ、MAをネットワークでつなぎます。 nnsc.nsf.netからの公開FTPで、利用可能です。
[RS90] Rose, M., and M. Schoffstall, "The NYSERnet White Pages
Pilot Project", NYSERnet, Inc., Mar 1990.
[RS90] ローズ、M.、およびM.Schoffstall、「NYSERnetホワイトページパイロットプロジェクト」、NYSERnet Inc.、1990年3月。
[SHHH90] Schwartz, M., Hardy, D., Heinzman, W., and G.
Hirschowitz, "Supporting Resource Discovery Among
Public Internet Archives", Department of Computer
Science, University of Colorado, Boulder, CO.,
September 1990.
[SHHH90] シュワルツとM.とハーディーとD.とHeinzman、W.とG.Hirschowitz、「公共のインターネットアーカイブの中でリソース発見をサポートする」コンピュータサイエンス学部、コロラド大学、ボウルダー、CO、9月1990日
8. Security Considerations
8. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
9. Author's Address
9. 作者のアドレス
Vikas Aggarwal JvNCnet 6 von Neumann Hall Princeton University Princeton, NJ 08544
Vikas Aggarwal JvNCnet6フォンノイマン・Hallプリンストン大学プリンストン、ニュージャージー 08544
Phone: +1-609-258-2403 Email: vikas@jvnc.net
以下に電話をしてください。 +1-609-258-2403 メールしてください: vikas@jvnc.net
Aggarwal [Page 9] RFC 1291 Potential Technical Services December 1991
サービス1991年12月に技術的なAggarwal[9ページ]RFC1291の可能性
Appendix A - Mailing Lists
付録A--メーリングリスト
The following is a list of popular mailing lists for the services listed in this document. To subscribe to a particular mailing list, send a request to "mailing-list-request" (do not send a request to the entire mailing list).
↓これは本書では記載されたサービスのためのポピュラーなメーリングリストのリストです。 特定のメーリングリストに加入するには、「郵送リスト要求」に要求を送ってください(全体のメーリングリストに要求を送らないでください)。
o ietf@isi.edu: The general mailing list for the Internet
Engineering Task Force. This group is concerned with the evolution
and development of Internet related protocols and standards. Old
mail is archived at "venera.isi.edu" in directory ftp/irg/ietf.
o ietf@isi.edu : インターネット・エンジニアリング・タスク・フォースのための一般的なメーリングリスト。 このグループは発展に関係がありました、そして、インターネットの開発はプロトコルと規格を関係づけました。 古いメールはディレクトリftp/irg/ietfの"venera.isi.edu"に格納されます。
o ntp@trantor.umd.edu: For discussions on the Network Time
Protocol (NTP).
o ntp@trantor.umd.edu : Network Timeプロトコル(NTP)についての議論のために。
o namedroppers@nic.ddn.mil: Mailing list for discussions on DNS
topics. Old mail is archived at "nic.ddn.mil".
o namedroppers@nic.ddn.mil : DNS話題についての議論のためのメーリングリスト。 古いメールは"nic.ddn.mil"に格納されます。
At the time of writing this document, a list of mailing lists on the Internet is available via anonymous FTP from host "ftp.nisc.sri.com" in the file "netinfo/interest-groups".
これを書いている時点でこのドキュメント、インターネットに関するメーリングリストのリストは「netinfo/営利団体」というファイルでホスト"ftp.nisc.sri.com"からの公開FTPで利用可能です。
Appendix B - DNS Architecture Strategy
付録B--DNSアーキテクチャ戦略
This section discusses practical strategies for implementing a nameserver architecture within a mid-level network, so that it can resolve nameserver queries for all domains directly attached to it.
このセクションは中間レベルのネットワークの中でネームサーバアーキテクチャを実装するための実用的な戦略を論じます、直接それに付けられたすべてのドメインのためのネームサーバ質問を決議できるように。
In order to resolve queries for all directly connected networks, a host that is authoritative for all directly attached domains will need to exist within the mid-level network. Nameservers at the end sites would then treat this "group-of-domains" nameserver as a forwarding server to resolve all non-local queries.
すべてのための質問が直接ネットワークを接続したと決議するために、すべての直接付属しているドメインに、正式のホストは、中間レベルのネットワークの中に存在する必要があるでしょう。 そして、端のサイトのネームサーバは、すべての非地方の質問を決議するために推進サーバとしてこの「ドメインのグループ」ネームサーバを扱うでしょう。
This can be done by adding a line to the named.boot file on the end site nameservers such as:
以下などの終わりのサイトネームサーバのnamed.boot fileに系列を加えることによって、これができます。
forwarders 128.121.50.7 128.32.0.4
混載業者128.121.50.7 128.32.0.4
This method has the added advantage that the forwarding server builds up a very rich cache of data [BOG] and acts like a metacache that all hosts can benefit from. Note that the forwarding server is queried only if the end-site server cannot service a query locally -- hence the "meta-domain" server is not overloaded with queries for all nameserver lookups.
このメソッドには、推進サーバがデータ[BOG]の大金持ちのキャッシュに築き上げて、すべてのホストが利益を得ることができるmetacacheのように機能させる加えられた利点があります。 端サイトサーバが局所的に質問を修理できない場合にだけ推進サーバが質問されることに注意してください--したがって、「メタドメイン」サーバはすべてのネームサーバルックアップのための質問で積みすぎられません。
Aggarwal [Page 10]
Aggarwal[10ページ]
一覧
スポンサーリンク
