RFC1419 日本語訳

Network Working Group                                       G. Minshall
Request for Comments: 1419                                 Novell, Inc.
                                                              M. Ritter
                                                   Apple Computer, Inc.
                                                             March 1993

Minshallがコメントのために要求するワーキンググループG.をネットワークでつないでください: 1419 1993年のノベルInc.M.リッター病アップル・コンピューターのInc.行進

                          SNMP over AppleTalk

AppleTalkの上のSNMP

Status of this Memo

このMemoの状態

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Introduction

序論

   This memo describes the method by which the Simple Network Management
   Protocol (SNMP) as specified in [1] can be used over AppleTalk
   protocols [2] instead of the Internet UDP/IP protocol stack.  This
   specification is useful for network elements which have AppleTalk
   support but lack TCP/IP support.  It should be noted that if  a
   network element supports multiple protocol stacks, and UDP is
   available, it is the preferred network layer to use.

このメモはインターネットUDP/IPプロトコル・スタックの代わりにAppleTalkプロトコル[2]の上で[1]の指定されるとしてのSimple Network Managementプロトコル(SNMP)を使用できるメソッドを説明します。 この仕様はAppleTalkサポートにもかかわらず、不足TCP/IPサポートを持っているネットワーク要素の役に立ちます。 ネットワーク要素が、複数のプロトコルがスタックであるとサポートして、UDPが利用可能であるなら、それが使用する都合のよいネットワーク層であることに注意されるべきです。

   SNMP has been successful in managing Internet capable network
   elements which support the protocol stack at least through UDP, the
   connectionless Internet transport layer protocol.  As originally
   designed, SNMP is capable of running over any reasonable transport
   mechanism (not necessarily a transport protocol) that supports bi-
   directional flow and addressability.

SNMPは少なくともUDP(コネクションレスなインターネットトランスポート層プロトコル)を通してプロトコル・スタックを支えるインターネットのできるネットワーク要素を管理するのに成功しています。 元々設計されるように、SNMPは両性愛者の方向の流れとアドレス指定能力をサポートするどんな妥当な移送機構(必ずトランスポート・プロトコルであるというわけではない)もひくことができます。

   Many non-Internet capable network elements are present in networks.
   Some of these elements are equipped with the AppleTalk protocols.
   One method of using SNMP to manage these elements is to define a
   method of transmitting an SNMP message inside an AppleTalk protocol
   data unit.

多くの非インターネットのできるネットワーク要素がネットワークで存在しています。 これらのいくつかの要素はAppleTalkプロトコルを備えています。 これらの要素を管理するSNMPを使用する1つのメソッドはAppleTalkプロトコルデータ単位にSNMPメッセージを送るメソッドを定義することです。

   This RFC is the product of the SNMP over a Multi-protocol Internet
   Working Group of the Internet Engineering Task Force (IETF).

このRFCはMulti-プロトコルの上のSNMPインターネットインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。

1. Background

1. バックグラウンド

   The AppleTalk equivalent of UDP (and IP) is DDP (Datagram Delivery
   Protocol).  The header field of a DDP datagram includes (at least
   conceptually) source and destination network numbers, source and

UDP(そして、IP)のAppleTalk同等物はDDP(データグラムDeliveryプロトコル)です。 そしてソース、DDPデータグラムのヘッダーフィールドが(少なくとも概念的に)のソースと目的地ネットワーク・ナンバーを含んでいる。

Minshall & Ritter                                               [Page 1]

RFC 1419                  SNMP over AppleTalk                 March 1993

1993年のAppleTalk行進の間のMinshallとリッター[1ページ]RFC1419SNMP

   destination node numbers, and source and destination socket numbers.
   Additionally, DDP datagrams include a "protocol type" in the header
   field which may be used to further demultiplex packets.  The data
   portion of a DDP datagram may contain from zero to 586 octets.

目的地ノード番号、ソース、および目的地ソケット番号。 さらに、DDPデータグラムは「反-マルチプレックス」パケットを促進するのに使用されるかもしれないヘッダーフィールドに「プロトコルタイプ」を含んでいます。 DDPデータグラムのデータ部はゼロ〜586まで八重奏を含むかもしれません。

   AppleTalk's Name Binding Protocol (NBP) is a distributed name-to-
   address mapping protocol.  NBP names are logically of the form
   "object:type@zone", where "zone" is determined, loosely, by the
   network on which the named entity resides; "type" is the kind of
   entity being named; and "object" is any string which causes
   "object:type@zone" to be unique in the AppleTalk internet.
   Generally, "object" also helps an end-user determine which instance
   of a specific type of service is being accessed.  NBP names are not
   case sensitive.  Each field of the NBP name ("object", "type", and
   "zone") is  limited to 32 octets.  The octets usually consist of
   human-readable ascii characters.

AppleTalkのName Bindingプロトコル(NBP)は分配された名前からアドレス・マッピングへのプロトコルです。 NBP名は論理的に「ゾーン」がフォーム「オブジェクト: type@zone 」命名された実体があるネットワークで緩く断固としているところのそうです。 「タイプ」は命名される実体の種類です。 そして、「オブジェクト」は「オブジェクト: type@zone 」がAppleTalkインターネットで特有であることを引き起こすあらゆるストリングです。 一般に、また、「オブジェクト」は、エンドユーザが、特定のタイプのサービスのどのインスタンスがアクセスされているかを決心しているのを助けます。 NBP名は大文字と小文字を区別していません。 NBP名(「タイプと、ゾーン」を「反対する」)の各分野は32の八重奏に制限されます。 通常、八重奏は人間読み込み可能なASCIIキャラクタから成ります。

2. Specification

2. 仕様

   SNMP REQUESTS encapsulated according to this standard will be sent to
   DDP socket number 8; they will contain a DDP protocol type of 8.  The
   data octets of the DDP datagram will be a standard SNMP message as
   defined in [1].

この規格に従ってカプセル化されたSNMP REQUESTSをDDPソケットNo.8に送るでしょう。 それらは8人のDDPプロトコルタイプを含むでしょう。 DDPデータグラムのデータ八重奏は[1]で定義されるように標準のSNMPメッセージになるでしょう。

   SNMP RESPONSES encapsulated according to this standard will be sent
   to the DDP socket number which originated the corresponding SNMP
   request; they will contain a DDP protocol type of 8.  The data octets
   of the DDP datagram will be a standard SNMP message as defined in
   [1].  (Note:  as stated in [1], section 4.1, the *source* address of
   a RESPONSE PDU will be the same as the *destination* address of the
   corresponding REQUEST PDU.)

対応するSNMP要求を溯源したDDPソケット番号にこの規格に従ってカプセル化されたSNMP RESPONSESを送るでしょう。 それらは8人のDDPプロトコルタイプを含むでしょう。 DDPデータグラムのデータ八重奏は[1]で定義されるように標準のSNMPメッセージになるでしょう。 (注意: [1]、セクション4.1で述べられているように、RESPONSE PDUの*ソース*アドレスは対応するREQUEST PDUの*目的地*アドレスと同じになるでしょう。)

   A network element which is capable of responding to SNMP REQUESTS
   over AppleTalk must advertise this capability via the AppleTalk Name
   Binding Protocol using an NBP type of "SNMP Agent" (hex 53, 4E, 4D,
   50, 20, 41,  67, 65, 6E, 74).

53人に魔法をかけてください、4Eです、50、20、41、67、65、6Eの4D。AppleTalkの上のSNMP REQUESTSに応じることができるネットワーク要素が「SNMPエージェント」のNBPタイプを使用することでこの能力のAppleTalk Name Bindingプロトコルで広告を出さなければならない、(74)。

   A network management station which is capable of receiving an SNMP
   TRAP must advertise this capability via the AppleTalk Name Binding
   Protocol using an NBP type of "SNMP Trap Handler" (hex 53, 4E, 4D,
   50, 20, 54, 72, 61, 70, 20, 48, 61, 6E, 64, 6C, 65, 72).

SNMP TRAPを受けることができるネットワークマネージメントステーションは、「SNMP罠操作者」のNBPタイプを使用することでこの能力のAppleTalk Name Bindingプロトコルで広告を出さなければなりません(65、72人に53、4Eと、4D、50、20、54、72、61、70、20、48、61、6E、64、6C魔法をかけてください)。

   SNMP TRAPS encapsulated according to this standard will be sent to
   DDP socket number 9; they will contain a DDP protocol type of 8.  The
   data octets of the DDP datagram will be a standard SNMP message as
   defined in [1].  The agent-addr field of the Trap-PDU must be filled
   with a NetworkAddress of all zeros (the unknown IP address). Thus, to
   identify the trap sender, the name and value of the nbpObject and

この規格に従ってカプセル化されたSNMP TRAPSをDDPソケットNo.9に送るでしょう。 それらは8人のDDPプロトコルタイプを含むでしょう。 DDPデータグラムのデータ八重奏は[1]で定義されるように標準のSNMPメッセージになるでしょう。 すべてのゼロ(未知のIPアドレス)のNetworkAddressでTrap-PDUのエージェント-addr分野を満たさなければなりません。 そしてこのようにしてnbpObjectの罠送付者、名前、および値を特定する。

Minshall & Ritter                                               [Page 2]

RFC 1419                  SNMP over AppleTalk                 March 1993

1993年のAppleTalk行進の間のMinshallとリッター[2ページ]RFC1419SNMP

   nbpZone corresponding to the nbpEntry with the nbpType equal to "SNMP
   Agent" should be included in the variable-bindings of any trap that
   is sent [3].

「SNMPエージェント」と等しいnbpTypeとnbpEntryに対応するnbpZoneは[3]が送られるどんな罠の変項束縛にも含まれるべきです。

   The NBP name for both an agent and a trap handler should be stable -
   it should not change any more often than the IP address of a typical
   TCP/IP end system changes.  It is suggested that the NBP name be
   stored in some form of stable storage (PRAM, local disk, etc.).

エージェントと罠操作者の両方のためのNBP名は安定しているべきです--それはもう典型的なTCP/IPエンドシステムのIPアドレスが変化するよりしばしば変化するべきであるというわけではありません。 NBP名が何らかの形式の安定貯蔵(PRAM、ローカルディスクなど)に保存されることが提案されます。

3. Discussion of AppleTalk Addressing

3. AppleTalkアドレシングの議論

3.1 Introduction

3.1 序論

   The AppleTalk protocol suite has certain features not manifest in the
   standard TCP/IP suite.  Its unique naming strategy and the dynamic
   nature of address assignment can cause problems for SNMP management
   stations that wish to manage AppleTalk networks.  TCP/IP end nodes,
   as of this writing, have an associated IP address which distinguishes
   each from the other.  AppleTalk end nodes, in general, have no such
   characteristic.  The network level address, while often relatively
   stable, can change at every reboot (or more frequently).

AppleTalkプロトコル群で、ある特徴は標準のTCP/IPスイートで現れるようになりません。 ユニークな命名戦略とアドレス課題のダイナミックな本質はAppleTalkネットワークを管理したがっているSNMP管理ステーションに問題を起こすことができます。 TCP/IPエンドノードには、この書くこと現在、もう片方とそれぞれを区別する関連IPアドレスがあります。 一般に、AppleTalkエンドノードには、どんなそのような特性もありません。 ネットワークレベルアドレスはあらゆるリブート(より頻繁)のときにしばしば比較的安定している間、変化できます。

   Thus, a thrust of this proposal is that a "name" (as opposed to an
   "address") for an end system be used as the identifying attribute.
   This is the equivalent, when dealing with TCP/IP end nodes, of using
   the domain name.  While the mapping (DNS name, IP address) is more
   stable than the mapping (NBP name, DDP address), the mapping (DNS
   name, IP address) is not required to exist (e.g., hosts with no host
   name, only an IP address). In contrast, all AppleTalk nodes that
   implement this specification are required to respond to NBP lookups
   and confirms (e.g., implement the NBP protocol stub), which
   guarantees that the mapping (NBP name, DDP address) will exist.

したがって、この提案の突きはエンドシステムのための「名前」(「アドレス」と対照的に)が特定属性として使用されるということです。 ドメイン名を使用するTCP/IPエンドノードに対処するとき、これは同等物です。 マッピング(DNS名、IPアドレス)がマッピング(NBP名、DDPアドレス)より安定している間、マッピング(DNS名、IPアドレス)は、存在すること(例えば、ホスト名ではなく、IPアドレスだけをもっているホスト)に必要ではありません。 対照的に、この仕様を履行するすべてのAppleTalkノードが、NBPルックアップに応じるのが必要であり、どれが、マッピング(NBP名、DDPアドレス)が存在するのを保証するかと確認します(例えば、NBPプロトコルスタッブを実装します)。

   In determining the SNMP name to register for an agent, it is
   suggested that the SNMP name be a name which is associated with other
   network services offered by the machine.  On a Macintosh system, for
   example, it is suggested that the system name (the "Macintosh Name"
   for System 7.0 which is used to advertise file sharing, program-to-
   program communication, and possibly other services) be used as the
   "object" field of the NBP name.  This name has AppleTalk
   significance, and is tightly bound to the network's concept of a
   given system's identity.

SNMP名がエージェントに登録することを決定する際に、SNMP名がマシンで提供する他のネットワーク・サービスに関連している名前であると示唆されます。 マッキントッシュシステムで、例えば、システム名(ファイル共有の広告を出すのに使用されるSystem7.0のための「マッキントッシュ名」、プログラムからプログラムへのコミュニケーション、およびことによると他のサービス)がNBP名の「オブジェクト」分野として使用されることが提案されます。 この名前は、AppleTalk意味を持って、しっかり与えられたシステムのアイデンティティに関するネットワークの概念に縛られます。

   NBP lookups, which are used to turn NBP names into DDP addresses, can
   cause large amounts of network traffic as well as consume CPU
   resources. It is also the case that the ability to perform an NBP
   lookup is sensitive to certain network disruptions (such as zone
   table inconsistencies, etc.) which would not prevent direct AppleTalk

NBPルックアップ(NBP名をDDPアドレスに変えるのに使用される)は、多量のネットワークトラフィックを引き起こして、CPUリソースを消費できます。 また、NBPルックアップを実行する能力がダイレクトAppleTalkを防がない、あるネットワーク分裂(ゾーンテーブル矛盾などの)に敏感であることは、事実です。

Minshall & Ritter                                               [Page 3]

RFC 1419                  SNMP over AppleTalk                 March 1993

1993年のAppleTalk行進の間のMinshallとリッター[3ページ]RFC1419SNMP

   communications between a management station and an agent.

管理局とエージェントとのコミュニケーション。

   Thus, it is recommended that NBP lookups be used infrequently with
   the primary purpose being to create a cache of name-to-address
   mappings. These cached mappings should then be used for any further
   SNMP requests. It is recommended that SNMP management stations
   maintain this cache between reboots.  This caching can help minimize
   network traffic, reduce CPU load on the network, and allow for (some
   amount of) network trouble shooting when the basic name-to-address
   translation mechanism is broken.

したがって、NBPルックアップが使用されているのが、プライマリ目的で名前からアドレス・マッピングのキャッシュをまれに作成することであるということであることはお勧めです。 そして、これらのキャッシュされたマッピングはどんなさらなるSNMP要求にも使用されるべきです。 SNMP管理局がリブートの間のこのキャッシュを維持するのは、お勧めです。 このキャッシュが、ネットワークトラフィックを最小にするのを助けることができて、ネットワークでCPU荷重を抑えてください、許容、(或るものが達する、)、名前からアドレス変換への基本的なメカニズムが壊れているときにはトラブルシューティングをネットワークでつないでください。

3.2 How To Acquire NBP names:

3.2 To Acquire NBPはどう以下を命名するか。

   A management station may have a pre-configured list of names of
   agents to manage. A management station may allow for an interaction
   with an operator in which a list of manageable agents is acquired
   (via NBP) and presented for the operator to choose which agents
   should be managed by that management station.  Finally, a management
   station may manage all manageable agents in a set of zones or
   networks.

管理局には、管理するエージェントのあらかじめ設定された名簿があるかもしれません。 管理ステーションは、処理しやすいエージェントのリストが取得されて(NBPを通して)、オペレータのために提示されるオペレータとの相互作用が、どのエージェントがその管理局によって管理されるべきであるかを選ぶのを許容するかもしれません。 最終的に、管理局は1セットのゾーンかネットワークのすべての処理しやすいエージェントを管理するかもしれません。

   An agent must be configured with the name of a specific management
   station or group of management stations before sending SNMP traps.
   In the absence of any such configured information, an agent is NOT to
   generate any SNMP traps.  In particular, an agent is NEVER to
   initiate a wildcard NBP lookup to find a management station to
   receive a trap.  All NBP lookups generated by an agent must be fully
   specified.  Note, however, that this does not apply to a
   configuration utility that might be associated with such an agent.
   Such a utility may well allow a user to navigate around the network
   to select a management station or stations to receive SNMP traps from
   the agent.

罠をSNMPに送る前に、管理局の特定の管理局かグループの名前でエージェントを構成しなければなりません。 そのようなどんな構成された情報がないとき、どんなSNMP罠も生成するために、エージェントはいません。 特に、エージェントは、罠を受けるために管理局を見つけるためにワイルドカードNBPルックアップを決して開始することになっていません。 エージェントによって生成されたすべてのNBPルックアップを完全に指定しなければなりません。 しかしながら、これがそのようなエージェントに関連するかもしれない構成ユーティリティに適用されないことに注意してください。 そのようなユーティリティで、ユーザは、管理局かステーションがエージェントからSNMP罠を受けるのを選択するためにたぶんネットワークの周りでナビゲートできるでしょう。

3.3 When To Turn NBP Names Into Addresses:

3.3 いつNBPをターンするかは以下をアドレスと命名します。

   When SNMP agents or management stations use a cache entry to address
   an SNMP packet, they should attempt to confirm the mapping if it
   hasn't been confirmed in T1 seconds.  This cache entry lifetime, T1,
   has a minimum, default value of 60 seconds.  This value should be
   configurable.

SNMPエージェントか管理局がSNMPパケットを扱うのにキャッシュエントリーを使用して、それがT1秒に確認されていないなら、それらは、マッピングを確認するのを試みるべきです。 エントリー生涯(T1)で最小限、デフォルトが評価する60秒のこのキャッシュ。 この値は構成可能であるべきです。

   A management station may decide to prime its cache of names prior to
   actually sending any SNMP requests to any given agent.  In general,
   it is expected that a management station may want to keep certain
   mappings "more current" than other mappings.  In particular, those
   nodes which represent the network infrastructure (routers, etc.) may
   be deemed "more important" by the management station.

管理局は、実際にどんなSNMP要求もどんな与えられたエージェントにも送る前に名前のキャッシュを用意すると決めるかもしれません。 一般に、管理局が「他のマッピングより現在」に、あるマッピングを保ちたがっているかもしれないと予想されます。 特に、ネットワークインフラ(ルータなど)を表すそれらのノードは管理局によって「より重要である」と考えられるかもしれません。

Minshall & Ritter                                               [Page 4]

RFC 1419                  SNMP over AppleTalk                 March 1993

1993年のAppleTalk行進の間のMinshallとリッター[4ページ]RFC1419SNMP

   Note, however, that a long-running management station starting up and
   reading a configuration file containing a number of NBP names should
   not attempt to prime its cache all at once.  It should, instead,
   issue the resolutions over an extended period of time (perhaps in
   some pre-determined or configured priority order).  Each resolution
   might, in fact, be a wildcard lookup in a given zone.

しかしながら、多くのNBP名を含む構成ファイルを立ち上げて、読む長い実行している管理局が、キャッシュを一気に用意するのを試みるはずがないことに注意してください。 それは代わりに時間(恐らく何らかの予定されたか構成された優先順による)の長期間の間、決議を発布するべきです。 事実上、各解決は与えられたゾーンのワイルドカードルックアップであるかもしれません。

   An agent should NEVER prime its cache.  It should do NBP lookups (or
   confirms) only when it needs to send an SNMP trap to a given
   management station.  An agent does not need to confirm a cache entry
   to reply to a request.

エージェントはキャッシュを決して用意するべきではありません。 NBPにルックアップをするべきである、(確認、)、SNMP罠を与えられた管理局に送る必要がある場合にだけ。 エージェントは、要求に答えるためにキャッシュエントリーを確認する必要はありません。

3.4 How To Turn NBP Names Into Addresses:

3.4 NBPをターンするのはどう以下をアドレスと命名するか。

   If the only piece of information available is the NBP name, then an
   NBP lookup should be performed to turn that name into a DDP address.

唯一の利用可能な情報がNBP名であるなら、NBPルックアップは、その名前をDDPアドレスに変えるために実行されるべきです。

   However, if there is a piece of stale information, it can be used as
   a hint to perform an NBP confirm (which sends a unicast to the
   network address which is presumed to be the target of the name
   lookup) to see if the stale information is, in fact, still valid.

しかしながら、1つの聞き古した情報があれば、NBPを実行するのにヒントとしてそれを使用できる、確認、(あえてルックアップという名前の目標であるネットワーク・アドレスにユニキャストを送ります) 事実上、聞き古した情報がまだ有効であるかどうか確認するために。

   An NBP name to DDP address mapping can also be confirmed implicitly
   using only SNMP transactions.  If a management station is sending a
   get-request, it can add a request, in the same packet, for the
   destination's nbpObject and nbpZone corresponding to the nbpEntry
   with the nbpType equal to "SNMP Agent" [3].  The source DDP address
   can be gleaned from the reply and used with the nbpObject and nbpZone
   returned to confirm the cache entry.

また、それとなくSNMPトランザクションだけを使用することでDDPアドレス・マッピングへのNBP名を確認できます。 管理局が要求を得てaを送るなら、要求を加えることができます、同じパケットで、目的地の「SNMPエージェント」[3]と等しいnbpTypeとnbpEntryに対応するnbpObjectとnbpZoneのために。 キャッシュエントリーを確認するのにソースDDPアドレスを回答から収集して、返すnbpObjectとnbpZoneと共に使用できます。

   The above notwithstanding, for set-requests, there is a race
   condition that can occur where an SNMP request may go to the wrong
   agent (because the old node went down and a new node came up with the
   same DDP address.)  This is problematic becase the wrong agent might
   generate a response packet that the management station could not
   distinguish from a reply from the intended agent.  In the future,
   when SNMP security is implemented, each packet is authenticated at
   the destination, and the reply should implicitly confirm the validity
   of the cache entry used and prevent this race condition.

上記に、セット要求のために、SNMP要求が間違ったエージェントのものになるかもしれない(古いノードが落ちて、新しいノードが同じDDPアドレスを思いついたので)ところに起こることができる競合条件があります。 これは間違ったエージェントが管理局が回答と意図しているエージェントと区別できなかった応答パケットを生成するかもしれない問題の多いbecaseです。 未来に、各パケットが目的地で認証されて、回答は、それとなくエントリーが使用したキャッシュの正当性を確認して、この競合条件を防ぐべきです。(その時、SNMPセキュリティは実装されます)。

3.5 What if NBP is broken:

3.5 NBPが壊れていると、どうなるだろうか:

   Under some circumstances, there may be connectivity between a
   management station and an agent, but the NBP machinery required to
   turn an NBP name into a DDP address may be broken.  Examples of
   failures which would cause this include:  NBP FwdReq (forward NBP
   lookup onto locally attached network) broken at a router on the
   network containing the agent; NBP BrRq (NBP broadcast request)

いくつかの状況で、管理局とエージェントの間には、接続性があるかもしれませんが、機械がNBP名をDDPアドレスに変えるのを必要としたNBPは壊れているかもしれません。 これを引き起こす失敗に関する例は: エージェントを含むネットワークでルータで壊れているNBP FwdReq(局所的に添付のネットワークへの前進のNBPルックアップ)。 NBP BrRq(NBP放送要求)

Minshall & Ritter                                               [Page 5]

RFC 1419                  SNMP over AppleTalk                 March 1993

1993年のAppleTalk行進の間のMinshallとリッター[5ページ]RFC1419SNMP

   mechanism broken at a router on the network containing the managment
   station (because of a zone table mis-configuration, for example); or
   NBP broken in the target node.

managmentステーション(例えばゾーンテーブル誤構成のために)を含むネットワークでルータで壊れているメカニズム。 または、目標ノードで壊れているNBP。

   A management station which is dedicated to AppleTalk management might
   choose to alleviate some of these failures by implementing the router
   portion of NBP within the management station itself.  For example,
   the management station might already know all the zones on the
   AppleTalk internet and the networks on which each zone appears.
   Given an NBP lookup which fails, the management station could send an
   NBP FwdReq to the network in which the agent was last located.  If
   that failed, the station could then send an NBP LkUp (an NBP lookup
   packet) as a directed (DDP) multicast to each network number on that
   network.  Of the above (single) failures, this combined approach will
   solve the case where either the local router's BrRq to NBP FwdReq
   mechanism is broken or the remote router's NBP FwdReq to NBP LkUp
   mechanism is broken.

AppleTalk管理に捧げられる管理局は、管理局自体の中でNBPのルータ一部を実装することによってこれらの失敗のいくつかを軽減するのを選ぶかもしれません。 例えば、管理ステーションは既に、AppleTalkインターネットのすべてのゾーンと各ゾーンが現れるネットワークを知るかもしれません。 失敗するNBPルックアップを考えて、管理局はエージェントが最後に位置したネットワークにNBP FwdReqを送るかもしれません。 それが失敗するなら、ステーションは指示された(DDP)マルチキャストとしてNBP LkUp(NBPルックアップパケット)をそのネットワークの各ネットワーク・ナンバーに送ることができるでしょうに。 上(単一の)の失敗では、この結合したアプローチはNBP FwdReqメカニズムへのローカルルータのBrRqが壊れているか、またはNBP LkUpメカニズムへのリモートルータのNBP FwdReqが壊れているケースを解決するでしょう。

4. Acknowledgements

4. 承認

   Some of the boilerplate in this memo is copied from [4], [5], and
   [6].  The Apple-IP Working Group was instrumental in defining this
   document.  Their support and work was greatly appreciated.

このメモによる決まり文句のいくつかが[4]、[5]、および[6]からコピーされます。 アップル-IP作業部会はこのドキュメントを定義する際に手段になっていました。 彼らのご支援と仕事に大いに感謝しました。

5. References

5. 参照

   [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
       Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP
       Research, Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

[1] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル(SNMP)」、STD15、RFC1157、SNMPは研究します、国際言語運用機構、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。

   [2] Sidhu, G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk
       (Second Edition)", Addison-Wesley, 1990.

[2]SidhuとG.とアンドリュース、R.とA.オッペンハイマー、「AppleTalk(第2版)」アディソン-ウエスリー、1990。

   [3] Waldbusser, S., "AppleTalk Management Information Base", RFC
       1243, Carnegie Mellon University, August 1991.

[3]Waldbusser、S.、「AppleTalk管理情報ベース」、RFC1243、カーネギメロン大学、1991年8月。

   [4] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over
       Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT
       Laboratory for Computer Science, NYSERNet, Inc., University of
       Tennessee at Knoxville, February 1989.

[4]SchoffstallとM.とデーヴィンとC.とヒョードル、M.とJ.ケース、「イーサネットの上のSNMP」RFC1089、レンセラー工科大学、MITコンピュータサイエンス研究所、NYSERNet Inc.、ノクスビル(1989年2月)のテネシー大学。

   [5] Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.

[5]Bostock、S.、「IPXの上のSNMP」、RFC1420、ノベルInc.、1993年3月。

   [6] Piscitello, D., "Guidelines for the Specification of Protocol
       Support of the SNMP", Work in Progress.

[6] D.、「SNMPのプロトコルサポートの仕様のためのガイドライン」というPiscitelloは進行中で働いています。

Minshall & Ritter                                               [Page 6]

RFC 1419                  SNMP over AppleTalk                 March 1993

1993年のAppleTalk行進の間のMinshallとリッター[6ページ]RFC1419SNMP

6. Security Considerations

6. セキュリティ問題

   Security issues are discussed in section 3.4.

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

7. Authors' Addresses

7. 作者のアドレス

   Greg Minshall
   Novell, Inc.
   1340 Treat Blvd, ste. 500
   Walnut Creek, CA  94596

グレッグMinshallノベルInc.1340トリートBlvd、ste。 500 ウォールナットクリーク、カリフォルニア 94596

   Phone: 510 947-0998
   Fax:   510 947-1238
   EMail:  minshall@wc.novell.com

以下に電話をしてください。 510 947-0998 Fax: 510 947-1238 メールしてください: minshall@wc.novell.com

   Mike Ritter
   Apple Computer, Inc.
   10500 North De Anza Boulevard, MS: 35-K
   Cupertino, California 95014

マイクリッター病アップル・コンピューターInc.10500の北のDeアンサBoulevard、MS: 35Kのカルパチーノ、カリフォルニア 95014

   Phone: 408 862-8088
   Fax:   408 862-1159
   EMail: MWRITTER@applelink.apple.com

以下に電話をしてください。 408 862-8088 Fax: 408 862-1159 メールしてください: MWRITTER@applelink.apple.com

Minshall & Ritter                                               [Page 7]

Minshallとリッター[7ページ]