RFC1207 日本語訳
1207 FYI on Questions and Answers: Answers to commonly asked"experienced Internet user" questions. G.S. Malkin, A.N. Marine, J.K.Reynolds. February 1991. (Format: TXT=33385 bytes) (Also FYI0007) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Malkin
Request for Comments: 1207 FTP Software, Inc.
FYI: 7 A. Marine
SRI
J. Reynolds
ISI
February 1991
コメントを求めるワーキンググループG.マルキンの要求をネットワークでつないでください: 1207FTPソフトウェアInc.FYI: 7 海洋のA.の様のJ.レイノルズISI1991年2月
FYI on Questions and Answers
Answers to Commonly asked "Experienced Internet User" Questions
「経験豊富なインターネットユーザ」Questionsが尋ねられたCommonlyへのQuestionsとAnswers Answersの上のFYI
Status of this Memo
このMemoの状態
This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet.
このFYI RFCはFYIが呼んだ2の1つと、「質問と答え」です。(User Servicesインターネット・エンジニアリング・タスク・フォース作業部会(IETF)によって生産されたQ/a)。 目標はインターネットに最も一般的に尋ねられた質問と答を記録することです。
This memo provides information for the Internet community. It does not specify any standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな規格も指定しません。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction.................................................. 1
2. Acknowledgements.............................................. 3
3. Questions about the Internet.................................. 3
4. Questions About Other Networks and Internets.................. 3
5. Questions About Internet Documentation........................ 4
6. Questions About the Domain Name System (DNS).................. 4
7. Questions About Network Management............................ 7
8. Questions about Serial Line Internet Protocol (SLIP) and
Point-to-Point Protocol (PPP) Implementations................. 9
9. Questions About Routing....................................... 11
10. Other Protocol and Standards Implementation Questions........ 11
11. Suggested Reading............................................ 12
12. References................................................... 13
13. Security Considerations...................................... 14
14. Authors' Addresses........................................... 15
1. 序論… 1 2. 承認… 3 3. インターネットに関する質問… 3 4. 他のネットワークとインターネットに関する質問… 3 5. インターネットドキュメンテーションに関する質問… 4 6. ドメインネームシステム(DNS)に関する質問… 4 7. ネットワークマネージメントに関する質問… 7 8. シリアル回線インターネット・プロトコル(メモ用紙)に関する質問とポイントツーポイントは(ppp)実装について議定書の中で述べます… 9 9. ルート設定に関する質問… 11 10. 他のプロトコルと規格実装質問… 11 11. 読むのを示します… 12 12. 参照… 13 13. セキュリティ問題… 14 14. 作者のアドレス… 15
1. Introduction
1. 序論
During the last few months, several people have monitored various major mailing lists and have extracted questions that are important or commonly asked. This FYI RFC is one of two in a series of FYI's which present the questions and their answers. The first FYI, FYI 4, presented questions new Internet users commonly ask and their answers.
ここ数カ月、数人は、様々な主要なメーリングリストをモニターして、重要な質問を抜粋するか、または一般的に尋ねました。 このFYI RFCは質問と彼らの答えを提示するFYIのもののシリーズにおける2の1つです。 最初のFYI(FYI4)は新しいインターネットユーザが一般的に尋ねるという質問と彼らの答えを提示しました。
User Services Working Group [Page 1] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[1ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
The goal of this FYI is to codify the Internet lore so that network operations staff, especially for networks just joining the Internet, will have an accurate and up to date set of references from which to work. Also, redundancies are moved away from the electronic mailing lists so that the lists' subscribers do not have to read the same queries and answers over and over again.
このFYIの目標がインターネット口碑を成文化することであるので、そのネットワーク操作スタッフには、特にただインターネットに合流するネットワークのために、働いている正確で最新の参照があるでしょう。 また、冗長がメーリング・リストから遠くに動かされるので、リストの加入者は同じ質問と答えを幾重にも読む必要はありません。
Although the questions and their responses are taken from various mailing lists, they are presented here loosely grouped by related topic for ease of reading. First the question is presented, then the answer (or answers) as it appeared on the mailing list.
質問と彼らの応答は様々なメーリングリストから抜粋されますが、それらはここに読書する容易さのために関連した話題によって緩く分類されていた状態で提示されます。 まず最初に、質問は提示されて、次に、それとしての答え(または、答え)はメーリングリストに現れました。
Sometimes the answers are abridged for better use of space. If a question was not answered on the mailing list, the editors provide an answer. These answers are not distinguished from the answers found on the lists. Sometimes, in order to be as complete as possible, the editors provide additional information that was not present in the original answer. If so, that information falls under the heading "Additional Information".
時々、答えは、より良い宇宙利用のために要約されます。 質問がメーリングリストで答えられなかったなら、エディタは答えを提供します。 これらの答えはリストで見つけられた答えと区別されません。 時々、エディタは、できるだけ完全になるように存在していない追加情報をオリジナルの答えに提供します。 そうだとすれば、その情報は「追加情報」の見出しで下がります。
The answers are as correct as the reviewers can make them. However, much of this information changes with time. As the FYI is updated, temporal errors will be corrected.
答えは評論家が彼らを作ることができるのと同じくらい正しいです。 しかしながら、この情報の多くが時間を交換します。 FYIをアップデートするとき、時の誤りを修正するでしょう。
Many of the questions are in first person, and the answers were directed to the originator of the question. These phrasings have not been changed except where necessary for clarity. References to the correspondents' names have been removed.
質問の多くが最初に、人にありました、そして、答えは質問の創始者に向けられました。 明快に必要であるところ以外に、これらの言い回しは変えられていません。 通信員の名前の参照を取り除いてあります。
The Q/A mailing lists are maintained by Gary Malkin at FTP.COM. They are used by a subgroup of the User Services Working Group to discuss the Q/A FYIs. They include:
Q/AメーリングリストはFTP.COMでゲーリー・マルキンによって維持されます。 それらは、Q/A FYIsについて議論するのにUser Services作業部会のサブグループによって使用されます。 それらは:
quail@ftp.com This is a discussion mailing list. Its
primary use is for pre-release review of
the Q/A FYIs.
quail@ftp.com 、これは議論メーリングリストです。 プライマリ使用はQ/A FYIsのプレリリースレビューのためのものです。
quail-request@ftp.com This is how you join the quail mailing list.
あなたがうずらのメーリングリストに加わる quail-request@ftp.com 。
quail-box@ftp.com This is where the questions and answers
will be forwarded-and-stored. It is
not necessary to be on the quail mailing
list to forward to the quail-box.
質問と答が進められて保存するようになる quail-box@ftp.com 。 うずら箱に転送するうずらのメーリングリストにあるのは必要ではありません。
User Services Working Group [Page 2] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[2ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
2. Acknowledgments
2. 承認
The following people deserve thanks for their help and contributions to this FYI Q/A: Jim Conklin (EDUCOM), John C. Klensin (MIT), Professor Kynikos (Special Consultant), Jon Postel (ISI), Marshall Rose (PSI, Inc.), David Sitman (Tel Aviv University), Patricia Smith (Merit), Gene Spafford (Purdue), and James Van Bokkelen (FTP Software, Inc.).
以下の人々は彼らのお力添えの感謝とこのFYI Q/A:への貢献に値します。 ジム・コンクリン(EDUCOM)、ジョンC.Klensin(MIT)、Kynikos(特別なコンサルタント)(ジョン・ポステル(ISI))のマーシャル・ローズ(ψInc.)、デヴィッドSitman(テルアビブ大学)、パトリシア・スミス(長所)、遺伝子Spafford(パドゥー)、およびジェームス教授はBokkelen(FTPソフトウェアInc.)をバンに積みます。
3. Questions about the Internet
3. インターネットに関する問題
3.1. How do I get statistics regarding the traffic on NSFNET?
3.1. 私はどのようにトラフィックに関する統計をNSFNETに乗せますか?
Merit/NSFNET Information Services maintains a variety of
statistical data at 'nis.nsf.net' (35.1.1.48) in the 'stats'
directory. Information includes packet counts by NSS and byte
counts for type of use (ftp, smtp, telnet, etc.). Filenames are
of the form 'NSFyy-mm.type'.
長所/NSFNET情報Servicesが'nis.nsf.net'のさまざまな統計データを維持する、(35.1 .1 .48) '統計'ディレクトリで。 情報は使用(ftp、smtp、telnetなど)のタイプのためのNSSとバイト・カウントでパケットカウントを含んでいます。 ファイル名はフォーム'NSFyy-mm.type'のものです。
Files are available for anonymous ftp; use 'guest' as the
password.
ファイルはアノニマスFTPに利用可能です。 パスワードとして'ゲスト'を使用してください。
The data in these files represent only traffic which traverses the
highest level of the NSFNET, not traffic within a campus or
regional network. Send questions/comments to nsfnet-
info@merit.edu.
これらのファイルのデータはキャンパスか地域ネットワークの中でトラフィックではなく、NSFNETの最高水準を横断するトラフィックだけを表します。 質問/コメントをnsfnet info@merit.edu に送ってください。
4. Questions About Other Networks and Internets
4. 他のネットワークとインターネットに関する問題
4.1. We have a user who would like to access a machine on
"EARN/BITNET". I can't find anything on this in the domain
name tables. Please, what is this, and how do I connect to it?
4.1. 私たちには、「/Bitnetを稼いでください」でマシンにアクセスしたがっているユーザがいます。 私はドメイン名テーブルでこれで何も見つけることができません。 これは何をお願いします、そして、私はどのようにそれに接続しますか?
There are several machines on the Internet that act as gateways
between the Internet and BITNET. Two examples are UICVM.UIC.EDU
and CUNYVM.CUNY.EDU. You can address a mail message to
user%nodename.bitnet@uicvm.uic.edu where the message will be
passed from the Internet to BITNET.
インターネットとBitnetの間には、インターネットのゲートウェイとして作動する数台のマシンがあります。 2つの例が、UICVM.UIC.EDUとCUNYVM.CUNY.EDUです。 あなたはメッセージがインターネットからBitnetまで通過される user%nodename.bitnet@uicvm.uic.edu にメール・メッセージを扱うことができます。
Additional Information:
追加情報:
These same gateways, known as INTERBIT on the BITNET/EARN side,
transfer mail from computers on that network which support SMTP
mail headers, onto the Internet. (Many BITNET/EARN computers
still do not support SMTP, which is not a part of the IBM
protocol used, and it is not possible to send mail from those
computers across the gateways into the Internet, in general.)
Bitnet/EARN側の上のINTERBITとして知られているこれらの同じゲートウェイはそのネットワークのSMTPにメールヘッダをサポートするコンピュータからメールを移します、インターネットに。 (多くのBitnet/EARNコンピュータはまだ使用されるIBMプロトコルの一部でないSMTPをサポートしていなくて、また一般に、ゲートウェイの向こう側にメールをそれらのコンピュータからインターネットに送るのは可能ではありません。)
User Services Working Group [Page 3] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[3ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
BITNET and EARN are the two largest of several cooperating
networks which use the IBM RSCS/NJE protocol suite, but are not
limited to IBM systems. These independently administered,
interconnected networks function as a single, worldwide network
directly connecting more than 3,300 computers in about 1,400,
mostly higher-education, organizations worldwide. This
worldwide network supports electronic mail, including mailing
lists, sender-initiated file transfer, and short "interactive"
messages.
BitnetとEARNは2歳です。いくつかのIBM RSCS/NJEプロトコル群を使用しますが、IBMシステムに制限されない中で最も大きい協力ネットワーク独自に管理されたこれら、相互接続ネットワークはおよそ1,400で直接3,300台以上のコンピュータを接続しながら、単一の、そして、世界的なネットワークとして機能します、ほとんど高等教育、世界中の組織。 この世界規模のネットワークはメーリングリスト、送付者によって開始されたファイル転送、および短い「対話的な」メッセージを含む電子メールをサポートします。
BITNET, frequently used (outside of Europe) to refer to the
whole worldwide network, technically refers to that portion in
the United States, plus sites in other countries which are
connected through the United States and do not have their own
separately administered cooperating networks. More than 550
organizations in the U.S. participate in BITNET.
全体の世界規模のネットワークを示すのに頻繁に使用される(ヨーロッパの外)Bitnetは合衆国でその部分について技術的に言及します、そして、合衆国を通って接続されて、別々にそれら自身のを持っていない他国におけるサイトは協力ネットワークを管理しました。 米国での550以上の組織がBitnetに参加します。
EARN is the European Academic Research Network. EARN links
more than 500 institutions in Europe and several surrounding
countries.
EARNはヨーロッパのAcademic Research Networkです。 EARNはヨーロッパといくつかの周囲の国の500以上の団体をリンクします。
BITNET and CSNET merged organizationally on October 1, 1990, to
form CREN, the Corporation for Research and Educational
Networking. The two networks remain separate at the
operational level level, however. (EARN and the other
Cooperating Networks were not involved in this merger.)
BitnetとCSNETはフォームCRENへの1990年10月1日、Researchのための社、およびEducational Networkingで組織的で合併しました。 しかしながら、2つのネットワークが業務計画レベルレベルで別々のままで残っています。(EARNと他のCooperating Networksはこの合併にかかわりませんでした。)
5. Questions About Internet Documentation
5. インターネットドキュメンテーションに関する問題
5.1. Where do I get information regarding ordering documents
related to GOSIP?
5.1. どこで、私はGOSIPにドキュメントに関連するよう命令することの情報を得ますか?
The complete information as issued by NIST is available online on
the NIC.DDN.MIL host as PROTOCOLS:GOSIP-ORDER-INFO.TXT. The file
contains pointers to contact people, ordering addresses, prices,
and, in some cases, online pathnames, for various GOSIP related
documents. In addition, the information as of August 1990 was
published as an appendix to RFC 1169, "Explaining the Role of
GOSIP" [1].
NISTによって発行される完全な情報はプロトコルとしてNIC.DDN.MILホストでオンラインで利用可能です: GOSIP-ORDER-INFO.TXT。 ファイルは接触の人々に指針を含んでいます、アドレス、価格、およびいくつかの場合オンラインパス名を注文して、様々なGOSIP関連するドキュメントのために。 さらに、1990年8月現在情報は付録としてRFC1169(「GOSIPについて役割について説明する」[1])に発表されました。
6. Questions About Domain Name System (DNS)
6. ドメインネームシステムに関する問題(DNS)
6.1. Is there a DNS Query server?
6.1. DNS Queryサーバがありますか?
Actually, what you are looking for is the service that host
128.218.1.109 provides on port 5555 - you simply connect to that
host at that port, type in a fully qualified domain name and it
responds with an internet address and closes the connection. I
実際に、あなたが探しているものがそれが主催するサービスである、128.218、.1、.109、提供する、5555を移植してください--あなたが単におまけにそのホストにポート、完全修飾ドメイン名のタイプに接して、それは、インターネットアドレスで応じて、接続を終えます。 I
User Services Working Group [Page 4] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[4ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
used it when I had a host that still only had /etc/hosts and it
did just what I needed - which was basically a manual nslookup.
私にはまだ/etc/hostsを持っていただけであるホストがいて、ちょうど私が必要としたこと(基本的に手動のnslookupであった)をしたとき、それを使用しました。
However, the vast majority of users will find it simpler to just
use a DNS query tool and ask the DNS directly. This doesn't
require much sophistication, and does allow the user to see how
short names are expanded at the user's site rather than at
128.218.1.109 (wherever that is). For example, suppose a user
wants to find out the address of a fully-qualified domain name
"X.MISKATONIC.EDU", and also see what host and address are used
when "Z" is typed as a host name.
しかしながら、かなりの大多数のユーザは、ただDNS質問ツールを使用して、直接DNSに尋ねるのが、より簡単であることがわかるでしょう。 これは、多くの洗練を必要としないで、ユーザが、省略名が128.218でというよりむしろユーザのサイトでどのように広げられるかを見るのを許容します。.1 .109 (それがいるどこ。) 例えば、ユーザが「X.MISKATONIC.EDU」という完全修飾ドメイン名のアドレスを見つけたがっていると仮定してください、そして、また、「Z」がホスト名としてタイプされるとき、どんなホストとアドレスが使用されているかを見てください。
Assuming the user is on a UNIX host and has a copy of the dig
program, type:
ユーザがUNIXホストの上にいて、皮肉プログラムのコピーを持っていると仮定して、タイプしてください:
dig x.miskatonic.edu
and
dig z
x.miskatonic.eduを掘ってください、そして、zを掘ってください。
and the answers will appear. You are now on your way to
becoming a DNS expert. There are other UNIX alternatives,
e.g., nslookup, and similar programs for non-UNIX systems.
Your local DNS guru certainly has one or more of these tools,
and although they are often kept from the public, they are
really quite easy to use for simple cases.
そして、答えは現れるでしょう。 あなたは現在、DNS専門家になるのに行く途中です。 非UNIXシステムのための例えば他のUNIX代替手段、nslookup、および同様のプログラムがあります。地元のDNS導師には、確かに、これらのツールの1つ以上があります、そして、公衆からしばしば妨げられますが、それらは簡単なケースに本当にかなり使用しやすいです。
6.2. We have been having a frequent BIND failure on both our VAX
and Solbourne that is traced to TCP domain queries from an
IBM NSMAIN nameserver running in cache mode (UDP queries do
not cause this problem, though it is usually a UDP
resolution that is active upon the crash -- this resolution
is an innocent victim).
6.2. 私たちは、キャッシュモードへ駆け込みながら、私たちのVAXとIBM NSMAINネームサーバからTCPドメイン質問にたどられるSolbourneの両方に頻繁なBINDの故障を持っています(UDP質問はこの問題を引き起こしません、それが通常クラッシュで活発なUDP解決であるのにもかかわらずの--この解決は罪のない犠牲者です)。
I have discovered that something is trashing the hash areas
(sometimes even as it is being recursively used in a
resolution). Also, occasionally the socket/file descriptor
for the TCP connection is changed to invalid entries causing
a reply write fail (though this is not necessarily fatal,
and the rest of the structure is not apparently altered).
私は、何かがハッシュ領域を破壊していると発見しました(それが解決に時々再帰的に使用されているときさえ)。 また、TCP接続が回答を引き起こすと書かれる無効のエントリーに変わるので、時折ソケット/ファイルディスクリプタは失敗します(これが必ず致命的であるというわけではありません、そして、構造の残りは明らかに変えられませんが)。
Has any one else had frequent BIND failures (especially
major domain sites that have heavy TCP domain loads)?
ほかの何かには、頻繁なBINDの故障(重いTCP藩主を持っている特に主要なドメインサイト)がありましたか?
In both the case of BIND and the IBM implementation, often called
FAL, there are multiple versions, with older versions being truly
bad. Upgrade to recent version before exploring further.
FALは、しばしば複数のバージョンがBINDに関するケースとIBM実装の両方にあると呼びました、本当に、旧式のバージョンが悪い状態で。 さらに探検する前に、最近のバージョンにアップグレードしてください。
BIND has always had a problem with polluting its own database.
BINDには、それ自身のデータベースを堕落することに関する問題がいつもありました。
User Services Working Group [Page 5] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[5ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
These problems have been related to TCP connections, NS RRs with
small TTLs, and several other causes. Experience suggests that
the style of bug fixing has often been that of reducing the
problem by 90% rather than eliminating it.
これらの問題はTCP接続、小さいTTLsとNS RRs、および他のいくつかの原因に関連しました。 経験は、誤り訂正のスタイルがしばしばそれを排除するより問題を90%むしろ減少させるものであると示唆します。
IBM's support for the DNS (outside of UNIX systems) is interesting
in its techniques, encouraging in its improvement, but still
somewhat depressing when compared to most other DNS software. IBM
also uses terminology that varies somewhat from the usual DNS
usage and preserves some archaic syntax, e.g., "..".
他のほとんどのDNSソフトウェアと比べると、IBMのDNS(UNIXシステムの外部)のサポートは、テクニックでおもしろくて、改善で励みになりますが、まだいくらか陰うつです。 「IBMは、また、普通のDNS用法からいくらか変わる用語を使用して、例えば何らかの古風な構文を保存する」、」
The combination of an old BIND and an old IBM server is just plain
unpleasant.
古いBINDと古いIBMサーバの組み合わせはただ不快な状態で明瞭です。
6.3. Is the model used by the domain name system for host names
that the owner of a name gets to choose its case?
6.3. モデルは名前の所有者がケースを選ばせるホスト名のドメイン名システムによって使用されますか?
The model used by the DNS is that you get to control at a specific
point in the name space, and are hence free to select case as you
choose, until points where you in turn give away control. As a
practical matter, there are several implementations that don't do
the right thing. IBM implementations often map everything into a
single case.
DNSによって使用されたモデルはあなたが特定のポイントでスペースという名前でコントロールを始めて、したがって、選ぶように自由にケースを選択できるということです、あなたが順番に遠くに与えるところでポイントが制御されるまで。 実際問題として、正しいことをしないいくつかの実装があります。 IBM実装はしばしばただ一つのケースの中にすべてを写像します。
6.4. According to RFC 1034 [2], section 4.2.1, one should not have
to code glue RR's for name server's names unless they are below
the cut. When I don't put glue RR's in, and do a query for
NS records, the "additional" field is left blank. As far as I
can tell, all other zones I query for NS records have this
filled with the IP addresses of the NS hosts. Is this required
or should I not be concerned that the additional field is empty?
6.4. RFC1034[2]によると、それらがカットの下にない場合、セクション4.2.1、ネームサーバの名前のために接着剤RRのものをコード化する必要はないはずです。 私が接着剤RRのものを入れて、NS記録のために質問しないと、「追加している」野原は空白のままにされます。 私が判断できる限り、私がNS記録のために質問する他のすべてのゾーンはNSホストのIPアドレスでこれを満たします。 これは必要でないべきですかそれとも、私が追加分野が人影がないことを心配しないべきですか?
The protocol says that an empty additional field is not a problem
when the name server's name is not "below" the cut.
プロトコルは、人影のない追加分野がネームサーバの名前が“below"でない問題でないと言います。カット。
In practice, putting in the glue where it is not required can
cause problems if the servers named in the glue are used for
several zones. This is broken behavior in BIND. Not putting in
glue can cause other problems in BIND, usually when the server
name is difficult to resolve. So, the bottom line is to put glue
in only when required, and don't use aliases or anything else
tricky when it comes to identifying name servers.
実際には、接着剤で指定されたサーバがいくつかのゾーンに使用されるなら、それは必要でない接着剤を入れるのが問題を起こすことができます。 これはBINDの中断した振舞いです。 通常、サーバー名は決議するのが難しいときに、接着剤を入れないと、BINDの他の問題が引き起こされる場合があります。 それで、ネームサーバを特定することとなると、結論は、必要である場合にだけ接着剤を入れて、別名か扱いにくい他の何も使用しないことです。
User Services Working Group [Page 6] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[6ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
7. Questions About Network Management Implementations
7. ネットワークマネージメント実装に関する問題
7.1. In reading the SNMP RFCs [3,4,5,6] I find mention of
authentication of PDUs. Are there any standards for
authentication mechanisms?
7.1. SNMP RFCs[3、4、5、6]を読む際に、私はPDUsの認証の言及を見つけます。 何か認証機構の規格がありますか?
There is a working group of the IETF that is working on this
problem. They are close to a solution, but nothing has yet
reached RFC publication yet. Expect something solid and
implementable by October of 1991.
この問題に取り組んでいるIETFのワーキンググループがあります。 彼らはソリューションの近くにいますが、何もまだまだRFC公表に達していません。 1991年10月までに固体であって何か実装可能なものを予想してください。
7.2. Can vendors make their enterprise-specific variables available
to users through a standard distribution mechanism?
7.2. ベンダーはそれらの企業特有の変数を標準分布メカニズムを通してユーザにとって利用可能にすることができますか?
Yes. But before someone submits a MIB, they should check it out
themselves.
はい。 しかし、だれかがMIBを提出する前に彼らは自分たちでそれを調べるべきです。
On uu.psi.com in pilot/snmp-wg/, there are two files
pilot/snmp-wg/のuu.psi.comに、2個のファイルがあります。
mosy-sparc-4.0.3.c
mosy-sparc-4.0.3.c
mosy-sun3-3.5
mosy-sun3-3.5
The first will run on a Sun-Sparc, the second will run on a Sun-3.
After retrieving one of these files in BINARY mode via anonymous FTP,
the submittor can run their MIB through it, e.g.,
2番目は、Sun-3に1番目がSun-Sparcの上で作業すると述べるでしょう。 公開FTPでBINARYモードによるこれらのファイルの1つを検索した後に、submittorは例えばそれを通してそれらのMIBを実行できます。
% mosy mymib.my
%mosy mymib.my
Once your MIB passes, send it to:
MIBがいったん通る後、以下のことのためにそれを送ってください。
mib-checker@isi.edu
mib-checker@isi.edu
If everything is OK, the mib-checker will arrange to have it
installed in the /share/ftp/mib directory on venera.isi.edu.
すべてがOKであるなら、mib-市松模様は、venera.isi.eduの上の/share/ftp/mibディレクトリにそれをインストールさせるように手配するでしょう。
Note: This processing does not offer an official endorsement. The
documents submitted must not be marked proprietary, confidential,
or the like.
以下に注意してください。 この処理は公式の裏書きを提供しません。 独占であって、秘密であると提出されたドキュメントにマークしてはいけない、または、同様のもの。
7.3. I have a question regarding those pesky octet strings again.
I use the variable-type field of the Response pdu to determine
how the result should be displayed to the user. For example,
I convert NetworkAddresses to their dotted decimal format
("132.243.50.4"). I convert Object Identifiers into strings
("1.3.6.1.2....").
7.3. 私には、それらのやっかいな八重奏ストリングに関する質問が再びあります。 私は、結果がどのようにユーザに表示されるべきであるかを決定するのにResponse pduの可変タイプ分野を使用します。 例えば、私が彼らのドット付き10進法形式にNetworkAddressesを変換する、(「132.243 .50 0.4インチ)、」 私がObject Identifiersをストリングに変換する、(「1.3、.6、.1、.2インチ)
I would LIKE to just print Octet Strings as strings. But,
私はまさしくストリングとしての印刷Octet StringsへのLIKEがそうするでしょう。 しかし
User Services Working Group [Page 7] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[7ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
this causes a problem in such cases as atPhysAddress in
which the Octet string contains the 6 byte address instead
of a printable ASCII string. In this case, I would want to
display the 6 bytes instead of just trying to print the
string.
これはOctetストリングが印刷可能なASCIIストリングの代わりに6バイト・アドレスを含むatPhysAddressのような場合における問題を引き起こします。 この場合、ただストリングを印刷しようとすることの代わりに6バイト表示したいと思うでしょう。
MY QUESTION IS: Does anyone have a suggestion as to how I
can determine whether I can just print the string or whether
I should display the octet bytes. * Remember: I want to
support enterprise specific variables too.
私の質問は以下の通りです。 だれかに、八重奏バイトが私が、ただストリングを印刷できるかどうかとどうしたら決心できるか、そして、または私が決心するべきであるかどうかに表示しているように提案がありますか? * 覚えています: 企業の特定の変数もサポートしたいと思います。
In general, there is no way that you can tell what is inside an
OCTET STRING without knowing something about the object that the
OCTET STRING comes from. In MIB-II [6], some objects are marked
as DisplayString which has the syntax of OCTET STRING but is
restricted to characters from the NVT ASCII character set (see the
TELNET Specification, RFC 854 [7], for further information).
These objects are:
一般に、あなたがOCTET STRINGの中に何がOCTET STRINGが来るオブジェクトに関して何かを知らないであるかを言うことができる方法が全くありません。 MIB-II[6]では、いくつかのオブジェクトがOCTET STRINGの構文を持っていますが、NVT ASCII文字の組からキャラクタに制限されるDisplayStringとしてマークされます(TELNET Specificationを見てください、RFC854[7]、詳細のために)。 これらのオブジェクトは以下の通りです。
sysDescr
sysContact
sysName
sysLocation
ifDescr
sysDescr sysContact sysName sysLocation ifDescr
If you want to be able to arbitrarily decide how to display the
strings, without knowing anything about the object, then you can
scan the octets, looking for any octet which is not printable
ASCII. If you find at least one, you can print the entire string,
octet by octet, in "%02x:" notation. If all of the octets are
printable ASCII, then you can just printf the string.
任意にストリングを表示する方法を決めることができるようになりたがっているなら、オブジェクトに関して何も知らないで、あなたは八重奏をスキャンできます、印刷可能なASCIIでないどんな八重奏も探して。 「少なくとも1つを見つけるなら、あなたは八重奏で」 %02xに全体のストリング、八重奏を印刷できます」 記法。 八重奏のすべてが印刷可能なASCIIであるなら、あなたはただストリングをprintfすることができます。
7.4. If archived MIBs must be 1155-compatible [3], it would be nice
if those who submit them check them first. Where are these
MIB tools available for public FTP? Ideally, a simple
syntax checker (that didn't actually generate code) would be
nice.
7.4. 格納されたMIBsが1155コンパチブル[3]であるに違いないなら、彼らを提出する人が最初に彼らをチェックするなら、良いでしょう。 どこで、これらのMIBツールは公共のFTPに入手できますか? 理想的に、簡単なシンタクスチェッカ(それは実際にコードを生成しなかった)は良いでしょう。
In the ISODE 6.0 release there is a tool called MOSY which
recognizes the 1155 syntax and produces a flat ASCII file. If you
can run it through MOSY without problems then you are OK.
ISODE6.0リリースには、1155年の構文を認識して、平坦なASCIIファイルを作り出すMOSYと呼ばれるツールがあります。 MOSYを通して問題なしでそれを実行できるなら、あなたはOKです。
7.5. Suppose I want to create a private MIB object for causing
some action to happen, say, do a reset. Should the syntax
or this object specify a value such as:
7.5. 何らかの動作が起こることを引き起こすために個人的なMIBオブジェクトを作成したいと思うと仮定してください、そして、たとえば、リセットしてください。 構文かこのオブジェクトが以下などの値を指定するはずですか?
User Services Working Group [Page 8] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[8ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
Syntax:
INTEGER {
perform reset (1),
}
構文: 整数リセット(1)を実行してください。
even though there is only a single value? Or, is it ok to
just allow a Set on this object with any value to perform
the desired action? If the later, how is this specified?
ただ一つの値しかありませんが? または、何か値があるこのオブジェクトの上のSetが必要な動作を実行するのをただ許容するのは間違いありませんか? より遅れているなら、これはどのように指定されますか?
For our SNMP manageable gizmos and doohickies with similar
"action" type MIB variables, I've defined two values
同様の「動作」タイプMIB変数がある私たちのSNMPの処理しやすい機械装置と道具のために、私は2つの値を定義しました。
Syntax:
INTEGER {
reset(1)
not-reset(2)
}
構文: 整数リセット(1)リセット(2)でない
And defined behavior so that the only valid value that the
variable may be set to is "reset" (which is returned in the get
response PDU) and at all other times a get/getnext will respond
with "not-reset".
応答を得てください。変数が設定しているかもしれない唯一の有効値が「リセットされる」ように振舞いを定義する、(どれに戻るか、PDU) そして、全く他の回aがgetnextが「リセットでない」で反応させる/を得る。
8. Questions about Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) Implementations
8. シリアル回線インターネット・プロトコル(メモ用紙)と二地点間プロトコル(ppp)実装に関する問題
8.1. I seem to recall hearing that SLIP [8] will only run on
synchronous serial lines. Is this true? ... is there
something about SLIP which precludes it's being implemented
over async lines?
8.1. 私は、SLIP[8]が同期シリアル・ラインで動くだけであると聞いたと思い出すように思えます。 これは本当ですか? … それのものを排除するSLIPに関する何かが、async系列の上で実装されながら、ありますか?
Other way around: SLIP is designed for async lines and is not a
good fit on sync lines. PPP [9, 10] works on either, and is what
you should be implementing if you're implementing something.
以下の周りの他の道 SLIPはasync系列のために設計されていて、同時性系列における良いフィットではありません。 PPP[9、10]はどちらかに働いて、あなたが何かを実装しているなら、あなたが実装するべきであることです。
8.2. Since we are very interested in standards in this area,
could someone tell me were I can find more information on PPP?
8.2. だれかが、I缶の掘り出し物がPPPに関する詳しい情報であるなら以来私たちはこの領域の規格に非常に関心があると私に言うことができるでしょうか?
Also, can this protocol be used in other fields than for the
Internet (i.e., telecontrol, telemetering) where we see a
profusion of proprietary incompatible and hard to maintain
Point-to-Point Protocols?
また、私たちが独占の大量が両立しなくて、Pointからポイントへのプロトコルを維持しにくいのを見るインターネット(すなわち、遠隔操作、遠方測定)以外の分野でこのプロトコルを使用できますか?
PPP was designed to be useful for many protocols besides just IP.
Whether it would be useful for your particular application should
probably be discussed with the IETF's Point-to-Point Protocol
Working Group discussion list. For general discussion: ietf-
ppp@ucdavis.edu. To subscribe: ietf-ppp-request@ucdavis.edu
PPPは、まさしくIP以外に多くのプロトコルの役に立つように設計されました。 たぶんPointからポイントへのプロトコル作業部会議論IETFのリストとそれがあなたの特定用途の役に立つだろうかどうか議論するべきです。 一般的な議論のために: ietf ppp@ucdavis.edu 。 申し込むために: ietf-ppp-request@ucdavis.edu
User Services Working Group [Page 9] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[9ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
The PPP specification is available as RFC 1171 [9], and a PPP
options specification is available as RFC 1172 [10].
PPP仕様はRFC1171[9]として利用可能です、そして、PPPオプション仕様はRFC1172[10]として利用可能です。
In UnixWorld of April 1990 (Vol. VII, No. 4, Pg. 85), Howard
Baldwin writes:
1990年4月のUnixWorldで(いいえ、Vol.VII、4、Pg。 85), ハワード・ボールドウィンは書きます:
"Point-to-Point Protocol (PPP) has just been submitted to the
CCITT from the Internet Engineering Task Force. It specifies a
standard for encapsulating Internet Protocol data and other
network layer (level three on ISO's OSI Model) protocol
information over point-to-point links; it also provides ways to
test and configure lines and the upper level protocols on the
OSI Model. The only requirement is a provision of a duplex
circuit either dedicated or switched, that can operate in
either an asynchronous or synchronous mode, transparent to the
data-linklayer frame.
「インターネット・エンジニアリング・タスク・フォースからCCITTに指すポイントプロトコル(PPP)をちょうど、提出したところです。」 それはポイントツーポイント接続の上でインターネットがプロトコルデータと他のネットワーク層(ISOのOSI Modelのレベルthree)プロトコル情報であるとカプセル化する規格を指定します。 また、それはOSI Modelで系列と上側の平らなプロトコルをテストして、構成する方法を提供します。 唯一の要件がどちらかが捧げたか、または切り換えた複式の回路の設備である、それはどちらかで非同期であるか同期モードを操作できます、データ-linklayerフレームに、透明です。
"According to Michael Ballard, director of network systems for
Telebit, PPP is a direct improvement upon Serial Line Internet
Protocol (SLIP), which had neither error correction nor a way
to exchange network address."
「マイケル・バラード、テレビットのネットワーク・システムのディレクターによると、PPPはシリアル回線インターネット・プロトコル(SLIP)よりダイレクト改良です。」(シリアル回線インターネット・プロトコルには、エラー修正もネットワーク・アドレスを交換する方法もありませんでした)。
8.3. Does anyone know if there is a way to run a SLIP program on
a IBM computer running SCO Xenix/Unix, with a multi-port
serial board?
8.3. だれか、マルチポートシリアルボードでSCO Xenix/unixを実行しながらIBMコンピュータでSLIPプログラムを動かす方法があるかどうかを知っていますか?
SCO TCP/IP for Xenix supports SLIP. It works. However, be
warned: SCO SLIP works *only* with SCO serial drivers, so it will
*not* work with intelligent boards that come with their own
drivers. If you want lots of SLIP ports, you'll need lots of dumb
ports, perhaps with a multi-dumb-port board.
XenixのためのSCO TCP/IPはSLIPをサポートします。 それは働いています。 しかしながら、警告されてください: SCO SLIPは、*仕事ではなく、それら自身のドライバーと共に来る知的なボードがある*を扱うためにSCOシリアルドライバーで唯一の**を扱います。 多くのSLIPポートが欲しいなら、あなたは恐らくマルチ馬鹿なポートボードがある多くの馬鹿なポートを必要とするでしょう。
Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP
distributions installed. Slip is running between the "ttya" ports
of two Sun 3/60's. "ping", "rlogin", etc., works fine, but a NFS
mount results in "server not responding: RPC Timed Out".
ここに、セットアップがあります--SunOS3.5、4.3BSD TCPと共に、IPとSLIP配はインストールされました。 メモ用紙は2Sun3/60の"ttya"ポートの間を動いています。 「ピング」、"rlogin"などはきめ細かに働いていますが、NFSマウントは「以下を反応させないサーバ」をもたらします。 「RPCは外で調節しました。」
SunOS 3.5 turns the UDP checksum off, which is legal and works
okay over interfaces such as ethernet which has link- level
checksumming. On the other hand, SLIP doesn't perform checksums
thus running NFS over SLIP requires you to turn the UDP checksum
on. Otherwise, you'll experience erratic behavior such as the one
described above.
SunOS3.5はUDPチェックサムをオフにして、どれが法的であり、間違いなくリンクを持っているイーサネットなどのインタフェースよりやり直すかがchecksummingを平らにします。 他方では、SLIPはチェックサムを実行しません、その結果、SLIPの上の実行しているNFSがあなたがUDPチェックサムをつけるのを必要とします。 さもなければ、あなたは上で説明されたものなどの一貫性のない行動を経験するでしょう。
User Services Working Group [Page 10] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[10ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
Save the older kernel and try,
より古いカーネルを節約してください、そして、試みてください。
% adb -k -w /vmunix /dev/kmem udpcksum?w 1
%adb-k-w/vmunix/dev/kmem udpcksum--w1
to patch up the kernel.
カーネルを繕うために。
9. Questions About Routing
9. ルート設定に関する問題
9.1. Some postings mentioned "maximum entropy routing". Could
someone please provide a pointer to on-line or off-line
references to this topic?
9.1. いくつかの任命が「最大のエントロピールーティング」について言及しました。 だれかがこの話題のオンラインの、または、オフラインの参照に指針を提供であってくれできますか?
Try NYU CSD Technical Report 371: "Some Comments on Highly Dynamic
Network Routing," by Herbert J. Bernstein, May 1988.
NYU CSD技術報告書371を試みてください: ハーバート・J.バーンスタインで、「非常にダイナミックなネットワークルート設定のいくつかのコメント」は1988がそうするかもしれません。
10. Other Protocol and Standards Implementation Questions
10. 他のプロトコルと規格実装問題
10.1. Does anyone recognize ethernet type "80F3"? I don't see it
in RFC 1010, but I am seeing it on our net.
10.1. だれでもイーサネットタイプ"80F3"?"を認識します。 RFC1010のそれを見ませんが、私は私たちのネットにそれが見えています。
Ethernet type 0x80F3 is used by AppleTalk for address resolution.
You must have Macs on your network which are directly connected to
Ethernet. These packets are used by the Mac (generally at
startup) to determine a valid AppleTalk node number.
イーサネットタイプ0x80F3はアドレス解決にAppleTalkによって使用されます。 あなたはあなたのネットワークの直接イーサネットに接続されるMacsを持たなければなりません。 Mac(一般に始動の)によってこれらのパケットは使用されて、有効なAppleTalkノード番号を測定します。
Additional Information:
追加情報:
RFC 1010 is obsolete. Please consult RFC 1060 [11], the current
"Assigned Numbers" (issued March 1990), which does list "80F3":
RFC1010は時代遅れです。 RFC1060[11]、記載する現在の「規定番号」(1990年3月に、発行される)に相談してください、「80F3":」
Ethernet Exp. Ethernet Description References
------------- ------------- ----------- ----------
decimal Hex decimal octal
33011 80F3 - - AppleTalk AARP (Kinetics)[XEROX]
イーサネットExp。 イーサネット記述参照------------- ------------- ----------- ---------- 10進Hex10進の8進33011 80F3----AppleTalk AARP(動力学)[ゼロックス]
10.2. Does anyone know the significance of a high value for
"Bad proto" in the output from netstat on Unix machines using
ethernet? We're seeing values in the tens of thousands out of
a few hundred thousand packets sent/received in all. Some
"Bad proto" values are negative, too. (Off the scale?) Any
help would be appreciated.
10.2. 「悪いproto」によって、だれかUnixマシンの上のnetstatから出力でイーサネットを使用することで高い価値の意味を知っていますか? 私たちはすべてに送るか、または受け取る数10万のパケットのうちの何万に値が見えています。 また、いくつかの「悪いproto」値が否定的です。 (スケールの)? 助けをよろしくお願いします。
This probably indicates that you are getting tens of thousands of
broadcast packets from some host or hosts on your network. You
might want to buy or rent a LAN monitor, or install one of the
public-domain packages to see what private protocol is guilty.
"FYI on a Network Management Tool Catalog: Tools for Monitoring
and Debugging TCP/IP Internets and Interconnected Devices" (RFC
これは、あなたがあなたのネットワークの何人かのホストかホストから何万もの放送パケットを得ているのをたぶん示します。 あなたは、LANモニターを買いたいか、賃借したい、または個人的なプロトコルが何であるかを有罪で確認するために公共の場パッケージの1つをインストールするかもしれません。 「ネットワークマネージメントツールのFYIはカタログに載ります」 「TCP/IPインターネットとインタコネクトされたデバイスをモニターして、デバッグするためのツール」、(RFC
User Services Working Group [Page 11] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[11ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
1147, FYI 2), [12] contains pointers to tools that may help you
zero in on the problem.
1147、FYI2) [12]はあなたが問題を対象にするのを助けるかもしれないツールに指針を含んでいます。
10.3. Which RFC would explain the proper way to configure broadcast
addresses when using subnets?
10.3. どのRFCがサブネットを使用するとき放送演説を構成する適切な方法を説明するでしょうか?
Consult RFC 1122, "Requirements for Internet Hosts --
Communication Layer" [13].
RFC1122、「インターネットホストのための要件--コミュニケーションは層にする」という[13]に相談してください。
10.4. Can anyone tell me what .TAR files exactly are? Is it like
ZIP or LZH for the IBM PC's? IF so, how do I go about getting
a compressor/decompressor for .TAR files and what computer
does this run on?
10.4. だれか、.TARファイルがちょうど何であるかを私に言うことができますか? それはIBM PCのためのZIPかLZHに似ていますか? そのようになら、私は.TARのためのコンプレッサー/減圧装置にファイルを得て、コンピュータがすることにこの走行を得ることに関してどのようにオンになりますか?
TAR stands for "Tape ARchive". It is a Unix utility which takes
files, and directories of files, and creates a single large file.
Originally intended to back up directory trees onto tape (hence
the name), TAR is also used to combine files for easier electronic
file transfer.
TARは「テープアーカイブ」を表します。 それはファイル、およびファイルのディレクトリを取って、ただ一つの大きいファイルを作成するUnixユーティリティです。 元々テープ(したがって、名前)にディレクトリツリーを支援することを意図していて、また、TARは、より簡単な電子ファイル転送のためのファイルを結合するのに使用されます。
11. Suggested Reading
11. 提案された読書
For further information about the Internet and its protocols in general, you may choose to obtain copies of the following works:
インターネットに関する詳細と一般に、そのプロトコルのために、あなたは、以下の作品のコピーを入手するのを選ぶことができます:
Bowers, K., T. LaQuey, J. Reynolds, K. Roubicek, M. Stahl, and A.
Yuan, "Where to Start - A Bibliography of General Internetworking
Information", RFC 1175, FYI 3, CNRI, U Texas, ISI, BBN, SRI,
Mitre, August 1990.
バワーズ、K.、T.LaQuey、J.レイノルズ、K.Roubicek、M.スタール、およびA.元、「始めに--一般インターネットワーキング情報の図書目録、」、RFC1175、FYI3、CNRI、UテキサスISI、BBN、様、斜め継ぎ(1990年8月)
Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layer", RFC 1122, Internet Engineering Task Force,
October 1989.
ブレーデン、R.、エディタ、RFC1122、インターネットが特別委員会を設計することでの1989年10月に「インターネットホストのための要件--コミュニケーションは層にします」。
Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, Internet Engineering Task
Force, October 1989.
ブレーデン、R.、エディタ、「RFC1123、インターネットが特別委員会を設計することでの10月1989日アプリケーションとサポート」インターネットホストのための要件--
Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
and Architecture", Prentice Hall, New Jersey, 1989.
新来者、D.、「TCP/IPがあるインターネットワーキング:」 「原則、プロトコル、およびアーキテクチャ」、新米のホール、ニュージャージー、1989
Frey, D. and R. Adams, "!%@:: A Directory of Electronic Mail
Addressing and Networks", O'Reilly and Associates, Newton, MA,
August 1989.
Frey, D. and R. Adams, "!%@:: 「電子メールアドレシングとネットワークのディレクトリ」とオライリーと仲間、ニュートン、MA、1989年8月。
Krol, E., "The Hitchhikers Guide to the Internet", RFC 1118,
University of Illinois Urbana, September 1989.
クロール、E.、RFC1118、イリノイアーバナ大学の「インターネットへのヒッチハイカーガイド」1989年9月。
User Services Working Group [Page 12] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[12ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
LaQuey, T, Editor, "Users' Directory of Computer Networks",
Digital Press, Bedford, MA, 1990.
LaQuey、T、エディタ、「ユーザのコンピュータネットワークのディレクトリ」、デジタルプレス、ベッドフォード、MA、1990。
Malkin, G., and A. Marine, "FYI on Questions and Answers - Answers
to Commonly asked "New Internet User" Questions", RFC 1206, FYI 4,
FTP Software, Inc., SRI, February 1991.
マルキン、G.、およびA.海兵隊員、「QuestionsとAnswersの上のFYI--Commonlyの答えは「新しいインターネットユーザ」Questionsに尋ねました」、RFC1206、FYI4、FTP Software Inc.、SRI、1991年2月。
Postel, J., Editor, "IAB Official Protocol Standards", RFC 1140,
Internet Activities Board, May 1990.
ポステル(J.、エディタ、「IABの公式のプロトコル標準」、RFC1140、活動が入るインターネット)は1990がそうするかもしれません。
Quarterman, J., "Matrix: Computer Networks and Conferencing
Systems Worldwide", Digital Press, Bedford, MA, 1989.
Quarterman、J.、「マトリクス:」 ベッドフォード、Digitalが「世界中のコンピュータネットワークと会議システム」と押す、MA、1989
Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
USC/情報科学が1990年3月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1060。
Socolofsky, T., and C. Kale, "A TCP/IP Tutorial", RFC 1180, Spider
Systems Limited, January 1991.
1991年1月に制限されたSocolofsky、T.、およびC.ケール、「TCP/IPチュートリアル」、RFC1180、クモのシステム。
Stevens, W., "UNIX Network Programming", ISBN 0-13-949876-1,
Prentice Hall, Englewood Cliffs, NJ, 1990.
スティーブンス、W.、「UNIXネットワーク・プログラミング」、ISBN0-13-949876-1、新米のホール、イングルウッドがけ、ニュージャージー、1990。
Stine, R., Editor, "FYI on a Network Management Tool Catalog:
Tools for Monitoring and Debugging TCP/IP Internets and
Interconnected Devices" RFC 1147, FYI 2, Sparta, Inc., April 1990.
スタイン、R.、エディタ、「ネットワークマネージメントツールのFYIはカタログに載ります」。 「TCP/IPインターネットとインタコネクトされたデバイスをモニターして、デバッグするためのツール」RFC1147、FYI2、スパルタInc.、1990年4月。
12. References
12. 参照
[1] Cerf, V., and K. Mills, "Explaining the Role of GOSIP", RFC 1169,
IAB, NIST, August 1990.
[1] サーフ、V.とK.工場、「GOSIPの役割について説明します」、RFC1169、IAB、NIST、1990年8月。
[2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, USC/Information Sciences Institute, November 1987.
[2]Mockapetris、P.、「ドメイン名--、概念と施設、」、RFC1034、科学が設けるUSC/情報、11月1987日
[3] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[3] ローズ、M.、およびK.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」(RFC1155、国際言語運用機構、ヒューズLANシステム)は1990がそうするかもしれません。
[4] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[4]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1156、ヒューズLAN Systems、国際パフォーマンスSystems、1990年5月。
[5] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
Network Management Protocol (SNMP)", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[5] ケース、J.、M.ヒョードル、M.Schoffstall、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル(SNMP)」、RFC1157、SNMPは研究します、国際言語運用機構、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
[6] Rose, M., Editor, "Management Information Base for Network
[6] ローズ、M.、エディタ、「ネットワークのための管理情報ベース」
User Services Working Group [Page 13] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[13ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
Management of TCP/IP-based internets: MIB-II", RFC 1158,
Performance Systems International, May 1990.
TCP/IPベースのインターネットの管理: 「MIB-II」(RFC1158、国際言語運用機構)は1990がそうするかもしれません。
[7] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC
854, USC/Information Sciences Institute, May 1983.
[7] RFC854、科学が設けるUSC/情報がそうするポステル、J.とJ.レイノルズ、「telnetプロトコル仕様」1983。
[8] Romkey, J., "A Nonstandard for Transmission of IP Datagrams over
Serial Lines: SLIP", RFC 1055, June 1988.
[8] J.、Romkeyに、「IPデータグラムの送信に、シリーズの上で標準的でないAは立ち並んでいます」。 「メモ用紙」、RFC1055、1988年6月。
[9] Perkins, D., "The Point-to-Point Protocol: A Proposal for Multi-
Protocol Transmission of Datagrams Over Point-to-Point Links",
RFC 1171, CMU, July 1990.
[9] パーキンス、D.、「ポイントツーポイントは以下について議定書の中で述べます」。 「ポイントツーポイント接続の上のデータグラムのマルチプロトコル送信のための提案」、RFC1171、米カーネギーメロン大学、1990年7月。
[10] Perkins, D., and R. Hobby, "The Point-to-Point Protocol (PPP)
Initial Configuration Options", CMU, UC Davis, July 1990.
[10] パーキンス、D.、およびR.趣味、「二地点間プロトコル(ppp)の初期の設定オプション」、米カーネギーメロン大学、UCデイヴィス、1990年7月。
[11] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
[11] USC/情報科学が1990年3月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1060。
[12] Stine, R., Editor, "FYI on a Network Management Tool Catalog:
Tools for Monitoring and Debugging TCP/IP Internets and
Interconnected Devices" RFC 1147, FYI 2, Sparta, Inc., April
1990.
[12] スタイン、R.、エディタ、「ネットワークマネージメントツールのFYIはカタログに載ります」。 「TCP/IPインターネットとインタコネクトされたデバイスをモニターして、デバッグするためのツール」RFC1147、FYI2、スパルタInc.、1990年4月。
[13] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layer", RFC 1122, Internet Engineering Task Force,
October 1989.
[13] ブレーデン、R.、エディタ、RFC1122、インターネットが特別委員会を設計することでの1989年10月に「インターネットホストのための要件--コミュニケーションは層にします」。
13. Security Considerations
13. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
User Services Working Group [Page 14] RFC 1207 FYI Q/A - for Experienced Internet Users February 1991
ユーザサービス作業部会[14ページ]RFC1207FYI Q/A--経験豊富なインターネットユーザ1991年2月に
14. Authors' Addresses
14. 作者のアドレス
Gary Scott Malkin FTP Software, Inc. 26 Princess Street Wakefield, MA 01880
通りウェークフィールド、ゲーリースコットマルキンFTPソフトウェアInc.26姫MA 01880
Phone: (617) 246-0900 EMail: gmalkin@ftp.com
以下に電話をしてください。 (617) 246-0900 メールしてください: gmalkin@ftp.com
April N. Marine SRI International Network Information Systems Center 333 Ravenswood Avenue, EJ294 Menlo Park, CA 94025
EJ294メンローパーク、カリフォルニア Marine AprilのNetwork Information Systems Center333レーヴンズウッドN.SRI Internationalアベニュー、94025
Phone: (415) 859-5318 EMail: APRIL@nic.ddn.mil
以下に電話をしてください。 (415) 859-5318 メールしてください: APRIL@nic.ddn.mil
Joyce K. Reynolds USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
ジョイスK.レイノルズUSC/情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695
Phone: (213) 822-1511 EMail: jkrey@isi.edu
以下に電話をしてください。 (213) 822-1511 メールしてください: jkrey@isi.edu
User Services Working Group [Page 15]
ユーザサービス作業部会[15ページ]
一覧
スポンサーリンク
