RFC101 日本語訳
0101 Notes on the Network Working Group meeting, Urbana, Illinois,February 17, 1971. R.W. Watson. February 1971. (Format: TXT=30343 bytes) (Updated by RFC0108, RFC0123) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Richard W. Watson Request for Comments: 101 SRI-ARC NIC: 5762 February 23, 1971
コメントを求めるワーキンググループリチャードW.ワトソン要求をネットワークでつないでください: 101 様アークNIC: 5762 1971年2月23日
NOTES ON THE NETWORK WORKING GROUP MEETING
ネットワークワーキンググループミーティングに関する注
Wednesday Evening, February 17
水曜日の晩、2月17日
Mike Sher opened by welcoming the group to Urbana and briefly indicated that ILLIAC IV was expected to be running this summer. The ILLIAC IV Project has been split into two projects; one on basic system hardware and software, and the other on applications. Their IMP is not yet connected to their PDP-11.
マイク・シェールは、アーバナにグループを歓迎することによって開いて、ILLIAC IVが今年の夏に走ると予想されたのを簡潔に示しました。 ILLIAC IV Projectは2つのプロジェクトに分割されました。 基本体系ハードウェアとソフトウェアの上の1つ、およびアプリケーションでのもう片方。 それらのIMPはまだそれらのPDP-11に接続されていません。
Steve Crocker asked for topics to be discussed at this meeting; these are indicated below.
スティーブ・クロッカーは、このミーティングで話題について議論するように頼みました。 これらは以下で示されます。
Peggy Karp of Mitre has been summarizing the old RFC's. She has a list of about 30 topics and is summarizing their present status. She expects to finish around the end of February. See RFC #100, NIC(5761). It was suggested that someone write an RFC indicating which ones are obsolete. It was also suggested that the Network Information Center (NIC) help sites in organizing their hardcopy material.
Mitreのペギー・カープは古いRFCのものをまとめています。 彼女は、およそ30の話題のリストを持って、それらの現況をまとめています。 彼女は、2月の終わり頃に終わると予想します。 NIC(5761)、RFC#100を見てください。 だれかがどれが時代遅れであるかを示すRFCに書くことが提案されました。 また、Networkインフォメーション・センター(NIC)が、サイトがそれらのハードコピーの材料を有機化するのを手伝うことが提案されました。
There then followed brief discussions of experiences in using the Network. John Melvin (SRI-ARC) summarized SRI's experience in using the Utah PDP-10 to help in SRI's transfer from an XDS 940 to a PDP- 10. In April-May 1970 it was clear that SRI was headed toward a PDP-10 in order to have the capacity and reliability to fulfill their role as the Network Information Center. They had had some previous experience in connecting with Utah, and so it seemed logical to try to use the Utah 10 to aid the transfer.
そして、Networkを使用することにおける、経験の簡潔な議論は続きました。 ジョン・メルビン(SRI-ARC)はSRIのXDS940からPDP10までの転送で助けるのにユタPDP-10を使用するSRIの経験をまとめました。 1970年4月-5月に、Networkインフォメーション・センターとしてそれらの役割を実現させるのはSRIが容量と信頼性を持つためにPDP-10に向かって率いられたのが明確でした。 彼らにはユタに接続する何らかの以前の経験があったので、転送を支援するのにユタ10を使用しようとするのは論理的に思えました。
In June use of the Network began. SRI uses higher level languages
extensively, so the first task was to transfer the compiler-
compiler Tree Meta. Source code was generated on the 940 to run
on the PDP-10. Binaries were then transmitted to Utah and run and
debugged. Patches were performed where possible, and source
changes accumulated. A new source and binaries would then be made
periodically.
6月に、Networkの使用は始まりました。 最初のタスクはSRIが手広く高水準言語を使用するのでコンパイラコンパイラTree Metaを移すことでした。 ソースコードは、PDP-10の上で作業するために940で発生しました。 2種混合毒ガスは、次に、ユタに送られて、走って、デバッグされました。 パッチは可能であるところで実行されました、そして、ソース変化は蓄積しました。 そして、新しいソースと2種混合毒ガスは定期的に作られているでしょう。
Watson [Page 1] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[1ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
Once Tree Meta was running, a new high level language (called L-
10) for programming the On-Line System (NLS) was implemented in
the same way. When L-10 was running the core device independent
parts of NLS were rewritten and debugged. NLS was completely
reorganized during the transfer.
Tree Metaがいったん走っていると、同様に、On-線System(NLS)をプログラムするための新しい高級言語(L10と呼ばれる)は実行されました。 L-10が走っていたとき、NLSのコアの装置の独立している一部が、書き直されて、デバッグされました。 NLSは転送の間、完全に再編成されました。
At the SRI and Utah ends a control program allowing three users to
connect to Utah was written, which ran as a user process and
allowed character interaction and files to be transmitted. The
scheme worked well and much useful work was accomplished in the
July--December period with some people on 4-5 hours per day. The
voice link was used when something would go wrong in trying to
determine where the problem existed and to reset. At times they
would go 2 weeks with no problems. SRI has an IMP interface
diagnostic which ran as a T/S process.
SRIとユタ終わりに、3人のユーザがユタに接続する制御プログラム(キャラクタ相互作用とファイルが送られるのをユーザ・プロセスとして走って、許容した)は、書かれました。 計画はうまくいきました、そして、多くの実質的な仕事が12月の期間に7月に1日あたりの4〜5時間何人かの人々と共に実行されました。 何かが問題が存在したところで決定して、リセットするトライで支障をきたすだろうというとき、声のリンクは使用されました。 時には、彼らは2週間問題なしで行くでしょう。SRIには、T/Sの過程として走ったIMPインタフェース病気の特徴があります。
Generally, echoing was handled at the SRI end. DDT was used at
Utah end. Round trip character delays of 4 seconds were not
uncommon, and at certain points delays of 8 or 10 minutes were
experienced. These delays were the result of the implementation
used which involved multiple processes at each end, each to be
scheduled. Utah was heavily loaded at 2:00 PM and the SRI people
took to running at night and on weekends.
一般に、反響はSRIエンドのときに扱われました。 DDTはユタ終わりに使用されました。 4秒の周遊旅行キャラクタ遅れは、珍しくなく、8か10の遅れが書き留めるある一定のポイントで経験されました。 これらの遅れは、それぞれ予定されるためには各端の複数の過程にかかわった使用される実現の結果でした。 ユタは午後2時に大いにロードされました、そして、SRIの人々は夜、週末に走り始めました。
When the SRI PDP-10 came in in December, use of the Network
slowed.
SRI PDP-10が12月に来たとき、Networkの使用は遅くなりました。
Users would have liked a more constant response time instead of
the widely varying one so that their work habits could adapt to it
even if it was slow.
ユーザは、それが遅かったとしても彼らの作業慣行がそれに順応できるくらい広く異なったものの代わりにより一定の応答時間が欲しかったです。
Gerry Cole reported on some results of measurements made during the SRI-Utah work. Measurements were also made at SRI to help in interpreting the data obtained by UCLA. Gerry wrote a paper summarizing these statistics which is available from him care of SDC.
ゲリー・コールはSRI-ユタ仕事の間にされた測定のいくつかの結果に関して報告しました。 また、SRIでUCLAによって得られたデータを解釈するのを手伝うのを測定をしました。 ゲリーはこれらの統計をまとめる利用可能な紙に彼からのSDCの注意を書きました。
Gerry requested that when people are set up to use the Network,
they inform him so that he can gather statistics. UCLA will
eventually have a program to scan the Network for utilization, but
if people could tell him when they were going to use the Network,
it would be easier to measure meaningful things and interpret the
data from a knowledge of type of usage.
ゲリーは、人々がNetworkを使用するためにセットアップされるとき、彼が統計を集めることができるように彼らが彼に知らせるよう要求しました。 結局、UCLAには利用のためにNetworkをスキャンするプログラムがあるでしょうが、人々が、彼らがいつNetworkを使用するつもりであったかを彼に言うことができるなら、用法のタイプに関する知識から重要なものを測定して、データを解釈するのは、より簡単でしょうに。
Bob Kahn indicated that BBN is interested in the Statistics on overall flow to see if the Network is configured properly. Gerry said that UCLA is interested in the statistics for Network modeling studies. Measurements are taken by remote control by use of a feature designed into the IMP's by BBN for such a function.
ボブ・カーンは、Networkが適切に構成されるならBBNが見る総合的な流れのStatisticsに興味を持っているのを示しました。 ゲリーは、UCLAがNetworkモデル研究への統計に興味を持っていると言いました。 遠隔操作はそのような機能のためにBBNによってIMPのものに設計された特徴の使用で測定値を取ります。
Watson [Page 2] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[2ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
Jim White of UCSB said that UCSB and RAND had begun to experiment in use of the Network for the climate study at RAND. The UCSB NCP has been up the last 3 or 4 weeks during the day. A document, NIC (5480) is available in the NIC collection describing it. UCSB is also using their NCP for local interprocess communication experiments. RAND is using the Remote Job Entry facility of the UCSB 360-75. They are using UCSB to check out their NCP. Now that UCSB is running their NCP during normal usage hours, they have uncovered some bugs in their hardware interface to their IMP. The software at both UCSB and RAND seems to be working. Typical jobs being sent back and forth are just test jobs of a few source statements. The UCSB NCP is about 39K bytes and runs in a 60K byte partition. Users access it through assembly language, Fortran or PL/I calls.
UCSBのジム・ホワイトは、UCSBとRANDがNetworkのRANDでの気候研究の使用を実験し始めると言いました。 UCSB NCPは日間のここ3週間か4週間上がっています。 ドキュメントであり、NIC(5480)はそれについて説明するNIC収集で利用可能です。 また、UCSBはローカルのプロセス間通信実験にそれらのNCPを使用しています。 RANDはUCSB360-75のRemote Job Entry施設を使用しています。 彼らは、それらのNCPを調べるのにUCSBを使用しています。 UCSBが正常な用法の間、それらのNCPを何時間も走らせているので、彼らはそれらのハードウェア・インタフェースのいくつかのバグの自分達のIMPに覆いを取りました。 UCSBとRANDの両方のソフトウェアは働いているように思えます。 前後に送られる典型的な仕事はただいくつかのソース声明のテスト仕事です。 UCSB NCPは60Kのバイトにおけるバイトと走行が仕切るおよそ39Kです。 FortranかPL/Iが、ユーザがアセンブリ言語を通してそれにアクセスすると呼びます。
Steve Crocker now returned to the discussion of the agenda for the meeting and longer range organization of the NWG. Steve felt that Working committees on various topics were required as the open meeting was good for bringing up problems, general discussion and education, but was too large to prepare detailed specifications on various topics.
スティーブ・クロッカーは今や、ミーティングのための議題の議論とNWGの、より長い範囲組織に戻りました。 スティーブは、問題、一般的な議論、および教育を持って来るのに、公開の会議が良くて、様々な話題のWorking委員会が必要であったと感じますが、様々な話題に関して仕様詳細を準備できないくらい大きかったです。
The following topics requiring work were listed:
仕事を必要とする以下の話題が記載されました:
1. Graphics
1. グラフィックス
2. Data Transformation Languages
2. データ媒体変換言語
3. Host-Host Protocol -- long range study
3. ホスト兼ホストプロトコル--長い範囲研究
4. Host-Host Protocol -- Short term maintenance and modifications
4. ホスト兼ホストプロトコル--短期間維持と変更
5. Accounting
5. 会計
6. Logger Protocol
6. きこりのプロトコル
7. Typewriter connection protocol
7. タイプライタ接続プロトコル
8. Documentation
8. ドキュメンテーション
9. Data Management
9. データ管理
In #1 Al Vezza of MIT is organizing an NWG meeting in graphics April 25-27 which can accommodate 31 people. People desiring to come should prepare for their institution a working paper. Al sees three classes of problems:
#では、MITの1アルVezzaが31人の人を収容できるグラフィックス4月25日〜27日にNWGミーティングを計画します。 来ることを望んでいる人々は彼らの団体のために監査調書を準備するべきです。 アルは3つのクラスの問題を認めます:
i) two hosts, each with computing and graphics facilities,
wanting to use special facilities at the other
i) もう片方に特別な施設を使用するためにそれぞれコンピューティングとグラフィックス施設で足りない2人のホスト
Watson [Page 3] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[3ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
ii) one host with graphic facilities but no number crunching
facilities wanting to use computing capabilities of a second host
ii) グラフィック施設がかみ砕きますが、どんな数も2番目のホストのコンピューティング能力を使用したくしながら施設をかみ砕いていない1人のホスト
iii) a node with a graphic terminal not having picture processing
or computing capability desiring to obtain these from other nodes.
iii) グラフィックターミナルが他のノードから画像処理を持っていないか、またはこれらを得る能力の望みを計算していないノード。
With respect to #2 John Heafner of RAND indicated RAND wants to provide data rearrangement services of the type indicated in RFC #83, NIC (5621). More on this topic below.
#、に関して、RANDの2ジョンHeafnerは、RANDがRFC#83で示されたタイプのデータ配列換えサービスを提供したがっているのを示しました、NIC(5621)。 さらに以下のこの話題に関して。
With respect to #3 a group under A. N. Habermann of CMU has been formed to look at the Host-Host protocol. Toward the end of March they are planning a paper discussing their ideas. The group consists of:
#3、に関して、米カーネギーメロン大学のA.N.ハーバーマンの下のグループは、Host-ホストプロトコルを見るために結成されました。 3月の終わりに向かって、彼らは、彼らの考えについて議論しながら、論文を計画しています。 グループは以下から成ります。
A. N. Habermann, CMU
A.N.ハーバーマン、米カーネギーメロン大学
G. B. Hansen, CMU
G.B.ハンセン、米カーネギーメロン大学
W. Wulf, CMU
W.ウルフ、米カーネギーメロン大学
R. Chen, CMU
R.チェン、米カーネギーメロン大学
R. Kalin, Lincoln Lab
R.Kalin、リンカーン研究室
The group welcomes suggestions of topics.
グループは話題の提案を歓迎します。
With respect to #4 a group is to be set up to evaluate present protocol and produce needed changes to the protocol. The group is to be conservative and produce only changes needed to solve known problems and leave esthetic changes until later.
#4、に関して、グループは現在のプロトコルを評価するために設立されることになっていました、そして、生産物はプロトコルへの変化を必要としました。 グループは、既知の問題を解決して、より遅れるまで美的な変化を出発するのが必要である変化だけを、保守的であり、発生させることになっています。
With respect to the other problems discussion was put off until later (see below).
もう片方に関して、問題議論は、より遅れるまで延期されました(以下を見てください)。
Two people interested in the Network who were observers at the meeting spoke briefly.
ミーティングでオブザーバであったNetworkに興味を持っている2人の人が簡潔に話しました。
C. D. (Terry) Shepard of the Computer Communication Task Force,
Canadian Government, outlined the goals of his group. These goals
are:
コンピュータCommunication Task ForceのC.D.(テリー)シェパード(カナダの政府)は彼のグループの目標について概説しました。 これらの目標は以下の通りです。
1) establish a plan to link up various Canadian computers and
establish a network
1) 様々なカナダのコンピュータをリンクして、ネットワークを確立する計画を確立してください。
2) develop what the needs of Canada are for such a network
2) カナダの必要性がそのようなネットワークのためのものであると開発してください。
Watson [Page 4] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[4ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
3) see that the benefits of such a network are distributed
throughout Canada
3) そのようなネットワークの利益がカナダ中で分配されるのを確実にしてください。
4) prevent control of computing in Canada from being totally
dependent on foreign sources.
4) 外国人のソースの上でカナダで計算するコントロールが完全に依存しているのを防いでください。
5) see that critical computer facilities exist in Canada.
5) 批判的なコンピューター施設がカナダに存在するのを確実にしてください。
Doug McKay of IBM then described briefly a network project started
in IBM about 2 years ago. Basic network is completed. Users are
coming on. The network is to be used heavily to send files back
and forth for program updating. IBM is trying to look at the
network as a multiprocessor machine. They are trying to handle
all IBM system possibly heterogeneous such as 360's, 370's, CP '
67, the 91, a 44, and a NYU CDC 6600.
そして、IBMのダグ・マッケイは簡潔におよそ2年前にIBMで始められたネットワークプロジェクトについて説明しました。 基本的なネットワークは完成します。 ユーザは来ています。 ネットワークは、プログラムアップデートのためにファイルを前後に送るのに大いに使用されることになっています。 IBMはマルチプロセッサマシンとしてネットワークを見ようとしています。 彼らはことによると360、370、CP'67、91、44、NYU CDC6600'などのような異種のすべてのIBMシステムを扱おうとしています。
There is another project linking TSS systems using a 91 for remote
job entry. IBM has taken a centralized control point of view
using one central machine for control and flow distribution. They
are not entirely happy with this approach and are moving toward a
more decentralized approach like the ARPA Network. IBM presently
has about 14 people involved in the project.
リモートジョブエントリに91を使用することでTSSシステムをリンクする別のプロジェクトがあります。 IBMは、コントロールと流れ分配に1台の中央のマシンを使用することで集中制御観点を取りました。 彼らは、このアプローチに完全に満足でなく、アーパネットのようにさらに分散しているアプローチに近づいています。 IBMは現在、およそ14人の人をプロジェクトにかかわらせます。
Thursday morning, February 18
木曜日の朝、2月18日
Thursday morning started with the various sites reporting their status. Alex McKenzie of BBN prepared a status form later in the day which was filled out by the representatives of the sites Thursday evening. BBN and NIC will prepare a procedure for keeping this information at the sites and up to date.
木曜日に、朝はそれらの状態を報告する様々なサイトから始まりました。 木曜日の晩にサイトの代表によって書き込まれた状態フォームがその日のより遅く準備されたBBNのアレックス・マッケンジー。 BBNとNICは、サイトにおいて最新にこの情報を保つために手順を準備するでしょう。
STATUS
状態
BBN, TENEX PROJECT: Final stage of incorporating NCP in TENEX. A connection was attempted to Utah, but some bugs were found. The NCP treats the network as a file in a way integral with other types of files. The NCP includes a teletype interface. They hope to incorporate the NCP in SRI'S TENEX system by the end of the month.
BBN、TENEXは突出しています: 最終段階についてTENEXのNCPを取り入れること。 接続はユタに試みられましたが、いくつかのバグが見つけられました。 NCPはある意味で他のタイプのファイルで不可欠のファイルとしてネットワークを扱います。 NCPはテレタイプインタフェースを含んでいます。 彼らは、今月中にSRIのTENEXシステムにNCPを取り入れることを望んでいます。
BBN, NETWORK GROUP: reported that they were working on three areas
BBN、ネットワークグループ: 彼らが3つの領域で働いていたと報告します。
1. Improving the current network
1. 現在のネットワークを改良します。
2. Working on a 316 version of the IMP and as a Terminal Interface
Processor (TIMP)
2. IMPの316バージョンとTerminal Interface Processorとして働いています。(TIMP)
3. Accounting
3. 会計
Watson [Page 5] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[5ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
There are currently 15 IMPs connected to the network. A new software system with minor changes is expected by March.
現在、ネットワークに接続された15IMPsがあります。 マイナーチェンジがある新しいソフトウェア・システムは3月までに予想されます。
The TIMP uses the 316. A hardware design exists, but they are still defining the software. A TIMP can handle up to 64 variable speed terminals both sync and assync. The first machine is to go to MITRE in September.
TIMPは316を使用します。 ハードウェアデザインは存在していますが、彼らはまだソフトウェアを定義しています。 TIMPは両方が同期させる最大64台の可変速度端末とassyncを扱うことができます。 最初のマシンは9月にMITREに動くことになっています。
BBN emphasized that there are 3 products: a 516 IMP, a 316 IMP, and a 316 TIMP. The 316 IMP is less expensive than the 516 IMP and can connect to one host. BBN is not planning at the moment to exchange 316 IMPs for 516 IMPs. The two are plug-plug compatible.
BBNは、3個の製品があると強調しました: 516悪童、316悪童、および316TIMP。 316IMPは516IMPほど高価でなく、1人のホストに接できます。 BBNは、現在、316IMPsを516IMPsと交換するのを計画していません。 2はプラグプラグ・コンパチブルです。
SDC: In the debug phase for their NCP and expect it up in 4 to 6 weeks. Maybe by 8 weeks their T/S available for network use. Their T/S is a 360/65 running the ADEPT system.
SDC: デバッグでは、4〜6週間後にそれをそれらのNCPのために位相を合わせて、予想してください。 8週間そうかもしれない、それらのネットワーク使用に利用可能なT/S。 それらのT/SはADEPTシステムを動かす360/65です。
CASE WESTERN RESERVE UNIVERSITY: The IMP has been connected for about one month, but as yet have no NCP. They are planning to use the NCP implemented at Harvard. Case has a PDP-10/50 system. They expect to be up in two to three months.
ウェスタンリザーブ大学をケースに入れてください: IMPはおよそ1カ月接続されますが、まだ、NCPを全く持たないでください。 彼らは、ハーバードで実行されたNCPを使用するのを計画しています。 ケースに、PDP-10/50システムがあります。 彼らは、2〜3カ月後に上がると予想します。
HARVARD: Harvard has a PDP-1 and PDP-10 connected to the IMP. The NCP for the 10 is in final debugging. The PDP-1 is for refreshing displays. The PDP-10 is for linguistic research and students. Expect to be up in one to two months.
ハーバード: ハーバードはPDP-1とPDP-10をIMPに接続させます。 10のためのNCPは最終的なデバッグ中です。 PDP-1は壮快な表示のためのものです。 PDP-10は言語学の研究と学生のためのものです。 1〜2カ月後に上がると予想してください。
SRI-ARC: SRI has been in the final stage of conversion from an XDS 940 to a PDP-10. They plan to use the BBN TENEX NCP and should be up in three or four weeks.
様アーク: SRIがXDS940からPDP-10までの変換の最終段階にありました。 彼らは、BBN TENEX NCPを使用するのを計画して、3週間か4週間後に上がっているべきです。
MIT DYNAMIC MODELING - PDP-10: They expect an NCP to be working by March.
MITのダイナミックなモデル--、PDP-10: 彼らは、NCPが3月までに働いていると予想します。
MIT MULTICS: They are connected to the IMP and expect their NCP to be in the final debug stage in four weeks. As Multics is a service machine, they don't have unlimited access and must perform checkout at off hours. They expect to offer regular service to the network in three or four months.
MIT MULTICS: 彼らは、IMPに接続されて、4週間後に、それらのNCPが最終的なデバッグ段階にあると予想します。 Multicsがサービスマシンであるので、彼らは、無制限なアクセスを持たないで、オフ時間にチェックアウトを実行しなければなりません。 彼らは、3カ月か4カ月後にネットワークへの定期点検を提供すると予想します。
UTAH: PDP-10/50 probably going to be running TENEX in the fall. Their NCP is being written in a higher level language (Euler run interpretively) and are debugging in conjunction with BBN. They have connected to and logged into themselves and expect a debugged version within a month.
ユタ: たぶん秋にTENEXを走らせるのに行くPDP-10/50。 それらのNCPは、高水準言語(オイラー走行解釈的)で書かれていて、BBNに関連してデバッグされています。 彼らは、1カ月以内に接続して、自分たちにログインして、デバッグされたバージョンを予想しました。
Watson [Page 6] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[6ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
LINCOLN LABORATORY, TX-2: They are testing the IMP interface, found errors in Lincoln hardware. Currently, no data errors, but have errors with message IDs. They expect their NCP with logger to be up by April 15. They indicated that for testing purposes, they would like to bring up their IMP without being open to network traffic. BBN says that there is a way to echo to yourself without being open to the network (contact BBN for details).
リンカーン実験室、テキサス-2: リンカーンハードウェアにおける誤りが見つけられて、彼らはIMPインタフェースをテストしています。 現在メッセージIDとの誤りを持っている以外のデータ誤りがありません。 彼らは、4月15日までにきこりがいるそれらのNCPが上がっていると予想します。 彼らは、テスト目的のために、ネットワークトラフィックに開かれていなくて自分達のIMPを持って来たいのを示しました。 BBNは、ネットワークに開かれていなくて自分に反響する方法があると言います(詳細のためにBBNに連絡してください)。
LINCOLN LABORATORY, 360/97: Running CP/CMS. The IMP interface was completed last month. The NCP and Logger are working. They are planning to put up the NCP as a regular service in April. On request experiments with them can be run sooner.
リンカーン実験室、360/97: 走行CP/CMS IMPインタフェースは先月完成しました。 NCPとLoggerは働いています。 彼らは、4月に定期点検としてNCPを提供するのを計画しています。 要求に応じて、それらがある実験は、より早く、走ることができます。
UCSB: Has had their NCP since October. The NCP runs as independent batch job. They plan to provide service to their On-Line System (a manual is in the NIC collection at each site NIC (5480). They plan to be on the air morning to evening on a regular basis. There are some interface bugs as indicated earlier.
UCSB: 10月以来それらのNCPを持っています。 NCPは独立しているバッチ・ジョブとして走ります。 彼らは、それらのOn-線Systemに対するサービスを提供するのを計画しています。マニュアルが各サイトNIC(5480)にNIC収集にあります。彼らは、定期的の放送された朝から晩であることを計画しています。(いくつかのインタフェースバグが、より早く示されるようにあります。
RAND: 360/65. Their NCP is a user process and can be resident. It requires 8K bytes and does not have a logger.
底ならし革: 360/65. それらのNCPは、ユーザ・プロセスであり、居住している場合があります。 それには、8Kのバイトを必要として、きこりがいません。
UCLA, Sigma-7: Their NCP is in final debugging. They expect to be up by March 1 with NCP, logger, and typewriter connection program.
UCLA、σ-7: それらのNCPは最終的なデバッグ中です。 彼らは、3月1日までにNCP、きこり、およびタイプライタ接続プログラムに上がると予想します。
COMPUTER CORPORATION OF AMERICA (CCA): Has just started a project to create a node for the 10-12 bit laser store. They are going to use a PDP-10 as a front end. They are developing a language for data manipulation. The store will also be connected to the B-6500-ILLIAC IV. They are planning data compression as part of their language to ease the problems in use of the network's 50 kilobit line. They are concentrating on security and privacy measures. Initial emphasis will be on shared files. Installation is planned during 1972.
アメリカ(CCA)のコンピュータ会社: ちょうど、10-12ビットのレーザ店のためのノードを作成するために、計画を始めたところです。 彼らはフロントエンドとしてPDP-10を使用するでしょう。 彼らはデータ操作のために言語を開発しています。 また、店はB-6500-ILLIAC IVにつなげられるでしょう。 彼らは、ネットワークの50キロビット線で使用中の問題を緩和するためにそれらの言語の一部としてデータ圧縮を計画しています。 彼らはセキュリティとプライバシー測定に集中しています。 共有ファイルの上に初期の強調があるでしょう。 インストールは1972の間、計画されています。
The following projects did not have representatives at the meeting. Steve Crocker reported on their status.
以下のプロジェクトには、代表がミーティングにいませんでした。 スティーブ・クロッカーはそれらの状態に関して報告しました。
CMU: PDP-10/50: Their IMP is connected, and they are planning to
use the Harvard NCP.
米カーネギーメロン大学: PDP-10/50: それらのIMPは接続されています、そして、彼らはハーバードNCPを使用するのを計画しています。
SRI-AI PROJECT: PDP10. They are planning to run TENEX in the
fall.
様AIプロジェクト: PDP10。 彼らは、秋にTENEXを走らせるのを計画しています。
STANFORD-AI: They are not connected yet, but expect to be on by
summer.
スタンフォード-AI: それらはまだ接続されていませんが、夏までにオンであると予想してください。
Watson [Page 7] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[7ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
The above completed the review of status. Steve Crocker then indicated that the old NWG mailing list was no longer to be used and that the list maintained by the NIC (5731,) was the one to be used or that the NIC would handle distribution by sending things through your station agent to them. If your station agent or liaison person should change, please let the NIC know immediately.
上記は状態のレビューを終了しました。 次に、スティーブ・クロッカーは、使用されるために古いNWGメーリングリストがもうそうであることを示しました、そして、NIC(5731)によって維持されたリストが使用されるべきものであったかそれがNICであったのがあなたの小駅の駅長を通して事態をそれらに送ることによって、分配を扱うでしょう。 小駅の駅長か連絡の人が変化するなら、至急、NICにお知らせください。
HOST-HOST LOGGER PROTOCOL DISCUSSION: Tom Skinner of Multics opened the discussion of the logger by indicating that they wanted at least an interim protocol so that use of the network could get started. They had handed out RFC #98 NIC(5744), containing their ideas Wednesday night. SRI-ARC had a similar document, RFC #97, NIC (5740), handed out Wednesday night also. Multics recommended the revised logger protocol of RFC #80, NIC (5608).
ホスト兼ホストきこりのプロトコル議論: 彼らがネットワークの使用が開始できるくらい少なくとも当座のプロトコルが欲しかったのを示すことによって、MulticsのトムSkinnerはきこりの議論を開きました。 水曜日の夜彼らの考えを含んで、彼らはRFC#98NIC(5744)を与えました。 SRI-ARCには、同様のドキュメントがありました、また、RFC#97(NIC(5740))は水曜日の夜を与えました。 NIC(5608)、MulticsはRFC#80の改訂されたきこりのプロトコルを推薦しました。
Some discussion on the relative merits of the logger protocol of
RFC #66, NIC (5409), versus RFC #80 was given. The protocol of
#80 had some potential problems due to assumptions which must be
made after the initial contact was established.
RFC#80に対してRFC#66のきこりのプロトコルの優劣についての何らかの議論(NIC(5409))をしました。 #80のプロトコルには、いくつかの潜在的な問題が初期接触が設置された後にしなければならない仮定のためありました。
The result of the discussion was that the logger protocol of RFC
#66 was adopted with the correction that the allocate commands
were to be issued after the connection was established.
議論の結果は接続が確立された後にRFC#66のきこりのプロトコルが割り当てコマンドが発行されることになっていた修正で採用されたということでした。
There seemed to be a need for an official document to be issued
with the correct logger specification given.
公文書が正しいきこりの仕様を与えていて発行される必要性はあるように思えました。
Tom also recommended that initial communication to the logger be
in 7-bit ASCII in a 8-bit field. There was some discussion as to
whether the eighth bit should be a 0 or a 1. It was finally
decided that it should be a 0.
また、トムは、7ビットのASCIIにはきこりへの初期のコミュニケーションが8ビットの分野にあることを勧めました。 8番目のビットが0かそれとも1であるべきであるかに関して何らかの議論がありました。 それが0であるべきであると最終的に決められました。
Steve then listed some known problems or questions about the
host-host protocol.
そして、スティーブはホスト兼ホストプロトコルに関するいくつかの既知の問題か質問を記載しました。
1) Echo
1) エコー
2) Message Type
2) メッセージタイプ
3) Interrupts
3) 中断
4) Marking-Padding
4) マークしている詰め物
5) Half Duplex vs. Full Duplex communication during the
establishing of a socket.
5) 半分Duplex対ソケットの設立の間のFull Duplexコミュニケーション
Watson [Page 8] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[8ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
With regard to marking the following choices existed
以下の選択をマークすることに関して、存在しています。
a) leave alone
a) まして
b) separate the heading and data into two messages
b) 2つのメッセージに見出しとデータを切り離してください。
c) have message by multiples of 72 bits
c) 72ビットの倍数でメッセージを持ってください。
With regard to interrupts (INS, INR), there was a synchronization
problem with regard to message transmission. That is, a message
could be sent and then an interrupt issued. The interrupt could
arrive before the message, in the middle of the message. Some way
of marking the point in the data stream where an interrupt was
sent is needed.
中断(INS、INR)に関して、メッセージ送信に関して同期問題がありました。 そして、すなわち、メッセージは、送って発行された中断であるかもしれません。 中断はメッセージの前にメッセージの中央に到着できました。 中断が送られたデータ・ストリームでポイントをマークする何らかの方法が必要です。
A subgroup was appointed to consider the above Host-Host problems. Shortly, they would issue an RFC with modifications to the Host-Host protocol, then collect comments and then issue an official revision. People with suggestions should contact the committee. The committee would also be contacting the sites. The committee is:
サブグループは、上のHost-ホスト問題を考えるために任命されました。まもなく、それらは、Host-ホストプロトコルへの変更でRFCを発行して、次に、コメントを集めて、次に、公式の改正を発行するでしょう。 提案をもっている人々は委員会に連絡するべきです。 また、委員会はサイトに接触しているでしょう。 委員会は以下の通りです。
S. Crocker, UCLA (Chairman)
S.クロッカー、UCLA(議長)
R. Tomlinson, BBN
R.トムリンスン、BBN
T. Barkalow, Lincoln Lab
T.Barkalow、リンカーン研究室
G. Grossman, University of Illinois
G.グロースマン、イリノイ大学
J. White, UCSB
J.ホワイト、UCSB
R. Bressler, MIT, Project MAC
R.Bressler(MIT)はMACを映し出します。
The discussion then returned to problems of typewriter access to the network. The problems are presented in RFC #97, NIC (5740). Some are:
そして、議論はネットワークへのタイプライタアクセスの問題に戻りました。 NIC(5740)、問題はRFC#97で提示されます。 何かは以下の通りです。
a) Character set
a) 文字の組
b) End of Line
b) 行末
c) Interrupts
c) 中断
d) Message Format
d) メッセージ・フォーマット
e) Half Duplex, Full Duplex
e) 半二重、全二重
Watson [Page 9] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[9ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
These problems were given to a committee on typewriter connection protocol for solution:
解決策のためにタイプライタ接続プロトコルの委員会にこれらの問題を与えました:
Tom O'Sullivan, Raytheon (Chairman)
トム・オサリヴァン、レイセオン(議長)
Ed Meyer, MIT-MAC
エド・マイヤー、MIT-MAC
John Melvin, SRI-ARC
ジョン・メルビン、様アーク
Bob Long, SDC
SDC、長い間、たたいてください。
Bob Metcalfe, Harvard
ボブメトカルフェ、ハーバード
Wil Crowther, BBN
ピルクラウザー、BBN
This committee will come up quickly (within a week) with an interim protocol and within several weeks a longer term protocol.
この委員会は当座のプロトコルと数週間以内にすばやさ(1週間以内に)により長い用語プロトコルを来るでしょう。
Thursday afternoon, February 18
木曜日の午後、2月18日
Thursday afternoon was open to a presentation by the University of Illinois on the ILLIAC IV and a demonstration of the Plato project. The initial test in November of the transmission lines to the ILLIAC IV processors indicated no timing problems. The ILLIAC IV hardware is to be up the fall as is the software. The system will be located in California at NASA Ames Research Center. The connection to the network from the University of Illinois will be a PDP-11 with storage CRTs, 2400 baud character CRTs, typewriters attached. It will have a Gould Clevite printer, DECtapes and small disc. The B6500 at the University will also be connected to the Network.
木曜日に、午後はILLIAC IVの上のイリノイ大学とプラトンプロジェクトのデモンストレーションによるプレゼンテーションに開かれていました。 ILLIAC IVプロセッサへの伝送路の11月の初期のテストはタイミング問題を全く示しませんでした。ILLIAC IVハードウェアは秋の上にソフトウェアのようにあることです。 システムは米航空宇宙局エイムズ研究所にカリフォルニアに位置するでしょう。 イリノイ大学からのネットワークとの接続は格納CRTをもってPDP-11になるでしょう、2400ボーキャラクタCRT、添付のタイプライタ。 それはグールドCleviteプリンタ、DECtapes、および小さいディスクを持つでしょう。 また、大学のB6500はNetworkに接続されるでしょう。
Thursday evening, February 18
木曜日の晩、2月18日
The initial topic was a discussion of status and plans for the Network Information Center. Dick Watson of SRI reviewed the present off-line system consisting of a Station Agent and Network Liaison person. The function of the Station Agent is to aid in the use of the NIC services. The function of the Network Liaison person is to be a point of contact for technical questions about his site which may be asked by people at other sites, and to see that the appropriate people see relevant documents and information received by the site. If the network is really going to develop the feeling of a community, people need to be aware of what people are doing and thinking at the various sites. Therefore, people were encouraged to send reports, memos, notes, records of conversations of general interest through the NIC. Any kind of information can be sent through the NIC from formal reports to informal handwritten notes. In order to encourage people to send out initial thoughts and ideas
初期の話題は、状態の議論であり、Networkインフォメーション・センターの計画を立てます。 SRIのディック・ワトソンは駅のエージェントとNetwork Liaison人から成る現在のオフラインシステムを見直しました。 駅のエージェントの機能はNICサービスの使用で支援することです。 Network Liaison人の機能は、他のサイトで人々によって尋ねられるかもしれない彼のサイトに関する技術的な質問のための連絡先であり、適切な人々が、関連ドキュメントと情報がサイトによって受け取られるのを見るのがわかることです。 ネットワークが本当に共同体の感じを育むなら、人々は、人々が様々なサイトでして、考えていることを意識している必要があります。 したがって、人々が注意、NICを通した一般的に関心の会話に関する記録をレポート、メモに送るよう奨励されました。 NICを通してどんな種類の情報も正式な報告書から非公式の手書きのメモに送ることができます。 人々が出すよう奨励するには、考えと考えに頭文字をつけてください。
Watson [Page 10] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[10ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
as well as those having had much thought, the question was raised as to whether of not there should be titles for different classes of documents which would help to make clear the level of informality or formality of the communication.
そこについてでないか否かに関係なく、ものが、質問がそうであると高くした状態で非常に思ったとき井戸が非公式のレベルかコミュニケーションの堅苦しさを明らかにするのを助ける異なったクラスのドキュメントのためのタイトルであるべきであるので。
There did not seem to be a need for such an arrangement. The
question of privacy and security was then raised. There was some
feeling among a few people that if letters or records of
conversations were entered in the NIC collection that there might
be compromise of some privacy. The NIC was asked if it would
check all parties involved in such a communication before entering
it in the collection. Dick felt that given NIC's resources, it
would be better if the parties involved gave their approval before
giving the letter or other communication to the NIC.
そのようなアレンジメントの必要性はあるように思えませんでした。 そして、プライバシーとセキュリティの問題は引き起こされました。 何らかの感じが会話に関する手紙か記録があるかもしれないNIC収集に入力されたなら妥協する何らかのプライバシーの数人の人々にありました。 NICはそれが収集にそれを入れる前にそのようなコミュニケーションにかかわったすべてのパーティーをチェックするかどうか尋ねられました。 ディックは、NICのリソースを考えて、手紙か他のコミュニケーションをNICに与える前にかかわったパーティーが賛意を表するならより良いと感じました。
The initial online services to be provided by the NIC are access
to a typewriter version of the SRI-ARC On-Line system (NLS),
provision of a message service, access to the NIC catalog and
probably files of site status, network personnel, etc. Services
will be provided later to aid station agents in communities at
their sites. At the principal investigators meeting there seemed
to be considerable interest in having NIC obtain a collection of
ARPA project reports and working papers. To handle storage from
such an expanded collection, user of microfilm seemed important.
There are number of problems with use of microfilm, such as a
single or limited number of readers and need for hardcopy
facilities. The NIC will be looking into these problems and begin
experimenting with use of microfilm material.
NICによって提供される初期のオンラインサービスはSRI-ARC On-回線システム(NLS)とメッセージサービスの支給とNICカタログへのアクセスとたぶんサイトステータス、ネットワーク人員などのファイルのタイプライタバージョンへのアクセスです。 後でそれらのサイトの共同体で小駅の駅長を支援するためにサービスを提供するでしょう。 実験責任者では、そこで会うのはNICにARPAプロジェクト報告と働く書類の収集を得させることへの相当な興味であるように思えました。 そのような拡張収集から格納を扱うために、マイクロフィルムのユーザは重要に見えました。 マイクロフィルムの使用に関する問題の数があります、ハードコピー施設の単一の、または、限られた数の読者や必要性のように。 NICはこれらの問題を調べて、マイクロフィルムの材料の使用を実験し始めます。
The NIC is experimenting with remote access to NLS using an IMLAC
terminal. Considerable interest in graphic access to NIC was
indicated. The NIC feels graphic access is not an immediate high
priority requirement, but will as soon as possible provide
specifications to those sites with programming resources waiting
to experiment with graphic access.
NICは、IMLAC端末を使用することで遠隔アクセスをNLSに実験しています。 NICへのグラフィックアクセスへの相当な興味は示されました。 NICはグラフィックアクセスが即座の高い優先権要件でないと感じますが、プログラミングリソースが、グラフィックアクセサリーを実験するのを待っていて、できるだけ早く、それらのサイトに仕様を提供するでしょう。
Steve Crocker brought up the problem of how people are to gain
access and learn to use service facilities at various sites. The
question of what additional information needed to be included with
or appended to user documentation to use service facilities over
the network was discussed. The question of what material should
be in hardcopy, and what online was raised. The NIC will study
these problems and produce a set of recommended procedures for
handling user manuals, and a list of information needed to enable
network access.
スティーブ・クロッカーは人々が、どうアクセスを得て、様々なサイトでサービス施設を使用することを学ぶことになっているかに関する問題を持って来ました。 どんな追加情報が、サービス施設がネットワークの上で含められているか、または使用するユーザドキュメンテーションに追加される必要があったかに関する問題について議論しました。 どんな材料の問題がハードコピーにあるべきであったか、そして、何がオンラインで上げられましたか? NICは取り扱い利用者マニュアル、およびネットワークアクセサリーを可能にするのに必要である情報のリストのためにこれらの問題を研究して、1セットのお勧めの手順を作成するでしょう。
Watson [Page 11] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[11ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
Dick Watson indicated that users of the NIC would feel most
comfortable using typewriter terminals running at 30 char/sec and
having upper and lower case graphics, although service would be
available for slower terminals and terminals with single-case
graphics. RFC #97, NIC (5740), described an initial protocol for
connection to the NIC. As a result of the formation of a
committee to produce a standard typewriter connection protocol,
the protocol of RFC #97 will be modified to conform to an interim
protocol suggested by that committee. A new RFC will be issued
shortly with the interim protocol. Since the meeting the
typewriter connection protocol committee has decided not to issue
an interim protocol.
ディック・ワトソンは、NICのユーザが30炭/秒のときに動くタイプライタ端末を使用して、大文字と小文字グラフィックスを持ちながら最も快適であると感じるのを示しました、サービスはただ一つのケースグラフィックスで、より遅い端末と端末に利用可能でしょうが。 RFC#97(NIC(5740))は接続のために初期のプロトコルについてNICに説明しました。 標準のタイプライタ接続プロトコルを作成する委員会の構成の結果、RFC#97のプロトコルは、その委員会によって提案された当座のプロトコルに従うように変更されるでしょう。 新しいRFCはすぐ当座のプロトコルで発行されるでしょう。 ミーティング以来、タイプライタ接続プロトコル委員会は、当座のプロトコルを発行しないと決めています。
The discussion turned to file transfer between sites by name and without users being required to log into each site involved in the transfer. Gary Grossman of the University of Illinois will produce an initial RFC on this subject.
議論は名前のサイトの間と、そして、転送にかかわる各サイトにログインしなければならないユーザなしでファイル転送に変わりました。 イリノイ大学のゲーリー・グロースマンはこの問題に関して初期のRFCを生産するでしょう。
Friday morning, February 19
金曜日の朝、2月19日
There are several aspects of Data Management associated with the network. The following aspects and the people responsible for them were indicated:
ネットワークに関連しているData Managementのいくつかの局面があります。 彼らに原因となる以下の局面と人々は示されました:
Data Machine 10^12 bit store
データMachine10^12の噛み付いている店
Data Management Language
データ管理言語
The Form Machine
フォームマシン
ILLIAC IV Information Management System
ILLIAC IV情報管理システム
Interim File System
当座のファイルシステム
File Transfer Protocol
ファイル転送プロトコル
The Data Machine is Computer Corporation of America's responsibility, but close coordination with the ILLIAC IV Information Management System and network efforts toward a Data Management Language is required.
Data Machineはアメリカの責任のコンピュータ社ですが、Data Management Languageに向かったILLIAC IV情報Management Systemとネットワーク取り組みがある綿密な調整が必要です。
The work on a Data Management Language is to be coordinated by J. Madden of University of Illinois, Bob Metcalfe of Harvard, J. Heafner of RAND, Jim White of UCSB, and Doug McKay of IBM.
Data Management Languageへの作業はイリノイ大学のJ.Madden、ハーバードのボブメトカルフェ、RANDのJ.Heafner、UCSBのジム・ホワイト、およびIBMのダグ・マッケイによって調整されることです。
John Heafner indicated that he plans to implement his plans for the Form Machine, RFC #83, NIC (5609) UCSB, Multics, and Lincoln Lab also indicated that they are interested in getting a version running.
ジョンHeafnerは、彼が、Form Machineのために計画を実行するのを計画しているのを示しました、RFC#83、また、NIC(5609)UCSB、Multics、およびリンカーンLabは、彼らがバージョンを稼働させたいのを示しました。
Watson [Page 12] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[12ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
A number of sites, UCLA, SRI, RAND, University of Illinois, Raytheon, MITRE, indicated interest in the range 1-3 months in storing files on UCSB 360/75 disc packs. Jim White said he would produce a system within the next 4-6 weeks to allow network users to store files at UCSB.
多くのサイト、UCLA、SRI、RAND、イリノイ大学、レイセオン(MITRE)は1-3カ月の範囲へのUCSB360/75ディスクにファイルを保管することにおける関心が荷造りするのを示しました。 ジム・ホワイトは、4-6週間以内にネットワーク利用者がUCSBにファイルを保管するのを許容するためにシステムを作成すると言いました。
The problems of file transfer by name between host systems was again raised and G. Grossman of University of Illinois indicated he would start a dialog on the subject by producing an RFC.
ホストシステムの間の名前のファイル転送の問題は再び提起されました、そして、イリノイ大学のG.グロースマンは彼がRFCを生産することによって対話を話題に始めるのを示しました。
The question of user names and the meaning of user IDs in socket numbers was raised. At present socket numbers have no structure, but several people felt that for accounting, file transfer, and interprocess communication some structure was probably valuable. A committee consisting of:
ユーザ名の問題とソケット番号におけるユーザIDの意味は引き起こされました。 現在のところ、ソケット番号は骨格がありませんでしたが、数人は、或るものが構造化する会計、ファイル転送、およびプロセス間通信のためのそれがたぶん貴重であると感じました。 以下から成る委員会
J. Heafner, RAND (chairman)
J.Heafner、底ならし革(議長)
E. Meyer, MIT-Multics
E.マイヤー、MIT-Multics
G. Grossman, University of Illinois
G.グロースマン、イリノイ大学
will produce an RFC stating the issues behind alternate proposals for socket number structures.
ソケット数の構造のための代替の提案の後ろに問題を述べるRFCを生産するでしょう。
UCLA indicated it wanted a link number in the experimental range of link numbers for use in measurements experiments with the network. Link number 223 was assigned to this function. (Link 223 was later discovered to be assigned. Link 191 was chosen instead. See RFC #104, NIC (5768,).
UCLAは、実験範囲のリンク番号における、ネットワークによる測定値実験における使用のリンク番号が欲しかったのを示しました。 リンク番号223はこの機能に割り当てられました。 後でリンク223が割り当てられると発見されました。リンク191は代わりに選ばれました。(NIC、RFC#104を見てください(5768)。
The problem of accounting was raised as a number of machine or systems on the network will provide service functions. The present service facilities being the 360/91 at UCLA, the 360/75 at UCSB, the NIC at SRI, Multics at MIT, the ILLIAC IV, the 360/67 at Lincoln Lab, and the Data Machine. The advanced Host-Host protocol study committee is looking at the accounting problem. There was brief mention made of a network banking system. Bob Kahn of BBN indicated that he would start a dialog on the subject of accounting by producing a paper putting down the issues as he sees them.
ネットワークの多くのマシンかシステムがサービス機能を提供するのに従って、会計の問題は提起されました。 UCLAの360/91と、UCSBの360/75と、SRIのNICと、MITのMulticsと、ILLIAC IVと、リンカーンLabの360/67と、Data Machineである現在のサービス施設。 高度なHost-ホストプロトコル研究委員会は会計問題を見ています。 ネットワークバンキングシステムでされた簡潔な言及がありました。 BBNのボブ・カーンは、論文を製作するのによる会計に関する話題の上の対話がそれらを見るので彼が問題をこき下ろし始めるのを示しました。
The question was then raised about handling of administrative procedures such as obtaining accounting numbers on foreign systems. Dick Watson said he would look into this problem and see how the NIC can help in its solution.
次に、疑問は外国システムの上のアカウント番号を得などなどの行政手続の取り扱いに関して引き起こされました。ディック・ワトソンは、彼がこの問題を調べて、NICが解決でどう助けることができるかを見ると言いました。
Watson [Page 13] RFC 101 NOTES ON THE NETWORK WORKING GROUP MEETING February 1971
ワトソン[13ページ]RFC101はミーティング1971年2月にネットワークで作業部会に注意します。
The final question to be considered was the frequency and utility of these NWG meetings. The general consensus was that this had been a useful meeting, but that more preparation on specific topics to be discussed at the meeting should be done ahead of time. People who want to bring up topics at the meeting were asked to distribute position or introductory papers about a month ahead of the next meeting, if possible. Peggy Karp will handle trying to obtain a block of rooms for the NWG during the Spring Joint. She will send out a request for reservations to the sites soon.
考えられる最終的な質問は、これらのNWGミーティングに関する頻度とユーティリティでした。 全体的な合意はこれが役に立つミーティングであったのにもかかわらずの、早めにミーティングで議論されるべき特定の話題におけるより多くの準備をするべきであるということでした。 ミーティングで話題を持って来たがっている人々が次のミーティングのおよそ1カ月前に位置か紹介している書類を配布するように頼まれました、できれば。 ペギー・カープはNWGのためにSpring Jointの間、1棟の部屋を入手するトライを扱うでしょう。 彼女はすぐ、予約を求める要求をサイトに出すでしょう。
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Kelly Tardif, Viag駭ie 10/99]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ケリーTardifによるオンラインRFCアーカイブへのViag駭ie10/99]
Watson [Page 14]
ワトソン[14ページ]
一覧
スポンサーリンク
