RFC849 日本語訳

Network Working Group                                       Mark Crispin
Request for Comments: 849                                       Stanford
                                                                May 1983

コメントを求めるワーキンググループマーククリスピンRequestをネットワークでつないでください: 849 スタンフォード1983年5月

            SUGGESTIONS FOR IMPROVED HOST TABLE DISTRIBUTION

改良されたホストテーブル分配のための提案

     This RFC may be something unique among modern-day RFC's, an RFC
that actually is a request for comments.  The issue dealt with is that
of a naming registry update procedure, both as exists currently and what
could exist in the future.  None of the proposed solutions are intended
as standards at this time; rather it is hoped that a general consensus
will emerge as the appropriate solution, leaving eventually to the
adoption of standards.

このRFCは現代のRFCのもの、コメントを求めて実際に要求であるRFCの中で何かユニークなものであるかもしれません。 ともに現在存在するとき、対処された問題は命名登録アップデート手順のものです、そして、何が将来、存在できますか? 提案された解決策のいずれもこのとき、規格として意図しません。 結局規格の採用にいなくなって、むしろ、全体的な合意が適切な解決策として現れることが望まれています。

                                THE PROBLEM

問題

     I am somewhat dissatisfied with the current level of Internet name
service and name registry updating.  Each site is expected to
individually maintain a copy of the [SRI-NIC]<NETINFO>HOSTS.TXT file,
and in fact has to, since SRI-NIC is simply not reliable enough to
depend upon as a name server.  Neither the Tenex operating system nor
the Foonly computer are known for exceptional reliability or
performance.  Probably they serve the NIC's internal operations well;
that is not at issue.  What is needed is a name service that is
available at all times.  Only then could a site sacrifice maintaining
its own local copy of "the host table".

私は現在のレベルのインターネット名前サービスと名前登録アップデートにいくらか不満です。 各サイトは個別に[SRI-NIC]<NETINFO>HOSTS.TXTファイルのコピーを維持すると予想されて、事実上、予想されなければなりません、SRI-NICが絶対にネームサーバとしてよるくらいには信頼できないので。TenexオペレーティングシステムもFoonlyコンピュータも例外的な信頼性か性能で知られていません。 たぶん、NICの社内業務によく役立ちます。 問題にはそれがいません。 必要であるものはいつも利用可能な名前サービスです。 そして、サイトは、それ自身の「ホストテーブル」の地方のコピーを維持しながら、犠牲にされることができただけです。

     The NIC indirectly acknowledges this, by providing a service by
which the entire Internet name registry can be dumped, as well as
ANONYMOUS FTP access to the <NETINFO>HOSTS.TXT file.  The problem is,
some individual has to know to retrieve the latest version of the file
from the NIC.  The NIC has not always been careful to announce updates
to the name registry.  My experience with maintaining an independent
name registry from the NIC's in the past leads me to appreciate the
NIC's problems.

NICは間接的にこれを承認します、登録という全体のインターネット名をどさっと落とすことができるサービスを提供することによって、<NETINFO>HOSTS.TXTファイルへの更生会FTPアクセスと同様に。 問題があって、何らかの個人が、最新版を検索するのをNICからのファイルを知らなければなりません。 NICは登録という名前にアップデートを発表するのにいつも慎重であるというわけではありませんでした。 過去にNICから独立している名前登録を維持する私の経験は、私がNICの問題に感謝するように導きます。

     There also seems to be no good automated way to cross-check the
version at the local site with the NIC's.  It is clearly inefficient to
go to the effort of retrieving the same version of the host table that
already has been installed on site.

また、NICのものと共にローカル・サイトでバージョンにクロスチェックするどんな良い自動化された方法もあるように思えません。 既にサイトにインストールされたホストテーブルの同じバージョンを検索する努力に行くのは明確に効率が悪いです。

                             SOME SOLUTIONS

何らかの解決法

     One could argue that a solution is to replace or augment the
present SRI-NIC system with VAX Unix system(s) dedicated to name service
and network information.  A reliable and highly-responsive name service
would ultimately lead to the elimination of the necessity to maintain
copies of the registry locally.  This solution requires money, time, and
effort, which may or may not be immediately available; it must therefore
be considered a longer-term solution.

1つは、解決策が現在のSRI-NICシステムを取り替えるか、またはVAX Unixシステムがサービスとネットワーク情報を命名するために捧げられている状態で増大させることであると主張するかもしれません。 信頼できて非常に敏感な名前サービスは結局、局所的に登録のコピーを維持する必要性の除去につながるでしょう。 この解決策はすぐに空くかもしれないお金、時間、および努力を必要とします。 したがって、より長い期間ソリューションであるとそれを考えなければなりません。

Crispin                                                         [Page 1]

     A more short-term solution is to make possible faster and more
thorough updating of the various local copies of the name tables.  I
have several suggestions in this area, and would like to hear comments
(I said this was an RFC that requested comments!):

より短期的な解決策が可能なより速くて、より徹底的なアップデートを作ることであるネームテーブルの様々な地方のコピーのクリスピン[1ページ]。 この領域にいくつかの提案を持って、コメントを聞きたいと思います(私は、これがコメントを要求したRFCであると言いました!):

     (1) a new protocol by which the NIC could ship updated name
registries to the hosts itself.  This would take the form of a server
process on each site listening on a registered port for updates from
certain "trusted" sites (specifically SRI-NIC but possibly other sites
as well).  This would allow for nearly immediate updates for cooperating
sites, provided that the hosts in question are up.  There should be some
sort of checksum applied to the updated name registry, to make sure it
arrived complete and intact.

(1) NICが出荷できた新しいプロトコル自体は名前登録をホストにアップデートしました。 これは、アップデートのために登録されたポートの上で、ある一定の「信じられた」サイト(また、明確にSRI-NICにもかかわらず、ことによると他のサイト)から聴きながら、各サイトでサーバの過程の形を取るでしょう。 問題のホストが起きていれば、これは協力サイトのためのほとんど即座のアップデートを考慮するでしょう。 それが完全であって、完全な状態で到着したのを確実にするために、登録というアップデートされた名前に適用されたある種のチェックサムがあるべきです。

     (2) a new protocol by which the NIC will report the current
"version" of the host table.  Tenex and TOPS-20 sites would find the use
of the file generation number natural.  I presently maintain a
SYSTEM:HOSTS.TXT with the same generation as it existed on the NIC, and
just check at the NIC from time to time to see if the generation number
changed there.  I would like to automate this.

(2) NICがホストテーブルの現在の「バージョン」を報告する新しいプロトコル。 TenexとTOPS-20サイトによって、ファイル世代番号の使用が当然であることがわかるでしょう。 私は現在、SYSTEMを維持します: それと同じ世代があるHOSTS.TXTは、NICに存在していて、世代番号がそこで変化したかどうかを見るためにNICで時々ただチェックします。 これを自動化したいと思います。

     (3) A variation on (1), whereby the NIC would mail the updated host
table to a mailing list of "host table update" recepients and each site
would establish its own update procedures.  This is the simplest to
implement for the NIC, but is fraught with all sorts of problems.  Mail
is not a good means for bulk-shipping files to many recepients,
especially when the files are likely to become hugh.

(3) (1)の変化であり、NICがどうして「ホストテーブルアップデート」recepientsに関するメーリングリストと各サイトにアップデートされたホストテーブルを郵送するだろうかがそれ自身のアップデート手順を確立するでしょう。 これは、NICのために実行するのが最も簡単ですが、いろいろな問題について悲惨です。メールは多くのrecepientsへのばら積輸送ファイルのための良い手段ではありません、特にファイルがhughになりそうなとき。

     I like (1) best of these three, because that would guarantee
immediate updating without a local necessity to periodically poll the
NIC.  That does place the burden on the NIC to make sure all sites
receive the update, and also requires that the NIC remember which sites
are dead to retry the update later.  This leads me to what I think is
the best solution, which is:

それは定期的にNICに投票する地方の必要性のない即座のアップデートを保証するでしょう、したがって、私が(1) これらの3のベストが好きです。 それは、すべてのサイトがアップデートを受けるのを確実にするためにNICに負担をかけて、また、後でアップデートを再試行するためにNICが、どのサイトが死んでいるかを覚えているのを必要とします。 これは私を私が以下の通りである最も良い解決策であると思うことに導きます。

     (4) A combination of (1) and (2).  The NIC will ship updates to all
hosts which are registered with it to receive the updates, and will try
only once.  Each site, as part of its system startup procedure, will run
a program to poll the NIC for a possible update and if one is available
retrieve it.  As a backup, there could also be a periodic poll on, say,
a daily basis.

(4) (1)と(2)の組み合わせ。 NICはすべてのホストへのアップデートを受けるためにそれに登録されるアップデートを出荷して、一度だけ試みるでしょう。 システム起動手順の一部として、各サイトは可能なアップデートのためにNICに投票するためにプログラムを動かすでしょう、そして、1つが利用可能であるなら、それを検索してください。 また、バックアップとして、周期的な投票がたとえば、日課にあるかもしれません。

Crispin                                                         [Page 2]

クリスピン[2ページ]