RFC1109 日本語訳
1109 Report of the second Ad Hoc Network Management Review Group. V.G.Cerf. August 1989. (Format: TXT=20642 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Cerf Request for Comments: 1109 NRI August 1989
コメントを求めるワーキンググループV.サーフの要求をネットワークでつないでください: 1109 NRI1989年8月
Report of the Second Ad Hoc Network Management Review Group
第2臨時のネットワークマネージメントレビューグループのレポート
Status of this Memo
このMemoの状態
This RFC reports an official Internet Activities Board (IAB) policy position on the treatment of Network Management in the Internet. This RFC presents the results and recommendations of the second Ad Hoc Network Management Review on June 12, 1989. The results of the first such meeting were reported in RFC 1052 [1]. This report was approved and its recommendations adopted by the IAB as assembled on July 11- 13, 1989. Distribution of this memo is unlimited.
このRFCはインターネットでのNetwork Managementの処理に関して公式のインターネットActivities Board(IAB)政治的な立場を報告します。 このRFCは1989年6月12日の第2Ad Hoc Network Management Reviewの結果と推薦を提示します。 そのようなミーティングがRFC1052[1]で報告されたという1つの番目ものの結果。 このレポートは、承認されていて1989年7月11- 13日の組み立てられるとしてのIABによって採用されたその推薦でした。 このメモの分配は無制限です。
INTRODUCTION
序論
On February 29, 1988, an Ad Hoc Network Management Review Group was convened to consider the state of network management technology for the Internet and to make recommendations to the Internet Activities Board as to network management policy. The outcome of that meeting was summarized in RFC 1052 and essentially established a framework in which two network management protocols now known respectively as Simple Network Management Protocol (SNMP) and Common Management Information Protocol on TCP (CMOT) were selected for further work. Subsequently, both SNMP [6] and CMOT [5] were advanced to Draft- Standard/Recommended status for use in the Internet [SNMP: RFC 1098, CMOT: RFC 1095].
1988年2月29日に、Ad Hoc Network Management Review Groupは、ネットワークの状態が管理技術であるとインターネットと考えて、ネットワークマネージメント方針に関してインターネットへの推薦状をActivities Boardにするように召集されました。 TCP(CMOT)の上のSimple Network Managementプロトコル(SNMP)と共通管理情報プロトコルがさらなる仕事のために選択されたとき、そのミーティングの結果は、RFC1052にまとめられて、今それぞれ知られていたどの2つのネットワーク管理プロトコルに本質的には体制を確立していたか。 次に、SNMP[6]とCMOT[5]の両方がインターネット[SNMP: RFC1098、RFC CMOT:1095]での使用のためにDraftの標準の、または、お勧めの状態に進められました。
Simultaneously, it was agreed to establish a working group to coordinate the definition and specification of managed objects to be used in common with either protocol. In addition, it was agreed to use the then current ISO Structure of Management Information (SMI) specification as a reference standard to guide the naming and abstraction conventions that would be followed in constructing the common Internet Management Information Base (MIB). The Internet versions of SMI and MIB were specified in RFC 1065 [2] and RFC 1066 [3] respectively.
同時に、調整するためにワーキンググループを証明するために、どちらかと共用して使用されるべき管理オブジェクトの定義と仕様が議定書を作るのに同意されました。 さらに、Management情報(SMI)仕様の当時の現在のISO Structureを使用するために命名を誘導する基準ゲージと抽象化コンベンションとして、一般的なインターネットManagement Information基地(MIB)を構成する際にそれに続いているのに同意されました。 SMIとMIBのインターネットバージョンはRFC1065[2]とRFC1066[3]でそれぞれ指定されました。
In the intervening fifteen months, considerable progress has been made in the specification of a common Management Information Base and in the implementation, deployment and use of network management tools in the Internet.
介入している15カ月で、かなりの進展はネットワークマネージメントツールをインターネットでの一般的なManagement Information基地の仕様、実装、展開、使用で作られています。
Cerf [Page 1] RFC 1109 Internet Management August 1989
サーフ[1ページ]RFC1109インターネット管理1989年8月
The current public subtree of the Internet MIB contains roughly 100 variables (i.e., managed objects) agreed by the SNMP and CMOT working groups as mandatory for Internet network management. The June 12, 1989 meeting which this document reports was convened to review the progress to date, to determine whether actions were needed to foster further evolution of network management tools and to recommend specific actions in this area to the IAB.
インターネットMIBの現在の公共の下位木はインターネットネットワークマネージメントに義務的であるとしてSNMPによって同意されたおよそ100の変数(すなわち、管理オブジェクト)とCMOTワーキンググループを含みます。 このドキュメントが報告する1989年6月12日ミーティングは、これまでの進歩を再検討して、動作がネットワークマネージメントツールの一層の発展を伸ばすのに必要であったかどうか決定して、この領域で特定の動作をIABに推薦するために召集されました。
SNMP STATUS
SNMP状態
Immediately after the meeting reported in RFC 1052, a group was convened to make extensions and changes to the predecessor to SNMP: Simple Gateway Monitoring Protocol. A "connectathon" was held at NYSERNet, an RFC published, and demonstrations of network management tools using SNMP were offered in the Fall at Interop 88 [a conference and show presented by Advanced Computing Environments (ACE)]. The protocol is in use in a number of networks within the Internet as well as in private packet networks internationally. A number of vendor implementations are in the field (e.g., cisco Systems, Proteon, The Wollongong Group), vendor independent reference implementations (e.g., NYSERNet, Case and Key in Tennessee) along with some freely available versions (e.g., MIT, CMU).
RFC1052で報告されたミーティング直後、グループは拡大と前任者への変更をSNMPにするように召集されました: 簡単なゲートウェイモニターしているプロトコル。 NYSERNetに"connectathon"を保持しました、そして、RFCは発行しました、そして、Interop88[Advanced Computing Environments(ACE)によって提示された会議とショー]のFallでSNMPを使用するネットワークマネージメントツールのデモンストレーションを提供しました。 プロトコルはインターネットの中の多くのネットワークと個人的なパケット網で国際的に使用中です。 多くのベンダー実装が分野(例えば、コクチマスSystems、Proteon、ウォロンゴンGroup)にあって、いくつかの自由に利用可能なバージョン(例えば、MIT、米カーネギーメロン大学)と共にベンダー非依存指示は実装(テネシーの例えば、NYSERNet、Case、およびKey)です。
It is important to note that while the common Internet Management Information Base has roughly 100 variables, a typical SNMP monitoring system may support anywhere from 100 to 200 ADDITIONAL objects which have been defined in private or experimental MIB space. Many of these are device or protocol dependent variables.
一般的なインターネットManagement Information基地にはおよそ100の変数がある間典型的なSNMP監視システムがどこでも100〜200まで個人的であるか実験しているMIBスペースで定義されたオブジェクトをADDITIONALに支えるかもしれないことに注意するのが重要です。 これらの多くが、デバイスであるか従変数について議定書の中で述べます。
Scaling to include larger numbers of monitored objects and subsystems remains a challenge. It was observed that fault monitoring was easier to scale than performance and configuration monitoring, since the former may operate on an exception basis while the latter is more likely to require periodic reporting.
モニターされたオブジェクトと、より多くのサブシステムを含むように比例するのは挑戦のままで残っています。 欠点モニターは性能と構成モニターよりスケーリングしやすいと認められました、前者が例外ベースを作動させるかもしれないので後者が周期的な報告がさらに必要でありそうな間、。
CMOT STATUS
CMOT状態
RFC 1095 (CMOT) was recently published and built upon experience gained earlier with prototype implementations demonstrated at Interop 88 in the Fall of that year. The present specification for CMOT is based on the ISO Draft International Standard version of Common Management Information Protocol (CMIP). The CMIP is being moved to International Standard status, though the precise timing is not perfectly clear. It will happen late in 1989 or perhaps in the first quarter of 1990. Some changes will be made to correct known errors and the CMIP document itself will probably be restructured.
RFC1095(CMOT)はその年のFallで最近、発行されて、プロトタイプ実装がInterop88に示されている状態で、より早く行われた経験を当てにしました。 CMOTのための現在の仕様は共通管理情報プロトコル(CMIP)のISO国際規格案バージョンに基づいています。 正確なタイミングは澄み渡っていませんが、CMIPは国際規格状態に動かされています。 それは1989か恐らく1990年の第1四半期遅く、起こるでしょう。 いくつかの変更が知られている誤りを修正すると行われて、CMIPドキュメント自体はたぶん再構築されるでしょう。
During this discussion, it was pointed out that there is much to
この議論の間、多くがあるのは、先鋭なアウトでした。
Cerf [Page 2] RFC 1109 Internet Management August 1989
サーフ[2ページ]RFC1109インターネット管理1989年8月
network management which is not addressed by either the CMOT or the SNMP specifications: for example, down loading of software, configuration management and user access control. Authentication of the source of network management commands and responses is another area important to providers and users of network management tools.
CMOTによって扱われないネットワークマネージメントかSNMP仕様: 例えば、ソフトウェアのローディングの下側に、構成管理とユーザアクセスは制御されます。 ネットワークマネージメント命令と応答の源の認証はネットワークマネージメントツールのプロバイダーとユーザにとって、重要な別の領域です。
The National Institute for Standards and Technology (NIST) is sponsoring the development of implementors' agreements on the functional behavior of network management tools including, inter alia, logging, event reporting, error reporting, structured object management, and alarm reporting.
StandardsとTechnology(NIST)のためのNational Instituteはとりわけ伐採、イベント報告、誤り報告、構造化されたオブジェクト管理、およびアラーム報告を含むネットワークマネージメントツールの機能的な振舞いの実装者間協定の開発を後援しています。
Although at the time of the meeting, there were no publicly available implementations of CMOT reported, developments were reportedly planned by a number of vendors both in the form of agents and network management tools. The University of Wisconsin plans to demonstrate CMOT using the ISODE software at Interop 89 [(tm) ACE] in September 1989.
ミーティング時点で、報告されたCMOTのどんな公的に利用可能な実装もありませんでしたが、伝えられるところによれば、開発はエージェントとネットワークマネージメントツールの形のベンダーの多くの両方によって計画されていました。 ウィスコンシン大学は、1989年9月にInterop89[(tm)ACE]でISODEソフトウェアを使用することでCMOTのデモをするのを計画しています。
MIB AND SMI STATUS
MIBとSMI状態
In the Fall of 1988, two RFCs were published (1065 and 1066) to specify the Structure of Management Information (SMI) and the initial Internet Management Information Base (MIB) respectively. There were some challenges in crafting this set of commonly agreed variables; in the end, roughly 100 were agreed and defined as mandatory for Internet management.
1988年のFallでは、2RFCsが、それぞれ、Management情報のStructure(SMI)と初期のインターネットManagement Information基地(MIB)を指定するために発行されました(1065と1066)。 このセットの一般的に同意された変数を作るのにおいていくつかの挑戦がありました。 結局、およそ100は、インターネット管理に義務的であると同意されて、定義されました。
It was recognized in this process that the definition of the layer BELOW IP was a difficult task. IP is sufficiently simple and general that it has been moved in encapsulated form over many media including the MAC level of various local nets, X.25 packet level, serial line protocols, multiplexors, tunnels and, it is rumored, tin cans and string.
このプロセスでは、BELOW IP層の定義が厄介な問題であると認められました。 IPは十分簡単です、そして、様々なローカルのネットのMACレベルを含んでいて、それが一般であったのは多くのメディアの上でカプセル化されたフォームに入って来ました、そして、X.25パケット・レベル(シリアル・ラインプロトコル、マルチプレクサー)はトンネルを堀ります、そして、それは噂されています、ブリキ缶。そして、ストリング。
At the Transport level, specifically for TCP, it was observed that information about the transient status of connections was potentially inaccessible to the network management tools since the loss of a TCP connection typically meant loss of its Transmission Control Block (status block) just when you wanted to look back into the history of its state. Countervailing this observation was evidence that looking at TCBs with network management tools yielded far more insight into the transient behavior of TCP than looking at aggregated network statistics.
Transportレベルにおいて特にTCPに関して、ちょうどあなたが状態の歴史を見返したがっていたとき、TCP接続の損失がTransmission Control Block(状態ブロック)の損失を通常意味したので接続の一時的な状態の情報が潜在的にネットワークマネージメントツールに近づきがたいのが観測されました。 この観測を相殺するのは、ネットワークマネージメントツールがあるTCBsを見るとTCPの遷移挙動に関する、より多くの洞察が集められたネットワーク統計を見るより遠くにもたらされたという証拠でした。
It was clear from the discussion that there is strong interest in extending the variables accessible via network management tools. Adding new devices, new higher level protocols and the ability to
議論によって、ネットワークマネージメントツールを通してアクセスしやすい変数を広げることへの強い関心があるのは、明確でした。 新しいデバイス、新しいより高い平らなプロトコル、および能力を加えます。
Cerf [Page 3] RFC 1109 Internet Management August 1989
サーフ[3ページ]RFC1109インターネット管理1989年8月
manipulate configuration information were high on the list of desirable extensions, although several participants felt that this desire needed some moderation.
高値が望ましい拡大のリストにあったなら、設定情報を操ってください、数人の関係者が、この願望が中道主義者を必要としたと感じましたが。
A vital, but unsettled research area has to do with relationships among groups of monitored variables. A particular implementation may have IP operating atop X.25. The problem is to be able to make queries about the condition of monitored variables so that those for the IP level can be correlated with those for a lower layer, for instance. This notion of relationship is especially important as network devices (including hosts) begin to sport multiple network connections and multiple protocol suites operating in parallel. Just how the dynamics of such relationships are to be specified, defined and instantiated is the research question. What sort of SMI is appropriate? What generic structure is needed for the management objects?
重大な、しかし、未解決の研究領域はモニターされた変数のグループで関係と関係があります。 特定の実装で、IPはX.25の上で作動するかもしれません。 問題はIPレベルのためのものが例えば、下層のためにそれらで関連できるようにモニターされた変数の状態に関して質問をすることであることができます。 ネットワークデバイス(ホストを含んでいる)がスポーツマルチネットワーク接続と平行で作動する複数のプロトコル群に始まるので、関係のこの概念は特に重要です。 指定されて、定義されて、どうそのような関係の力学がいったいことである例示されるかは、研究問題です。 どういうSMIが適切ですか? どんなジェネリック構造が管理オブジェクトに必要ですか?
Another difficult topic has to do with version numbers for SMI. The issue is "which version of MIB is instantiated in this monitored system?" As consideration of extensions to the currently agreed SMI were contemplated during the last fifteen months, it became apparent that the question of versions was central.
別の難しい話題はSMIのバージョン番号と関係があります。 問題は「MIBのどのバージョンがこのモニターされたシステムに例示されますか?」です。 現在同意されたSMIへの拡大の考慮がここ15カ月熟考されたとき、バージョンの問題が主要であったのは明らかになりました。
Not far behind was the question of functionality of the underlying support protocols (SNMP and CMOT). The RFC 1052 recommendation was to tightly link the MIB/SMI, keeping only one such definition for both protocols. In theory, this plan would make it easier to move from one protocol base to another. In practice, it appears to have stifled exploration of new variable and function definitions in operating network environments. This point needs to be underscored: it is essential for the Internet community to have the freedom to explore the utility of the OSI offerings while, at the same time, having the freedom to respond to operational needs through the definition and use of new MIB variables and SMI features.
後ろで遠くないのは、基本的なサポートプロトコル(SNMPとCMOT)の機能性の問題でした。 RFC1052推薦は両方のプロトコルのためのそのような定義の1つだけを保って、しっかりMIB/SMIをリンクすることでした。 理論上、このプランで、1個のプロトコルベースから別のベースまで移行するのは、より簡単になるでしょう。 実際には、それは操作ネットワーク環境における、新しい変数と関数定義の探検をやめさせたように見えます。 このポイントは、下線を引かれる必要があります: インターネットコミュニティが同時に新しいMIB変数とSMIの特徴の定義と使用で操作上の必要性に応じる自由を持っている間にOSI提供に関するユーティリティを探る自由を持っているのは、不可欠です。
Yet another area still needing development has to do with the archiving of operational data collected by means of a network management tool. The ISO Common Management Information Service (CMIS) specifications do not treat this matter.
まだ開発を必要とするさらに別の領域がネットワークマネージメントツールによって集められた操作上のデータの格納と関係があります。 ISO Common Management情報Service(CMIS)仕様はこの件を扱いません。
Finally, it was pointed out that registration of managed objects and their definitions was still an open area although the NIST has apparently made progress through its Network Management Special Interest Group (NMSIG) in planning for cataloging of defined management information objects.
最終的に、NISTがNetwork Management特別利益団体Group(NMSIG)を通して定義された経営情報オブジェクトをカタログに載せることの計画を立てる際に明らかに進展しましたが、管理オブジェクトと彼らの定義の登録が空地であると指摘されました。
Cerf [Page 4] RFC 1109 Internet Management August 1989
サーフ[4ページ]RFC1109インターネット管理1989年8月
APPLICATION PROGRAMMING INTERFACE (API)
アプリケーションプログラミングインターフェース(アピ)
It was generally agreed that the actual network management tools available to operators, rather than the specifics of the protocols supporting the tools, would be the determining factor in the effectiveness of any Internet network management system. A brief report was offered and discussion ensued on the possibility of creating a common application programming interface that could be used independent of the specific protocol (CMOT, SNMP, CMIP or proprietary) used to transport queries and commands.
一般に、オペレータにとって、利用可能な実際のネットワークマネージメントツールがツールをサポートするプロトコルの詳細よりむしろどんなインターネットネットワーク管理システムの有効性が決定的要因であるのにも同意されました。 手短な報告を提供しました、そして、議論は質問を輸送するのに使用される特定のプロトコル(CMOT、CMIPの、または、独占であるSNMP)の如何にかかわらず使用できた一般的なアプリケーションプログラミングインターフェースとコマンドを作成する可能性に起こりました。
It was acknowledged that the present service interfaces of both SNMP and CMIS have limitations (e.g., neither has any sense of time other than "now"; this makes it impossible to express queries for historical information, or to issue command requests of the form: Do X at device Y, beginning in 30 minutes). These limitations hinder both SNMP and CMOT from directly offering a comprehensive API for network management applications.
SNMPとCMISの両方の現在のサービスインタフェースには制限がある(例えば、「現在」を除いた時間のどんな感覚もそうしません; これで、歴史に関する知識のための質問を言い表すか、または形式のコマンド要求を出すのが不可能になります: デバイスYにXをしてください、30分後に始まって)と認められました。 これらの制限は、SNMPとCMOTの両方がネットワークマネージメントアプリケーションのために直接包括的なAPIを提供するのを妨げます。
Although some positive sentiment was expressed for defining a kind of "super SMI" metalanguage to aid in the the definition of a general API, it was not clear whether the current crop of supporting protocols had sufficient semantic commonality to be used in this way. The matter remains open for investigation.
何らかの積極的な感情が一般的なAPIの定義で支援するために一種の「最高のSMI」メタ言語を定義するために述べられましたが、サポートプロトコルの現在の作物にはこのように使用できるくらいの意味共通点があったかどうかは、明確ではありませんでした。 その件は調査において開いたままで残っています。
NIST ACTIVITIES
NIST活動
The Ad Hoc Review had the benefit of representatives from NIST who are active in the network management area. It was reported that the major focus at present is at layers 3 and 4 where objects are being defined in accordance with "templates" provided by ISO's SC21. IEEE 802 is also pursuing the definition of MIB objects, though not with the benefit of the same templates now in use by the NIST NMSIG. The layers above transport are just beginning to receive attention.
Ad Hoc Reviewには、ネットワークマネージメント領域でアクティブなNISTからの代表の利益がありました。 主要な焦点が現在のところISOのSC21によって提供された「テンプレート」に従ってオブジェクトが定義されている層3と4にあると報告されました。 また、IEEE802はMIBオブジェクトの定義を追求しています、現在NIST NMSIGで使用中の同じテンプレートのいずれの利益でもそうしませんが。 輸送を超えた層はただ配慮を受け始めています。
It was observed that the Internet SMI is not quite a subset of the ISO CMIS SMI. The Internet variable naming conventions are a little different and some functionality may vary. There was some uncertainty about the treatment of gauges in the Internet SMI and the corresponding OSI SMI. [L. Steinberg reported, subsequent to the meeting, that gauges latch and counters roll over in the OSI SMI, as they appear to do in the Internet SMI - VGC].
インターネットSMIがISO CMIS SMIのかなりの部分集合でないことが観測されました。 インターネットの変化する命名規則は少し異なっています、そして、何らかの機能性が異なるかもしれません。 インターネットSMIと対応するOSI SMIでのゲージの処理に関して何らかの不確実性がありました。 [それは掛け金を測ります、そして、L.スタインバーグは報告しました、ミーティングにその後であり、カウンタはOSI SMIでひっくり返ります、インターネットSMIでするように見えるとき--VGC。]
The general sense of this portion of the discussion was that a considerable amount of activity is underway with the sponsorship of NIST and that this work is relevant to the Internet community, particularly as the time approaches in which coexistence of the OSI protocol suite with the existing Internet protocols is the norm.
議論のこの部分の一般的な感覚はかなりの量の活動がNISTのスポンサーシップと共に進行中であり、この仕事がインターネットコミュニティに関連しているということでした、特に時間に既存のインターネットプロトコルとのOSIプロトコル群のどの共存が標準であるかに近づくように。
Cerf [Page 5] RFC 1109 Internet Management August 1989
サーフ[5ページ]RFC1109インターネット管理1989年8月
CONCLUSIONS AND RECOMMENDATIONS
結論と推薦
The assembled attendees came to the conclusions enumerated below and recommends to the IAB that actions be taken which are consistent with these conclusions:
集まっている出席者は、以下に列挙された結論に来て、行動が取られることをIABに勧めます(これらの結論と一致しています):
1. The Internet will exist in a pluralistic protocol stack environment and the need to coexist will persist.
1. インターネットは多元的なプロトコル・スタック環境で存在するでしょう、そして、共存する必要性は持続するでしょう。
2. Expansion of the common MIB has been impeded by an inability to agree on a common, extended SMI.
2. 一般的なMIBの拡張は一般的で、拡張しているSMIに同意できないことによって妨害されました。
3. The Internet community must not ignore the work of other groups in the network management area, while at the same time, coping with the current operational needs of the Internet (and internet) communities.
3. インターネットコミュニティはネットワークマネージメント領域での他のグループの仕事を無視してはいけません、同時に、インターネット(そして、インターネット)共同体の現在の操作上の必要性に対処して。
4. Until we can gain operational experience with OSI network management tools (e.g., with CMIP on TCP or on OSI), we cannot specify a plan for coexistence with and transition to use of the OSI-based protocols in the Internet.
4. 私たちはOSIネットワークマネージメントツール(例えば、TCPの上、または、OSIの上にCMIPがある)の運用経験を獲得できるまでインターネットでのOSIベースのプロトコルの使用への共存と変遷のためのプランを指定できません。
Therefore:
したがって:
(a) We want to foster an environment for real CMOT/CMIP use.
(a) 本当のCMOT/CMIP使用のために環境を育成したいと思います。
(b) We should take action as needed to extend SNMP for operational reasons.
(b) 私たちは、操作上の理由でSNMPを広げるために必要に応じて行動を取るべきです。
(c) We must preserve the utility of the first agreed common MIB (RFC 1066).
(c) 私たちは最初の同意された一般的なMIB(RFC1066)に関するユーティリティを保存しなければなりません。
(d) We should develop, separately, experimental and enterprise MIB variables and seek opportunity for placing these in the common MIB.
(d) 私たちは、別々に実験的、そして、企業MIB変数を開発して、一般的なMIBにこれらを置く機会を求めるべきです。
(e) In a coexisting environment, we will need to access the same set of variables (e.g., in a given gateway or router) by means of more than one protocol (e.g., SNMP, CMIP/TCP, CMIP/CLNP, etc.).
(e) 共存環境で、私たちは、1つ以上のプロトコル(例えば、SNMP、CMIP/TCP、CMIP/CLNPなど)によって同じセットの変数(例えば、与えられたゲートウェイかルータにおける)にアクセスする必要があるつもりです。
It is recommended to the IAB that the network management efforts using SNMP and CMOT be allowed independently to explore new variables and potentially non-overlapping SMI definitions for the next 12 months so as to foster operational deployment and experience with these network management tools. In essence, it is recommended that the binding of SNMP and CMOT to a common MIB/SMI be relaxed for this period of exploration. Variables which are NOT supportable in common
SNMPとCMOTを使用するネットワークマネージメントの努力がこれらのネットワークマネージメントツールの操作上の展開と経験を伸ばすために次の12カ月独自に新しい変数と潜在的に非重なっているSMI定義を探ることができることがIABに勧められます。 本質では、一般的なMIB/SMIへのSNMPとCMOTの結合がこの期間の探検のためにリラックスするのは、お勧めです。 一般的で我慢できない変数
Cerf [Page 6] RFC 1109 Internet Management August 1989
サーフ[6ページ]RFC1109インターネット管理1989年8月
by both protocols should be defined in the experimental or private parts of the MIB definition space. Obviously, care should be taken to achieve agreement within each respective working group on any variables added to the distinct SNMP and CMOT experimental spaces.
両方で、プロトコルはMIB定義スペースの実験的であるか恥部で定義されるべきです。 明らかに、異なったSNMPとCMOTの実験空間に加えられたどんな変数のそれぞれのそれぞれのワーキンググループの中でも協定を達成するために注意するべきです。
Specifically, the CMOT working group should extend its MIB and SMI definitions in the direction of the OSI/NIST specifications so as to bring CMOT into closer alignment with the OSI CMIS design.
明確に、CMOTワーキンググループは、オウシ/NIST仕様の向きにOSI CMISデザインで、より厳密な整列にCMOTを運び込むようにMIBとSMI定義を広げるべきです。
During this period of experimentation, it is strongly recommended that the IAB seek opportunities to encourage the introduction of Internet elements which use the OSI protocols into the Internet environment. Such OSI-based elements offer an opportunity to obtain operational experience with monitoring and management support by way of the CMIP and CMOT protocols. It is anticipated that network management systems based on the OSI Common Management Information Service (CMIS) will be developed which use CMIP or CMOT, as appropriate, to manage various elements in the Internet.
この期間の実験の間、IABがインターネット環境にOSIプロトコルを使用するインターネット要素の挿入を奨励する機会を求めることが強く勧められます。 そのようなOSIベースの要素はモニターの運用経験を得る機会を提供します、そして、経営者側はCMIPとCMOTを通してプロトコルをサポートします。 OSI Common Management情報Serviceに基づいたCMIPかCMOTを使用するネットワーク管理システムが開発される(CMIS)と予期されます、インターネットで様々な要素を管理するために適宜。
It is also recommended that the IAB engage in an active liaison effort with the NIST, focusing especially on the question of coexistence of the Internet protocols with OSI protocols. If at all possible, joint experimental or test-bed efforts should be initiated to identify means for supporting this coexistence.
また、IABがNISTとの活発な連絡の努力に従事しているのも、お勧めです、OSIプロトコルとのインターネットプロトコルの共存の問題に特に焦点を合わせて。 できれば、実験的であるかテストベッドの共同努力は、この共存を支持するための手段を特定するために開始されるべきです。
As necessary, the Internet Engineering Task Force should be directed to restructure its network management efforts both to support the need for MIB/SMI exploration by the SNMP and CMOT groups and to strengthen links between the IETF efforts and those of NIST.
必要に応じて、ともにSNMPによるMIB/SMI探検の必要性を支持するためのネットワークマネージメントの努力とCMOTグループを再構築して、インターネット・エンジニアリング・タスク・フォースがNISTのIETFの努力とものとのリンクを強化するよう指示されるべきです。
Finally, it is recommended that the Ad Hoc Review Group be reconvened at 6 month intervals to review status and to determine whether opportunities for expanding the common MIB/SMI are available.
最終的に、Ad Hoc Review Groupが状態について調査して、一般的なMIB/SMIを広げる機会が利用可能であるかどうか決定するために6カ月の間隔を置いて再召集されるのは、お勧めです。
REFERENCES
参照
1. Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988.
1. サーフ、V.、「インターネットネットワークマネージメント規格の開発のためのIAB推薦」、RFC1052、NRI、1988年4月。
2. Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.
2. ローズ、M.、K.McCloghrie、および「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、RFC1065、TWG、8月1988日
3. McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.
3. McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1066、TWG、1988年8月。
4. Schoffstall, M., C. Davin, M. Fedor, and J. Case, "SNMP over
4. Schoffstall、M.、デーヴィン、M.ヒョードル、およびJ.がケースに入れるC.、「SNMP、より多くの」
Cerf [Page 7] RFC 1109 Internet Management August 1989
サーフ[7ページ]RFC1109インターネット管理1989年8月
Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT Laboratory for Computer Science, NYSERNet, Inc., and University of Tennessee at Knoxville, February 1989.
ノクスビル(1989年2月)の「イーサネット」、RFC1089、レンセラー工科大学、MITコンピュータサイエンス研究所、NYSERNet Inc.、およびテネシー大学。
5. Warrier, U., and L. Besaw, "Common Management Information Services and Protocol over TCP/IP (CMOT)", RFC 1095, Unisys Corporation, and Hewlett-Packard, April 1989.
5. Warrier、U.、L.Besaw、「TCP/IP(CMOT)の上の共通管理情報サービスとプロトコル」、RFC1095、ユニシス社、およびヒューレット・パッカード(1989年4月)。
6. Case, J., M. Fedor, M. Schoffstall, and C. Davin, "Simple Network Management Protocol (SNMP)", RFC 1098, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, and MIT Laboratory for Computer Science, April 1989.
6. ケースとJ.とM.ヒョードル、M.SchoffstallとC.デーヴィン、「簡単なネットワーク管理プロトコル(SNMP)」RFC1098、ノクスビル、NYSERNet Inc.、レンセラー工科大学、およびMITコンピュータサイエンス研究所(1989年4月)のテネシー大学。
Appendix A - Ad Hoc Net Management Review Attendance List
付録A--臨時のネットの経営監査出席リスト
Amatzia Ben-Artzi 3Com Paul Brusil MITRE John Burruss Wellfleet Communications Jeff Case University of Tennessee at Knoxville Vint Cerf National Research Initiatives Ralph Droms Bucknell University (on sabbatical at NRI) Mark Fedor NYSERNet Phill Gross National Research Initiatives Lee LaBarre MITRE Bruce Laird Bolt Beranek and Newman Gary Malkin Proteon Keith McCloghrie Wollongong Craig Partridge Bolt Beranek and Newman Marshall Rose NYSERNet Greg Satz cisco Systems Marty Schoffstall NYSERNet Louis Steinberg IBM Dan Stokesberry NIST Unni Warrier Netlabs
ノクスビルVintサーフNational Research InitiativesラルフDroms Bucknell大学(NRIのサバティカルの)マークヒョードルNYSERNetフィルGross National Research InitiativesのテネシーのAmatziaベン-Artzi 3ComポールBrusil MITREジョンBurruss Wellfleet CommunicationsジェフCase大学; リーLaBarre MITREブルースLaird Bolt Beranek、ニューマンゲーリーマルキンProteonキースMcCloghrieウォロンゴンクレイグPartridge Bolt Beranek、およびニューマンマーシャルローズNYSERNetグレッグSatzコクチマスSystemsマーティSchoffstall NYSERNetルイススタインバーグIBMダンStokesberry NIST Unni Warrier Netlabs
Author's Address
作者のアドレス
Vinton G. Cerf Corporation for National Research Initiatives 1895 Preston White Drive, Suite 100 Reston, VA 22091
レストン、Suite100ヴァージニア 国家の研究イニシアチブ1895のプレストンの白いドライブ、22091へのビントンG.サーフ社
Phone: (703) 620-8990
以下に電話をしてください。 (703) 620-8990
EMail: CERF@A.ISI.EDU
メール: CERF@A.ISI.EDU
Cerf [Page 8]
サーフ[8ページ]
一覧
スポンサーリンク