RFC504 日本語訳

Network Working Group                                     Bob Thomas
RFC # 504                                                 BBN
NIC # 16155                                               April 30, 1973

1973年4月30日にワーキンググループボブトーマスRFC#504BBN NIC#16155をネットワークでつないでください。

                         Workshop Announcement

ワークショップ発表

Title: Automated Resource Sharing on the ARPANET

タイトル: アルパネットに関する自動化されたリソース・シェアリング

Date:  Monday May 21, 1973

日付: 1973年5月21日月曜日

Time:  9:00 AM to 5:00 PM

時間: 午前9時から午後5時

Place: Bolt Beranek and Newman Inc., Cambridge, Mass.

以下を置いてください。 ボルトBeranekとニューマン株式会社、ケンブリッジ、マサチューセッツ州

Hosts: TENEX and TIP Groups at BBN

ホスト: BBNのTENEXとチップグループ

Theme:
-----

テーマ: -----

This workshop will focus on various aspects of the question:

このワークショップは質問の種々相に焦点を合わせるでしょう:

    What steps can be taken to automate access to the distributed
    resources on the ARPANET?

アルパネットに関する分配されたリソースへのアクセスを自動化するためにどんな方法を取ることができますか?

In particular, how can we move from where we are today toward an
environment which facilitates resource sharing by moving the burden of
dealing with the network from the human user to processes which act on
his behalf?  Additionally, operating systems themselves perform various
operations not directly initiated by human users which could better be
performed with the availability of resources on other systems (e.g.
file system backup); how can we move toward an environment which
facilitates such system-system cooperation?

特に、私たちは彼に代わってどの行為をどうしたら私たちが今日人間のユーザからネットワークと取り引きする負担を動かすことによってリソース・シェアリングを容易にする環境に向かっているところから過程まで動かすことができますか? さらに、オペレーティングシステム自体は人間のユーザによって直接開始されなかった様々な操作を実行します(リソースの有用性で他のシステム(例えば、ファイルシステム・バックアップ)に実行できたほうがよいです)。 私たちはどうしたらそのようなシステムシステム協力を容易にする環境に近づくことができますか?

Objectives of Workshop:
----------------------

ワークショップの目的: ----------------------

1.  To identify and clarify the issues raised by automated resource
    sharing.
    What are the obstacles preventing more widespread resource sharing
    on the ARPANET?  Are they technical, political, administrative in
    nature?  Is it that there are few resources worth sharing (we don't
    think so)?  Is automated sharing a bad idea (We don't think so)?

1. 自動化されたリソース・シェアリングによって提起された問題を特定して、はっきりさせるために。 アルパネットで、より広範囲のリソース・シェアリングを防ぐ障害は何ですか? それらは、技術的であるのと、政治上で、現実に管理ですか? 共有する価値があるリソースがわずかしかないという(私たちはそのように思いません)ことですか? 自動化された共有は悪い考え(私たちはそのように思わない)ですか?

Thomas                                                          [Page 1]

RFC 504                  Workshop Announcement                April 1973

トーマス[1ページ]RFC504ワークショップ発表1973年4月

2.  To identify resources at various network sites appropriate for
    automated sharing; and to identify the need for resources which
    don't but should exist.

2. 自動化された共有に、適切な様々なネットワークサイトでリソースを特定するために。 そして、しかし、そうしないリソースの必要性を特定するのは存在するべきです。

3.  To formulate a series of experiments for the purpose of evaluating
    relative merits and disadvantages of different approaches to
    automating resource sharing.
    The intent of such experimentation is to gain experience through
    construction and use of prototype systems which support automated
    sharing.

3. 優劣を評価する目的のための一連の実験とリソース・シェアリングを自動化することへの異なるアプローチの損失を定式化するために。 そのような実験の意図は自動化された共有を支持するプロトタイプ装置の工事と使用で経験を積むことです。

Format of Workshop:
------------------

ワークショップの形式: ------------------

Morning:

朝:

In order to get the workshop "up to speed", each participant will be
expected to give a brief presentation of relevant work he (his site) is
currently engaged in, is planning to do, or to identify and discuss
issues he feels are relevant to the subject.  Time will be allowed for
brief discussion after each presentation.

ワークショップを「速度」まで得るには、各関係者が彼(彼のサイト)が現在従事している関連仕事の簡潔なプレゼンテーションをすると予想されるでしょう、と計画はすることになっているか、または特定することになっています、そして、彼が対象に関連していると感じる問題について議論してください。 時間は各プレゼンテーションの後の簡潔な議論のために許容されるでしょう。

Afternoon:

午後:

General discussion of the issues raised during the morning session.
Possible subjects for discussion include (but need not be limited to):

前場の間に提起された問題の一般議論。 しかし、議論のための可能な対象が含んでいる、(制限される必要はない、)、:

1.  Identification of possible multi-site "services".
    Intersite mail, terminal linking, status information are some
    examples - what are others?

1. 可能なマルチサイト「サービス」の識別。 Intersiteメール、端末のリンク、状態情報はいくつかの例です--他のものは者ですか?

2.  Identification of resources appropriate for remote utilization.
    File systems, compilers, on-line query systems, manuscript
    preparation systems are some examples - what are others?

2. リモート利用に、適切なリソースの識別。 ファイルシステム、コンパイラ、オンライン質問システム、原稿準備システムはいくつかの例です--他のものは者ですか?

3.  Access to remote resources.
    Possibility of access paths other than the standard logger port.  To
    what extent (if at all) can the access paths to a variety of
    different resources be standardized?  How can resources which may
    move from Host to Host or may be available on several Hosts be
    dynamically located and selected for use?  The need for
    (desirability of) a "broadcast ICP".

3. 遠隔資源へのアクセス。 標準のきこりのポート以外のアクセス経路の可能性。 どんな範囲(せいぜい)にさまざまな異なったリソースへのアクセス経路を標準化できますか? どうしたらHostからHostまで動くかもしれないか、または数個のHostsで利用可能であるかもしれないリソースは、ダイナミックに見つけていて、使用のために選択できますか? 必要性、(願わしさ、)、「放送ICP。」

4.  Problems of accounting for resource utilization.
    Some form of network wide accounting would be a great convenience.
    For example, it would be nice if a user could use the same account
    at many (all?) sites.  What are the problems (if any) preventing
    this?

4. リソース利用のための会計の問題。 何らかの形式のネットワークの広い会計はかなりの便利でしょう。 例えば、ユーザが多くの(すべて?)サイトで同じアカウントを使用できるなら、良いでしょうに。 これを防ぐことにおける問題(もしあれば)は何ですか?

Thomas                                                          [Page 2]

RFC 504                  Workshop Announcement                April 1973

トーマス[2ページ]RFC504ワークショップ発表1973年4月

5.  Problems of security and access control.
    Authentication of users/processes attempting to use resources.  As
    with network wide accounts, the ability to use the same name and
    password at all sites would be convenient.  How can a user's
    password and other sensitive data be protected in such an
    environment?
    The notion of a third party password validation and user
    authentication service.

5. セキュリティとアクセスの問題は制御されます。 リソースを使用するのを試みるユーザ/過程の認証。 広いアカウント、すべてのサイトで同じ名前とパスワードを使用する能力がそうするネットワークのように、便利であってください。 そのような環境でどうしたらユーザのパスワードと他の極秘データを保護できますか? 第三者パスワード合法化であってユーザー認証サービスの概念。

6.  Approaches to automating resource sharing.
    It is possible without difficulty to identify several which on the
    surface appear to be different:

6. リソース・シェアリングを自動化することへのアプローチ。 表面で異なるように見える数個を特定するのは難無く可能です:

    a.  Multi-site executive programs which make resources accessible to
        the user at the command language level; e.g.  the inter-site,
        user-user interaction and file maintenance activity supported by
        the RSEXEC.
    b.  A programming language environment designed to facilitate
        resource sharing; e.g. LISP is a machine independent language -
        one could imagine a multi-computer LISP system which supported
        automated resource sharing.
    c.  The "collect a resource" approach - identify an Editor here,
        file storage service there, a compiler somewhere else, etc; and
        build a "workshop" environment which provides convenient access
        to these resources.

a。 リソースをコマンド言語水準でユーザにとってアクセスしやすくするマルチサイト管理プログラム。 例えばRSEXEC. bによってサポートされた相互サイト、ユーザユーザ相互作用、およびファイルメインテナンス活動。 リソース・シェアリングを容易にするように設計されたプログラミング言語環境。 例えば、LISPはマシンの独立している言語です--人は自動化されたリソース・シェアリングcを支持したマルチコンピュータLISPシステムを想像できました。 「リソースを集めてください」というアプローチ--ここのEditor、そこでのファイル記憶装置サービス、他のどこかのコンパイラなどを特定してください。 そして、これらのリソースへの便利なアクセスを提供する「ワークショップ」環境を築き上げてください。

    What are the relative merits and disadvantages of these approaches?
    What aspects do these approaches have in common?  Is it possible to
    identify a common base capable of supporting them all?

これらのアプローチの優劣と損失は何ですか? これらのアプローチはどんな局面が共通ですか? それらを皆、支持できる一般的なベースを特定するのは可能ですか?

7.  Protocols to support automated resource sharing.
    It would be inappropriate to attempt to generate a detailed protocol
    specification at this workshop. However, it is appropriate to
    discuss the kinds of activity a protocol should support. Existing
    protocols (excepting Host-Host protocol and possibly, the new TELNET
    protocol) appear to be oriented toward human users. Automated
    resource sharing suggests processes acting on behalf of human users
    to interface to remote resources; this in turn suggests that the
    protocols should be highly process oriented. For example, because
    there should be minimal human intervention in error recovery, the
    protocols should be extremely robust; e.g., include well specified
    time outs, etc.

7. サポートするプロトコルはリソース・シェアリングを自動化しました。 このワークショップで詳細なプロトコル仕様を発生させるのを試みるのは不適当でしょう。 しかしながら、プロトコルが支持するべきである活動の種類について議論するのは適切です。 既存のプロトコル(Host-ホストプロトコルとことによると新しいTELNETプロトコルを除いた)は人間のユーザに向かって適応するように見えます。 自動化されたリソース・シェアリングは遠隔資源に連結するように人間のユーザを代表して行動する過程を示します。 これは、プロトコルが過程非常に指向しているべきであると順番に示唆します。 例えば、最小量の人間の介入間違った回復があるべきであるので、プロトコルは非常に強健であるべきです。 例えば、よく指定されたタイムアウトなどを含めてください。

Thomas                                                          [Page 3]

RFC 504                  Workshop Announcement                April 1973

トーマス[3ページ]RFC504ワークショップ発表1973年4月

Arrangements:
------------

アレンジメント: ------------

If you are planning to attend the workshop, please notify Bob Thomas at
BBN (send net mail to BTHOMAS@BBN, telephone (617) 491-1850, x483).  If
you would like us to make motel reservations for you (at the homestead
Inn at Fresh Pond) call Mrs Terry Bernier at BBN (x545).

ワークショップに出席するのを計画しているなら、BBNでボブ・トーマスに通知してください(ネットのメールを BTHOMAS@BBN に送ってください、電話(617)491-1850、x483)。 私たちがあなたのモーテルの予約をするのが好きであって頂ける、(BBN(x545)でFresh Pond) 呼び出しテリー・ベルニエ夫人でインに入植してください。

It is possible that a single day will prove to be insufficient for this
workshop.  If that is the consensus of the attendees, the workshop will
continue through Tuesday May 22.

1日がこのワークショップに不十分であると判明するのは、可能です。 それが出席者のコンセンサスであるなら、ワークショップは5月22日火曜日まで続くでしょう。

Position papers, memos, notes, etc. prepared by participants in advance
of the workshop will help contribute to the success of the workshop and
are requested.  All such papers received before May 11 will be
distributed, in advance, to workshop attendees.

方針書、メモ、ワークショップの前に関係者によって準備された注意などは、ワークショップの成功に貢献するのを助けて、要求されています。 5月11日があらかじめワークショップの出席者に分配される前にそのようなすべての書類が受信されました。

The following questions may be helpful in focusing your thinking:

以下の質問はあなたの考えの焦点を合わせる際に役立っているかもしれません:

- What resources would your site be willing to make available for use in
  automated resource sharing experiments?
- Under what conditions would your site be willing or able to
  participate in such experiments?
- What administrative and/or technical considerations would prevent your
  site from entering into a network wide resource sharing agreement?
- If you employ accounting Procedures that require cost recovery, how,
  if at all, should they be modified to work in a network resource
  sharing environment?

- あなたのサイトは、自動化されたリソース・シェアリング実験における使用に利用可能にどんなリソースを作ることを望んでいるでしょうか? - どんな状態の下では、あなたのサイトは、望んでいますか、そのような実験に参加できるでしょうか? - どんな管理的である、そして/または、技術的な問題が、あなたのサイトがネットワークの広いリソース・シェアリング協定に入るのを防ぐでしょうか? - あなたが原価回収を必要とする会計Proceduresを使うなら、せいぜい、彼らは、環境を共有しながらネットワーク資源で働くようにどのように変更されるべきですか?

Reading List:
------------

推薦図書: ------------

We are aware of little that has been written on the subject of automated
resource sharing.  However, the following items are relevant (at least
marginally) to the workshop.  Please inform us of others of which you
are aware.

私たちは少ししか自動化されたリソース・シェアリングに関して書かれていない意識しています。 しかしながら、以下の項目はワークショップに関連しています(少なくともわずかに)。 あなたが意識している他のものについて私たちに知らせてください。

1.  ARPANET NEWS, Issue 2, Report on COMPCON 73 "Birds of a Feather
    Session" on Resource Sharing Networks, NIC 15337.
2.  "A Resource Sharing Executive for the ARPANET", R. Thomas, Preprint
    of paper for 1973 National Computer Conference, BBN Report 2522, NIC
    #14689.
3.  "Terminal Access to the ARPANET - Experience and Improvements", N.
    Mimno, B. Cosell, Walden, et. al., COMPCON 73 Proceedings, NIC
    14791.
4.  "A Tentative Proposal for a Modified User Protocol", M. Padlipsky,
    RFC 451, NIC #14135.

1. アルパネットニュース、問題2はリソース・シェアリングネットワーク、NIC15337のCOMPCON73「同じ羽毛の鳥セッション」に関して報告します。 2. 「アルパネットのためのResource Sharing Executive」、R.トーマス、1973年のNationalコンピュータコンファレンス(BBN Report2522、NIC#14689)のための紙のPreprint。 3. 「アルパネットへの端末のAccess--、経験とImprovements、」、N.Mimno、B.コーセル、ウォルデンet(アル)、COMPCON73Proceedings(NIC14791) 4. 「変更されたユーザプロトコルのための試案」、M.Padlipsky、RFC451、NIC#14135。

Thomas                                                          [Page 4]

RFC 504                  Workshop Announcement                April 1973

トーマス[4ページ]RFC504ワークショップ発表1973年4月

5.  "Interentity Communication - An experiment", R. Bressler, R. Thomas,
    RFC 441, NIC 13773.
6.  "Netbank", J. Postel, RFC 408, NIC #12390.

5. 「Interentity Communication--、実験、」、R.Bressler、R.トーマス、RFC441、NIC13773 6. "Netbank"、J.ポステル、RFC408、NIC#12390。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社9/99]

Thomas                                                          [Page 5]

トーマス[5ページ]