RFC1173 日本語訳

1173 Responsibilities of host and network managers: A summary of the"oral tradition" of the Internet. J. VanBokkelen. August 1990. (Format: TXT=12527 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                    J. Van Bokkelen
Request for Comments:  1173                           FTP Software, Inc.
                                                             August 1990

ヴァンBokkelenがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1173 FTPソフトウェアInc.1990年8月

             Responsibilities of Host and Network Managers
           A Summary of the "Oral Tradition" of the Internet

ホストとネットワークマネージャの責任はインターネットの「口頭の伝統」の概要です。

Status of this Memo

このMemoの状態

   This informational RFC describes the conventions to be followed by
   those in charge of networks and hosts in the Internet.  It is a
   summary of the "oral tradition" of the Internet on this subject.
   [RFC Editor's note:  This memo is a contribution by the author of his
   view of these conventions.  It is expected that this RFC will provide
   a basis for the development of official policies in the future.]
   These conventions may be supplemented or amended by the policies of
   specific local and regional components of the Internet.  This RFC
   does not specify a standard, or a policy of the IAB.  Distribution of
   this memo is unlimited.

ネットワークとホストを担当してインターネットでものによって続かれるように、この情報のRFCはコンベンションについて説明します。 それはこの話題の上のインターネットの「口頭の伝統」の概要です。 [RFC Editorの注意: このメモは彼のこれらのコンベンションの視点の作者による貢献です。 このRFCが将来公式方針の開発の基礎を提供すると予想されます。] これらのコンベンションは、インターネットの特定の地方の、そして、地方のコンポーネントの方針で補われるか、または修正されるかもしれません。 このRFCは規格、またはIABの方針を指定しません。 このメモの分配は無制限です。

Table of Contents

目次

   Status of this Memo .............................................. 1
   1. Basic Responsibilities......................................... 1
   2. Responsibilities of Network Managers........................... 2
   3. Responsibilities of Host System Managers....................... 2
   4. Postmaster@foo.bar.baz......................................... 3
   5. Problems and Resolutions....................................... 3
   6. The Illusion of Security....................................... 4
   7. Summary........................................................ 5
   8. Security Considerations........................................ 5
   9. Author's Address............................................... 5

このMemoの状態… 1 1. 基本的な責任… 1 2. ネットワークマネージャの責任… 2 3. ホストシステム・マネージャの責任… 2 4. Postmaster@foo.bar.baz........................................ 。 3 5. 問題と解決… 3 6. セキュリティの幻想… 4 7. 概要… 5 8. セキュリティ問題… 5 9. 作者のアドレス… 5

1. Basic Responsibilities

1. 基本的な責任

   The Internet is a co-operative endeavor, and its usefulness depends
   on reasonable behaviour from every user, host and router in the
   Internet.  It follows that people in charge of the components of the
   Internet MUST be aware of their responsibilities and attentive to
   local conditions.  Furthermore, they MUST be accessible via both
   Internet mail and telephone, and responsive to problem reports and
   diagnostic initiatives from other participants.

インターネットは協力的な努力です、そして、有用性はインターネットですべてのユーザ、ホスト、およびルータから合理的なふるまいに依存します。 インターネットのコンポーネント担当の人々がそれらの責任を意識していて現地の状況に注意深いに違いないということになります。 その上、彼らは、インターネット・メールと電話の両方を通してアクセスしやすくて、他の関係者からの問題報告書と診断イニシアチブに敏感であるに違いありません。

   Even local problems as simple and transient as system crashes or
   power failures may have widespread effects elsewhere in the net.
   Problems which require co-operation between two or more responsible
   individuals to diagnose and correct are relatively common.  Likewise,

システムクラッシュか停電と同じくらい簡単で同じくらい一時的な地方の問題さえネットにおけるほかの場所に広範囲の効果を持っているかもしれません。 診断して、誤りを正す責任がある2人以上の個人の間の協力を必要とする問題は比較的一般的です。 同様に

Van Bokkelen                                                    [Page 1]

RFC 1173     Responsibilities of Host and Network Managers   August 1990

ホストとネットワークマネージャ1990年8月のヴァンBokkelen[1ページ]RFC1173責任

   the tools, access and experience needed for efficient analysis may
   not all exist at a single site.

効率的な分析に必要であるツール、アクセス、および経験はただ一つのサイトにすべて存在しないかもしれません。

   This communal approach to Internet management and maintenance is
   dictated by the present decentralized organizational structure.  The
   structure, in turn, exists because it is inexpensive and responsive
   to diverse local needs.  Furthermore, for the near term, it is our
   only choice; I don't see any prospect of either the government or
   private enterprise building a monolithic, centralized, ubiquitous "Ma
   Datagram" network provider in this century.

インターネット管理とメインテナンスへのこの共同のアプローチは現在の分散組織体制によって書き取られます。 それがさまざまの地方の必要性に安価であって、敏感であるので、構造は順番に存在しています。 その上、短期間、それは私たちの唯一の選択です。 私は政府か今世紀に一枚岩的で、集結されて、遍在している「マDatagram」ネットワーク内の提供者を築き上げる私企業のどちらかのどんな見通しも見ません。

2. Responsibilities of Network Managers

2. ネットワークマネージャの責任

   One or more individuals are responsible for every IP net or subnet
   which is connected to the Internet.  Their names, phone numbers and
   postal addresses MUST be supplied to the Internet NIC (or to the
   local or regional transit network's NIC) prior to the network's
   initial connection to the Internet, and updates and corrections MUST
   be provided in a timely manner for as long as the net remains
   connected.

1人以上の個人がインターネットに関連づけられるあらゆるIPネットかサブネットに責任があります。 インターネットとのネットワークの初期の接続の前にインターネットNIC(または地方の、または、地方のトランジットネットワークのNICに)にそれらの名前、電話番号、および郵便の宛先を提供しなければなりません、そして、ネットの残りが接続した限り、直ちにアップデートと修正に備えなければなりません。

   In order to adequately deal with problems that may arise, a network
   manager must have either:

適切に起こるかもしれない問題に対処するために、ネットワークマネージャには、どちらかがなければなりません:

      A. System management access privileges on every host and router
         connected to the local network, or:

または、あらゆるホストとルータに関するA.システム管理アクセス権が企業内情報通信網に接続した、:

      B. The authority and access to either power off, re-boot,
         physically disconnect or disable forwarding IP datagrams from
         any individual host system that may be misbehaving.

B. パワーに取り止めになっている権威とアクセス(リブート)は、ふらちな事をしているどんな個々のホストシステムからも、推進IPがデータグラムであると物理的に切断するか、または無効にします。

   For all networks, a network manager capable of exercising this level
   of control MUST be accessible via telephone 8 hours a day, 5 days a
   week.  For nets carrying transit traffic, a network manager SHOULD be
   accessible via telephone 24 hours a day.

すべてのネットワークにおいて、この管理水準を運動させることができるネットワークマネージャは8時間電話を通して1日(1週間あたり5日間)アクセスしやすくなければなりません。 トランジットトラフィック、ネットワークマネージャSHOULDを運ぶネットにおいて、1日24時間電話を通してアクセスしやすくいてください。

3. Responsibilities of Host System Managers

3. ホストシステム・マネージャの責任

   One or more individuals must be responsible for every host connected
   to the Internet.  This person MUST have the authority, access and
   tools necessary to configure, operate and control access to the
   system.  For important timesharing hosts, primary domain name servers
   and mail relays or gateways, responsible individual(s) SHOULD be
   accessible via telephone 24 hours a day, 7 days a week.

1人以上の個人がインターネットに接続されたすべてのホストに責任があるに違いありません。 この人は権威、アクセス、およびツールをシステムへのアクセスを構成して、操作して、制御するのに必要にしなければなりません。 重要な時分割ホストか一次的領域ネームサーバとメール中継かゲートウェイ、責任がある個人SHOULDに、1日24時間電話を通してアクセスしやすくいてください、年中無休。

   For less-important timesharing hosts or single-user PCs or
   workstations, the responsible individual(s) MUST be prepared for the
   possiblity that their network manager may have to intervene in their

それほど重要でない時分割ホスト、シングルユーザーPCまたはワークステーションに関しては、責任がある個人がそれらのネットワークマネージャが干渉しなければならないかもしれないpossiblityのために用意ができていなければならない、それら

Van Bokkelen                                                    [Page 2]

RFC 1173     Responsibilities of Host and Network Managers   August 1990

ホストとネットワークマネージャ1990年8月のヴァンBokkelen[2ページ]RFC1173責任

   absence, should the resolution of an Internet problem require it.

不在インターネット問題の決議がそれが必要であるなら。

4. Postmaster@foo.bar.baz

4. Postmaster@foo.bar.baz

   Every Internet host that handles mail beyond the local network MUST
   maintain a mailbox named "postmaster".  In general, this should not
   simply forward mail elsewhere, but instead be read by a system
   maintainer logged in to the machine.  This mailbox SHOULD be read at
   least 5 days a week, and arrangements MUST be made to handle incoming
   mail in the event of the absence of the normal maintainer.

企業内情報通信網でメールを扱うすべてのインターネット・ホストが「郵便局長」というメールボックスを維持しなければなりません。 一般に、これはメールをほかの場所に絶対に転送するべきではありませんが、代わりにマシンにログインされたシステム維持装置によって読まれてください。 このメールボックスSHOULD、1週間あたり少なくとも5日間の読書になってください、そして、正常な維持装置の不在の場合、入って来るメールを扱うのを手配をしなければなりません。

   A machine's "postmaster" is the normal point of contact for problems
   related to mail delivery.  Because most traffic on the long-haul
   segments of the Internet is in the form of mail messages, a local
   problem can have significant effects elsewhere in the Internet.  Some
   problems may be system-wide, such as disk or file system full, or
   mailer or domain name server hung, crashed or confused.  Others may
   be specific to a particular user or mailing list (incorrect aliasing
   or forwarding, quota exceeded, etc.).

マシンの「郵便局長」は郵便配達に関連する問題のための正常な連絡先です。 インターネットの長期セグメントに関するほとんどのトラフィックがメール・メッセージの形にあるので、ローカルの問題はインターネットのほかの場所に重要な効果を持つことができます。 いくつかの問題がディスクやファイルシステムのように完全にシステム全体であるかもしれないか、または郵送者かドメイン名サーバが、掛かったか、ダウンしたか、混乱させられました。 他のものは特定のユーザかメーリングリスト(不正確なエイリアシングや推進、超えられていた割当てなど)に特定であるかもしれません。

   In either case, the maintainer of a remote machine will normally send
   mail about delivery problems to "postmaster".  Also, "postmaster" is
   normally specified in the "reply-to:" field of automatically
   generated mail error messages (unable to deliver due to nonexistent
   user name, unable to forward, malformed header, etc.).  If this
   mailbox isn't read in a timely manner, significant quantities of mail
   may be lost or returned to its senders.

どちらの場合ではも、通常、リモートマシンの維持装置は配送問題に関するメールを「郵便局長」に送るでしょう。 また、通常、「郵便局長」は「reply-to」で指定されます。 自動的に生成しているメールエラーメッセージ(進めないどんな実在しないユーザ名であることができる、奇形のヘッダーなどのためも配送できない)の分野。 このメールボックスが直ちに読まれないなら、メールの有意量は、送付者に失われているか、または返されるかもしれません。

5. Problems and Resolutions

5. 問題と解決

   Advances in network management tools may eventually make it possible
   for a network maintainer to detect and address most problems before
   they affect users, but for the present, day-to-day users of
   networking services represent the front line.  No responsible
   individual should allow their "dumb-question" filter to become too
   restrictive; reports of the form "I haven't gotten any mumblefrotz
   mail for a week... " or "I could get there this morning, but not
   now..." should always get timely attention.

ユーザに影響する前にネットワークマネージメントツールにおける進歩でネットワーク維持装置がそのほとんどの問題を検出して、訴えるのが結局、可能になるかもしれませんが、当分その日その日のネットワークサービスのユーザは最前線を表します。 どんな責任がある個人によっても、それらの「ばかな質問」フィルタは制限するようになり過ぎるはずがありません。 「私は1週間少しのmumblefrotzメールも受け取っていない」フォームのレポート… 「または、「私は、今朝そこに到着しますが、現在、到着できないだろうこと」はいつもタイムリーな注意を得るべきです。」

   There are three basic classes of problems that may have network-wide
   scope:  User-related, host-related and network-related.

ネットワーク全体の範囲を持っているかもしれない3つの基本的なクラスの問題があります: ユーザ関連で、ホスト関連でネットワーク関連です。

      A. User-related problems can range from bouncing mail or
         uncivilized behaviour on mailing lists to more serious
         issues like violation of privacy, break-in attempts or
         vandalism.

A.のユーザ関連の問題はメーリングリストにおけるメールを戻って来させるか、未開のふるまいから、より重大なプライバシーの違反、不法侵入未遂または破壊のような問題まで及ぶことができます。

      B. Host-related problems may include mis-configured software,

B.のホスト関連の問題は誤構成されたソフトウェアを含むかもしれません。

Van Bokkelen                                                    [Page 3]

RFC 1173     Responsibilities of Host and Network Managers   August 1990

ホストとネットワークマネージャ1990年8月のヴァンBokkelen[3ページ]RFC1173責任

         obsolete or buggy software and security holes.

時代遅れの、または、バギーのソフトウェアとセキュリティは掘られます。

      C. Network-related problems are most frequently related to
         routing: incorrect connectivity advertisements, routing
         loops and black holes can all have major impacts.
         Mechanisms are usually in place for handling failure of
         routers or links, but problems short of outright failure
         can also have severe effects.

C.のネットワーク関連の問題は最も頻繁にルーティングに関連します: 不正確な接続性広告、ルーティング輪、およびブラックホールはすべて、強い影響を持つことができます。 メカニズムがしかし、ルータかリンクの取り扱い失敗、また、完全では、急に、失敗が厳しい効果を持つことができることにおける問題によって通常適所にあります。

   Each class of problem has its own characteristics.  User-related
   problems can usually be solved by education, but system managers
   should be aware of applicable federal and state law as well; Privacy
   violations or "cracking" attempts have always been grounds for
   pulling a user's account, but now they can also result in
   prosecution.  Host-related problems are usually resolvable by re-
   configuration or upgrading the software, but sometimes the
   manufacturer needs to be made aware of a bug, or jawboned into doing
   something about it; Bugs that can't be fixed may be serious enough to
   require partial or total denial of service to the offending system.
   Similar levels of escalation exist for network-related problems, with
   the solution of last resort being ostracism of the offending net.

それぞれのクラスの問題には、それ自身の特性があります。 教育で通常ユーザ関連の問題を解決できますが、システム・マネージャはまた、連邦と州の適切な法を意識しているべきです。 いつもプライバシー違反か「分解」試みがユーザのアカウントを引く根拠ですが、今、また、それらは起訴をもたらすことができます。 通常、ホスト関連の問題が再構成かソフトウェアをアップグレードさせることによって溶解性ですが、メーカーは、時々、バグを意識しているのに作られているか、またはそれに関して何かをするのにjawbonedされる必要があります。 修理できないバグは部分的であるか総怒っているシステムに対するサービスの否定を必要とすることができるくらい重大であるかもしれません。 増大の同じ水準は怒っているネットの切り札の存在追放の解決に関するネットワーク関連の問題によって存在しています。

6. The Illusion of Security

6. セキュリティの幻想

   Every host and network manager MUST be aware that the Internet as
   presently constituted is NOT secure.  At the protocol level, much
   more effort has been put into interoperability, reliability and
   convenience than has been devoted to security, although this is
   changing.  Recent events have made software developers and vendors
   more sensitive to security, in both configuration and the underlying
   implementation, but it remains to be demonstrated how much long-term
   effect this will have.  Meanwhile, the existing system survives
   through the co-operation of all responsible individuals.

あらゆるホストとネットワークマネージャが現在構成されているとしてのインターネットが安全でないことを意識しているに違いありません。 プロトコルレベルでは、セキュリティにささげられたより相互運用性、信頼性、および便利にずっと多くの取り組みをそそぎました、これは変化しますが。 近頃の出来事は構成と基本的な実装の両方でソフトウェアをセキュリティにより敏感な開発者とベンダーにしましたが、示されるために、これにはどのくらいの長期効果があるかは残っています。 その間、既存のシステムはすべての責任がある個人の協力で存続します。

   Security is subjective; one site might view as idle curiosity what
   another would see as a hostile probe.  Since ultimately the existence
   of the Internet depends on its usefulness to all members of the
   community, it is important for managers to be willing to accept and
   act on other sites' security issues, warning or denying access to
   offending users.  The offended site, in turn, must be reasonable in
   its demands (someone who set off an alarm while idly seeing if the
   sendmail "DEBUG" hole was closed on a "sensitive" host probably
   should be warned, rather than prosecuted).

セキュリティは主観的です。 1つのサイトが別のものが敵対的な徹底的調査をみなすことと活動していない好奇心をみなすかもしれません。 インターネットの存在が結局共同体のすべてのメンバーへの有用性によるので、マネージャが、他のサイトの安全保障問題、警告または怒っているユーザへのアクセスを拒絶するのに受け入れる、行動しても構わないと思っているのは、重要です。 怒っているサイトは要求が順番に妥当でなければなりません(sendmail「デバッグ」穴が「敏感な」ホストで閉じられたかどうか無為にわかっている間、アラームを引きたたせただれかにたぶん起訴されるよりむしろ注意されるべきです)。

   Because Internet security issues may require that local management
   people either get in touch with any of their users, or deny an
   offending individual or group access to other sites, it is necessary
   that mechanisms exist to allow this.  Accordingly, Internet sites

インターネット安全保障問題が、現地管理職者の人々が彼らのユーザのどれかに連絡を取るか、または他のサイトへの怒っている個人かグループアクセスを拒絶するのを必要とするかもしれないので、メカニズムがこれを許容するために存在するのが必要です。 それに従って、インターネットを位置させます。

Van Bokkelen                                                    [Page 4]

RFC 1173     Responsibilities of Host and Network Managers   August 1990

ホストとネットワークマネージャ1990年8月のヴァンBokkelen[4ページ]RFC1173責任

   SHOULD NOT have "general use" accounts, or "open" (without password)
   terminal servers that can access the rest of the Internet.

SHOULD NOTは、「一般的使用」がインターネットの残りにアクセスできるターミナルサーバを説明するか、または「開くこと」を(パスワードなしで)持っています。

   In turn, the "sensitive" sites MUST be aware that it is impossible in
   the long term to deny Internet access to crackers, disgruntled former
   employees, unscrupulous competitors or agents of other countries.
   Getting an offender flushed is at best a stop-gap, providing a
   breathing space of a day or an hour while the security holes under
   attack are closed.  It follows that each host's manager is ultimately
   responsible for its security; the more "sensitive" the application or
   data, the more intimate the manager must be with the host's operating
   system and network software and their foibles.

順番に、「敏感な」サイトは他国のクラッカー、不満を抱いていた元従業員、無節操な競争者またはエージェントへのインターネット・アクセスを否定するのが長期で不可能であることを意識していなければなりません。 犯罪者を洗い流させるのは、せいぜい間に合せです、攻撃しているセキュリティーホールが閉じられている間、1日か1時間の休息を提供して。 各ホストのマネージャは結局セキュリティに責任があるということになります。 アプリケーションであり、データでありマネージャが親密であるに違いなければ、ホストのオペレーティングシステム、ネットワークソフトウェア、および彼らの弱点は、より「敏感です」。

7. Summary

7. 概要

   The heart of the Internet is the unique community of interest
   encompassing its users, operators, maintainers and suppliers.
   Awareness and acceptance of the shared interest in a usable Internet
   is vital to its survival and growth.  The simple conventions
   presented here should be supplemented by common sense as necessary to
   achieve that end.

インターネットの中心はユーザ、オペレータ、維持装置、および供給者を包含する興味があるユニークな共同体です。 使用可能なインターネットへの共有された関心の認識と承認はその生存と成長に重大です。 ここに提示された簡単なコンベンションは必要に応じて常識によって補われて、その終わりを達成するべきです。

8. Security Considerations

8. セキュリティ問題

   Security issues are discussed in Sections 5 and 6.

セクション5と6で安全保障問題について議論します。

9. Author's Address

9. 作者のアドレス

   James B. VanBokkelen
   FTP Software Inc.
   26 Princess St.
   Wakefield, MA  01880

聖ウェークフィールド、ジェームスB.VanBokkelen FTPソフトウェアInc.26姫MA 01880

   Phone:  617-246-0900

以下に電話をしてください。 617-246-0900

   EMail: jbvb@ftp.com

メール: jbvb@ftp.com

Van Bokkelen                                                    [Page 5]

ヴァンBokkelen[5ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Outlook ExpressからWindows Liveメールにメールを移行する方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る