RFC5190 日本語訳
5190 Definitions of Managed Objects for Middlebox Communication. J.Quittek, M. Stiemerling, P. Srisuresh. March 2008. (Format: TXT=204929 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Quittek
Request for Comments: 5190 M. Stiemerling
Category: Standards Track NEC
P. Srisuresh
Kazeon Systems
March 2008
Quittekがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5190年のM.Stiemerlingカテゴリ: 2008年の標準化過程NEC P.Srisuresh Kazeonシステム行進
Definitions of Managed Objects for Middlebox Communication
Middleboxコミュニケーションのための管理オブジェクトの定義
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、middleboxesを構成する1セットの管理オブジェクトについて説明します、ファイアウォールやネットワークアドレス変換機構のように、これらのデバイスの向こう側にコミュニケーションを可能にするために。 このドキュメントとの管理オブジェクトの定義は密接にRFC5189で定義されたMIDCOM意味論に従います。
Quittek, et al. Standards Track [Page 1] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................4
2. The Internet-Standard Management Framework ......................4
3. Overview ........................................................4
3.1. Terminology ................................................5
4. Realizing the MIDCOM Protocol with SNMP .........................6
4.1. MIDCOM Sessions ............................................6
4.1.1. Authentication and Authorization ....................6
4.2. MIDCOM Transactions ........................................7
4.2.1. Asynchronous Transactions ...........................7
4.2.2. Configuration Transactions ..........................8
4.2.3. Monitoring Transactions ............................11
4.2.4. Atomicity of MIDCOM Transactions ...................12
4.2.4.1. Asynchronous MIDCOM Transactions ..........12
4.2.4.2. Session Establishment and
Termination Transactions ..................12
4.2.4.3. Monitoring Transactions ...................13
4.2.4.4. Lifetime Change Transactions ..............13
4.2.4.5. Transactions Establishing New
Policy Rules ..............................14
4.2.5. Access Control .....................................14
4.3. Access Control Policies ...................................14
5. Structure of the MIB Module ....................................15
5.1. Transaction Objects .......................................16
5.1.1. midcomRuleTable ....................................17
5.1.2. midcomGroupTable ...................................19
5.2. Configuration Objects .....................................20
5.2.1. Capabilities .......................................20
5.2.2. midcomConfigFirewallTable ..........................21
5.3. Monitoring Objects ........................................22
5.3.1. midcomResourceTable ................................22
5.3.2. midcomStatistics ...................................24
5.4. Notifications .............................................25
6. Recommendations for Configuration and Operation ................26
6.1. Security Model Configuration ..............................26
6.2. VACM Configuration ........................................27
6.3. Notification Configuration ................................28
6.4. Simultaneous Access .......................................28
6.5. Avoiding Idempotency Problems .............................29
6.6. Interface Indexing Problems ...............................29
6.7. Applicability Restrictions ................................30
7. Usage Examples for MIDCOM Transactions .........................30
7.1. Session Establishment (SE) ................................31
7.2. Session Termination (ST) ..................................31
7.3. Policy Reserve Rule (PRR) .................................31
7.4. Policy Enable Rule (PER) after PRR ........................33
7.5. Policy Enable Rule (PER) without Previous PRR .............34
1. 序論…4 2. インターネット標準の管理フレームワーク…4 3. 概要…4 3.1. 用語…5 4. SNMPと共にMIDCOMプロトコルがわかります…6 4.1. MIDCOMセッション…6 4.1.1. 認証と承認…6 4.2. MIDCOMトランザクション…7 4.2.1. 非同期なトランザクション…7 4.2.2. 構成トランザクション…8 4.2.3. トランザクションをモニターします…11 4.2.4. MIDCOMトランザクションの最小単位…12 4.2.4.1. 非同期なMIDCOMトランザクション…12 4.2.4.2. セッション設立と終了トランザクション…12 4.2.4.3. トランザクションをモニターします…13 4.2.4.4. 生涯変化トランザクション…13 4.2.4.5. 新しい政策規則を確立するトランザクション…14 4.2.5. コントロールにアクセスしてください…14 4.3. コントロール方針にアクセスしてください…14 5. MIBモジュールの構造…15 5.1. トランザクションオブジェクト…16 5.1.1midcomRuleTable…17 5.1.2midcomGroupTable…19 5.2. 構成オブジェクト…20 5.2.1. 能力…20 5.2.2midcomConfigFirewallTable…21 5.3. モニターしているオブジェクト…22 5.3.1midcomResourceTable…22 5.3.2midcomStatistics…24 5.4. 通知…25 6. 構成と操作のための推薦…26 6.1. セキュリティは構成をモデル化します…26 6.2. VACM構成…27 6.3. 通知構成…28 6.4. 同時のアクセス…28 6.5. Idempotency問題を避けます…29 6.6. 問題に索引をつけて、連結してください…29 6.7. 適用性制限…30 7. MIDCOMトランザクションのための用法の例…30 7.1. セッション設立(SE)…31 7.2. セッション終了(ST)…31 7.3. 責任準備金規則(PRR)…31 7.4. 方針は規則(PER)後PRRを有効にします…33 7.5. 方針は前のPRRなしで規則(PER)を可能にします…34
Quittek, et al. Standards Track [Page 2] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[2ページ]。
7.6. Policy Rule Lifetime Change (RLC) .........................35
7.7. Policy Rule List (PRL) ....................................35
7.8. Policy Rule Status (PRS) ..................................35
7.9. Asynchronous Policy Rule Event (ARE) ......................36
7.10. Group Lifetime Change (GLC) ..............................36
7.11. Group List (GL) ..........................................36
7.12. Group Status (GS) ........................................37
8. Usage Examples for Monitoring Objects ..........................37
8.1. Monitoring NAT Resources ..................................37
8.2. Monitoring Firewall Resources .............................38
9. Definitions ....................................................38
10. Security Considerations .......................................85
10.1. General Security Issues ..................................85
10.2. Unauthorized Middlebox Configuration .....................86
10.3. Unauthorized Access to Middlebox Configuration ...........87
10.4. Unauthorized Access to MIDCOM Service Configuration ......88
11. Acknowledgements ..............................................88
12. IANA Considerations ...........................................88
13. Normative References ..........................................88
14. Informative References ........................................90
7.6. 政策ルール生涯変化(RLC)…35 7.7. 政策ルールリスト(PRL)…35 7.8. 政策ルール状態(PRS)…35 7.9. 非同期な政策ルールイベント(あります)…36 7.10. 生涯変化(GLC)を分類してください…36 7.11. リスト(GL)を分類してください…36 7.12. 状態(GS)を分類してください…37 8. モニターしているオブジェクトのための用法の例…37 8.1. NATリソースをモニターします…37 8.2. ファイアウォールリソースをモニターします…38 9. 定義…38 10. セキュリティ問題…85 10.1. 総合証券問題…85 10.2. 権限のないMiddlebox構成…86 10.3. Middlebox構成への権限のないアクセス…87 10.4. MIDCOMサービス構成への権限のないアクセス…88 11. 承認…88 12. IANA問題…88 13. 標準の参照…88 14. 有益な参照…90
Quittek, et al. Standards Track [Page 3] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[3ページ]。
1. Introduction
1. 序論
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow controlling middleboxes.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはmiddleboxesを制御する1セットの管理オブジェクトについて説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. The Internet-Standard Management Framework
2. インターネット標準の管理フレームワーク
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、RFC3410[RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIBオブジェクトはSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBのオブジェクトは、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されるSMIv2に対応であるMIBモジュールを指定します。
3. Overview
3. 概要
The managed objects defined in this document serve for controlling firewalls and Network Address Translators (NATs). As defined in [RFC3234], firewalls and NATs belong to the group of middleboxes. A middlebox is a device on the datagram path between source and destination, which performs other functions than just IP routing. As outlined in [RFC3303], firewalls and NATs are potential obstacles to packet streams, for example, if dynamically negotiated UDP or TCP port numbers are used, as in many peer-to-peer communication applications.
本書では定義された管理オブジェクトはファイアウォールを制御して、Network Address Translators(NATs)を満たします。 [RFC3234]で定義されるように、ファイアウォールとNATsはmiddleboxesのグループのものです。 middleboxはソースと目的地の間のデータグラム経路のデバイスです。(それは、まさしくIPルーティング以外の機能を実行します)。 [RFC3303]に概説されているように、例えば、ダイナミックに交渉されたUDPかTCPポートナンバーが使用されているなら、ファイアウォールとNATsはパケットストリームへの潜在的障害です、多くのピアツーピアコミュニケーションアプリケーションのように。
As one possible solution for this problem, the IETF MIDCOM working group defined a framework [RFC3303], requirements [RFC3304], and protocol semantics [RFC5189] for communication between applications and middleboxes acting as firewalls, NATs, or a combination of both. The MIDCOM architecture and framework define a model in which trusted third parties can be delegated to assist middleboxes in performing their operations, without requiring application intelligence being embedded in the middleboxes. This trusted third party is referred to as the MIDCOM agent. The MIDCOM protocol is defined between a MIDCOM agent and a middlebox.
この問題のための1つの可能なソリューションと、IETF MIDCOMワーキンググループは両方のファイアウォール、NATs、または組み合わせとして作動するアプリケーションとmiddleboxesとのコミュニケーションのために、フレームワーク[RFC3303]、要件[RFC3304]、およびプロトコル意味論[RFC5189]を定義しました。 MIDCOMアーキテクチャとフレームワークは彼らの操作を実行するのにmiddleboxesを助けるのを信頼できる第三者機関を代表として派遣することができるモデルを定義します、middleboxesに埋め込まれているアプリケーション知性を必要としないで。 この信頼できる第三者機関はMIDCOMエージェントと呼ばれます。 MIDCOMプロトコルはMIDCOMエージェントとmiddleboxの間で定義されます。
Quittek, et al. Standards Track [Page 4] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[4ページ]。
The managed objects defined in this document can be used for dynamically configuring middleboxes on the datagram path to permit datagrams traversing the middleboxes. This way, applications can, for example, request pinholes at firewalls and address bindings at NATs.
データグラムを可能にするためにmiddleboxesを横断しながらデータグラム経路でダイナミックにmiddleboxesを構成するのに本書では定義された管理オブジェクトは使用できます。 このように、例えば、アプリケーションはファイアウォールとアドレス結合のときにNATsでピンホールを要求できます。
Besides managed objects for controlling the middlebox operation, this document also defines managed objects that provide information on middlebox resource usage (such as firewall pinholes, NAT bindings, NAT sessions, etc.) affected by requests.
また、middlebox操作を制御するための管理オブジェクト以外に、このドキュメントは要求で影響を受けるmiddleboxリソース用法(ファイアウォールピンホール、NAT結合、NATセッションなどの)の情報を提供する管理オブジェクトを定義します。
Since firewalls and NATs are critical devices concerning network security, security issues of middlebox communication need to be considered very carefully.
ファイアウォールとNATsがネットワークセキュリティに関する重大なデバイスであるので、middleboxコミュニケーションの安全保障問題は、非常に慎重に考えられる必要があります。
3.1. Terminology
3.1. 用語
The terminology used in this document is fully aligned with the terminology defined in [RFC5189] except for the term 'MIDCOM agent'. For this term, there is a conflict between the MIDCOM terminology and the SNMP terminology. The roles of entities participating in SNMP communication are called 'manager' and 'agent' with the agent acting as server for requests from the manager. This use of the term 'agent' is different from its use in the MIDCOM framework: The SNMP manager corresponds to the MIDCOM agent and the SNMP agent corresponds to the MIDCOM middlebox, also called MIDCOM server. In order to avoid confusion in this document specifying a MIB module, we replace the term 'MIDCOM agent' with 'MIDCOM client'. Whenever the term 'agent' is used in this document, it refers to the SNMP agent. Figure 1 sketches the entities of MIDCOM in relationship to SNMP manager and SNMP agent.
本書では使用される用語は'MIDCOMエージェント'という用語を除いた[RFC5189]で定義される用語に完全に並べられます。 今期の間、MIDCOM用語とSNMP用語との闘争があります。 エージェントが要求のためのサーバとして務めていて、SNMPコミュニケーションに参加する実体の役割はマネージャから'マネージャ'と'エージェント'と呼ばれます。 'エージェント'という用語のこの使用はMIDCOMフレームワークにおける使用と異なっています: SNMPマネージャはMIDCOMエージェントに文通します、そして、SNMPエージェントはまた、MIDCOMサーバと呼ばれるMIDCOM middleboxに文通します。本書ではMIBモジュールを指定する混乱を避けるために、私たちは'MIDCOMエージェント'という用語を'MIDCOMクライアント'に取り替えます。 'エージェント'という用語が本書では使用されるときはいつも、それはSNMPエージェントについて言及します。 図1はSNMPマネージャとSNMPエージェントとの関係における、MIDCOMの実体についてスケッチします。
+---------+ MIDCOM +-----------+
| MIDCOM |<~ ~ ~ ~ ~ ~ ~ ~>| MIDCOM |
| Client | Transaction | middlebox |
| | | (server) |
+---------+ +-----------+
^ ^
| |
v v
+---------+ +-----------+
| SNMP | SNMP | SNMP |
| Manager |<===============>| Agent |
+---------+ Protocol +-----------+
+---------+ MIDCOM+-----------+ | MIDCOM|<~ ~ ~ ~ ~ ~ ~ ~>| MIDCOM| | クライアント| トランザクション| middlebox| | | | (サーバ) | +---------+ +-----------+ ^ ^ | | v対+---------+ +-----------+ | SNMP| SNMP| SNMP| | マネージャ|<========>| エージェント| +---------+ プロトコル+-----------+
Figure 1: Mapping of MIDCOM to SNMP
図1: SNMPへのMIDCOMに関するマッピング
Quittek, et al. Standards Track [Page 5] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[5ページ]。
4. Realizing the MIDCOM Protocol with SNMP
4. SNMPと共にMIDCOMプロトコルがわかります。
In order to realize middlebox communication as described in [RFC5189], several aspects and properties of the MIDCOM protocol need to be mapped to SNMP capabilities and expressed in terms of the Structure of Management Information version 2 (SMIv2).
[RFC5189]で説明されるようにmiddleboxコミュニケーションがわかるために、MIDCOMプロトコルのいくつかの局面と特性は、SNMP能力に写像されて、Management情報バージョン2(SMIv2)のStructureに関して言い表される必要があります。
Basic concepts to be mapped are MIDCOM sessions and MIDCOM transactions. For both, access control policies need to be supported.
写像するべき基本概念は、MIDCOMセッションとMIDCOMトランザクションです。 両方のために、アクセス制御方針は、サポートされる必要があります。
4.1. MIDCOM Sessions
4.1. MIDCOMセッション
SNMP has no direct support for sessions. Therefore, they need to be modeled. A MIDCOM session is stateful and has a context that is valid for several transactions. For SNMP, a context is valid for a single transaction only, for example, covering just a single request/reply pair of messages.
SNMPには、セッションのどんなダイレクトサポートもありません。 したがって、彼らは、モデル化される必要があります。 MIDCOMセッションは、statefulで、いくつかのトランザクションに、有効な文脈を持っています。 SNMPに関しては、単に、そして、例えば、単一取引に、文脈は有効です、ちょうどメッセージのただ一つの要求/回答組をカバーしていて。
Properties of sessions that are utilized by the MIDCOM semantics and not available in SNMP need to be modeled. Particularly, the middlebox needs to be able to authenticate MIDCOM clients, authorize access to policy rules, and send notification messages concerning policy rules to MIDCOM clients participating in a session. In the MIDCOM-MIB module, authentication and access control are performed on a per-message basis using an SNMPv3 security model, such as the User-based Security Model (USM) [RFC3414], for authentication, and the View-based Access Control Model (VACM) [RFC3415] for access control. Sending notifications to MIDCOM clients is controlled by access control models such as VACM and a mostly static configuration of objects in the SNMP-TARGET-MIB [RFC3413] and the SNMP- NOTIFICATION-MIB [RFC3413].
MIDCOM意味論によって利用された、SNMPで利用可能でないセッションの特性は、モデル化される必要があります。 特に、middleboxはMIDCOMクライアントを認証して、政策ルールへのアクセスを認可して、MIDCOMクライアントへの政策ルールに関する通知メッセージが会議に参加させることができる必要があります。 MIDCOM-MIBモジュールでは、認証とアクセスコントロールは1メッセージあたり1個のベースにSNMPv3機密保護モデルを使用することで実行されます、UserベースのSecurity Model(USM)[RFC3414]などのように、認証、およびアクセスコントロールのためのViewベースのAccess Control Model(VACM)[RFC3415]のために。 MIDCOMクライアントに通告を送るのはVACMやSNMP-TARGET-MIB[RFC3413]とSNMP- NOTIFICATION-MIB[RFC3413]でのオブジェクトのほとんど静的な構成などのアクセス制御モデルによって制御されます。
This session model is static except that the MIDCOM client can switch on and off the generation of SNMP notifications that the middlebox sends. Recommended configurations of VACM and the SNMP-TARGET-MIB and the SNMP-NOTIFICATION-MIB that can serve for modeling a session are described in detail in section 6.
MIDCOMクライアントが断続的にmiddleboxが発信するというSNMP通知の世代を切り換えることができるのを除いて、このセッションモデルは静的です。 セッションをモデル化するために役立つことができるVACM、SNMP-TARGET-MIB、およびSNMP-NOTIFICATION-MIBのお勧めの構成はセクション6で詳細に説明されます。
4.1.1. Authentication and Authorization
4.1.1. 認証と承認
MIDCOM sessions are required for providing authentication, authorization, and encryption for messages exchanged between a MIDCOM client and a middlebox. SNMPv3 provides these features on a per- message basis instead of a per-session basis applying a security model and an access control model, such as USM and VACM. Per-message
MIDCOMセッションが、MIDCOMクライアントとmiddleboxの間で交換されたメッセージのための認証、承認、および暗号化を提供するのに必要です。 SNMPv3がaに関するこれらの特徴を提供する、-、機密保護モデルを適用する1セッションあたり1つの基礎の代わりにメッセージ基礎とアクセス制御はモデル化されます、USMやVACMのように。 メッセージ
Quittek, et al. Standards Track [Page 6] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[6ページ]。
security mechanisms can be considered as overhead compared to per- session security mechanisms, but it certainly satisfies the security requirements of middlebox communication.
セキュリティー対策を比較されたオーバーヘッドと考えることができる、-、セッションセキュリティー対策、確かに、それだけがmiddleboxコミュニケーションのセキュリティ要件を満たします。
For each authenticated MIDCOM client, access to the MIDCOM-MIB, particularly to policy rules, should be configured as part of the VACM configuration of the SNMP agent.
それぞれの認証されたMIDCOMクライアントに関しては、MIDCOM-MIBと、そして、特に政策ルールへのアクセスはSNMPエージェントのVACM構成の一部として構成されるべきです。
4.2. MIDCOM Transactions
4.2. MIDCOMトランザクション
[RFC5189] defines the MIDCOM protocol semantics in terms of transactions and transaction parameters. Transactions are grouped into request-reply transactions and asynchronous transactions.
[RFC5189]はトランザクションとトランザクションパラメタに関してMIDCOMプロトコル意味論を定義します。 トランザクションは要求回答トランザクションと非同期なトランザクションに分類されます。
SNMP offers simple transactions that in general cannot be mapped one-to-one to MIDCOM transactions. This section describes how the MIDCOM-MIB module implements MIDCOM transactions using SNMP transactions. The concerned MIDCOM transactions are asynchronous transactions and request-reply transactions. Within the set of request-reply transactions, we distinguish configuration transactions and monitoring transactions, because they are implemented in slightly different ways by using SNMP transactions.
SNMPは一般に、1〜1にMIDCOMトランザクションに写像できない単純取引を提供します。 このセクションはMIDCOM-MIBモジュールがSNMPトランザクションを使用することでどうトランザクションを実装するかをMIDCOMに説明します。 関係があるMIDCOMトランザクションは、非同期なトランザクションと要求回答トランザクションです。 要求回答トランザクションのセットの中では、私たちは構成トランザクションとモニターしているトランザクションを区別します、それらがSNMPトランザクションを使用することによってわずかに異なった方法で実装されるので。
The SNMP terminology as defined in [RFC3411] does not use the concept of transactions, but of SNMP operations. For the considerations in this section, we use the terms SNMP GET transaction and SNMP SET transaction. An SNMP GET transaction consists of an SNMP Read Class operation and an SNMP Response Class operation. An SNMP SET transaction consists of an SNMP Write Class operation and an SNMP Response Class operation.
[RFC3411]で定義されるSNMP用語はトランザクションについて概念を使用するのではなく、SNMP操作について使用します。 このセクションの問題のために、私たちは用語SNMP GETトランザクションとSNMP SETトランザクションを使用します。 SNMP GETトランザクションはSNMP Read Class操作とSNMP Response Class操作から成ります。 SNMP SETトランザクションはSNMP Write Class操作とSNMP Response Class操作から成ります。
4.2.1. Asynchronous Transactions
4.2.1. 非同期なトランザクション
Asynchronous transactions can easily be modeled by SNMP Notification Class operations. An asynchronous transaction contains a notification message with one to three parameters. The message can be realized as an SNMP Notification Class operation with the parameters implemented as managed objects contained in the notification.
SNMP Notification Class操作で容易に非同期なトランザクションをモデル化できます。 非同期なトランザクションは1〜3つのパラメタがある通知メッセージを含んでいます。 パラメタが通知に含まれた管理オブジェクトとして実装されている状態で、SNMP Notification Class操作としてメッセージを実現できます。
Quittek, et al. Standards Track [Page 7] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[7ページ]。
+--------------+ notification +------------+
| MIDCOM client|<--------------| middlebox |
+--------------+ message +------------+
+--------------+ 通知+------------+ | MIDCOMクライアント| <、-、-、-、-、-、-、-、-、-、-、-、-、--、| middlebox| +--------------+ メッセージ+------------+
MIDCOM asynchronous transaction
MIDCOMの非同期なトランザクション
+--------------+ SNMP +------------+
| SNMP manager |<--------------| SNMP agent |
+--------------+ notification +------------+
+--------------+ SNMP+------------+ | SNMPマネージャ| <、-、-、-、-、-、-、-、-、-、-、-、-、--、| SNMPエージェント| +--------------+ 通知+------------+
Implementation of MIDCOM asynchronous transaction
MIDCOMの非同期なトランザクションの実装
Figure 2: MIDCOM asynchronous transaction
mapped to SNMP Notification Class operation
図2: SNMP Notification Class操作に写像されたMIDCOMの非同期なトランザクション
One of the parameters is the transaction identifier that should be unique per middlebox. It does not have to be unique for all notifications sent by the particular SNMP agent, but for all sent notifications that are defined by the MIDCOM-MIB module.
パラメタの1つはmiddlebox単位でユニークであるべきトランザクション識別子です。 それは、特定のSNMPエージェントによって送られたすべての通知にユニークであるのではなく、MIDCOM-MIBモジュールで定義されるすべての送られた通知のためにユニークでなければなりません。
Note that SNMP notifications are usually sent as unreliable UDP packets and may be dropped before they reach their destination. If a MIDCOM client is expecting an asynchronous notification on a specific transaction, it would be the job of the MIDCOM client to poll the middlebox periodically and monitor the transaction in case notifications are lost along the way.
SNMP通知が通常、頼り無いUDPパケットとして送られて、目的地に到着する前に下げられるかもしれないことに注意してください。 MIDCOMクライアントが特定のトランザクションに関する非同期な通知を予想しているなら、通知が道に沿って失われるといけないので、定期的にmiddleboxに投票して、トランザクションをモニターするのは、MIDCOMクライアントの仕事でしょう。
4.2.2. Configuration Transactions
4.2.2. 構成トランザクション
All request-reply transactions contain a request message, a reply message, and potentially also a set of notifications. In general, they cannot be modeled by just having a single SNMP message per MIDCOM message, because some of the MIDCOM messages carry a large set of parameters that do not necessarily fit into an SNMP message consisting of a single UDP packet only.
要求回答トランザクションはすべて、要求メッセージ、応答メッセージ、および潜在的に1セットの通知も含んでいます。 一般に、ただMIDCOMメッセージあたり1つのただ一つのSNMPメッセージを持っていることによって、それらをモデル化できません、MIDCOMメッセージのいくつかが必ず単一のUDPパケットだけから成るSNMPメッセージに収まるというわけではない大きいセットのパラメタを運ぶので。
For configuration transactions, the MIDCOM request message can be modeled by one or more SNMP SET transactions. The action of sending the MIDCOM request to the middlebox is realized by writing the parameters contained in the message to managed objects at the SNMP agent. If necessary, the SNMP SET transaction includes creating these managed objects. If not all parameters of the MIDCOM request message can be set by a single SNMP SET transaction, then more than one SET transaction is used; see Figure 3. Completion of the last of the SNMP transactions indicates that all required parameters are set and that processing of the MIDCOM request message can start at the middlebox.
構成トランザクションにおいて、1つ以上のSNMP SETトランザクションはMIDCOM要求メッセージをモデル化できます。 MIDCOMがmiddleboxに要求する発信の動作は、SNMPエージェントにメッセージに管理オブジェクトに含まれたパラメタを書くことによって、実現されます。 必要なら、SNMP SETトランザクションは、これらの管理オブジェクトを作成するのを含んでいます。 そうでなければ、ただ一つのSNMP SETトランザクションでMIDCOM要求メッセージのすべてのパラメタを設定できます、次に、1つ以上のSETトランザクションが使用されています。 図3を見てください。 SNMPトランザクションの最終完成はすべての必要なパラメタが設定されて、MIDCOM要求メッセージの処理がmiddleboxで始まることができるのを示します。
Quittek, et al. Standards Track [Page 8] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[8ページ]。
Please note that a single SNMP SET transaction consists of an SNMP SET request message and an SNMP SET reply message. Both are sent as unreliable UDP packets and may be dropped before they reach their destination. If the SNMP SET request message or the SNMP reply message is lost, then the SNMP manager (the MIDCOM client) needs to take action, for example, by just repeating the SET transaction or by first checking the success of the initial write transaction with an SNMP GET transaction and then only repeating the SNMP SET transaction if necessary.
ただ一つのSNMP SETトランザクションはSNMP SET要求メッセージとSNMP SET応答メッセージから成ります。 両方が、頼り無いUDPパケットとして送られて、目的地に到着する前に下げられるかもしれません。 SNMP SET要求メッセージかSNMP応答メッセージが無くなるなら、SNMPマネージャ(MIDCOMクライアント)は、例えば、ただSETトランザクションを繰り返すことによって行動を取るか、または必要なら、最初に初期の成功をチェックすることによってSNMP GETトランザクションと次に、反復だけがあるトランザクションにSNMP SETトランザクションを書く必要があります。
+--------------+ request +------------+
| MIDCOM client|-------------->| middlebox |
+--------------+ message +------------+
+--------------+ 要求+------------+ | MIDCOMクライアント|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| middlebox| +--------------+ メッセージ+------------+
MIDCOM request message
MIDCOM要求メッセージ
+--------------+ +------------+
| | SNMP SET | |
| |-------------->| |
| | message | |
| | | |
| | SNMP SET | |
| |<--------------| |
| | reply message | |
| SNMP manager | | SNMP agent |
| | SNMP SET | |
| |- - - - - - - >| |
| | message | |
| | | |
| | SNMP SET | |
| |< - - - - - - -| |
| | reply message | |
| | | |
| | . . . | |
+--------------+ +------------+
+--------------+ +------------+ | | SNMPはセットしました。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| メッセージ| | | | | | | | SNMPはセットしました。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 応答メッセージ| | | SNMPマネージャ| | SNMPエージェント| | | SNMPはセットしました。| | | |- - - - - - - >|、|、|、| メッセージ| | | | | | | | SNMPはセットしました。| | | |<--、--、--、--、--、--、-| | | | 応答メッセージ| | | | | | | | . . . | | +--------------+ +------------+
Implementation of MIDCOM request message
by one or more SNMP SET transactions
1つ以上のSNMP SETトランザクションによるMIDCOM要求メッセージの実装
Figure 3: MIDCOM request message
mapped to SNMP SET transactions
図3: SNMP SETトランザクションに写像されたMIDCOM要求メッセージ
The MIDCOM reply message can be modeled in two ways. The first way is an SNMP Notification Class operation optionally followed by one or more SNMP GET transactions as shown in Figure 4. The MIDCOM server informs the MIDCOM client about the end of processing the request by sending an SNMP notification. If possible, the SNMP notification
2つの方法でMIDCOM応答メッセージをモデル化できます。 最初の道は1つ以上のSNMP GETトランザクションが図4に示されるように任意にいうことになったSNMP Notification Class操作です。 MIDCOMサーバはSNMP通知を送ることによって要求を処理する終わり頃にMIDCOMクライアントに知らせます。 できればSNMP通知
Quittek, et al. Standards Track [Page 9] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[9ページ]。
carries all reply parameters. If this is not possible, then the SNMP manager has to perform additional SNMP GET transactions as long as necessary to receive all of the reply parameters.
すべての回答パラメタを運びます。 これが可能でないなら、SNMPマネージャは、回答パラメタのすべてを受けるために必要に応じて長い追加SNMP GET同じくらいトランザクションを実行しなければなりません。
+--------------+ reply +------------+
| MIDCOM client|<--------------| middlebox |
+--------------+ message +------------+
+--------------+ 回答+------------+ | MIDCOMクライアント| <、-、-、-、-、-、-、-、-、-、-、-、-、--、| middlebox| +--------------+ メッセージ+------------+
MIDCOM reply message
MIDCOM応答メッセージ
+--------------+ +------------+
| | SNMP | |
| |<--------------| |
| | notification | |
| | | |
| | SNMP GET | |
| |-------------->| |
| | message | |
| SNMP manager | | SNMP agent |
| | SNMP GET | |
| |<--------------| |
| | reply message | |
| | | |
| | SNMP GET | |
| |- - - - - - - >| |
| | message | |
| | | |
| | SNMP GET | |
| |< - - - - - - -| |
| | reply message | |
| | | |
| | . . . | |
+--------------+ +------------+
+--------------+ +------------+ | | SNMP| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 通知| | | | | | | | SNMPは得ます。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| メッセージ| | | SNMPマネージャ| | SNMPエージェント| | | SNMPは得ます。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 応答メッセージ| | | | | | | | SNMPは得ます。| | | |- - - - - - - >|、|、|、| メッセージ| | | | | | | | SNMPは得ます。| | | |<--、--、--、--、--、--、-| | | | 応答メッセージ| | | | | | | | . . . | | +--------------+ +------------+
Implementation of MIDCOM reply message
by an SNMP notification
and one or more SNMP GET transactions
SNMP通知と1つ以上のSNMP GETトランザクションによるMIDCOM応答メッセージの実装
Figure 4: MIDCOM reply message
mapped to SNMP notification and optional GET transactions
図4: SNMP通知と任意のGETトランザクションに写像されたMIDCOM応答メッセージ
The second way replaces the SNMP Notification Class operation by a polling operation of the SNMP manager. The manager polls status information at the SNMP agent using SNMP GET transactions until it detects the end of the processing of the request. Then it uses one or more SNMP GET transactions to receive all of the reply parameters. Note that this second way requires more SNMP operations, but is more
2番目の道はSNMP Notification Class操作をSNMPマネージャの世論調査操作に取り替えます。 要求の処理の終わりを検出するまでSNMP GETトランザクションを使用しているSNMPエージェントのマネージャ投票状態情報。 そして、それは、回答パラメタのすべてを受けるのに1つ以上のSNMP GETトランザクションを使用します。 この2番目の道が、より多くのSNMP操作を必要としますが、より多いことに注意してください。
Quittek, et al. Standards Track [Page 10] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[10ページ]。
reliable than the first way using an SNMP Notification Class operation.
信頼できる、SNMP Notification Class操作を使用する最初の道より。
4.2.3. Monitoring Transactions
4.2.3. モニターしているトランザクション
The realization of MIDCOM monitoring transactions in terms of SNMP transactions is simpler. The request message is very short and just specifies a piece of information that the MIDCOM client wants to retrieve.
SNMPトランザクションに関するMIDCOMのモニターしているトランザクションの実現は、より簡単です。 要求メッセージは、非常に短く、ただ、MIDCOMクライアントが検索したがっている1つの情報を指定します。
+--------------+ request +------------+
| |-------------->| |
| | message | |
| MIDCOM client| | middlebox |
| | reply | |
| |<--------------| |
+--------------+ message +------------+
+--------------+ 要求+------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| メッセージ| | | MIDCOMクライアント| | middlebox| | | 返信| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +--------------+ メッセージ+------------+
MIDCOM monitoring transaction
MIDCOMのモニターしているトランザクション
+--------------+ +------------+
| | SNMP GET | |
| |-------------->| |
| | message | |
| | | |
| | SNMP GET | |
| |<--------------| |
| | reply message | |
| SNMP manager | | SNMP agent |
| | SNMP GET | |
| |- - - - - - - >| |
| | message | |
| | | |
| | SNMP GET | |
| |< - - - - - - -| |
| | reply message | |
| | | |
| | . . . | |
+--------------+ +------------+
+--------------+ +------------+ | | SNMPは得ます。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| メッセージ| | | | | | | | SNMPは得ます。| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 応答メッセージ| | | SNMPマネージャ| | SNMPエージェント| | | SNMPは得ます。| | | |- - - - - - - >|、|、|、| メッセージ| | | | | | | | SNMPは得ます。| | | |<--、--、--、--、--、--、-| | | | 応答メッセージ| | | | | | | | . . . | | +--------------+ +------------+
Implementation of MIDCOM monitoring transaction
by one or more SNMP GET messages
1つ以上のSNMP GETメッセージによるMIDCOMのモニターしているトランザクションの実装
Figure 5: MIDCOM monitoring transaction
mapped to SNMP GET transactions
図5: SNMP GETトランザクションに写像されたMIDCOMのモニターしているトランザクション
Quittek, et al. Standards Track [Page 11] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[11ページ]。
Since monitoring is a strength of SNMP, there are sufficient means to realize MIDCOM monitoring transactions simpler than MIDCOM configuration transactions.
モニターがSNMPの強さであるので、MIDCOM構成トランザクションより簡単なMIDCOMモニターしているトランザクションをわかることができるくらいの手段があります。
All MIDCOM monitoring transactions can be realized as a sequence of SNMP GET transactions. The number of SNMP GET transactions required depends on the amount of information to be retrieved.
SNMP GETトランザクションの系列としてすべてのMIDCOMのモニターしているトランザクションを実現できます。 トランザクションが必要としたSNMP GETの数は、検索されるために情報量に依存します。
4.2.4. Atomicity of MIDCOM Transactions
4.2.4. MIDCOMトランザクションの最小単位
Given the realizations of MIDCOM transactions by means of SNMP transactions, atomicity of the MIDCOM transactions is not fully guaranteed anymore. However, this section shows that atomicity provided by the MIB module specified in section 9 is still sufficient for meeting the MIDCOM requirements specified in [RFC3304].
SNMPトランザクションによるMIDCOMトランザクションの実現を考えて、MIDCOMトランザクションの最小単位はそれ以上完全に保証されるというわけではありません。 しかしながら、このセクションは、セクション9で指定されたMIBモジュールで提供された最小単位が[RFC3304]で指定されたMIDCOM必要条件を満たすのにまだ十分であることを示します。
4.2.4.1. Asynchronous MIDCOM Transactions
4.2.4.1. 非同期なMIDCOMトランザクション
There are two asynchronous MIDCOM transactions: Asynchronous Session Termination (AST) and Asynchronous Policy Rule Event (ARE). The very static realization of MIDCOM sessions in the MIDCOM-MIB, as described by section 4.1, does not anymore support the asynchronous termination of a session. Therefore, the AST transaction is not modeled. For the ARE, atomicity is maintained, because it is modeled by a single atomic SNMP notification transaction.
2つの非同期なMIDCOMトランザクションがあります: 非同期なセッション終了(AST)と非同期な方針はイベント(ある)を統治します。 MIDCOM-MIBでのセクション4.1によって説明されるMIDCOMセッションの非常に静的な実現はそれ以上セッションの非同期な終了をサポートしません。 したがって、ASTトランザクションはモデル化されません。 ある、それがただ一つの原子SNMP通知トランザクションによってモデル化されるので、最小単位は維持されます。
In addition, the MIDCOM-MIB supports an Asynchronous Group Event transaction, which is an aggregation of a set of ARE transactions. Also, this MIDCOM transaction is implemented by a single SNMP transaction.
さらに、MIDCOM-MIBはAsynchronous Group Eventトランザクションをサポートして、どれがセットされたaの集合であるかはトランザクションです。 また、このMIDCOMトランザクションはただ一つのSNMPトランザクションによって実装されます。
4.2.4.2. Session Establishment and Termination Transactions
4.2.4.2. セッション設立と終了トランザクション
The MIDCOM-MIB models MIDCOM sessions in a very static way. The only dynamic actions within these transactions are enabling and disabling the generation of SNMP notifications at the SNMP agent.
MIDCOM-MIBは非常に静的な方法でMIDCOMセッションをモデル化します。 これらのトランザクションの中の唯一のダイナミックな動きが、SNMPエージェントでSNMP通知の世代を可能にして、無効にしています。
For the Session Establishment (SE) transaction, the MIDCOM client first reads the middlebox capabilities. It is not relevant whether or not this action is atomic because a dynamic change of the middlebox capabilities is not to be expected. Therefore, also non- atomic implementations of this action are acceptable.
Session特権階級(SE)トランザクションのために、MIDCOMクライアントは最初に、middlebox能力を読みます。 この動作がmiddlebox能力のダイナミックな変化を予想してはいけないので原子であるか否かに関係なく、それは関連していません。 したがって、また、この動作の非原子の実装も許容できます。
Then, the MIDCOM agent needs to enable the generation of SNMP notifications at the middlebox. This can be realized by writing to a single managed object in the SNMP-NOTIFICATION-MIB [RFC3413]. But even other implementations are acceptable, because atomicity is not required for this step.
そして、MIDCOMエージェントは、middleboxでSNMP通知の世代を可能にする必要があります。 SNMP-NOTIFICATION-MIB[RFC3413]のただ一つの管理オブジェクトに書くことによって、これを実感できます。 しかし、最小単位はこのステップに必要でないので、他の実装さえ許容できます。
Quittek, et al. Standards Track [Page 12] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[12ページ]。
For the Session Termination (ST) transaction, the only required action is disabling the generation of SNMP notifications at the middlebox. As for the SE transaction, this action can be realized atomically by using the SNMP-NOTIFICATION-MIB, but also other implementations are acceptable because atomicity is not required for this action.
Session Termination(ST)トランザクションのために、唯一の必要な動作がmiddleboxでSNMP通知の世代を無効にしています。 SEトランザクションに関して、SNMP-NOTIFICATION-MIBを使用することによって、原子論的にこの動作を実現できますが、最小単位はこの動作に必要でないので、他の実装はまた許容できます。
4.2.4.3. Monitoring Transactions
4.2.4.3. モニターしているトランザクション
Potentially, the monitoring transactions Policy Rule List (PRL), Policy Rule Status (PRS), Group List (GL), and Group Status (GS) are not atomic, because these transactions may be implemented by more than one SNMP GET operation.
潜在的に、モニターしているトランザクションのPolicy Rule List(PRL)、Policy Rule Status(PRS)、Group List(GL)、およびGroup Status(GS)は原子ではありません、これらのトランザクションが1つ以上のSNMP GET操作で実装されるかもしれないので。
The problem that might occur is that while the monitoring transaction is performed, the monitored items may change. For example, while reading a long list of policies, new policies may be added and already read policies may be deleted. This is not in line with the protocol semantics. However, it is not in direct conflict with the MIDCOM requirement requesting the middlebox state to be stable and known by the MIDCOM client, because the middlebox notifies the MIDCOM client on all changes to its state that are performed during the monitoring transaction by sending notifications.
起こるかもしれない問題はモニターしているトランザクションが実行されている間モニターされた項目が変化するかもしれないということです。 例えば、新しい政策は方針に関する長い一覧表を読んでいる間、加えられるかもしれません、そして、既に読まれた方針は削除されるかもしれません。 プロトコル意味論に沿ってこれがありません。 しかしながら、それは安定しているようmiddlebox状態に要求して、MIDCOMクライアントによって知られているMIDCOM要件とのダイレクト闘争中ではありません、middleboxが状態へのモニターしているトランザクションの間に通告を送ることによって実行されるすべての変化の上でMIDCOMクライアントに通知するので。
If the MIDCOM client receives such a notification while performing a monitoring transaction (or shortly after completing it), the MIDCOM client can then either repeat the monitoring transaction or integrate the result of the monitoring transaction with the information received via notifications during the transaction. In both cases, the MIDCOM client will know the state of the middlebox.
MIDCOMクライアントがモニターしているトランザクション(またはそれを完成したすぐ後に)を実行している間、そのような通知を受け取るなら、MIDCOMクライアントは、モニターしているトランザクションを繰り返すか、またはトランザクションの間、通知で受け取られた情報があるモニターしているトランザクションの結果を統合できます。 どちらの場合も、MIDCOMクライアントはmiddleboxの状態を知るでしょう。
4.2.4.4. Lifetime Change Transactions
4.2.4.4. 生涯変化トランザクション
For the policy Rule Lifetime Change (RLC) transaction and the Group Lifetime Change (GLC) transaction, atomicity is maintained. They both have very few parameters for the request message and the reply message. The request parameters can be transmitted by a single SNMP SET request message, and the reply parameters can be transmitted by a single SNMP notification message. In order to prevent idempotency problems by retransmitting an SNMP request after a lost SNMP reply, it is RECOMMENDED that either snmpSetSerialNo (see [RFC3418]) is included in the corresponding SNMP SET request or the value of the SNMP retransmission timer be lower than the smallest requested lifetime value. The same recommendation applies to the smallest requested value for the midcomRuleStorageTime. MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent.
方針Rule Lifetime Change(RLC)トランザクションとGroup Lifetime Change(GLC)トランザクションにおいて、最小単位は維持されます。 それらの両方には、要求メッセージと応答メッセージのためのほんのわずかなパラメタがあります。 ただ一つのSNMP SET要求メッセージで要求パラメタを伝えることができます、そして、ただ一つのSNMP通知メッセージは回答パラメタを伝えることができます。 無くなっているSNMP回答の後にSNMP要求を再送することによってidempotency問題を防ぐために、snmpSetSerialNo([RFC3418]を見る)が含まれている対応するSNMP SETが要求するどちらかかSNMP再送信タイマーの値が最も小さいのが生涯値を要求したより低いのは、RECOMMENDEDです。 同じ推薦はmidcomRuleStorageTimeのために最も小さい要求された値に適用されます。 MIDCOMクライアント実装がそれらのSNMPスタックを構成することによってこの問題を完全に避けるかもしれないので、「再-トランスミッション」を全く送りません。
Quittek, et al. Standards Track [Page 13] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[13ページ]。
4.2.4.5. Transactions Establishing New Policy Rules
4.2.4.5. 新しい政策規則を確立するトランザクション
Analogous to the monitoring transactions, the atomicity may not be given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions. Both transactions are potentially implemented using more than one SNMP SET operation and GET operation for obtaining transaction reply parameters. The solution for this loss of atomicity is the same as for the monitoring transactions.
モニターしているトランザクションに類似しています、最小単位はPolicy Reserve Rule(PRR)とPolicy Enable Rule(PER)トランザクションのために与えられないかもしれません。 両方のトランザクションは、トランザクション回答パラメタを得るのに1つ以上のSNMP SET操作とGET操作を使用することで潜在的に実装されます。 最小単位のこの損失のためのソリューションはモニターしているトランザクションのように同じです。
There is an additional atomicity problem for PRR and PER. If transferring request parameters requires more than a single SET operation, then there is the potential problem that multiple MIDCOM clients sharing the same permissions are able to access the same policy rule. In this case, a client could alter request parameters already set by another client before the first client could complete the request. However, this is acceptable since usually only one agent is creating a policy rule and filling it subsequently. It can also be assumed that in most cases where clients share permissions, they act in a more or less coordinated way avoiding such interferences.
PRRとPERのための追加最小単位問題があります。 要求パラメタを移すなら、ただ一つのSET操作以上を必要として、同じ許容を共有している複数のMIDCOMクライアントが同じ政策ルールにアクセスできるという潜在的問題があります。 この場合、クライアントは最初のクライアントが要求を終了できる前に別のクライアントによって既に設定された要求パラメタを変更できました。 しかしながら、1人のエージェントだけが通常政策ルールを作成して、次にそれをいっぱいにするので、これは許容できます。 また、多くの場合、クライアントが許容を共有するところでそのような干渉を避ける多少連携している方法で行動すると思うことができます。
All atomicity problems caused by using multiple SNMP SET transactions for implementing the MIDCOM request message can be avoided by transferring all request parameters with a single SNMP SET transaction.
ただ一つのSNMP SETトランザクションですべての要求パラメタを移すことによって、MIDCOMが要求メッセージであると実装するのに複数のSNMP SETトランザクションを使用することによって引き起こされたすべての最小単位問題は避けることができます。
4.2.5. Access Control
4.2.5. アクセス制御
Since SNMP does not offer per-session authentication and authorization, authentication and authorization are performed per SNMP message sent from the MIDCOM client to the middlebox.
SNMPが1セッションあたりの認証と承認を提供しないので、認証と承認はMIDCOMクライアントからmiddleboxに送られたSNMPメッセージ単位で実行されます。
For each transaction, the MIDCOM client has to authenticate itself as an authenticated principal, such as a USM user. Then, the principal's access rights to all resources affected by the transaction are checked. Access right control is realized by configuring the access control mechanisms, such as VACM, at the SNMP agent.
各トランザクションのために、MIDCOMクライアントはUSMユーザなどの認証された元本としてそれ自体を認証しなければなりません。 そして、トランザクションで影響を受けるすべてのリソースへの主体のアクセス権はチェックされます。 アクセス権制御は、SNMPエージェントのVACMなどのアクセス管理機構を構成することによって、実現されます。
4.3. Access Control Policies
4.3. アクセス制御方針
Potentially, a middlebox has to control access for a large set of MIDCOM clients and to a large set of policy rules configuring firewall pinholes and NAT bindings. Therefore, it can be beneficial to use access control policies for specifying access control rules. Generating, provisioning, and managing these policies are out of scope of this MIB module.
潜在的に、middleboxは大きいセットのMIDCOMクライアントと、そして、ファイアウォールピンホールとNAT結合を構成する大きい政策ルールへのアクセスを制御しなければなりません。 したがって、アクセス制御規則を指定するのにアクセス制御方針を使用するのは有益である場合があります。 このMIBモジュールの範囲の外にこれらの方針に生成して、食糧を供給して、管理するのがあります。
Quittek, et al. Standards Track [Page 14] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[14ページ]。
However, if such an access control policy system is used, then the SNMP agent acts as a policy enforcement point. An access control policy system must transform all active policies into configurations of, for example, the SNMP agent's View-based Access Control Model (VACM).
しかしながら、そのようなアクセス制御方針システムが使用されているなら、SNMPエージェントは方針実施ポイントとして務めます。 アクセス制御方針システムはすべての積極方針を例えば、SNMPエージェントのViewベースのAccess Control Model(VACM)の構成に変えなければなりません。
The mechanisms of access control models, such as VACM, allow an access control policy system to enforce MIDCOM client authentication rules and general access control of MIDCOM clients to middlebox control.
VACMなどのアクセス制御モデルのメカニズムで、アクセス制御方針システムはMIDCOMクライアントのMIDCOMクライアント認証規則と一般的なアクセスコントロールをmiddleboxコントロールに実施できます。
The mechanisms of VACM can be used to enforce access control of authenticated clients to MIDCOM-MIB policy rules based on the concept of ownership. For example, an access control policy can specify that MIDCOM-MIB policy rules owned by user A cannot be accessed at all by user B, can be read by user C, and can be read and modified by user D.
所有権の概念に基づくMIDCOM-MIB政策ルールに認証されたクライアントのアクセスコントロールを実施するのにVACMのメカニズムを使用できます。 例えば、アクセス制御方針は、ユーザBがユーザAによって所有されていたMIDCOM-MIB政策ルールに全くアクセスできないで、ユーザDがユーザCが読むことができて、読まれて、変更できると指定できます。
Further access control policies can control access to concrete middlebox resources. These are enforced, when a MIDCOM request is processed. For example, an authenticated MIDCOM client may be authorized to request new MIDCOM policies to be established, but only for certain IP address ranges. The enforcement of this kind of policies may not be realizable using available SNMP mechanisms, but needs to be performed by the individual MIB module implementation.
さらなるアクセス制御方針は具体的なmiddleboxリソースへのアクセスを制御できます。 MIDCOM要求が処理されるとき、これらは実施されます。 例えば、認証されたMIDCOMクライアントが、単にあるIPアドレスが及ぶので設立されるよう新しいMIDCOM方針に要求するのに権限を与えられるかもしれません。 この種類の方針の実施は、利用可能なSNMPメカニズムを使用することで実現可能でないかもしれませんが、個々のMIBモジュール実装によって実行される必要があります。
5. Structure of the MIB Module
5. MIBモジュールの構造
The MIB module defined in section 9 contains three kinds of managed objects:
セクション9で定義されたMIBモジュールは3種類の管理オブジェクトを含んでいます:
- Transaction objects
Transaction objects are required for implementing the MIDCOM
protocol requirements defined in [RFC3304] and the MIDCOM
protocol semantics defined in [RFC5189].
- 実装するTransactionオブジェクトがMIDCOMプロトコル要件が必要であるトランザクションオブジェクトは[RFC3304]とMIDCOMで[RFC5189]で定義されたプロトコル意味論を定義しました。
- Configuration objects
Configuration objects can be used for retrieving middlebox
capability information (mandatory) and for setting parameters of
the implementation of transaction objects (optional).
- middlebox能力情報(義務的な)を検索して、トランザクションオブジェクト(任意の)の実装のパラメタを設定するのに構成オブジェクトを使用できますConfigurationが、反対する。
- Monitoring objects
The optional monitoring objects provide information about used
resources and about MIDCOM transaction statistics.
- オブジェクトをモニターして、任意のモニターしているオブジェクトは中古のリソースとMIDCOMトランザクション統計の情報を提供します。
The transaction objects are organized in two tables: the midcomRuleTable and the midcomGroupTable. Entity relationships of
トランザクションオブジェクトは2個のテーブルで組織化されます: midcomRuleTableとmidcomGroupTable。 実体関係
Quittek, et al. Standards Track [Page 15] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[15ページ]。
entries of these tables and the midcomResourceTable from the monitoring objects are illustrated by Figure 6.
モニターしているオブジェクトからのこれらのテーブルとmidcomResourceTableのエントリーは図6によって例証されます。
+--------------------+
| midcomRuleEntry |
| indexed by |
| midcomRuleOwner |
| midcomGroupIndex |
| midcomRuleIndex |
+--------------------+
1...n | | 1
| |
1 | | 1
+--------------------+ +---------------------+
| midcomGroupEntry | | midcomResourceEntry |
| indexed by | | indexed by |
| midcomRuleOwner | | midcomRuleOwner |
| midcomGroupIndex | | midcomGroupIndex |
+--------------------+ | midcomRuleIndex |
+---------------------+
| | |
| | |
v v v
NAT Firewall other
MIB MIB MIB
+--------------------+ | midcomRuleEntry| | 索引をつけられます。| | midcomRuleOwner| | midcomGroupIndex| | midcomRuleIndex| +--------------------+ 1...n| | 1 | | 1 | | 1 +--------------------+ +---------------------+ | midcomGroupEntry| | midcomResourceEntry| | 索引をつけられます。| | 索引をつけられます。| | midcomRuleOwner| | midcomRuleOwner| | midcomGroupIndex| | midcomGroupIndex| +--------------------+ | midcomRuleIndex| +---------------------+ | | | | | | v対NAT Firewall他のMIB MIB MIBに
Figure 6: Entity relationships of table entries
図6: テーブル項目の実体関係
A MIDCOM client can create and delete entries in the midcomRuleTable. Entries in the midcomGroupTable are generated automatically as soon as there is an entry in the midcomRuleTable using the midcomGroupIndex. The midcomGroupTable can be used as shortcut for accessing all member rules with a single transaction. MIDCOM clients can group policy rules for various purposes. For example, they can assign a unique value for the midcomGroupIndex to all rules belonging to a single application or an application session served by the MIDCOM agent.
MIDCOMクライアントは、midcomRuleTableでエントリーを作成して、削除できます。 midcomRuleTableにあるとすぐに、midcomGroupTableのエントリーは、midcomGroupIndexを使用することで自動的に生成されます。 すべてのメンバーにアクセスするための近道が単一取引で統治されるようにmidcomGroupTableを使用できます。 MIDCOMクライアントは様々な目的のために政策ルールを分類できます。 例えば、彼らはmidcomGroupIndexのためにただ一つのアプリケーションに属すすべての規則かMIDCOMエージェントによって勤められたアプリケーションセッションまでユニークな値を割り当てることができます。
The midcomResourceTable augments the midcomRuleTable by information on the relationship of entries of the midcomRuleTable to resources listed in other MIB modules, such as the NAT-MIB [RFC4008].
midcomResourceTableはmidcomRuleTableのエントリーの関係の情報で他のMIBモジュールでリストアップされたリソースにmidcomRuleTableを増大させます、NAT-MIB[RFC4008]などのように。
5.1. Transaction Objects
5.1. トランザクションオブジェクト
The transaction objects are structured according to the MIDCOM semantics described in [RFC5189] into two subtrees, one for policy rule control and one for policy rule group control.
[RFC5189]で2つの下位木、政策ルールコントロールのためのもの、および政策ルール集団経営のための1つに説明されたMIDCOM意味論によると、トランザクションオブジェクトは構造化されます。
Quittek, et al. Standards Track [Page 16] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[16ページ]。
5.1.1. midcomRuleTable
5.1.1. midcomRuleTable
The midcomRuleTable contains information about policy rules including policy rules to be established, policy rules for which establishing failed, established policy rules, and terminated policy rules.
midcomRuleTableは証明されるために政策ルールを含む政策ルールの情報、設立が失敗した政策ルール、既定方針規則、および終えられた方針規則を含んでいます。
Entries in this table are indexed by the combination of midcomRuleOwner, midcomGroupIndex, and midcomRuleIndex. The midcomRuleOwner is the owner of the rule; the midcomGroupIndex is the index of the group of which the policy rule is a member.
midcomRuleOwner、midcomGroupIndex、およびmidcomRuleIndexの組み合わせでこのテーブルのエントリーは索引をつけられます。 midcomRuleOwnerは規則の所有者です。 midcomGroupIndexは政策ルールがメンバーであるグループのインデックスです。
midcomRuleOwner is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-based Access Control Model (VACM [RFC3415]) and allows a management application to identify its entries.
タイプSnmpAdminString(SNMPv3 ViewベースのAccess Control Model(VACM[RFC3415])の使用を考慮して、管理アプリケーションがエントリーを特定するのを許容する原文のコンベンション)にはmidcomRuleOwnerがあります。
Entries in this table are created by writing to midcomRuleRowStatus. Entries are removed when both their midcomRuleLifetime and midcomRuleStorageTime are timed out by counting down to 0. A MIDCOM client can explicitly remove an entry by setting midcomRuleLifetime and midcomRuleStorageTime to 0.
このテーブルのエントリーは、midcomRuleRowStatusに書くことによって、作成されます。 最小0を数えることによってそれらのmidcomRuleLifetimeとmidcomRuleStorageTimeの両方を調節するとき、エントリーを取り除きます。 MIDCOMクライアントは、midcomRuleLifetimeとmidcomRuleStorageTimeを0に設定することによって、明らかにエントリーを取り除くことができます。
The table contains the following columnar objects:
テーブルは以下の円柱状のオブジェクトを含んでいます:
o midcomRuleIndex
The index of this entry must be unique in combination with the
midcomRuleOwner and the midcomGroupIndex of the entry.
o midcomRuleIndex、このエントリーのインデックスはエントリーのmidcomRuleOwnerとmidcomGroupIndexと組み合わせてユニークであるに違いありません。
o midcomRuleAdminStatus
For establishing a new policy rule, a set of objects in this
entry needs to be written first. These objects are the request
parameters. Then, by writing either reserve(1) or enable(2) to
this object, the MIDCOM-MIB implementation is triggered to start
processing the parameters and tries to establish the specified
policy rule.
o このエントリーにおける、1セットのオブジェクトは、最初に新しい政策を確立するmidcomRuleAdminStatus Forが統治すると書かれる必要があります。 これらのオブジェクトは要求パラメタです。 次に、書くことによって、(1)を予約してくださいか、このオブジェクトに(2)を可能にしてください、MIDCOM-MIB実装は、パラメタを処理し始めるために引き起こされて、特約保険証券規則を確立しようとします。
o midcomRuleOperStatus
This read-only object indicates the current status of the entry.
The entry may have an initializing state, it may have a transient
state while processing requests, it may have an error state after
a request was rejected, it may have a state where a policy rule
is established, or it may have a terminated state.
o midcomRuleOperStatus This書き込み禁止オブジェクトはエントリーの現在の状態を示します。 エントリーには、初期値設定状態があるかもしれなくて、それでは、要求を処理している間、一時的な状態があるかもしれなくて、それでは、要求が拒絶された後に誤り状態があるかもしれなくて、それは政策ルールが確立されるか、または終えられた状態を持っているかもしれない状態を持っているかもしれません。
o midcomRuleStorageType
This object indicates whether or not the policy rule is stored as
volatile, non-volatile, or permanent. Depending on the MIDCOM-
MIB implementation, this object may be writable.
o midcomRuleStorageType Thisオブジェクトは、政策ルールが揮発性、非揮発性、永久的であるとして保存されるかどうかを示します。 MIDCOM- MIB実装によって、このオブジェクトは書き込み可能であるかもしれません。
Quittek, et al. Standards Track [Page 17] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[17ページ]。
o midcomRuleStorageTime
This object indicates how long the entry will still exist after
entering an error state or a termination state.
o midcomRuleStorageTime Thisオブジェクトは、それでも、エントリーが誤り州か終了状態に入った後にどれくらい長い間存在するかを示します。
o midcomRuleError
This object is a string indicating the reason for entering an
error state.
o midcomRuleError Thisオブジェクトは誤り状態に入る理由を示すストリングです。
o midcomRuleInterface
This object indicates the IP interface for which enforcement of a
policy rule is requested or performed, respectively.
o midcomRuleInterface Thisオブジェクトは政策ルールの実施が要求されているか、またはそれぞれ実行されるIPインタフェースを示します。
o midcomRuleFlowDirection
This object indicates a flow direction for which a policy enable
rule was requested or established, respectively.
o midcomRuleFlowDirection Thisオブジェクトは、方針が規則を可能にする流れ方向が要求されたか、またはそれぞれ確立されたのを示します。
o midcomRuleMaxIdleTime
This object indicates the maximum idle time of the policy rule in
seconds. If no packet to which the policy rule applies passes
the middlebox for the time specified by midcomRuleMaxIdleTime,
then the policy rule enters a termination state.
o midcomRuleMaxIdleTime Thisオブジェクトは秒に政策ルールの最大の遊休時間を示します。 政策ルールが適用されるどんなパケットもmidcomRuleMaxIdleTimeによって指定された時間のmiddleboxを渡さないなら、政策ルールは終了状態に入ります。
o midcomRuleTransportProtocol
This object indicates a transport protocol for which a policy
reserve rule or policy enable rule was requested or established,
respectively.
o midcomRuleTransportProtocol Thisオブジェクトは、責任準備金規則か方針が規則を可能にするトランスポート・プロトコルが要求されたか、またはそれぞれ確立されたのを示します。
o midcomRulePortRange
This object indicates a port range for which a policy reserve
rule or policy enable rule was requested or established,
respectively.
o midcomRulePortRange Thisオブジェクトは、責任準備金規則か方針が規則を可能にするポート範囲が要求されたか、またはそれぞれ確立されたのを示します。
o midcomRuleLifetime
This object indicates the remaining lifetime of an established
policy rule. The MIDCOM client can change the remaining lifetime
by writing to it.
o midcomRuleLifetime Thisオブジェクトは既定方針規則の残っている生涯を示します。 MIDCOMクライアントは、それに書くことによって、残っている生涯を変えることができます。
Beyond the listed objects, the table contains 10 further objects describing address parameters. They include the IP version, IP address, prefix length and port number for the internal address (A0), inside address (A1), outside address (A2), and external address (A3). These objects serve as parameters specifying a request or an established policy, respectively.
記載されたオブジェクトを超えて、テーブルはアドレスパラメタについて説明する一層の10個のオブジェクトを含んでいます。 彼らは内部のアドレス(A0)のためのIPバージョン、IPアドレス、接頭語の長さ、およびポートナンバーを含んでいます、インサイドアドレス(A1)、アドレス(A2)、および外部アドレス(A3)の外で。 これらのオブジェクトはそれぞれ要求か既定方針を指定するパラメタとして機能します。
A0, A1, A2, and A3 are address tuples defined according to the MIDCOM semantics [RFC5189]. Each of them identifies either a communication endpoint at an internal or external device or an allocated address at the middlebox.
A0、A1、A2、およびA3はMIDCOM意味論[RFC5189]に従って定義されたアドレスtuplesです。 それぞれの彼らはmiddleboxで内部の、または、外部のデバイスか割り当てられた住所のコミュニケーション終点を特定します。
Quittek, et al. Standards Track [Page 18] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[18ページ]。
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
+----------+ +----------+ | 内部| A0 A1+-----------+ A2 A3| 外部| | 終点+----------+ middlebox+----------+ 終点| +----------+ +-----------+ +----------+
Figure 7: Address tuples A0 - A3
図7: アドレスtuples A0--A3
- A0 - internal endpoint: Address tuple A0 specifies a communication
endpoint of a device within the internal network, with respect to
the middlebox.
- A0--インターナル終点: アドレスtuple A0は内部のネットワークの中でmiddleboxに関してデバイスのコミュニケーション終点を指定します。
- A1 - middlebox inside address: Address tuple A1 specifies a
virtual communication endpoint at the middlebox within the
internal network. A1 is the destination address for packets
passing from the internal endpoint to the middlebox and is the
source for packets passing from the middlebox to the internal
endpoint.
- A1--middleboxインサイドアドレス: アドレスtuple A1は内部のネットワークの中でmiddleboxで仮想のコミュニケーション終点を指定します。 A1はパケットのための内部の終点からmiddleboxまで終わる送付先アドレスであり、パケットのためのmiddleboxから内部の終点まで通るソースです。
- A2 - middlebox outside address: Address tuple A2 specifies a
virtual communication endpoint at the middlebox within the
external network. A2 is the destination address for packets
passing from the external endpoint to the middlebox and is the
source for packets passing from the middlebox to the external
endpoint.
- A2--middlebox外部アドレス: アドレスtuple A2は外部のネットワークの中でmiddleboxで仮想のコミュニケーション終点を指定します。 A2はパケットのための外部の終点からmiddleboxまで終わる送付先アドレスであり、パケットのためのmiddleboxから外部の終点まで通るソースです。
- A3 - external endpoint: Address tuple A3 specifies a communication
endpoint of a device within the external network, with respect to
the middlebox.
- A3--外部終点: アドレスtuple A3は外部のネットワークの中でmiddleboxに関してデバイスのコミュニケーション終点を指定します。
The MIDCOM-MIB requires the MIDCOM client to specify address tuples A0 and A3. This might be a problem for applications that are not designed in a firewall-friendly way. An example is an FTP application that uses the PORT command (instead of the recommended PASV command). The problem only occurs when the middlebox offers twice-NAT functionality, and it can be fixed following recommendations for firewall-friendly communication.
MIDCOM-MIBは、MIDCOMクライアントがアドレスtuples A0とA3を指定するのを必要とします。 これはファイアウォールに優しい方法で設計されていないアプリケーションのための問題であるかもしれません。 例はPORTコマンド(お勧めのPASVコマンドの代わりに)を使用するFTPアプリケーションです。 middleboxが2倍NATの機能性を提供するときだけ、問題は起こります、そして、ファイアウォールに優しいコミュニケーションのための推薦に続くのはそれに固定できます。
5.1.2. midcomGroupTable
5.1.2. midcomGroupTable
The midcomGroupTable has an entry per existing policy rule group. Entries in this table are created automatically when creating member entries in the midcomRuleTable. Entries are automatically removed from this table when the last member entry is removed from the midcomRuleTable. Entries cannot be created or removed explicitly by the MIDCOM client.
midcomGroupTableは既存の政策ルールあたり1つのエントリーを分類させます。 midcomRuleTableでメンバーエントリーを作成するとき、このテーブルのエントリーは自動的に作成されます。 midcomRuleTableから最後のメンバーエントリーを取り除くとき、このテーブルからエントリーを自動的に取り除きます。 MIDCOMクライアントは、明らかにエントリーを作成できないか、取り除くことができません。
Quittek, et al. Standards Track [Page 19] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[19ページ]。
Entries are indexed by the midcomRuleOwner of the rules that belong to the group and by a specific midcomGroupIndex. This allows each midcomRuleOwner to maintain its own independent group namespace.
エントリーはグループに属す規則のmidcomRuleOwnerと特定のmidcomGroupIndexによって索引をつけられます。 これで、各midcomRuleOwnerはそれ自身の独立しているグループ名前空間を維持できます。
An entry of the table contains the following objects:
テーブルのエントリーは以下のオブジェクトを含んでいます:
o midcomGroupIndex
The index of this entry must be unique in combination with the
midcomRuleOwner of the entry.
o midcomGroupIndex、このエントリーのインデックスはエントリーのmidcomRuleOwnerと組み合わせてユニークであるに違いありません。
o midcomGroupLifetime
This object indicates the maximum of the remaining lifetimes of
all established policy rules that are members of the group. The
MIDCOM client can change the remaining lifetime of all member
policies by writing to this object.
o midcomGroupLifetime Thisオブジェクトはグループのメンバーであるすべての既定方針規則の残っている生涯の最大を示します。 MIDCOMクライアントは、このオブジェクトに書くことによって、すべてのメンバー方針の残っている生涯を変えることができます。
5.2. Configuration Objects
5.2. 構成オブジェクト
The configuration subtree contains middlebox capability and configuration information. Some of the contained objects are (optionally) writable and can also be used for configuring the middlebox service.
構成下位木はmiddlebox能力と設定情報を含んでいます。 いくつかの含まれたオブジェクトは、(任意に)書き込み可能であり、また、middleboxサービスを構成するのに使用できます。
The capabilities subtree contains some general capability information and detailed information per supported IP interface. The midcomConfigFirewallTable can be used to configure how the MIDCOM-MIB implementation creates firewall rules in its firewall modules.
能力下位木は何らかのサポートしているIPインタフェースあたりの一般的な能力情報と詳細な情報を含んでいます。 MIDCOM-MIB実装がファイアウォールモジュールでどうファイアウォール規則を作成するかを構成するのにmidcomConfigFirewallTableを使用できます。
Note that typically, configuration objects are not intended to be written by MIDCOM clients. In general, write access to these objects needs to be restricted more strictly than write access to transaction objects.
通常、構成オブジェクトがMIDCOMクライアントによって書かれていることを意図しないことに注意してください。 一般に、これらへのアクセスを書いてください。オブジェクトは、トランザクションオブジェクトへのアクセスを書くよりさらに厳密に制限される必要があります。
5.2.1. Capabilities
5.2.1. 能力
Information on middlebox capabilities, i.e., capabilities of the MIDCOM-MIB implementation, is provided by the midcomCapabilities subtree of managed objects. The following objects are defined:
管理オブジェクトのmidcomCapabilities下位木はmiddlebox能力に関する情報(すなわち、MIDCOM-MIB実装の能力)を提供します。 以下のオブジェクトは定義されます:
o midcomConfigMaxLifetime
This object indicates the maximum lifetime that this middlebox
allows policy rules to have.
o midcomConfigMaxLifetime Thisオブジェクトはこのmiddleboxが政策ルールを持たせる最大の生涯を示します。
o midcomConfigPersistentRules
This is a boolean object indicating whether or not the middlebox
is capable of storing policy rules persistently.
o midcomConfigPersistentRules Thisはmiddleboxが政策ルールを持続して保存できるかどうかを示す論理演算子オブジェクトです。
Quittek, et al. Standards Track [Page 20] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[20ページ]。
Further capabilities are provided by the midcomConfigIfTable per
IP interface. This table contains just two objects. The first
one is a BITS object called midcomConfigIfBits containing the
following bit values:
さらなる能力はIPインタフェースあたりのmidcomConfigIfTableによって提供されます。 このテーブルはちょうど2個のオブジェクトを含んでいます。 最初の1つは以下のビットが評価するmidcomConfigIfBits含有と呼ばれるBITSオブジェクトです:
o ipv4 and ipv6
These two bit values provide information on which IP versions are
supported by the middlebox at the indexed interface.
o ipv4とipv6 These twoの噛み付いている値はIPバージョンが索引をつけられたインタフェースのmiddleboxによってサポートされる情報を提供します。
o addressWildcards and portWildcards
These two bit values provide information on wildcarding supported
by the middlebox at the indexed interface.
o ビットが評価するaddressWildcardsとportWildcards These twoは索引をつけられたインタフェースのmiddleboxによってサポートされたwildcardingの情報を提供します。
o firewall and nat
These two bit values provide information on availability of
firewall and NAT functionality at the indexed interface.
o ファイアウォールとnat These twoの噛み付いている値はファイアウォールの有用性の情報と索引をつけられたインタフェースにおけるNATの機能性を提供します。
o portTranslation, protocolTranslation, and twiceNat
These three bit values provide information on the kind of NAT
functionality available at the indexed interface.
o portTranslation、protocolTranslation、およびtwiceNat These threeの噛み付いている値は索引をつけられたインタフェースで利用可能なNATの機能性の種類の情報を提供します。
o inside
This bit indicates whether or not the indexed interface is an
inside interface with respect to NAT functionality.
o 内面のThisビットは、索引をつけられたインタフェースがNATの機能性に関する内面のインタフェースであるかどうかを示します。
The second object, called midcomConfigIfEnabled, indicates whether the middlebox capabilities described by midcomConfigIfBits are available or not available at the indexed IP interface.
midcomConfigIfEnabledと呼ばれる第二目的語は、midcomConfigIfBitsによって説明されたmiddlebox能力が索引をつけられたIPインタフェースで利用可能であるか、または利用可能でないかを示します。
The midcomConfigIfTable uses index 0 for indicating capabilities that are available for all interfaces.
midcomConfigIfTableは、すべてのインタフェースに利用可能な能力を示すのにインデックス0を使用します。
5.2.2. midcomConfigFirewallTable
5.2.2. midcomConfigFirewallTable
The midcomConfigFirewallTable serves for configuring how policy rules created by MIDCOM clients are realized as firewall rules of a firewall implementation. Particularly, the priority used for MIDCOM-MIB policy rules can be configured. For a single firewall implementation at a particular IP interface, all MIDCOM-MIB policy rules are realized as firewall rules with the same priority. Also, a firewall rule group name can be configured. The table is indexed by the IP interface index.
midcomConfigFirewallTableは、MIDCOMクライアントによって作成された政策ルールがファイアウォール実装のファイアウォール規則としてどのように実現されるかを構成するために役立ちます。 特に、MIDCOM-MIB政策ルールに使用される優先権は構成できます。 特定のIPインタフェースのただ一つのファイアウォール実装において、すべてのMIDCOM-MIB政策ルールがファイアウォール規則として同じ優先権で実現されます。 また、ファイアウォール規則グループ名を構成できます。 テーブルはIPインタフェースインデックスによって索引をつけられます。
An entry of the table contains the following objects:
テーブルのエントリーは以下のオブジェクトを含んでいます:
o midcomConfigFirewallGroupId
This object indicates the firewall rule group to which all
firewall rules of the MIDCOM server are assigned.
o midcomConfigFirewallGroupId ThisオブジェクトはMIDCOMサーバのすべてのファイアウォール規則が配属されるファイアウォール規則グループを示します。
Quittek, et al. Standards Track [Page 21] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[21ページ]。
o midcomConfigFirewallPriority
This object indicates the priority assigned to all firewall rules
of the MIDCOM server.
o midcomConfigFirewallPriority Thisオブジェクトは、優先権がMIDCOMサーバの規則をすべてのファイアウォールに割り当てたのを示します。
5.3. Monitoring Objects
5.3. モニターしているオブジェクト
The monitoring objects are structured into two subtrees: the resource subtree and the statistics subtree. The resource subtree provides information about which resources are used by which policy rule. The statistics subtree provides statistics about the usage of transaction objects.
モニターしているオブジェクトは2つの下位木に構造化されます: リソース下位木と統計下位木。 リソース下位木はリソースがどの政策ルールで使用される情報を提供します。 統計下位木はトランザクションオブジェクトの使用法に関する統計を提供します。
5.3.1. midcomResourceTable
5.3.1. midcomResourceTable
Information about resource usage per policy rule is provided by the midcomResourceTable. Each entry in the midcomResourceTable describes resource usage of exactly one policy rule.
1政策ルールあたりのリソース用法に関する情報はmidcomResourceTableによって提供されます。 midcomResourceTableの各エントリーはまさに1つの政策ルールのリソース用法を説明します。
Resources are NAT resources and firewall resources, depending on the type of middlebox. Used NAT resources include NAT bindings and NAT sessions. NAT address mappings are not covered. For firewalls, firewall filter rules are considered as resources.
middleboxのタイプに頼っていて、リソースは、NATリソースとファイアウォールリソースです。 中古のNATリソースはNAT結合とNATセッションを含んでいます。 NATアドレス・マッピングはカバーされていません。 ファイアウォールにおいて、ファイアウォールフィルタ規則はリソースであるとみなされます。
The values provided by the following objects on NAT binds and NAT sessions may refer to the detailed resource usage description in the NAT-MIB module [RFC4008].
NAT-MIBモジュール[RFC4008]でNATひもとNATセッションのときに以下のオブジェクトによって提供された値は詳細なリソース用法記述について言及するかもしれません。
The values provided by the following objects on firewall rules may refer to more detailed firewall resource usage descriptions in other MIB modules.
他のMIBモジュールでファイアウォール規則で以下のオブジェクトによって提供された値は、より詳細なファイアウォールリソース用法記述について言及するかもしれません。
Entries in the midcomResourceTable are only valid if the midcomRuleOperStatus object of the corresponding entry in the midcomRuleTable has a value of either reserved(7) or enabled(8).
midcomRuleTableの対応するエントリーの目的が値を持っているmidcomRuleOperStatusが(7)を予約したか、または(8)を可能にした場合にだけ、midcomResourceTableのエントリーは有効です。
An entry of the table contains the following objects:
テーブルのエントリーは以下のオブジェクトを含んでいます:
o midcomRscNatInternalAddrBindMode
This object indicates whether the binding of the internal address
is an address NAT binding or an address-port NAT binding.
o midcomRscNatInternalAddrBindMode Thisオブジェクトは、内部のアドレスの製本がアドレスNAT結合かそれともアドレス港のNAT結合であるかを示します。
o midcomRscNatInternalAddrBindId
This object identifies the NAT binding for the internal address
in the NAT engine.
o midcomRscNatInternalAddrBindId ThisオブジェクトはNATエンジンの内部のアドレスにおいて、拘束力があるNATを特定します。
o midcomRscNatExternalAddrBindMode
This object indicates whether the binding of the external address
is an address NAT binding or an address-port NAT binding.
o midcomRscNatExternalAddrBindMode Thisオブジェクトは、外部アドレスの製本がアドレスNAT結合かそれともアドレス港のNAT結合であるかを示します。
Quittek, et al. Standards Track [Page 22] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[22ページ]。
o midcomRscNatExternalAddrBindId
This object identifies the NAT binding for the external address
in the NAT engine.
o midcomRscNatExternalAddrBindId ThisオブジェクトはNATエンジンの外部アドレスにおいて、拘束力があるNATを特定します。
o midcomRscNatSessionId1
This object links to the first NAT session associated with one of
the above NAT bindings.
o midcomRscNatSessionId1 Thisオブジェクトは上のNAT結合の1つに関連している最初のNATセッションまでリンクされます。
o midcomRscNatSessionId2
This object links to the optional second NAT session associated
with one of the above NAT bindings.
o midcomRscNatSessionId2 Thisオブジェクトは上のNAT結合の1つに関連している2番目の任意のNATセッションまでリンクされます。
o midcomRscFirewallRuleId
This object indicates the firewall rule for this policy rule.
o midcomRscFirewallRuleId Thisオブジェクトはこの政策ルールのためにファイアウォール規則を示します。
The MIDCOM-MIB module does not require a middlebox to implement further specific middlebox (NAT, firewall, etc.) MIB modules as, for example, the NAT-MIB module [RFC4008].
MIDCOM-MIBモジュールは、middleboxが、特定のmiddleboxが(NAT、ファイアウォールなど)であるとさらに実装するのを必要としません。 例えば、NAT-MIBモジュール[RFC4008]としてのMIBモジュール。
The resource identifiers in the midcomResourceTable may be vendor proprietary in the cases where the middlebox does not implement the NAT-MIB [RFC4008] or a firewall MIB. The MIDCOM-MIB module affects NAT binding and sessions, as well as firewall pinholes. It is intentionally not specified in the MIDCOM-MIB module how these NAT and firewall resources are allocated and managed, since this depends on the MIDCOM-MIB implementation and middlebox's capabilities. However, the midcomResourceTable is useful for understanding which resources are affected by which MIDCOM-MIB transaction.
midcomResourceTableのリソース識別子はmiddleboxがNAT-MIB[RFC4008]かファイアウォールがMIBであると実装しない場合で独占であるベンダーであるかもしれません。 MIDCOM-MIBモジュールはNAT結合、セッション、およびファイアウォールピンホールに影響します。 これらのNATとファイアウォールリソースがどのように割り当てられて、管理されるかは故意にMIDCOM-MIBモジュールで指定されません、これがMIDCOM-MIB実装とmiddleboxの能力によるので。 しかしながら、どのリソースがどのMIDCOM-MIBトランザクションで影響を受けるかを理解していることのmidcomResourceTableは役に立ちます。
The midcomResourceTable is beneficial to the middlebox administrator in that the table lists all MIDCOM transactions and the middlebox specific resources to which these transactions refer. For instance, multiple MIDCOM clients might end up using the same NAT bind, yet each MIDCOM client might define a Lifetime parameter and directionality for the bind that is specific to the transaction. MIDCOM-MIB implementations are responsible for impacting underlying middlebox resources so as to satisfy the sometimes overlapping requirements on the same resource from multiple MIDCOM clients.
テーブルがこれらのトランザクションが参照されるすべてのMIDCOMトランザクションとmiddleboxの特定のリソースをリストアップするので、middlebox管理者にとって、midcomResourceTableは有益です。 例えば、複数のMIDCOMクライアントが結局同じNATひもを使用するかもしれません、しかし、それぞれのMIDCOMクライアントはトランザクションに特定のひものためにLifetimeパラメタと方向性を定義するかもしれません。 MIDCOM-MIB実装は複数のMIDCOMクライアントからの同じリソースに関する時々重なっている要件を満たすために基本的なmiddleboxリソースに影響を与えるのに原因となります。
Managing these resources is not a trivial task for MIDCOM-MIB implementers. It is possible that different MIDCOM-MIB policy rules owned by different MIDCOM clients share a NAT binding or a firewall rule. Then common properties, for example, the lifetime of the resource, need to be managed such that all clients are served well and changes to these resources need to be communicated to all affected clients. Also, dependencies between resources, for example, the precedence order of firewall rules, need to be considered
これらのリソースを管理するのは、MIDCOM-MIB implementersに、些細なタスクではありません。 異なったMIDCOMクライアントによって所有されていた異なったMIDCOM-MIB政策ルールがNAT結合かファイアウォール規則を共有するのは、可能です。 次に、通有性(例えば、リソースの生涯)が、管理される必要があるので、すべてのクライアントがよく役立たれています、そして、これらのリソースへの変化はすべての影響を受けるクライアントとコミュニケートする必要があります。 また、リソースの間の依存(例えば、ファイアウォール規則の先行命令)は、考えられる必要があります。
Quittek, et al. Standards Track [Page 23] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[23ページ]。
carefully in order to avoid that different policy rules -- potentially owned by different clients -- influence each other.
そんなに異なった政策ルール--異なったクライアントによって潜在的に所有されているのを避ける--慎重に、互いに影響を及ぼしてください。
MIDCOM clients may use the midcomResourceTable of the MIDCOM-MIB module in conjunction with the NAT-MIB module [RFC4008] to determine which resources of the NAT are used for MIDCOM. The NAT-MIB module stores the configured NAT bindings and sessions, and MIDCOM clients can use the information of the midcomResourceTable to sort out those NAT resources that are used by the MIDCOM-MIB module.
MIDCOMクライアントは、NATに関するどのリソースがMIDCOMに使用されるかを決定するのにNAT-MIBモジュール[RFC4008]に関連してMIDCOM-MIBモジュールのmidcomResourceTableを使用するかもしれません。 NAT-MIBモジュールは構成されたNAT結合とセッションを保存します、そして、MIDCOMクライアントはMIDCOM-MIBモジュールで使用されるそれらのNATリソースを整理するのにmidcomResourceTableの情報を使用できます。
5.3.2. midcomStatistics
5.3.2. midcomStatistics
The statistics subtree contains a set of non-columnar objects that provide 'MIDCOM protocol statistics', i.e., statistics about the usage of transaction objects.
統計下位木は'MIDCOMプロトコル統計'(すなわち、トランザクションオブジェクトの使用法に関する統計)を提供する1セットの非円柱状のオブジェクトを含んでいます。
o midcomCurrentOwners
This object indicates the number of different values for
midcomRuleOwner for all current entries in the midcomRuleTable.
o midcomCurrentOwners ThisオブジェクトはmidcomRuleOwnerのためにmidcomRuleTableのすべての現在のエントリーに異価の数を示します。
o midcomOwnersTotal
This object indicates the summarized number of all different
values that occurred for midcomRuleOwner in the midcomRuleTable
current and in the past.
o midcomOwnersTotal ThisオブジェクトはmidcomRuleTable海流と過去にmidcomRuleOwnerのために起こったすべての異価のまとめられた数を示します。
o midcomTotalRejectedRuleEntries
This object indicates the total number of failed attempts to
create an entry in the midcomRuleTable.
o midcomTotalRejectedRuleEntries ThisオブジェクトはmidcomRuleTableでエントリーを作成する未遂の総数を示します。
o midcomCurrentRulesIncomplete
This object indicates the total number of policy rules that have
not been fully loaded into a table row of the midcomRuleTable.
o midcomCurrentRulesIncomplete Thisオブジェクトは完全にmidcomRuleTableのテーブル行にロードされるというわけではなかった政策ルールの総数を示します。
o midcomTotalIncorrectReserveRules
This object indicates the total number of policy reserve rules
that were rejected because the request was incorrect.
o midcomTotalIncorrectReserveRules Thisオブジェクトは要求が不正確であったので拒絶された責任準備金規則の総数を示します。
o midcomTotalRejectedReserveRules
This object indicates the total number of policy reserve rules
that were failed while being processed.
o midcomTotalRejectedReserveRules Thisオブジェクトは処理されている間に失敗された責任準備金規則の総数を示します。
o midcomCurrentActiveReserveRules
This object indicates the number of currently active policy
reserve rules in the midcomRuleTable.
o midcomCurrentActiveReserveRules ThisオブジェクトはmidcomRuleTableの現在アクティブな責任準備金規則の数を示します。
o midcomTotalExpiredReserveRules
This object indicates the total number of expired policy reserve
rules.
o midcomTotalExpiredReserveRules Thisオブジェクトは満期の責任準備金規則の総数を示します。
Quittek, et al. Standards Track [Page 24] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[24ページ]。
o midcomTotalTerminatedOnRqReserveRules
This object indicates the total number of policy reserve rules
that were terminated on request.
o midcomTotalTerminatedOnRqReserveRules Thisオブジェクトは要求に応じて終えられた責任準備金規則の総数を示します。
o midcomTotalTerminatedReserveRules
This object indicates the total number of policy reserve rules
that were terminated, but not on request.
o midcomTotalTerminatedReserveRules Thisオブジェクトは、終えられた責任準備金規則の総数を示しますが、要求に応じて示すというわけではありません。
o midcomTotalIncorrectEnableRules
This object indicates the total number of policy enable rules
that were rejected because the request was incorrect.
o midcomTotalIncorrectEnableRules Thisオブジェクトは、方針の総数が要求が不正確であったので拒絶された規則を可能にするのを示します。
o midcomTotalRejectedEnableRules
This object indicates the total number of policy enable rules
that were failed while being processed.
o midcomTotalRejectedEnableRules Thisオブジェクトは、方針の総数が処理されている間に失敗された規則を可能にするのを示します。
o midcomCurrentActiveEnableRules
This object indicates the number of currently active policy
enable rules in the midcomRuleTable.
o midcomCurrentActiveEnableRules Thisオブジェクトは、現在アクティブな方針の数がmidcomRuleTableの規則を可能にするのを示します。
o midcomTotalExpiredEnableRules
This object indicates the total number of expired policy enable
rules.
o midcomTotalExpiredEnableRules Thisオブジェクトは、満期の方針の総数が規則を可能にするのを示します。
o midcomTotalTerminatedOnRqEnableRules
This object indicates the total number of policy enable rules
that were terminated on request.
o midcomTotalTerminatedOnRqEnableRules Thisオブジェクトは、方針の総数が要求に応じて終えられた規則を可能にするのを示します。
o midcomTotalTerminatedEnableRules
This object indicates the total number of policy enable rules
that were terminated, but not on request.
o midcomTotalTerminatedEnableRules Thisオブジェクトは、方針の総数が終えられた規則を可能にするのを示しますが、要求に応じて示すというわけではありません。
5.4. Notifications
5.4. 通知
For informing MIDCOM clients about state changes of MIDCOM-MIB implementations, three notifications can be used. They notify the MIDCOM client about state changes of individual policy rules or of groups of policy rules. Different notifications are used for different kinds of transactions.
MIDCOM-MIB実装の州の変化に関してMIDCOMクライアントに知らせるために、3つの通知を使用できます。 彼らは独特の政策ルールか政策ルールのグループの州の変化に関してMIDCOMクライアントに通知します。 異なった通知は異種のトランザクションに使用されます。
For asynchronous transactions, unsolicited notifications are used. The only asynchronous transaction that needs to be modeled by the MIDCOM-MIB is the Asynchronous Policy Rule Event (ARE). The ARE may be caused by the expiration of a policy rule lifetime, the expiration of the idle time, or an internal change in policy rule lifetime by the MIDCOM-MIB implementation for whatever reason.
非同期なトランザクションにおいて、求められていない通知は使用されています。 MIDCOM-MIBによってモデル化される必要がある唯一の非同期なトランザクションがAsynchronous Policy Rule Event(ある)です。 いかなる理由でもMIDCOM-MIB実装によって政策ルール生涯、遊休時間の満了、または政策ルール生涯の内的変化の満了で引き起こされるかもしれません。
Quittek, et al. Standards Track [Page 25] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[25ページ]。
For configuration transactions, solicited notifications are used. This concerns the Policy Reserve Rule (PRR) transaction, the Policy Enable Rule (PER) transaction, the Policy Rule Lifetime Change (RLC) transaction, and the Group Lifetime Change (GLC) transaction.
構成トランザクションにおいて、請求された通知は使用されています。 これはPolicy Reserve Rule(PRR)トランザクション、Policy Enable Rule(PER)トランザクション、Policy Rule Lifetime Change(RLC)トランザクション、およびGroup Lifetime Change(GLC)トランザクションに関係があります。
The separation between unsolicited and solicited notifications gives the implementer of a MIDCOM client some freedom to make design decisions on how to model the MIDCOM reply message as described at the end of section 4.2.2. Depending on the choice, processing of solicited notifications may not be required. In such a case, delivery of solicited notification may be disabled, for example, by an appropriate configuration of the snmpNotifyFilterTable such that solicited notifications are filtered differently to unsolicited notifications.
求められていなくて請求された通知の間の分離はデザインをセクション4.2.2の終わりで説明されるようにどうMIDCOM応答メッセージをモデル化するかに関する決定にする何らかの自由をMIDCOMクライアントのimplementerに与えます。 選択によって、請求された通知の処理は必要でないかもしれません。 例えば、このような場合には、請求された通知の配送がsnmpNotifyFilterTableの適切な構成によって無効にされるかもしれないので、請求された通知は求められていない通知に異なってフィルターにかけられます。
o midcomUnsolicitedRuleEvent
This notification can be generated for indicating the change of a
policy rule's state or lifetime. It is used for performing the
ARE transaction.
o 政策ルールの状態か生涯の変化を示すためにmidcomUnsolicitedRuleEvent This通知を生成することができます。 それが働くのに使用される、トランザクションはそうです。
o midcomSolicitedRuleEvent
This notification can be generated for indicating the requested
change of a policy rule's state or lifetime. It is used for
performing PRR, PER, and RLC transactions.
o 政策ルールの状態か生涯の要求された変化を示すためにmidcomSolicitedRuleEvent This通知を生成することができます。 それは、PRR、PER、およびRLCトランザクションを実行するのに使用されます。
o midcomSolicitedGroupEvent
This notification can be generated for indicating the requested
change of a policy rule group's lifetime. It is used for
performing the GLC transaction.
o 政策ルールグループの生涯の要求された変化を示すためにmidcomSolicitedGroupEvent This通知を生成することができます。 それは、GLCトランザクションを実行するのに使用されます。
6. Recommendations for Configuration and Operation
6. 構成と操作のための推薦
Configuring MIDCOM-MIB security is highly sensitive for obvious reasons. This section gives recommendations for securely configuring the SNMP agent acting as MIDCOM server. In addition, recommendations for avoiding idempotency problems are given and restrictions of MIDCOM-MIB applicability to a special set of applications are discussed.
MIDCOM-MIBセキュリティを構成するのは明白な理由によって非常に敏感です。 このセクションはしっかりとMIDCOMサーバとして務めているSNMPエージェントを構成するための推薦を与えます。さらに、idempotency問題を避けるための推薦を与えます、そして、特別なアプリケーションへのMIDCOM-MIBの適用性の制限について論じます。
6.1. Security Model Configuration
6.1. 機密保護モデル構成
Since controlling firewalls and NATs is highly sensitive, it is RECOMMENDED that SNMP Command Responders implementing the MIDCOM-MIB module use the authPriv security level for all users that may access managed objects of the MIDCOM-MIB module.
ファイアウォールとNATsを制御するのが非常に敏感であるので、MIDCOM-MIBモジュールを実装するSNMP Command RespondersがMIDCOM-MIBモジュールの管理オブジェクトにアクセスするかもしれないすべてのユーザにauthPrivセキュリティー・レベルを使用するのは、RECOMMENDEDです。
Quittek, et al. Standards Track [Page 26] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[26ページ]。
6.2. VACM Configuration
6.2. VACM構成
Entries in the midcomRuleTable and the midcomGroupTable provide information about existing firewall pinholes and/or NAT sessions. They also could be used for manipulating firewall pinholes and/or NAT sessions. Therefore, access control to these objects is essential and should be restrictive.
midcomRuleTableとmidcomGroupTableのエントリーは、ファイアウォールピンホールを存在することの情報に提供する、そして/または、セッションをNATに提供します。 また、ファイアウォールピンホール、そして/または、NATセッションを操るのにそれらを使用できました。 したがって、これらのオブジェクトへのアクセスコントロールは、不可欠であり、制限しているべきです。
It is RECOMMENDED that SNMP Command Responders instantiating an implementation of the MIDCOM-MIB module use VACM for controlling access to managed objects in the midcomRuleTable and the midcomGroupTable.
MIDCOM-MIBモジュールの実装を例示するSNMP Command RespondersがmidcomRuleTableとmidcomGroupTableで管理オブジェクトへのアクセスを制御するのにVACMを使用するのは、RECOMMENDEDです。
It is further RECOMMENDED that individual MIDCOM clients, acting as SNMP Command Generators, only have access to an entry in the midcomRuleTable, the midcomResourceTable, or the midcomGroupTable, if they created the entry directly in the midcomRuleTable or indirectly in the midcomGroupTable and midcomResourceTable. Exceptions to this recommendation are situations where access by multiple MIDCOM clients to managed objects is explicitly required. One example is fail-over for MIDCOM agents where the stand-by MIDCOM agent needs the same access rights to managed objects as the currently active MIDCOM agent. Another example is a supervisor MIDCOM agent that monitors activities of other MIDCOM agents and/or may be used by network management systems to modify entries in tables of the MIDCOM-MIB.
SNMP Command Generatorsとして機能して、個々のMIDCOMクライアントがmidcomRuleTable、midcomResourceTable、またはmidcomGroupTableでエントリーに近づく手段を持っているだけであるのは、一層のRECOMMENDEDです、彼らが間接的に直接midcomRuleTableかmidcomGroupTableとmidcomResourceTableでエントリーを作成したなら。 この推薦への例外は管理オブジェクトへの複数のMIDCOMクライアントによるアクセスが明らかに必要である状況です。 1つの例がMIDCOMエージェントのための予備MIDCOMエージェントが現在活発なMIDCOMエージェントとして同じアクセス権を管理オブジェクトに必要とするところのフェイルオーバーです。 別の例はMIDCOM-MIBのテーブルの他のMIDCOMエージェントの活動をモニターする、そして/または、ネットワーク管理システムによって使用される、エントリーを変更するかもしれないMIDCOMエージェント監督です。
For this reason, all three tables listed above have the midcomRuleOwner as initial index. It is RECOMMENDED that MIDCOM clients acting as SNMP Command Generator have access to the midcomRuleTable and the midcomGroupTable restricted to entries with the initial index matching either their SNMP securityName or their VACM groupName. It is RECOMMENDED that they do not have access to entries in these tables with initial indices other than their SNMP securityName or their VACM groupName. It is RECOMMENDED that this VACM configuration is applied to read access, write access, and notify access for all objects in the midcomRuleTable and the midcomGroupTable.
この理由で、上に記載されたすべての3個のテーブルが初期のインデックスとしてmidcomRuleOwnerを持っています。 それはSNMP Command GeneratorがmidcomRuleTableに近づく手段を持っているので行動しているMIDCOMクライアントとmidcomGroupTableが初期のインデックスがそれらのSNMP securityNameかそれらのVACM groupNameのどちらかに合っているエントリーに制限したRECOMMENDEDです。 彼らがこれらのテーブルでそれらのSNMP securityNameかそれらのVACM groupName以外の初期のインデックスリストでエントリーに近づく手段を持っていないのは、RECOMMENDEDです。 このVACM構成がmidcomRuleTableのすべてのオブジェクトとmidcomGroupTableのためにアクセスを読んで、アクセスを書いて、アクセスに通知するために適用されるのは、RECOMMENDEDです。
Note that less restrictive access rights MAY be granted to other users, for example, to a network management application, that monitors MIDCOM policy rules.
それほど制限していないアクセス権を他のユーザに与えるかもしれなくて、例えば、ネットワークマネージメントアプリケーションに、それがMIDCOM政策ルールをモニターすることに注意してください。
Quittek, et al. Standards Track [Page 27] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[27ページ]。
6.3. Notification Configuration
6.3. 通知構成
For each MIDCOM client that has access to the midcomRuleTable, a notification target SHOULD be configured at a Command Responder instantiating an implementation of the MIDCOM-MIB. It is RECOMMENDED that such a configuration be retrievable from the Command Responder via the SNMP-TARGET-MIB [RFC3413].
それからmidcomRuleTable、通知目標にSHOULDにアクセスするそれぞれのMIDCOMクライアントに関しては、MIDCOM-MIBの実装を例示するCommand Responderで構成されてください。 そのような構成がSNMP-TARGET-MIB[RFC3413]を通してCommand Responderから回収可能であることは、RECOMMENDEDです。
For each entry of the snmpTargetAddrTable that is related to a MIDCOM client, there SHOULD be an individual corresponding entry in the snmpTargetParamsTable.
そこのMIDCOMクライアントと関係があるsnmpTargetAddrTableの各エントリー、SHOULD、snmpTargetParamsTableの個々の対応するエントリーになってください。
An implementation of the MIDCOM-MIB SHOULD also implement the SNMP- NOTIFICATION-MIB [RFC3413]. An instance of an implementation of the MIDCOM-MIB SHOULD have an individual entry in the snmpNotifyFilterProfileTable for each MIDCOM client that has access to the midcomRuleTable.
また、MIDCOM-MIB SHOULDの実装はSNMP- NOTIFICATION-MIB[RFC3413]を実装します。 MIDCOM-MIB SHOULDの実装のインスタンスはmidcomRuleTableに近づく手段を持っているそれぞれのMIDCOMクライアントのためのsnmpNotifyFilterProfileTableに個人出場者を持っています。
An instance of an implementation of the MIDCOM-MIB SHOULD allow MIDCOM clients to start and stop the generation of notifications targeted at themselves. This SHOULD be realized by giving the MIDCOM clients write access to the snmpNotifyFilterTable. If appropriate entries of the snmpNotifyFilterTable are established in advance, then this can be achieved by granting MIDCOM clients write access only to the columnar object snmpNotifyFilterType.
MIDCOM-MIB SHOULDの実装のインスタンスで、MIDCOMクライアントは、始まって、自分たちをターゲットにした通知の世代を止めます。 このSHOULD、クライアントが書くMIDCOMにsnmpNotifyFilterTableへのアクセスを与えることによって、実感されてください。 snmpNotifyFilterTableの適切なエントリーがあらかじめ設置されるなら、円柱状のオブジェクトsnmpNotifyFilterTypeだけへのアクセスをクライアントが書くMIDCOMに承諾することによって、これを達成できます。
It is RECOMMENDED that VACM be configured such that each MIDCOM agent can only access entries in the snmpTargetAddrTable, the snmpTargetParamsTable, the snmpNotifyFilterProfileTable, and the snmpFilterTable that concern that particular MIDCOM agent. Typically, read access to the snmpTargetAddrTable, the snmpTargetParamsTable, and the snmpNotifyFilterProfileTable is sufficient. Write access may be required for objects of the snmpFilterTable.
VACMが構成されるのは、それぞれのMIDCOMエージェントがsnmpTargetAddrTable、snmpTargetParamsTable、snmpNotifyFilterProfileTable、およびその特定のMIDCOMエージェントに関するsnmpFilterTableでエントリーにアクセスできるだけであるためのRECOMMENDEDです。 通常、snmpTargetAddrTable、snmpTargetParamsTableへのアクセスを読んでください。そうすれば、snmpNotifyFilterProfileTableは十分です。 アクセスを書いてください。snmpFilterTableのオブジェクトに必要であってもよいです。
6.4. Simultaneous Access
6.4. 同時アクセス
Situations with two MIDCOM clients simultaneously modifying the same policy rule should be avoided. For each entry in the midcomRuleTable, there should be only one client at a time that modifies it. If two MIDCOM clients share the same midcomRuleOwner index of the midcomRuleTable, then conflicts can be avoided, for example, by
2人のMIDCOMクライアントが同時に同じ政策ルールを変更している状況は避けられるべきです。 midcomRuleTableの各エントリーには、一度にそれを変更する1人のクライアントしかいるべきではありません。 2人のMIDCOMクライアントがmidcomRuleTableの同じmidcomRuleOwnerインデックスを共有するなら、例えば、闘争を避けることができます。
- scheduling access times, as, for example, in the fail-over case;
- using different midcomGroupIndex values per client; or
- using non-overlapping intervals for values of the
midcomRuleIndex per client.
- 例えばフェイルオーバーケースのようにアクセスタイムの計画をします。 - 1クライアントあたりの異なったmidcomGroupIndex値を使用します。 または、--1クライアントあたりのmidcomRuleIndexの値のために非重なっている間隔を費やします。
Quittek, et al. Standards Track [Page 28] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[28ページ]。
6.5. Avoiding Idempotency Problems
6.5. Idempotency問題を避けます。
As already discussed in section 4.2.4.4, the following recommendation is given for avoiding idempotency problems.
セクション4.2.4で既に議論するように、idempotency問題を避けるために.4、以下の推薦を与えます。
In general, idempotency problems can be solved by including snmpSetSerialNo (see [RFC3418]) in SNMP SET requests.
一般に、SNMP SET要求にsnmpSetSerialNo([RFC3418]を見る)を含んでいることによって、idempotency問題を解決できます。
In case this feature is not used, it is RECOMMENDED that the value of the SNMP retransmission timer of a MIDCOM client (acting as SNMP Command Generator) is lower than the smallest requested value for any rule lifetime or rule idle time in order to prevent idempotency problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime when retransmitting an SNMP SET request after a lost SNMP reply.
この特徴が使用されていないといけないので、MIDCOMクライアント(SNMP Command Generatorとして、機能する)のSNMP再送信タイマーの値が無くなっているSNMP回答の後にSNMP SET要求を再送するとき、midcomRuleLifetimeとmidcomRuleMaxIdleTimeを設定することに関するidempotency問題を防ぐ最も小さいのがどんな規則のためにも値を要求したより低い生涯か規則遊休時間であることがRECOMMENDEDです。
MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent.
MIDCOMクライアント実装がそれらのSNMPスタックを構成することによってこの問題を完全に避けるかもしれないので、「再-トランスミッション」を全く送りません。
Similar considerations apply to MIDCOM-MIB implementations acting as Notification Originator when sending a notification (midcomUnsolicitedRuleEvent, midcomSolicitedRuleEvent or midcomSolicitedGroupEvent) containing the remaining lifetime of a policy rule or a policy rule group, respectively.
同様の問題は政策ルールか政策ルールの残っている生涯を含んでいて、通知書を送るとき(midcomUnsolicitedRuleEvent、midcomSolicitedRuleEventまたはmidcomSolicitedGroupEvent)、Notification Originatorがそれぞれ分類するので行動するMIDCOM-MIB実装に適用されます。
6.6. Interface Indexing Problems
6.6. インタフェースインデックス問題
A well-known problem of MIB modules is indexing IP interfaces after a re-initialization of the managed device. The index for interfaces provided by the ifTable (see IF-MIB in [RFC2863]) may change during re-initialization, for example, when physical interfaces are added or removed.
MIBモジュールのよく知られる問題は管理されたデバイスの再初期化の後にIPインタフェースに索引をつけています。 インタフェースへのインデックスがifTableで提供した、(見る、-、MIB、[RFC2863)では、例えば、再初期化の間、物理インターフェースがいつ加えられるか、または取り除かれるかを変えるかもしれません。
The MIDCOM-MIB module uses the interface index for indicating at which interface which policy rule is (or is to be) applied. Also, this index is used for indicating how policy rules are prioritized at certain interfaces. The MIDCOM-MIB module specification requires that information provided is always correct. This implies that after re-initialization, interface index values of policy rules or firewall configurations may have changed even though they still refer to the same interface as before the re-initialization.
または、MIDCOM-MIBモジュールがどのインタフェースで政策ルールがどれであるかを示すかにインタフェースインデックスを使用する、(であることになっている)、適用されています。 また、このインデックスは、政策ルールが、あるインタフェースでどう最優先するかを示すのに使用されます。 MIDCOM-MIBモジュール仕様は、提供された情報がいつも正しいのを必要とします。 これは、彼らがまだ同じくらい言及していますが、従来と同様再再初期化を、構成が変えたかもしれない政策ルールかファイアウォールのインタフェースインデックス値が次々と連結するのを含意します。
MIDCOM client implementations need to be aware of this potential behavior. It is RECOMMENDED that before writing the value or using the value of indices that depend on the ifTable the MIDCOM client checks if the middlebox has been re-initialized recently.
MIDCOMクライアント実装は、この潜在的振舞いを意識している必要があります。 値を書くか、またはifTableによるインデックスリストの値を使用する前にMIDCOMクライアントが、middleboxが最近再初期化されたかどうかチェックするのは、RECOMMENDEDです。
Quittek, et al. Standards Track [Page 29] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[29ページ]。
MIDCOM-MIB module implementations MUST track interface changes of IP interface indices in the ifTable. This implies that after a re- initialization of a middlebox, a MIDCOM-MIB implementation MUST make sure that each instance of an interface index in the MIDCOM-MIB tables still points to the same interface as before the re- initialization. For any instance for which this is not possible, all affected entries in tables of the MIDCOM-MIB module MUST be either terminated, disabled, or deleted, as specified in the DESCRIPTION clause of the respective object. This concerns all objects in the MIDCOM-MIB module that are of type InterfaceIndexOrZero.
MIDCOM-MIBモジュール実装はifTableにおける、IPインタフェースインデックスリストのインタフェース変化を追わなければなりません。 これは、middleboxの再初期化の後にMIDCOM-MIB実装が、MIDCOM-MIBテーブルのインタフェースインデックスの各インスタンスがまだ従来と同様再初期化を同じインタフェースに向けているのを確実にしなければならないのを含意します。 これが可能でないどんなインスタンスにおいても、MIDCOM-MIBモジュールのテーブルのすべての影響を受けるエントリーを終えられなければならないか、無効にされなければならないか、または削除しなければなりません、それぞれのオブジェクトの記述節で指定されるように。 これはタイプInterfaceIndexOrZeroにはあるMIDCOM-MIBモジュールによるすべてのオブジェクトに関係があります。
6.7. Applicability Restrictions
6.7. 適用性制限
As already discussed in section 5.1.1, the MIDCOM-MIB requires the MIDCOM client to specify address tuples A0 and A3. This can be a problem for applications that do not have this information available when they need to configure the middlebox. For some applications, there are usage scenarios where address information is only available for a single address realm, A0 and A1 in the private realm or A2 and A3 in the public realm. An example is an FTP application using the PORT command (instead of the PASV command). The problem occurs when the middlebox offers twice-NAT functionality.
セクション5.1.1で既に議論するように、MIDCOM-MIBは、MIDCOMクライアントがアドレスtuples A0とA3を指定するのを必要とします。 これはそれらが、middleboxを構成する必要がある場合利用可能なこの情報を持っていないアプリケーションのための問題であるかもしれません。 いくつかのアプリケーションのために、私設の分野のただ一つのアドレス分野、A0、およびA1について、アドレス情報があるだけである用法シナリオかA2とA3が公共部門にあります。 例はPORTコマンド(PASVコマンドの代わりに)を使用するFTPアプリケーションです。 middleboxが2倍NATの機能性を提供するとき、問題は起こります。
7. Usage Examples for MIDCOM Transactions
7. MIDCOMトランザクションのための使用例
This section presents some examples that explain how a MIDCOM client acting as SNMP manager can use the MIDCOM-MIB module defined in this memo. The purpose of these examples is to explain the steps that are required to perform MIDCOM transactions. For each MIDCOM transaction defined in the MIDCOM semantics [RFC5189], a sequence of SNMP operations that realizes the transaction is described.
このセクションはSNMPマネージャとして務めているMIDCOMクライアントがどうこのメモで定義されたMIDCOM-MIBモジュールを使用できるかがわかるいくつかの例を提示します。 これらの例の目的はMIDCOMトランザクションを実行するのに必要であるステップについて説明することです。 MIDCOM意味論[RFC5189]で定義されたそれぞれのMIDCOMトランザクションにおいて、トランザクションがわかるSNMP操作の系列は説明されます。
The examples described below are recommended procedures for MIDCOM clients. Clients may choose to operate differently.
以下で説明された例はMIDCOMクライアントにとってのお勧めの手順です。 クライアントは、異なって作動するのを選ぶかもしれません。
For example, they may choose not to receive solicited notifications on completion of a transaction, but to poll the MIDCOM-MIB instead until the transaction is completed. This can be achieved by performing step 2 of the SE transaction (see below) differently. The MIDCOM agent then creates an entry in the snmpNotifyFilterTable such that only the midcomUnsolicitedRuleEvent may pass the filter and is sent to the MIDCOM client. In this case, the PER, PRR, and RLC transactions require a polling loop wherever in the example below the MIDCOM client waits for a notification.
例えば、彼らは、取引が完了されるまでトランザクションの完成に関する請求された通知を受け取るのではなく、代わりにMIDCOM-MIBに投票するのを選ぶかもしれません。 SEトランザクション(以下を見る)のステップ2を異なって実行することによって、これを達成できます。 そして、MIDCOMエージェントは、midcomUnsolicitedRuleEventだけをフィルタを渡すかもしれなくて、MIDCOMクライアントに送るようにsnmpNotifyFilterTableでエントリーを作成します。 この場合、MIDCOMクライアントが以下の例でどこで通知を待っても、PER、PRR、およびRLCトランザクションは世論調査輪を必要とします。
Quittek, et al. Standards Track [Page 30] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[30ページ]。
7.1. Session Establishment (SE)
7.1. セッション設立(SE)
The MIDCOM-MIB realizes most properties of MIDCOM sessions in a very static way. Only the generation of notifications targeted at the MIDCOM client is enabled by the client for session establishment.
MIDCOM-MIBは非常に静的な方法でMIDCOMセッションのほとんどの特性がわかります。 MIDCOMクライアントをターゲットにした通知の世代だけがセッション設立のためにクライアントによって可能にされます。
1. The MIDCOM client checks the middlebox capabilities by reading
objects in the midcomCapabilitiesGroup.
1. MIDCOMクライアントは、midcomCapabilitiesGroupでオブジェクトを読むことによって、middlebox能力をチェックします。
2. The MIDCOM client enables generation of notifications on events
concerning the policy rules controlled by the client. If the
SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3
of this document, then the agent just has to change the value of a
object snmpNotifyFilterType in the corresponding entry of the
snmpNotifyFilterTable from included(1) to excluded(2).
2. MIDCOMクライアントはクライアントによって制御された政策ルールに関してイベントにおける通知の世代を可能にします。 このドキュメントのセクション6.3によって推薦されるようにSNMP-NOTIFICATION-MIBがサポートされるなら、エージェントがsnmpNotifyFilterTableの対応するエントリーにおける、オブジェクトsnmpNotifyFilterTypeの値をただ変えなければならないその時は除かれるのに(1)を含めました。(2)。
7.2. Session Termination (ST)
7.2. セッション終了(ST)
For terminating a session, the MIDCOM client just disables the generation of notifications for this client.
終わるために、セッションであり、MIDCOMクライアントはただこのクライアントへの通知の世代を無効にします。
1. The MIDCOM client disables generation of notifications on events
concerning the policy rules controlled by the client. If the
SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3
of this document, then the agent just has to change the value of a
object snmpNotifyFilterType in the corresponding entry of the
snmpNotifyFilterTable from included(1) to excluded(2).
1. MIDCOMクライアントはクライアントによって制御された政策ルールに関してイベントにおける通知の世代を無効にします。 このドキュメントのセクション6.3によって推薦されるようにSNMP-NOTIFICATION-MIBがサポートされるなら、エージェントがsnmpNotifyFilterTableの対応するエントリーにおける、オブジェクトsnmpNotifyFilterTypeの値をただ変えなければならないその時は除かれるのに(1)を含めました。(2)。
7.3. Policy Reserve Rule (PRR)
7.3. 責任準備金規則(PRR)
This example explains steps that may be performed by a MIDCOM client to establish a policy reserve rule.
この例で、責任準備金規則を証明するためにMIDCOMクライアントによって実行されるかもしれないステップがわかります。
1. The MIDCOM client creates a new entry in the midcomRuleTable by
writing to midcomRuleRowStatus. The chosen value for index object
midcomGroupIndex determines the group membership of the created
rule. Note that choosing an unused value for midcomGroupIndex
creates a new entry in the midcomGroupTable.
1. MIDCOMクライアントは、midcomRuleTableでmidcomRuleRowStatusに書くことによって、新しいエントリーを作成します。 インデックスオブジェクトmidcomGroupIndexのための選ばれた値は作成された規則のグループ会員資格を決定します。 midcomGroupIndexのための未使用の値を選ぶと新しいエントリーがmidcomGroupTableで作成されることに注意してください。
2. The MIDCOM client sets the following objects in the new entry of
the midcomRuleTable to specify all request parameters of the PRR
transaction:
2. MIDCOMクライアントはPRRトランザクションのすべての要求パラメタを指定するためにmidcomRuleTableの新しいエントリーに以下のオブジェクトをはめ込みます:
- midcomRuleMaxIdleTime
- midcomRuleInterface
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleMaxIdleTime--midcomRuleInterface--midcomRuleTransportProtocol--midcomRulePortRange--midcomRuleInternalIpVersion
Quittek, et al. Standards Track [Page 31] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[31ページ]。
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleLifetime
- midcomRuleExternalIpVersion--midcomRuleInternalIpAddr--midcomRuleInternalIpPrefixLength--midcomRuleInternalPort--midcomRuleLifetime
Note that several of these parameters have default values that can
be used.
これらのいくつかのパラメタには使用できるデフォルト値があることに注意してください。
3. The MIDCOM client sets the midcomRuleAdminStatus objects in the
new row of the midcomRuleTable to reserve(1).
3. MIDCOMクライアントは、(1)を予約するためにmidcomRuleTableの新しい列にmidcomRuleAdminStatus物をはめ込みます。
4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
concerning the new policy rule in the midcomRuleTable. Waiting
for the notification is timed out after a pre-selected maximum
waiting time. In case of a timeout while waiting for the
notification or if the client does not use notifications, the
MIDCOM client retrieves the status of the midcomRuleEntry by one
or more SNMP GET operations.
4. MIDCOMクライアントはmidcomRuleTableの新しい政策規則に関してmidcomSolicitedRuleEvent通知を待ちます。 通知を待つのは前選択された最大の待ち時間の後に外で調節されています。 通知かそれともクライアントが通知を使用しないかどうかを待っている間のタイムアウトの場合には、MIDCOMクライアントは1つ以上のSNMP GET操作でmidcomRuleEntryの状態を検索します。
5. After receiving the midcomSolicitedRuleEvent notification, the
MIDCOM client checks the lifetime value carried by the
notification. If it is greater than 0, the MIDCOM client reads
all positive reply parameters of the PRR transaction:
5. midcomSolicitedRuleEvent通知を受け取った後に、MIDCOMクライアントは通知で運ばれた生涯値をチェックします。 それが0以上であるなら、MIDCOMクライアントはPRR取引のすべての積極的な返事パラメタを読みます:
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleMaxIdleTime
- midcomRuleLifetime
- midcomRuleOutsideIpAddr--midcomRuleOutsidePort--midcomRuleMaxIdleTime--midcomRuleLifetime
If the lifetime equals 0, then the MIDCOM client reads the
midcomRuleOperStatus and the midcomRuleError in order to analyze
the failure reason.
寿命が0と等しいなら、MIDCOMクライアントは、失敗理由を分析するためにmidcomRuleOperStatusとmidcomRuleErrorを読みます。
6. Optionally, after receiving the midcomSolicitedRuleEvent
notification with a lifetime value greater than 0, the MIDCOM
client may check the midcomResourceTable for the middlebox
resources allocated for this policy reserve rule. Note that PRR
does not necessarily allocate any middlebox resource visible in
the NAT-MIB module or in a firewall MIB module, since it does a
reservation only. If, however, the PRR overlaps with already
existing PERs, then the PRR may be related to middlebox resources
visible in other MIB modules.
6. 任意に、生涯値より多くの0でmidcomSolicitedRuleEvent通知を受け取った後に、MIDCOMクライアントはこの責任準備金規則のために割り当てられたmiddleboxリソースがないかどうかmidcomResourceTableをチェックするかもしれません。 PRRが必ずNAT-MIBモジュールかファイアウォールMIBモジュールで目に見えるどんなmiddleboxリソースも割り当てるというわけではないことに注意してください、予約するだけであるので。 しかしながら、PRRが既に既存のPERに重なるなら、PRRは他のMIBモジュールで目に見えるmiddleboxリソースに関連するかもしれません。
Quittek, et al. Standards Track [Page 32] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[32ページ]。
7.4. Policy Enable Rule (PER) after PRR
7.4. 方針は規則(PER)後PRRを有効にします。
This example explains steps that may be performed by a MIDCOM client to establish a policy enable rule after a corresponding policy reserve rule was already established.
この例で、対応する責任準備金規則が既に確立された後に方針を証明するためにMIDCOMクライアントによって実行されるかもしれないステップが規則を可能にするのがわかります。
1. The MIDCOM client sets the following objects in the row of the
established PRR in the midcomRuleTable to specify all request
parameters of the PER transaction:
1. MIDCOMクライアントはPER取引のすべての要求パラメタを指定するためにmidcomRuleTableで確立したPRRの列に以下の物をはめ込みます:
- midcomRuleMaxIdleTime
- midcomRuleExternalIpAddr
- midcomRuleExternalIpPrefixLength
- midcomRuleExternalPort
- midcomRuleFlowDirection
- midcomRuleMaxIdleTime--midcomRuleExternalIpAddr--midcomRuleExternalIpPrefixLength--midcomRuleExternalPort--midcomRuleFlowDirection
Note that several of these parameters have default values that can
be used.
これらのいくつかのパラメタには使用できるデフォルト値があることに注意してください。
2. The MIDCOM client sets the midcomRuleAdminStatus objects in the
row of the established PRR in the midcomRuleTable to enable(1).
2. MIDCOMクライアントは、(1)を可能にするためにmidcomRuleTableで確立したPRRの列にmidcomRuleAdminStatus物をはめ込みます。
3. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
concerning the new row in the midcomRuleTable. Waiting for the
notification is timed out after a pre-selected maximum waiting
time. In case of a timeout while waiting for the notification or
if the client does not use notifications, the MIDCOM client
retrieves the status of the midcomRuleEntry by one or more SNMP
GET operations.
3. MIDCOMクライアントはmidcomRuleTableの新しい列に関してmidcomSolicitedRuleEvent通知を待ちます。 通知を待つのは前選択された最大の待ち時間の後に外で調節されています。 通知かそれともクライアントが通知を使用しないかどうかを待っている間のタイムアウトの場合には、MIDCOMクライアントは1つ以上のSNMP GET操作でmidcomRuleEntryの状態を検索します。
4. After receiving the midcomSolicitedRuleEvent notification, the
MIDCOM client checks the lifetime value carried by the
notification. If it is greater than 0, the MIDCOM client reads
all positive reply parameters of the PER transaction:
4. midcomSolicitedRuleEvent通知を受け取った後に、MIDCOMクライアントは通知で運ばれた生涯値をチェックします。 それが0以上であるなら、MIDCOMクライアントはPER取引のすべての積極的な返事パラメタを読みます:
- midcomRuleInsideIpAddr
- midcomRuleInsidePort
- midcomRuleMaxIdleTime
- midcomRuleInsideIpAddr--midcomRuleInsidePort--midcomRuleMaxIdleTime
If the lifetime equals 0, then the MIDCOM client reads the
midcomRuleOperStatus and the midcomRuleError in order to analyze
the failure reason.
寿命が0と等しいなら、MIDCOMクライアントは、失敗理由を分析するためにmidcomRuleOperStatusとmidcomRuleErrorを読みます。
5. Optionally, after receiving the midcomSolicitedRuleEvent
notification with a lifetime value greater than 0, the MIDCOM
client may check the midcomResourceTable for the allocated
middlebox resources for this policy enable rule.
5. 任意に、生涯値が0、MIDCOMクライアントより大きい状態でmidcomSolicitedRuleEvent通知を受け取った後に、この方針のための割り当てられたmiddleboxリソースのためのmidcomResourceTableが可能にするチェックが統治されますように。
Quittek, et al. Standards Track [Page 33] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[33ページ]。
7.5. Policy Enable Rule (PER) without Previous PRR
7.5. 方針は前のPRRなしで規則(PER)を可能にします。
This example explains steps that may be performed by a MIDCOM client to establish a policy enable rule for which no PRR transaction has been performed before.
この例で、方針を証明するためにMIDCOMクライアントによって実行されるかもしれないステップがPRR取引が全く以前実行されたことがない規則を可能にするのがわかります。
1. Identical to step 1 for PRR (section 7.3).
1. PRR(セクション7.3)にステップ1と同じです。
2. Identical to step 2 for PRR (section 7.3).
2. PRR(セクション7.3)にステップ2と同じです。
3. The MIDCOM client sets the following objects in the new row of the
midcomRuleTable to specify all request parameters of the PER
transaction:
3. MIDCOMクライアントはPER取引のすべての要求パラメタを指定するためにmidcomRuleTableの新しい列に以下の物をはめ込みます:
- midcomRuleInterface
- midcomRuleFlowDirection
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleExternalIpAddr
- midcomRuleExternalIpPrefixLength
- midcomRuleExternalPort
- midcomRuleLifetime
- midcomRuleInterface--midcomRuleFlowDirection--midcomRuleTransportProtocol--midcomRulePortRange--midcomRuleInternalIpVersion--midcomRuleExternalIpVersion--midcomRuleInternalIpAddr--midcomRuleInternalIpPrefixLength--midcomRuleInternalPort--midcomRuleExternalIpAddr--midcomRuleExternalIpPrefixLength--midcomRuleExternalPort--midcomRuleLifetime
Note that several of these parameters have default values that can
be used.
これらのいくつかのパラメタには使用できるデフォルト値があることに注意してください。
4. The MIDCOM client sets the midcomRuleAdminStatus objects in the
new row of the midcomRuleTable to enable(1).
4. MIDCOMクライアントは、(1)を可能にするためにmidcomRuleTableの新しい列にmidcomRuleAdminStatus物をはめ込みます。
5. Identical to step 4 for PRR (section 7.3).
5. PRR(セクション7.3)にステップ4と同じです。
6. After receiving the midcomSolicitedRuleEvent notification, the
MIDCOM client checks the lifetime value carried by the
notification. If it is greater than 0, the MIDCOM client reads
all positive reply parameters of the PRR transaction:
6. midcomSolicitedRuleEvent通知を受け取った後に、MIDCOMクライアントは通知で運ばれた生涯値をチェックします。 それが0以上であるなら、MIDCOMクライアントはPRR取引のすべての積極的な返事パラメタを読みます:
- midcomRuleInsideIpAddr
- midcomRuleInsidePort
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleMaxIdleTime
- midcomRuleInsideIpAddr--midcomRuleInsidePort--midcomRuleOutsideIpAddr--midcomRuleOutsidePort--midcomRuleMaxIdleTime
Quittek, et al. Standards Track [Page 34] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[34ページ]。
If the lifetime equals 0, then the MIDCOM client reads the
midcomRuleOperStatus and the midcomRuleError in order to analyze
the failure reason.
寿命が0と等しいなら、MIDCOMクライアントは、失敗理由を分析するためにmidcomRuleOperStatusとmidcomRuleErrorを読みます。
7. Optionally, after receiving the midcomSolicitedRuleEvent
notification with a lifetime value greater than 0, the MIDCOM
client may check the midcomResourceTable for the allocated
middlebox resources for this policy enable rule.
7. 任意に、生涯値が0、MIDCOMクライアントより大きい状態でmidcomSolicitedRuleEvent通知を受け取った後に、この方針のための割り当てられたmiddleboxリソースのためのmidcomResourceTableが可能にするチェックが統治されますように。
7.6. Policy Rule Lifetime Change (RLC)
7.6. 政策ルール生涯変化(RLC)
This example explains steps that may be performed by a MIDCOM client to change the lifetime of a policy rule. Changing the lifetime to 0 implies terminating the policy rule.
この例で、政策ルールの生涯を変えるためにMIDCOMクライアントによって実行されるかもしれないステップがわかります。 生涯を0に変えるのは、方針を終えて、統治するように含意します。
1. The MIDCOM client issues a SET request for writing the desired lifetime to the midcomRuleLifetime object in the corresponding row of the midcomRuleTable. This does not have any effect if the lifetime is already expired.
1. MIDCOMクライアントはmidcomRuleTableの対応する列のmidcomRuleLifetime物への必要な生涯を書くのを求めるSET要求を出します。 これには、寿命が既に吐き出されるなら、少しの効果もありません。
2. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the corresponding row in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP GET operations.
2. MIDCOMクライアントはmidcomRuleTableの対応する列に関してmidcomSolicitedRuleEvent通知を待ちます。 通知を待つのは前選択された最大の待ち時間の後に外で調節されています。 通知かそれともクライアントが通知を使用しないかどうかを待っている間のタイムアウトの場合には、MIDCOMクライアントは1つ以上のSNMP GET操作でmidcomRuleEntryの状態を検索します。
3. After receiving the midcomSolicitedRuleEvent notification MIDCOM client checks the lifetime value carried by the notification.
3. 受信した後に、midcomSolicitedRuleEvent通知MIDCOMクライアントは通知で運ばれた生涯値をチェックします。
7.7. Policy Rule List (PRL)
7.7. 政策ルールリスト(PRL)
The SNMP agent can browse the list of policy rules by browsing the midcomRuleTable. For each observed row in this table, the SNMP agent should check the midcomRuleOperStatus in order to find out if the row contains information about an established policy rule or of a rule that is under construction or already terminated.
SNMPエージェントは、midcomRuleTableをブラウズすることによって、政策ルールのリストをブラウズできます。 このテーブルのそれぞれの観測された列がないかどうか、SNMPエージェントは、列が既定方針規則の情報を含んでいるか、またはそれが工事中か既に規則では、終えられるかを見つけるためにmidcomRuleOperStatusをチェックするべきです。
7.8. Policy Rule Status (PRS)
7.8. 政策ルール状態(PRS)
The SNMP agent can retrieve all status information and properties of a policy rule by reading the managed objects in the corresponding row of the midcomRuleTable.
SNMPエージェントは、midcomRuleTableの対応する列で管理オブジェクトを読むことによって、政策ルールのすべての状態情報と特性を検索できます。
Quittek, et al. Standards Track [Page 35] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[35ページ]。
7.9. Asynchronous Policy Rule Event (ARE)
7.9. 非同期な政策ルールイベント(あります)
There are two different triggers for the ARE. It may be triggered by the expiration of a policy rule's lifetime or the expiration of the idle time. But beyond this, the MIDCOM-MIB implementation may terminate a policy rule at any time. In all cases, two steps are required for performing this transaction:
2個の異なった引き金がある、あります。 それは政策ルールの生涯の満了か遊休時間の満了で引き起こされるかもしれません。 しかし、これを超えて、MIDCOM-MIB実現はいつでも、政策ルールを終えるかもしれません。 すべての場合では、2ステップがこの取引を実行するのに必要です:
1. The MIDCOM-MIB implementation sends a midcomUnsolicitedRuleEvent
notification containing a lifetime value of 0 to the MIDCOM client
owning the rule.
1. MIDCOM-MIB実現で、0の生涯値をMIDCOMクライアントに含むmidcomUnsolicitedRuleEvent通知は規則を所有しています。
2. If the midcomRuleStorageTime object in the corresponding row of
the midcomRuleTable has a value of 0, then the MIDCOM-MIB
implementation removes the row from the table. Otherwise, it sets
in this row the midcomRuleLifetime object to 0 and changes the
midcomRuleOperStatus object. If the event was triggered by policy
lifetime expiration, then the midcomRuleOperStatus is set to
timedOut(9); otherwise, it is set to terminated(11).
2. midcomRuleTableの対応する列のmidcomRuleStorageTime物に0の値があるなら、MIDCOM-MIB実現はテーブルから列を取り除きます。 さもなければ、それはmidcomRuleLifetimeが0に反対させるこの列と変化でmidcomRuleOperStatus物を設定します。 出来事が方針生涯満了で引き起こされたなら、midcomRuleOperStatusはtimedOut(9)に用意ができています。 さもなければ、終えられて、それは設定されます。(11)。
7.10. Group Lifetime Change (GLC)
7.10. グループ生涯変化(GLC)
This example explains steps that may be performed by a MIDCOM client to change the lifetime of a policy rule group. Changing the lifetime to 0 implies terminating all member policies of the group.
この例で、政策ルールグループの生涯を変えるためにMIDCOMクライアントによって実行されるかもしれないステップがわかります。 グループのすべてのメンバー方針を終える0への寿命が含意する変化。
1. The MIDCOM client issues a SET request for writing the desired
lifetime to the midcomGroupLifetime object in the corresponding
row of the midcomGroupTable.
1. MIDCOMクライアントはmidcomGroupTableの対応する列のmidcomGroupLifetime物への必要な生涯を書くのを求めるSET要求を出します。
2. The MIDCOM client waits for a midcomSolicitedGroupEvent
notification concerning the corresponding row in the
midcomGroupTable. Waiting for the notification is timed out after
a pre-selected maximum waiting time. In case of a timeout while
waiting for the notification or if the client does not use
notifications, the MIDCOM client retrieves the status of the
midcomGroupEntry by one or more SNMP GET operations.
2. MIDCOMクライアントはmidcomGroupTableの対応する列に関してmidcomSolicitedGroupEvent通知を待ちます。 通知を待つのは前選択された最大の待ち時間の後に外で調節されています。 通知かそれともクライアントが通知を使用しないかどうかを待っている間のタイムアウトの場合には、MIDCOMクライアントは1つ以上のSNMP GET操作でmidcomGroupEntryの状態を検索します。
3. After receiving the midcomSolicitedRuleEvent notification, the
MIDCOM client checks the lifetime value carried by the
notification.
3. midcomSolicitedRuleEvent通知を受け取った後に、MIDCOMクライアントは通知で運ばれた生涯値をチェックします。
7.11. Group List (GL)
7.11. グループリスト(GL)
The SNMP agent can browse the list of policy rule groups by browsing the midcomGroupTable. For each observed row in this table, the SNMP agent should check the midcomGroupLifetime in order to find out if the group does contain established policies.
SNMPエージェントは、midcomGroupTableをブラウズすることによって、政策ルールグループのリストをブラウズできます。 このテーブルのそれぞれの観測された列がないかどうか、SNMPエージェントは、グループが既定方針を含むかどうか見つけるためにmidcomGroupLifetimeをチェックするべきです。
Quittek, et al. Standards Track [Page 36] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[36ページ]。
7.12. Group Status (GS)
7.12. グループ状態(GS)
The SNMP agent can retrieve all member policies of a group by browsing the midcomRuleTable using the midcomGroupIndex of the particular group. For retrieving the remaining lifetime of the group, the SNMP agent reads the midcomGroupLifetime object in the corresponding row of the midcomGroupTable.
SNMPエージェントは、特定のグループのmidcomGroupIndexを使用することでmidcomRuleTableをブラウズすることによって、グループのすべてのメンバー方針を検索できます。 グループの残っている生涯を検索するために、SNMPエージェントはmidcomGroupTableの対応する列でmidcomGroupLifetime物を読みます。
8. Usage Examples for Monitoring Objects
8. モニターしている物のための使用例
This section presents some examples that explain how a MIDCOM client can use the midcomResourceTable to correlate policy rules with the used middlebox resources. One example is given for middleboxes implementing the NAT-MIB and another one is given for firewalls.
このセクションは中古のmiddleboxリソースでMIDCOMクライアントが関連するのにどうmidcomResourceTableを使用できるかがわかるいくつかの例に政策ルールを提示します。 NAT-MIBを実行するmiddleboxesのために1つの例を出します、そして、別の1つをファイアウォールに与えます。
8.1. Monitoring NAT Resources
8.1. モニターしているNATリソース
When a rule in the midcomRuleTable is executed, it directly impacts the middlebox resources. The midcomResourceTable provides the information on the relationships between the MIDCOM-MIB policy rules and the middlebox resources used for enforcing these rules.
midcomRuleTableの規則が実行されるとき、それは直接middleboxリソースに影響を与えます。 midcomResourceTableはMIDCOM-MIB政策ルールとmiddlebox運用資金との関係の情報をこれらの規則を実施するのに提供します。
A MIDCOM-MIB policy rule will cause the creation or modification of up to two NAT bindings and up to two NAT sessions. Two NAT bindings are impacted in the case of a session being subject to twice-NAT. Two NAT bindings may also be impacted when midcomRulePortRange is set to pair(2) in the policy rule. In the majority of cases, where traditional NAT is implemented, only a single NAT binding may be adequate. Note, however, that this BindId is set to 0 if the middlebox is implementing symmetric NAT function. Two NAT sessions are created or modified only when the midcomRulePortRange is set to pair(2) in the policy rule.
MIDCOM-MIB政策ルールは最大2つのNAT結合と最大2つのNATセッションの創造か変更を引き起こすでしょう。 セッション存在対象のケースで2つのNAT結合に2倍NATに影響を与えます。 また、midcomRulePortRangeが政策ルールで(2)を対にするように用意ができているとき、2つのNAT結合に影響を与えるかもしれません。 場合の大部分では、ただ一つのNAT結合だけが適切であるかもしれません。(そこでは、伝統的なNATが実行されます)。 しかしながら、middleboxが左右対称のNAT機能を実行するならこのBindIdが0に用意ができていることに注意してください。 midcomRulePortRangeが政策ルールで(2)を対にするように用意ができているときだけ、2つのNATセッションが、作成されるか、または変更されます。
When support for the NAT-MIB module is also available at the middlebox, the parameters in the combination of the midcomRuleTable and the midcomResourceTable for a given rule can be used to index the corresponding BIND and NAT session resources effected in the NAT-MIB. These parameters are valuable to monitor the impact on the NAT module, even when the NAT-MIB module is not implemented at the middlebox.
また、NAT-MIBモジュールのサポートもmiddleboxで利用可能であるときに、セッションリソースがNAT-MIBで作用した対応するBINDとNATに索引をつけるのに与えられた規則のためのmidcomRuleTableとmidcomResourceTableの組み合わせにおけるパラメタを使用できます。 これらのパラメタはNATモジュールへの影響をモニターするのにおいて貴重です、NAT-MIBモジュールがmiddleboxで実行さえされないとき。
The impact of MIDCOM rules on the NAT resources is important because a MIDCOM rule not only can create BINDs and NAT sessions, but also is capable of modifying the NAT objects that already exist. For example, FlowDirection and MaxIdleTime parameters in a MIDCOM rule directly affect the TranslationEntity and MaxIdleTime of the associated NAT bind object. Likewise, MaxIdleTime in a MIDCOM rule
MIDCOM規則がBINDsとNATセッションを作成できるだけではなく、既に存在するNAT物を変更もできるので、NATリソースへのMIDCOM規則の影響は重要です。 例えば、MIDCOM規則によるFlowDirectionとMaxIdleTimeパラメタは直接関連NATひもの物のTranslationEntityとMaxIdleTimeに影響します。 同様に、MIDCOMのMaxIdleTimeは統治します。
Quittek, et al. Standards Track [Page 37] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[37ページ]。
has a direct impact on the MaxIdleTime of the associated NAT session object. The lifetime parameter in the MIDCOM rule directly impacts the lifetime of all the impacted NAT BIND and NAT session objects.
関連NATセッション物のMaxIdleTimeに直接的な衝撃を持っています。 MIDCOM規則による生涯パラメタは直接すべての影響を与えられたNAT BINDとNATセッション物の生涯に影響を与えます。
8.2. Monitoring Firewall Resources
8.2. モニターしているファイアウォールリソース
When a MIDCOM-MIB policy rule is established at a middlebox with firewall capabilities, this may lead to the creation of one or more new firewall rules. Note that in general a single firewall rule per MIDCOM-MIB policy rule will be sufficient. For each policy rule, a MIDCOM client can explore the corresponding firewall filter rule by reading the midcomResourceEntry in the midcomResourceTable that corresponds to the midcomRuleEntry describing the rule. The identification of the firewall filter rule is stored in object midcomRscFirewallRuleId. The value of midcomRscFirewallRuleId may correspond directly to any firewall filter rule number or to an entry in a locally available firewall MIB module.
MIDCOM-MIB政策ルールがファイアウォール能力があるmiddleboxで確立されるとき、これは1つ以上の新しいファイアウォール規則の創造に通じるかもしれません。 一般に、MIDCOM-MIB政策ルールあたり1つのただ一つのファイアウォール規則が十分であることに注意してください。 各政策ルールのために、MIDCOMクライアントは、規則について説明するmidcomRuleEntryに対応するmidcomResourceTableでmidcomResourceEntryを読むことによって、対応するファイアウォールフィルタ規則を探ることができます。 ファイアウォールフィルタ規則の識別は物のmidcomRscFirewallRuleIdに格納されます。 midcomRscFirewallRuleIdの値は局所的に利用可能なファイアウォールMIBモジュールで直接どんなファイアウォールフィルタ規則番号、または、エントリーに対応するかもしれません。
9. Definitions
9. 定義
The following MIB module imports from [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3411], [RFC4001], and [RFC4008].
[RFC2578]、[RFC2579]、[RFC2580]、[RFC2863]、[RFC3411]、[RFC4001]、および[RFC4008]からの以下のMIBモジュール輸入。
MIDCOM-MIB DEFINITIONS ::= BEGIN
MIDCOM-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
NOTIFICATION-TYPE, Unsigned32,
Counter32, Gauge32, mib-2
FROM SNMPv2-SMI -- RFC 2578
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、NOTIFICATION-TYPE、RFC Unsigned32、Counter32、Gauge32、mib-2 FROM SNMPv2-SMI--2578
TEXTUAL-CONVENTION, TruthValue,
StorageType, RowStatus
FROM SNMPv2-TC -- RFC 2579
原文のコンベンション、TruthValue、StorageType、RFC SNMPv2-TcからのRowStatus--2579
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC 2580
SNMPv2-CONFからのモジュールコンプライアンス、物グループ、通知グループ--RFC2580
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- RFC 3411
SNMP枠組みのMIBからのSnmpAdminString--RFC3411
InetAddressType, InetAddress,
InetPortNumber,
InetAddressPrefixLength
FROM INET-ADDRESS-MIB -- RFC 4001
InetAddressType、InetAddress、InetPortNumber、RFC INETアドレスMIBからのInetAddressPrefixLength--4001
Quittek, et al. Standards Track [Page 38] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[38ページ]。
InterfaceIndexOrZero
FROM IF-MIB -- RFC 2863
InterfaceIndexOrZero、-、MIB、--、RFC2863
NatBindIdOrZero
FROM NAT-MIB; -- RFC 4008
NAT-MIBからのNatBindIdOrZero。 -- RFC4008
midcomMIB MODULE-IDENTITY
LAST-UPDATED "200708091011Z" -- August 09, 2007
ORGANIZATION "IETF Middlebox Communication Working Group"
CONTACT-INFO
"WG charter:
http://www.ietf.org/html.charters/midcom-charter.html
midcomMIB MODULE-IDENTITY LAST-UPDATED"200708091011Z"--、2007年8月9日組織「IETF Middleboxコミュニケーション作業部会」コンタクトインフォメーション、「WGは以下をチャーターします」。 http://www.ietf.org/html.charters/midcom-charter.html
Mailing Lists:
General Discussion: midcom@ietf.org
To Subscribe: midcom-request@ietf.org
In Body: subscribe your_email_address
メーリングリスト: 一般議論: 申し込む midcom@ietf.org : ボディーの midcom-request@ietf.org : _メール_アドレスを申し込んでください。
Co-editor:
Juergen Quittek
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Tel: +49 6221 4342-115
Email: quittek@nw.neclab.eu
共同エディタ: ユルゲンQuittek NECヨーロッパLtd.Kurfuersten-原基36 69115ハイデルベルグドイツTel: +49 6221 4342-115 メールしてください: quittek@nw.neclab.eu
Co-editor:
Martin Stiemerling
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Tel: +49 6221 4342-113
Email: stiemerling@nw.neclab.eu
共同エディタ: マーチンStiemerling NECヨーロッパLtd.Kurfuersten-原基36 69115ハイデルベルグドイツTel: +49 6221 4342-113 メールしてください: stiemerling@nw.neclab.eu
Co-editor:
Pyda Srisuresh
Kazeon Systems, Inc.
1161 San Antonio Rd.
Mountain View, CA 94043
U.S.A.
Tel: +1 408 836-4773
Email: srisuresh@yahoo.com"
共同エディタ: Pyda Srisuresh KazeonシステムInc.1161サンアントニオ、通り マウンテンビュー、カリフォルニア94043米国Tel: +1 408 836-4773 メールしてください: " srisuresh@yahoo.com "
DESCRIPTION
"This MIB module defines a set of basic objects for
configuring middleboxes, such as firewalls and network
「このMIBモジュールはファイアウォールやネットワークなどのmiddleboxesを構成しながら、1セットの基本的な物を定義する」記述
Quittek, et al. Standards Track [Page 39] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[39ページ]。
address translators, in order to enable communication
across these devices.
これらの装置の向こう側にコミュニケーションを可能にするために翻訳者に演説してください。
Managed objects defined in this MIB module are structured
in three kinds of objects:
- transaction objects required according to the MIDCOM
protocol requirements defined in RFC 3304 and according
to the MIDCOM protocol semantics defined in RFC 3989,
- configuration objects that can be used for retrieving or
setting parameters of the implementation of transaction
objects,
- optional monitoring objects that provide information
about used resource and statistics
このMIBモジュールで定義された管理オブジェクトは3種類の物で構造化されます: - RFC3989で定義されたMIDCOMプロトコル意味論--取引物の実現のパラメタを検索するか、または設定するのに使用できる構成物--RFC3304で定義されたMIDCOMプロトコル要件と中古のリソースと統計の情報を提供する任意のモニターしている物に従って、取引物が必要です。
The transaction objects are organized in two subtrees:
- objects modeling MIDCOM policy rules in the
midcomRuleTable
- objects modeling MIDCOM policy rule groups in the
midcomGroupTable
取引物は2つの下位木で組織化されます: - midcomRuleTableのMIDCOM政策ルールをモデル化する物--midcomGroupTableのMIDCOM政策ルールグループをモデル化する物
Note that typically, configuration objects are not intended
to be written by MIDCOM clients. In general, write access
to these objects needs to be restricted more strictly than
write access to objects in the transaction subtrees.
通常、構成物がMIDCOMクライアントによって書かれていることを意図しないことに注意してください。 一般に、これらへのアクセスを書いてください。物は、取引下位木に物へのアクセスを書くよりさらに厳密に制限される必要があります。
Copyright (C) The Internet Society (2008). This version
of this MIB module is part of RFC 5190; see the RFC
itself for full legal notices."
Copyright(C)インターネット協会(2008)。 このMIBモジュールのこのバージョンはRFC5190の一部です。 「完全な法定の通知に関してRFC自身を見てください。」
REVISION "200708091011Z" -- August 09, 2007
DESCRIPTION "Initial version, published as RFC 5190."
::= { mib-2 171 }
REVISION"200708091011Z"--「初期のバージョンであって、RFC5190として発行された」2007年8月9日記述。 ::= mib-2 171
-- -- main components of this MIB module --
-- -- このMIBモジュールの主な成分--
midcomNotifications OBJECT IDENTIFIER ::= { midcomMIB 0 }
midcomObjects OBJECT IDENTIFIER ::= { midcomMIB 1 }
midcomConformance OBJECT IDENTIFIER ::= { midcomMIB 2 }
midcomNotifications物の識別子:、:= midcomMIB0midcomObjects物の識別子:、:= midcomMIB1midcomConformance物の識別子:、:= midcomMIB2
-- Transaction objects required according to the MIDCOM
-- protocol requirements defined in RFC 3304 and according to
-- the MIDCOM protocol semantics defined in RFC 3989
midcomTransaction OBJECT IDENTIFIER ::= { midcomObjects 1 }
-- そして、MIDCOMによると、取引物が必要です--RFC3304で定義された要件について議定書の中で述べてください、--MIDCOMプロトコル意味論はRFCで3989midcomTransaction OBJECT IDENTIFIERを定義しました:、:= midcomObjects1
-- Configuration objects that can be used for retrieving -- middlebox capability information (mandatory) and for
-- そして検索に使用できる構成物--能力情報(義務的な)をmiddleboxする。
Quittek, et al. Standards Track [Page 40] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[40ページ]。
-- setting parameters of the implementation of transaction
-- objects (optional)
midcomConfig OBJECT IDENTIFIER ::= { midcomObjects 2 }
-- 取引の実現のパラメタを設定します--(任意)のmidcomConfig OBJECT IDENTIFIERは反対します:、:= midcomObjects2
-- Optional monitoring objects that provide information about
-- used resource and statistics
midcomMonitoring OBJECT IDENTIFIER ::= { midcomObjects 3 }
-- 周囲で情報を提供する任意のモニターしている物--中古のリソースと統計midcomMonitoring OBJECT IDENTIFIER:、:= midcomObjects3
-- -- Transaction Objects -- -- Transaction objects are structured according to the MIDCOM -- protocol semantics into two groups: -- - objects modeling MIDCOM policy rules in the midcomRuleTable -- - objects modeling MIDCOM policy rule groups in the -- midcomGroupTable
-- -- 取引Objects----MIDCOMによると、取引物は構造化されます--2つのグループに意味論について議定書の中で述べてください: -- - midcomRuleTableのMIDCOM政策ルールをモデル化する物----モデルMIDCOM政策ルールが分類する物、--、midcomGroupTable
-- -- Policy rule subtree -- -- The midcomRuleTable lists policy rules -- including policy reserve rules and policy enable rules. --
-- -- 政策ルール下位木----midcomRuleTableリスト政策ルール--責任準備金が統治する包含と方針は規則を可能にします。 --
midcomRuleTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomRuleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists policy rules.
「このテーブルリスト方針は統治する」midcomRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomRuleEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
It is indexed by the midcomRuleOwner, the
midcomGroupIndex, and the midcomRuleIndex.
This implies that a rule is a member of exactly
one group and that group membership cannot
be changed.
それはmidcomRuleOwner、midcomGroupIndex、およびmidcomRuleIndexによって索引をつけられます。 これは規則がまさに1つのグループのメンバーであり、グループ会員資格は変えることができないのを含意します。
Entries can be deleted by writing to
midcomGroupLifetime or midcomRuleLifetime
and potentially also to midcomRuleStorageTime."
::= { midcomTransaction 3 }
「また、潜在的にmidcomGroupLifetimeかmidcomRuleLifetimeに書くことによって、エントリーをmidcomRuleStorageTimeに削除できます。」 ::= midcomTransaction3
midcomRuleEntry OBJECT-TYPE
SYNTAX MidcomRuleEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular MIDCOM policy rule."
midcomRuleEntry OBJECT-TYPE SYNTAX MidcomRuleEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定のMIDCOM政策ルールを説明するエントリー。」
Quittek, et al. Standards Track [Page 41] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[41ページ]。
INDEX { midcomRuleOwner, midcomGroupIndex, midcomRuleIndex }
::= { midcomRuleTable 1 }
midcomRuleOwner、midcomGroupIndex、midcomRuleIndexに索引をつけてください:、:= midcomRuleTable1
MidcomRuleEntry ::= SEQUENCE {
midcomRuleOwner SnmpAdminString,
midcomRuleIndex Unsigned32,
midcomRuleAdminStatus INTEGER,
midcomRuleOperStatus INTEGER,
midcomRuleStorageType StorageType,
midcomRuleStorageTime Unsigned32,
midcomRuleError SnmpAdminString,
midcomRuleInterface InterfaceIndexOrZero,
midcomRuleFlowDirection INTEGER,
midcomRuleMaxIdleTime Unsigned32,
midcomRuleTransportProtocol Unsigned32,
midcomRulePortRange INTEGER,
midcomRuleInternalIpVersion InetAddressType,
midcomRuleExternalIpVersion InetAddressType,
midcomRuleInternalIpAddr InetAddress,
midcomRuleInternalIpPrefixLength InetAddressPrefixLength,
midcomRuleInternalPort InetPortNumber,
midcomRuleExternalIpAddr InetAddress,
midcomRuleExternalIpPrefixLength InetAddressPrefixLength,
midcomRuleExternalPort InetPortNumber,
midcomRuleInsideIpAddr InetAddress,
midcomRuleInsidePort InetPortNumber,
midcomRuleOutsideIpAddr InetAddress,
midcomRuleOutsidePort InetPortNumber,
midcomRuleLifetime Unsigned32,
midcomRuleRowStatus RowStatus
}
MidcomRuleEntry:、:= 系列{ midcomRuleOwner SnmpAdminString、midcomRuleIndex Unsigned32、midcomRuleAdminStatus整数、midcomRuleOperStatus整数、midcomRuleStorageType StorageType、midcomRuleStorageTime Unsigned32、midcomRuleError SnmpAdminString、midcomRuleInterface InterfaceIndexOrZero、midcomRuleFlowDirection整数、midcomRuleMaxIdleTime Unsigned32、midcomRuleTransportProtocol Unsigned32、midcomRulePortRange整数、midcomRuleInternalIpVersion InetAddressType、midcomRuleExternalIpVersion InetAddressType; midcomRuleInternalIpAddr InetAddress、midcomRuleInternalIpPrefixLength InetAddressPrefixLength、midcomRuleInternalPort InetPortNumber、midcomRuleExternalIpAddr InetAddress、midcomRuleExternalIpPrefixLength InetAddressPrefixLength、midcomRuleExternalPort InetPortNumber、midcomRuleInsideIpAddr InetAddress、midcomRuleInsidePort InetPortNumber、midcomRuleOutsideIpAddr InetAddress、midcomRuleOutsidePort InetPortNumber、midcomRuleLifetime Unsigned32、midcomRuleRowStatus RowStatus; }
midcomRuleOwner OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The manager who owns this row in the midcomRuleTable.
midcomRuleOwner OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「midcomRuleTableでこの列を所有しているマネージャ。」
This object SHOULD uniquely identify an authenticated
MIDCOM client. This object is part of the table index to
allow for the use of the SNMPv3 View-based Access Control
Model (VACM, RFC 3415)."
::= { midcomRuleEntry 1 }
この物のSHOULDは唯一認証されたMIDCOMクライアントを特定します。 「この物はSNMPv3 ViewベースのAccess Control Model(VACM、RFC3415)の使用のために許すテーブルインデックスの一部です。」 ::= midcomRuleEntry1
midcomRuleIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
アクセスしやすくないmidcomRuleIndex OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)マックス-ACCESS
Quittek, et al. Standards Track [Page 42] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[42ページ]。
STATUS current
DESCRIPTION
"The value of this object must be unique in
combination with the values of the objects
midcomRuleOwner and midcomGroupIndex in this row."
::= { midcomRuleEntry 3 }
STATUSの現在の記述は「物のmidcomRuleOwnerとmidcomGroupIndexの値と組み合わせて、この列でユニークこの値が反対するでなければならない」。 ::= midcomRuleEntry3
midcomRuleAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
reserve(1),
enable(2),
notSet(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object indicates the desired status of
the policy rule. See the definition of midcomRuleOperStatus
for a description of the values.
midcomRuleAdminStatus OBJECT-TYPE SYNTAX INTEGERは(1)を予約して、(2)、notSet(3)を有効にします。マックス-ACCESSは「統治この物の値が方針の必要な状態を示すす」STATUSの現在の記述を読書して作成します。 値の記述に関してmidcomRuleOperStatusの定義を見てください。
When a midcomRuleEntry is created without explicitly setting
this object, its value will be notSet(3).
midcomRuleEntryが明らかにこの物を設定しないで作成されるとき、値はnotSet(3)になるでしょう。
However, a SET request can only set this object to either
reserve(1) or enable(2). Attempts to set this object to
notSet(3) will always fail with an 'inconsistentValue'
error. Note that this error code is SNMP specific. If the
MIB module is used with other protocols than SNMP, errors
with similar semantics specific to those protocols should
be returned.
しかしながら、SET要求は、このオブジェクトに(1)を予約するか、または(2)を可能にするように設定できるだけです。 'inconsistentValue'誤りに応じて、このオブジェクトをnotSet(3)に設定する試みはいつも失敗するでしょう。 このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
When the midcomRuleAdminStatus object is set, then the
MIDCOM-MIB implementation will try to read the respective
relevant objects of the entry and try to achieve the
corresponding midcomRuleOperStatus.
midcomRuleAdminStatusオブジェクトが設定されると、MIDCOM-MIB実装は、エントリーのそれぞれの関連目的を読んで、対応するmidcomRuleOperStatusを達成しようとするでしょう。
Setting midcomRuleAdminStatus to value reserve(1) when
object midcomRuleOperStatus has a value of reserved(7)
does not have any effect on the policy rule.
Setting midcomRuleAdminStatus to value enable(2) when
object midcomRuleOperStatus has a value of enabled(8)
does not have any effect on the policy rule.
midcomRuleAdminStatusに(1) オブジェクトmidcomRuleOperStatusに予約された(7)の値があるときには蓄えを評価するように設定するのがどんな影響も政策ルールに与えません。 (2) midcomRuleOperStatusが値を持っているオブジェクトが(8)を可能にしたとき、値へのmidcomRuleAdminStatusが可能にする設定はどんな影響も政策ルールに与えません。
Depending on whether the midcomRuleAdminStatus is set to
reserve(1) or enable(2), several objects must be set in
advance. They serve as parameters of the policy rule to be
established.
midcomRuleAdminStatusが(1)を予約するか、または(2)を可能にするように用意ができているかどうかによって、あらかじめ、数個のオブジェクトを設定しなければなりません。 方針のパラメタが証明されるために統治されるようにそれらは役立ちます。
Quittek, et al. Standards Track [Page 43] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[43ページ]。
When object midcomRuleAdminStatus is set to reserve(1),
then the following objects in the same entry are of
relevance:
- midcomRuleInterface
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleLifetime
オブジェクトmidcomRuleAdminStatusが(1)を予約するように用意ができていると、同じエントリーにおける以下のオブジェクトは関連性のものです: - midcomRuleInterface--midcomRuleTransportProtocol--midcomRulePortRange--midcomRuleInternalIpVersion--midcomRuleExternalIpVersion--midcomRuleInternalIpAddr--midcomRuleInternalIpPrefixLength--midcomRuleInternalPort--midcomRuleLifetime
MIDCOM-MIB implementation may also consider the value
of object midcomRuleMaxIdleTime when establishing
a reserve rule.
また、蓄えの規則を確立するとき、MIDCOM-MIB実装はオブジェクトmidcomRuleMaxIdleTimeの値を考えるかもしれません。
When object midcomRuleAdminStatus is set to enable(2),
then the following objects in the same entry are of
relevance:
- midcomRuleInterface
- midcomRuleFlowDirection
- midcomRuleMaxIdleTime
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleExternalIpAddr
- midcomRuleExternalIpPrefixLength
- midcomRuleExternalPort
- midcomRuleLifetime
オブジェクトmidcomRuleAdminStatusが(2)を可能にするように用意ができていると、同じエントリーにおける以下のオブジェクトは関連性のものです: - midcomRuleInterface--midcomRuleFlowDirection--midcomRuleMaxIdleTime--midcomRuleTransportProtocol--midcomRulePortRange--midcomRuleInternalIpVersion--midcomRuleExternalIpVersion--midcomRuleInternalIpAddr--midcomRuleInternalIpPrefixLength--midcomRuleInternalPort--midcomRuleExternalIpAddr--midcomRuleExternalIpPrefixLength--midcomRuleExternalPort--midcomRuleLifetime
When retrieved, the object returns the last set value.
If no value has been set, it returns the default value
notSet(3)."
DEFVAL { notSet }
::= { midcomRuleEntry 4 }
検索されると、オブジェクトは最後に設定された値を返します。 「値が全く設定されていないなら、デフォルト値notSet(3)を返します。」 DEFVAL notSet:、:= midcomRuleEntry4
midcomRuleOperStatus OBJECT-TYPE
SYNTAX INTEGER {
newEntry(1),
setting(2),
checkingRequest(3),
incorrectRequest(4),
processingRequest(5),
midcomRuleOperStatus OBJECT-TYPE SYNTAX INTEGER、(2)、checkingRequest(3)、incorrectRequest(4)、processingRequest(5)を設定するnewEntry(1)
Quittek, et al. Standards Track [Page 44] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[44ページ]。
requestRejected(6),
reserved(7),
enabled(8),
timedOut(9),
terminatedOnRequest(10),
terminated(11),
genericError(12)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The actual status of the policy rule. The
midcomRuleOperStatus object may have the following values:
genericError(12)、requestRejected(6)(予約された(7))は(8)を可能にして、timedOut(9)(terminatedOnRequest(10))は(11)を終えました。 「方針の実際の状態は統治する」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 midcomRuleOperStatusオブジェクトには、以下の値があるかもしれません:
- newEntry(1) indicates that the entry in the
midcomRuleTable was created, but not modified yet.
Such an entry needs to be filled with values specifying
a request first.
- newEntry(1)は、midcomRuleTableのエントリーが作成されましたが、まだ変更されていなかったのを示します。 そのようなエントリーは、最初に要求を指定する値で満たされる必要があります。
- setting(2) indicates that the entry has been already
modified after generating it, but no request was made
yet.
- (2)を設定するのは、それを生成した後に、既にエントリーを変更しましたが、まだ要求を全くしていなかったのを示します。
- checkingRequest(3) indicates that midcomRuleAdminStatus
has recently been set and that the MIDCOM-MIB
implementation is currently checking the parameters of
the request. This is a transient state. The value of
this object will change to either incorrectRequest(4)
or processingRequest(5) without any external
interaction. A MIDCOM-MIB implementation MAY return
this value while checking request parameters.
- checkingRequest(3)は、midcomRuleAdminStatusが最近、用意ができて、MIDCOM-MIB実装が現在要求のパラメタをチェックしているのを示します。 これは一時的な状態です。 このオブジェクトの値は少しも外部の相互作用なしでincorrectRequest(4)かprocessingRequest(5)のどちらかに変化するでしょう。 MIDCOM-MIB実装は要求パラメタをチェックしている間、この値を返すかもしれません。
- incorrectRequest(4) indicates that checking a request
resulted in detecting an incorrect value in one of the
objects containing request parameters. The failure
reason is indicated by the value of midcomRuleError.
- incorrectRequest(4)は、要求パラメタを含んでいて、要求をチェックするのがオブジェクトの1つに不正確な値を検出するのに結果として生じたのを示します。 失敗理由はmidcomRuleErrorの値によって示されます。
- processingRequest(5) indicates that
midcomRuleAdminStatus has recently been set and that
the MIDCOM-MIB implementation is currently processing
the request and trying to configure the middlebox
accordingly. This is a transient state. The value of
this object will change to either requestRejected(6),
reserved(7), or enabled(8) without any external
interaction. A MIDCOM-MIB implementation MAY return
this value while processing a request.
- processingRequest(5)は、MIDCOM-MIB実装がmidcomRuleAdminStatusが最近、用意ができて、現在、要求を処理して、それに従って、middleboxを構成しようとしているのを示します。 これは一時的な状態です。 このオブジェクトの値は、少しも外部の相互作用なしでrequestRejected(6)に変化するか、(7)を予約したか、または(8)を可能にしました。 MIDCOM-MIB実装は要求を処理している間、この値を返すかもしれません。
- requestRejected(6) indicates that a request to establish
- requestRejected(6)は確立するそのa要求を示します。
Quittek, et al. Standards Track [Page 45] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[45ページ]。
a policy rule specified by the entry was rejected. The
reason for rejection is indicated by the value of
midcomRuleError.
エントリーで指定された政策ルールは拒絶されました。 不合格理由はmidcomRuleErrorの値によって示されます。
- reserved(7) indicates that the entry describes an
established policy reserve rule.
These values of MidcomRuleEntry are meaningful
for a reserved policy rule:
- midcomRuleMaxIdleTime
- midcomRuleInterface
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleLifetime
- 予約された(7)は、エントリーが既定方針蓄えの規則について説明するのを示します。 予約された政策ルールに、MidcomRuleEntryのこれらの値は重要です: - midcomRuleMaxIdleTime--midcomRuleInterface--midcomRuleTransportProtocol--midcomRulePortRange--midcomRuleInternalIpVersion--midcomRuleExternalIpVersion--midcomRuleInternalIpAddr--midcomRuleInternalIpPrefixLength--midcomRuleInternalPort--midcomRuleOutsideIpAddr--midcomRuleOutsidePort--midcomRuleLifetime
- enabled(8) indicates that the entry describes an
established policy enable rule.
These values of MidcomRuleEntry are meaningful
for an enabled policy rule:
- 可能にされて、(8)は、エントリーが既定方針を説明するのを示します。規則を可能にしてください。 可能にされた政策ルールに、MidcomRuleEntryのこれらの値は重要です:
- midcomRuleFlowDirection
- midcomRuleInterface
- midcomRuleMaxIdleTime
- midcomRuleTransportProtocol
- midcomRulePortRange
- midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleExternalIpAddr
- midcomRuleExternalIpPrefixLength
- midcomRuleExternalPort
- midcomRuleInsideIpAddr
- midcomRuleInsidePort
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleLifetime
- midcomRuleFlowDirection--midcomRuleInterface--midcomRuleMaxIdleTime--midcomRuleTransportProtocol--midcomRulePortRange--midcomRuleInternalIpVersion--midcomRuleExternalIpVersion--midcomRuleInternalIpAddr--midcomRuleInternalIpPrefixLength--midcomRuleInternalPort--midcomRuleExternalIpAddr--midcomRuleExternalIpPrefixLength--midcomRuleExternalPort--midcomRuleInsideIpAddr--midcomRuleInsidePort--midcomRuleOutsideIpAddr--midcomRuleOutsidePort--midcomRuleLifetime
- timedOut(9) indicates that the lifetime of a previously
established policy rule has expired and that the policy
rule is terminated for this reason.
- timedOut(9)は、以前に確立した政策ルールの寿命が期限が切れて、政策ルールがこの理由で終えられるのを示します。
Quittek, et al. Standards Track [Page 46] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[46ページ]。
- terminatedOnRequest(10) indicates that a previously
established policy rule was terminated by an SNMP
manager setting the midcomRuleLifetime to 0 or
setting midcomGroupLifetime to 0.
- terminatedOnRequest(10)は、以前に確立した政策ルールが0にmidcomRuleLifetimeを設定するか、または0にmidcomGroupLifetimeを設定するSNMPマネージャによって終えられたのを示します。
- terminated(11) indicates that a previously established
policy rule was terminated by the MIDCOM-MIB
implementation for a reason other than lifetime
expiration or an explicit request from a MIDCOM client.
- 終えられて、(11)は、以前に確立した政策ルールが生涯満了以外の理由かMIDCOMクライアントからの明白な要求のためのMIDCOM-MIB実装によって終えられたのを示します。
- genericError(12) indicates that the policy rule
specified by the entry is not established due to
an error condition not listed above.
- genericError(12)は、エントリーで指定された政策ルールが上に記載されなかったエラー条件のため確立されないのを示します。
The states timedOut(9), terminatedOnRequest(10), and
terminated(11) are referred to as termination states.
州のtimedOut(9)、terminatedOnRequest(10)、および終了と呼ばれた終えられた(11)州。
The states incorrectRequest(4), requestRejected(6),
and genericError(12) are referred to as error states.
州のincorrectRequest(4)、requestRejected(6)、およびgenericError(12)は誤り州と呼ばれます。
The checkingRequest(3) and processingRequest(5)
states are transient states, which will lead to either
one of the error states or the reserved(7) state or the
enabled(8) state. MIDCOM-MIB implementations MAY return
these values when checking or processing requests."
DEFVAL { newEntry }
::= { midcomRuleEntry 5 }
checkingRequest(3)とprocessingRequest(5)州は一時的な州です。(その州は誤り州、予約された(7)州または可能にされた(8)状態のどちらかに通じるでしょう)。 「要求をチェックするか、または処理するとき、MIDCOM-MIB実装はこれらの値を返すかもしれません。」 DEFVAL newEntry:、:= midcomRuleEntry5
midcomRuleStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"When retrieved, this object returns the storage
type of the policy rule. Writing to this object can
change the storage type of the particular row from
volatile(2) to nonVolatile(3) or vice versa.
midcomRuleStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「検索されると、このオブジェクトはタイプの政策ルールをストレージに返します」。 このオブジェクトに書くのは特定の行のストレージタイプを揮発性の(2)からnonVolatile(3)に変えることができますか、逆もまた同様です。
Attempts to set this object to permanent will always
fail with an 'inconsistentValue' error. Note that this
error code is SNMP specific. If the MIB module is used
with other protocols than SNMP, errors with similar
semantics specific to those protocols should be
returned.
'inconsistentValue'誤りに応じて、このオブジェクトを永久的に設定する試みはいつも失敗するでしょう。 このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If midcomRuleStorageType has the value permanent(4),
then all objects in this row whose MAX-ACCESS value
is read-create must be read-only."
「midcomRuleStorageTypeが値の永久的な(4)を持って、次に、すべて反対するなら、マックス-ACCESS値が必須を読書して作成することであるこの行では、書き込み禁止になってください。」
Quittek, et al. Standards Track [Page 47] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[47ページ]。
DEFVAL { volatile }
::= { midcomRuleEntry 6 }
DEFVAL、揮発性:、:= midcomRuleEntry6
midcomRuleStorageTime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object specifies how long this row
can exist in the midcomRuleTable after the
midcomRuleOperStatus switched to a termination state or
to an error state. This object returns the remaining
time that the row may exist before it is aged out.
midcomRuleStorageTime OBJECT-TYPE SYNTAX Unsigned32 UNITS「秒」マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトの値は、midcomRuleOperStatusが終了州、または、誤り状態に切り替わった後にこの行がどれくらい長い間midcomRuleTableに存在できるかを指定します」。 このオブジェクトはそれが外で熟成する前の行が存在するかもしれない残っている時に戻ります。
After expiration or termination of the context, the value
of this object ticks backwards. The entry in the
midcomRuleTable is destroyed when the value reaches 0.
文脈の満了か終了の後に、このオブジェクトの値は後方にカチカチします。 値が0に達するとき、midcomRuleTableのエントリーは破壊されます。
The value of this object may be set in order to increase
or reduce the remaining time that the row may exist.
Setting the value to 0 will destroy this entry as soon as
the midcomRuleOperStatus switched to a termination state
or to an error state.
このオブジェクトの値は、行が存在するかもしれない残っている時に増加するか、または減少するために設定されるかもしれません。 0に値を設定すると、midcomRuleOperStatusが終了州、または、誤り状態に切り替わるとすぐに、このエントリーは煙滅するでしょう。
Note that there is no guarantee that the row is stored as
long as this object indicates. At any time, the MIDCOM-
MIB implementation may decide to remove a row describing
a terminated policy rule before the storage time of the
corresponding row in the midcomRuleTable reaches the
value of 0. In this case, the information stored in this
row is not available anymore.
行がこのオブジェクトが示すのと同じくらい長い間保存されるという保証が全くないことに注意してください。 いつでも、MIDCOM- MIB実装は、midcomRuleTableの対応する行の蓄積時間が0の値に達する前に終えられた政策ルールを説明する行を取り除くと決めるかもしれません。 この場合、この行で保存された情報はそれ以上利用可能ではありません。
If object midcomRuleStorageType indicates that the policy
rule has the storage type permanent(4), then this object has
a constant value of 4294967295."
DEFVAL { 0 }
::= { midcomRuleEntry 7 }
「オブジェクトmidcomRuleStorageTypeが、ストレージが政策ルールで永久的な(4)をタイプするのを示すなら、このオブジェクトには、4294967295の恒常価値があります。」 DEFVAL0:、:= midcomRuleEntry7
midcomRuleError OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains a descriptive error message if
the transition into the operational status reserved(7)
or enabled(8) failed. Implementations must reset the
error message to a zero-length string when a new
midcomRuleError OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「操作上の状態への変遷が(7)を予約したか、または失敗された(8)を可能にしたなら、描写的であるエラーメッセージを含これが反対するしています」。 a新しいときに、実装はゼロ長ストリングにエラーメッセージをリセットしなければなりません。
Quittek, et al. Standards Track [Page 48] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[48ページ]。
attempt to change the policy rule status to reserved(7)
or enabled(8) is started.
政策ルール状態を予約された(7)に変えるのを試みるか、または可能にされて、(8)は始められます。
RECOMMENDED values to be returned in particular cases
include
- 'lack of IP addresses'
- 'lack of port numbers'
- 'lack of resources'
- 'specified NAT interface does not exist'
- 'specified NAT interface does not support NAT'
- 'conflict with already existing policy rule'
- 'no internal IP wildcarding allowed'
- 'no external IP wildcarding allowed'
特定の場合で返されるRECOMMENDED値は'外部のIP wildcardingは許容しなかった''財源不足'('指定されたNATインタフェースは存在しないこと'を('指定されたNATインタフェースは、NAT'--'が既に既存の政策ルールとの闘争であるとサポートしない')'内部のIP wildcardingは許容しなかった')を含んでいます('IPの不足は、'--'がポートナンバーの不足であると扱います')。
The semantics of these error messages and the corresponding
behavior of the MIDCOM-MIB implementation are specified
in sections 2.3.9 and 2.3.10 of RFC 3989."
REFERENCE
"RFC 3989, sections 2.3.9 and 2.3.10"
DEFVAL { ''H }
::= { midcomRuleEntry 8 }
「これらのエラーメッセージの意味論とMIDCOM-MIB実装の対応する振舞いは指定されたコネセクション2.3.9であり、2.3は.10RFC3989です。」 REFERENCE、「RFC3989、セクション2.3の.9と2.3の0.1インチのDEFVAL、「H、:、:、」= midcomRuleEntry8
midcomRuleInterface OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the IP interface for which
enforcement of a policy rule is requested or performed,
respectively.
midcomRuleInterface OBJECT-TYPE SYNTAX InterfaceIndexOrZeroマックス-ACCESSは「政策ルールのどの実施が要求されているか、またはそれぞれ実行されるかために連結このオブジェクトがIPを示すす」STATUSの現在の記述を読書して作成します。
The interface is identified by its index in the ifTable
(see IF-MIB in RFC 2863). If the object has a value of 0,
then no particular interface is indicated.
インタフェースがifTableのインデックスによって特定される、(見る、-、MIB、RFC2863)で。 オブジェクトに0の値があるなら、どんな特定のインタフェースも示されません。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to request its preference
concerning the interface at which it requests NAT service.
The default value of 0 indicates that the manager does not
have a preferred interface or does not have sufficient
topology information for specifying one. Writing to this
object in any state other than newEntry(1) or setting(2)
will always fail with an 'inconsistentValue' error.
同じエントリーのオブジェクトmidcomRuleOperStatusに値のnewEntry(1)があるなら、(2)を設定して、マネージャは、それがNATサービスを要求するインタフェースに関して好みを要求するためにこのオブジェクトを書くことができます。 0のデフォルト値は、マネージャには、都合のよいインタフェースを持っていないか、または1つを指定するための十分なトポロジー情報がないのを示します。 'inconsistentValue'誤りに応じて、newEntry(1)以外のどんな状態のこのオブジェクトにも書くか、または(2)を設定するのがいつも失敗するでしょう。
Quittek, et al. Standards Track [Page 49] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[49ページ]。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object indicates
the interface at which NAT service for this rule is
performed. If NAT service is not required for enforcing
the policy rule, then the value of this object is 0. Also,
if the MIDCOM-MIB implementation cannot indicate an
interface, because it does not have this information or
because NAT service is not offered at a particular single
interface, then the value of the object is 0.
同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトはこの規則のためのNATサービスが実行されるインタフェースを示します。 NATサービスは政策ルールを実施するのに必要でないなら、このオブジェクトの値が0です。 また、それにはこの情報がないか、またはNATサービスが特定の単一のインタフェースで提供されないのでMIDCOM-MIB実装がインタフェースを示すことができないなら、オブジェクトの値は0です。
Note that the index of a particular interface in the
ifTable may change after a re-initialization of the
middlebox, for example, after adding another interface to
it. In such a case, the value of this object may change,
but the interface referred to by the MIDCOM-MIB MUST still
be the same. If, after a re-initialization of the
middlebox, the interface referred to before
re-initialization cannot be uniquely mapped anymore to a
particular entry in the ifTable, then the value of object
midcomRuleOperStatus of the same entry MUST be changed to
terminated(11).
例えば、別のインタフェースをそれに加えた後にifTableの特定のインタフェースのインデックスがmiddleboxの再初期化の後に変化するかもしれないことに注意してください。 インタフェースだけが、MIDCOM-MIB MUSTでこのような場合には、このオブジェクトの値が変化するかもしれないと言及しました、それでも、同じであってください。 それ以上middleboxの再初期化の後に唯一再初期化の前に言及されたインタフェースをifTableの特定のエントリーに写像できないなら、同じエントリーのオブジェクトmidcomRuleOperStatusの値が変わらなければならないその時は(11)を終えました。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 0 }
::= { midcomRuleEntry 9 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL0:、:= midcomRuleEntry9
midcomRuleFlowDirection OBJECT-TYPE
SYNTAX INTEGER {
inbound(1),
outbound(2),
biDirectional(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This parameter specifies the direction of enabled
communication, either inbound(1), outbound(2), or
biDirectional(3).
マックス-ACCESSはSTATUSの現在の記述を読書して作成します。midcomRuleFlowDirection OBJECT-TYPE SYNTAX INTEGER、本国行きの(1)、外国行きの(2)、biDirectional(3)、「このパラメタは可能にされたコミュニケーション、本国行きの(1)、外国行きの(2)かbiDirectional(3)のどちらかの方向を指定します」。
The semantics of this object depends on the protocol
the rule relates to. If the rule is independent of
このオブジェクトの意味論は規則が関連するプロトコルによります。 規則は独立しています。
Quittek, et al. Standards Track [Page 50] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[50ページ]。
the transport protocol (midcomRuleTransportProtocol
has a value of 0) or if the transport protocol is UDP,
then the value of midcomRuleFlowDirection indicates
the direction of packets traversing the middlebox.
輸送は議定書を作るか(midcomRuleTransportProtocolには、0の値があります)、またはmidcomRuleFlowDirectionの値はトランスポート・プロトコルがUDPであるならmiddleboxを横断するパケットの方向を示します。
In this case, value inbound(1) indicates that packets
are traversing from outside to inside, value outbound(2)
indicates that packets are traversing from inside to
outside. For both values, inbound(1) and outbound(2)
packets can traverse the middlebox only unidirectional.
A bidirectional flow is indicated by value
biDirectional(3).
この場合、本国行きの(1)が示すパケットが外部から内面の、そして、値の外国行きの(2)まで横断している値は、パケットが内部から外部まで横断される予定であるのを示します。 両方の値のために、本国行きの(1)と外国行きの(2)パケットは唯一の単方向、middleboxを横断できます。 双方向の流れは値のbiDirectional(3)によって示されます。
If the transport protocol is TCP, the packet flow is
always bidirectional, but the value of
midcomRuleFlowDirection indicates that:
トランスポート・プロトコルがTCPであるなら、パケット流動はいつも双方向ですが、midcomRuleFlowDirectionの値は、以下のことを示します。
- inbound(1): bidirectional TCP packet flow.
First packet, with TCP SYN flag set, must arrive
at an outside interface of the middlebox.
- 本国行きの(1): 双方向のTCPパケット流動。 最初のパケットはTCP SYN旗のセットと共にmiddleboxの外のインタフェースに到着しなければなりません。
- outbound(2): bidirectional TCP packet flow.
First packet, with TCP SYN flag set, must arrive
at an inside interface of the middlebox.
- 外国行きの(2): 双方向のTCPパケット流動。 最初のパケットはTCP SYN旗のセットと共にmiddleboxの内面のインタフェースに到着しなければなりません。
- biDirectional(3): bidirectional TCP packet flow.
First packet, with TCP SYN flag set, may arrive
at an inside or an outside interface of the middlebox.
- 双方向の(3): 双方向のTCPパケット流動。 最初のパケットはTCP SYN旗のセットと共にmiddleboxの内部か外のインタフェースに到着するかもしれません。
This object is used as input to a request for
establishing a policy enable rule as well as for
indicating the properties of an established policy rule.
このオブジェクトは、方針を確立するのを求める要求への入力が規則を可能にして既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has a
value of either newEntry(1), setting(2), or reserved(7),
then this object can be written by a manager in order to
specify a requested direction to be enabled by a policy
rule. Writing to this object in any state other than
newEntry(1), setting(2), or reserved(7) will always fail
with an 'inconsistentValue' error.
(2)、または予約された(7)を設定して、同じエントリーのオブジェクトmidcomRuleOperStatusにnewEntry(1)の値があるなら、マネージャは、政策ルールで可能にされるために要求された方向を指定するためにこのオブジェクトを書くことができます。 newEntry(1)以外のどんな状態のこのオブジェクトにも書くと、'inconsistentValue'誤りに応じて、(2)を設定するか、または予約された(7)がいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object indicates the enabled
同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は(8)を可能にして、次に、このオブジェクトは可能にすることを示します。
Quittek, et al. Standards Track [Page 51] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[51ページ]。
flow direction.
流れ方向。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { outbound }
::= { midcomRuleEntry 10 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL、外国行き:、:= midcomRuleEntry10
midcomRuleMaxIdleTime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum idle time of the policy rule in seconds.
midcomRuleMaxIdleTime OBJECT-TYPE SYNTAX Unsigned32 UNITS「秒」マックス-ACCESSは「秒の政策ルールの遊休時間に、最大」の状態でSTATUSの現在の記述を読書して作成します。
If no packet to which the policy rule applies passes the
middlebox for the specified midcomRuleMaxIdleTime, then
the policy rule enters the termination state timedOut(9).
政策ルールが適用されるどんなパケットも指定されたmidcomRuleMaxIdleTimeのためにmiddleboxを渡さないなら、政策ルールは終了州のtimedOut(9)に入ります。
A value of 0 indicates that the policy does not require
an individual idle time and that instead, a default idle
time chosen by the middlebox is used.
0の値は方針が個々の遊休時間を必要としないで、代わりに、middleboxによって選ばれたデフォルト遊休時間が使用されているのを示します。
A value of 4294967295 ( = 2^32 - 1 ) indicates that the
policy does not time out if it is idle.
4294967295(=2^32--1)の値は、それが活動していないなら方針がどんなタイムアウトもしないのを示します。
This object is used as input to a request for
establishing a policy enable rule as well as for
indicating the properties of an established policy rule.
このオブジェクトは、方針を確立するのを求める要求への入力が規則を可能にして既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has a
value of either newEntry(1), setting(2), or reserved(7),
then this object can be written by a manager in order to
specify a maximum idle time for the policy rule to be
requested. Writing to this object in any state others
than newEntry(1), setting(2), or reserved(7) will always
fail with an 'inconsistentValue' error.
(2)、または予約された(7)を設定して、同じエントリーのオブジェクトmidcomRuleOperStatusにnewEntry(1)の値があるなら、マネージャは、政策ルールが要求されているために最大の遊休時間を指定するためにこのオブジェクトを書くことができます。 いずれのこのオブジェクトに書いて、(2)を設定するnewEntry(1)より他のものを述べてください。さもないと、'inconsistentValue'誤りに応じて、予約された(7)はいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object indicates the maximum
idle time of the policy rule. Note that even if a maximum
idle time greater than zero was requested, the middlebox
同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は(8)を可能にして、次に、このオブジェクトは政策ルールの最大の遊休時間を示します。 a最大であってもゼロよりすばらしい遊休時間が要求されたというメモ、middlebox
Quittek, et al. Standards Track [Page 52] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[52ページ]。
may not be able to support maximum idle times and set the
value of this object to zero when entering state
enabled(8).
入る州が(8)を可能にしたとき、最大の活動していない時勢をサポートして、このオブジェクトの値をゼロに設定できないかもしれません。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 0 }
::= { midcomRuleEntry 11 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL0:、:= midcomRuleEntry11
midcomRuleTransportProtocol OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The transport protocol.
midcomRuleTransportProtocol OBJECT-TYPE SYNTAX Unsigned32(0 .255)マックス-ACCESSは「輸送は議定書の中で述べる」STATUSの現在の記述を読書して作成します。
Valid values for midcomRuleTransportProtocol
other than zero are defined at:
http://www.iana.org/assignments/protocol-numbers
ゼロ以外のmidcomRuleTransportProtocolのための有効値は以下で定義されます。 http://www.iana.org/assignments/protocol-numbers
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has a
value of either newEntry(1) or setting(2), then this
object can be written by a manager in order to specify a
requested transport protocol. If translation of an IP
address only is requested, then this object must have the
default value 0. Writing to this object in any state
other than newEntry(1) or setting(2) will always fail
with an 'inconsistentValue' error.
同じエントリーのオブジェクトmidcomRuleOperStatusにnewEntry(1)か設定(2)のどちらかの値があるなら、マネージャは、要求されたトランスポート・プロトコルを指定するためにこのオブジェクトを書くことができます。 IPアドレスに関する翻訳だけが要求されるなら、このオブジェクトには、デフォルト値0がなければなりません。 'inconsistentValue'誤りに応じて、newEntry(1)以外のどんな状態のこのオブジェクトにも書くか、または(2)を設定するのがいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object
indicates which transport protocol is enforced by this
policy rule. A value of 0 indicates a rule acting on IP
addresses only.
同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトは、どのトランスポート・プロトコルがこの政策ルールによって励行されるかを示します。 0の値はIPアドレスだけに影響する規則を示します。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」
Quittek, et al. Standards Track [Page 53] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[53ページ]。
DEFVAL { 0 }
::= { midcomRuleEntry 12 }
DEFVAL0:、:= midcomRuleEntry12
midcomRulePortRange OBJECT-TYPE
SYNTAX INTEGER {
single(1),
pair(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The range of port numbers.
midcomRulePortRange OBJECT-TYPE SYNTAX INTEGERは(1)、組(2)を選抜します。マックス-ACCESSは「ポートの範囲は付番する」STATUSの現在の記述を読書して作成します。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule. It is relevant to the
operation of the MIDCOM-MIB implementation only if the
value of object midcomTransportProtocol in the same entry
has a value other than 0.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。 同じエントリーにおける、オブジェクトmidcomTransportProtocolの値に0以外の値がある場合にだけ、MIDCOM-MIB実装の操作に関連しています。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to specify the requested
size of the port range. With single(1) just a single
port number is requested, with pair(2) a consecutive pair
of port numbers is requested with the lower number being
even. Requesting a consecutive pair of port numbers may
be used by RTP [RFC3550] and may even be required to
support older RTP applications.
同じエントリーのオブジェクトmidcomRuleOperStatusに値のnewEntry(1)があるなら、(2)を設定して、マネージャは、ポート範囲の要求されたサイズを指定するためにこのオブジェクトを書くことができます。 シングル(1)で、まさしくただ一つのポートナンバーは要求されていて、組(2)と共に、下側の数が偶数でポートナンバーの連続した組は要求されています。 ポートナンバーの連続した組を要求するのが、RTP[RFC3550]によって使用されて、より古いRTPアプリケーションをサポートするのに必要でさえあるかもしれません。
Writing to this object in any state other than
newEntry(1), setting(2) or reserved(7) will always fail
with an 'inconsistentValue' error.
newEntry(1)以外のどんな状態のこのオブジェクトにも書くと、'inconsistentValue'誤りに応じて、(2)か予約された(7)を設定するのはいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has a
value of either reserved(7) or enabled(8), then this
object will have the value that it had before the
transition to this state.
このオブジェクトには、同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、どちらかの値は、(7)を予約したか、または(8)を可能にして、次に、それがこの状態への変遷の前に持っていた値があるでしょう。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { single }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL単一
Quittek, et al. Standards Track [Page 54] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[54ページ]。
::= { midcomRuleEntry 13}
::= midcomRuleEntry13
midcomRuleInternalIpVersion OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"IP version of the internal address (A0) and the inside
address (A1). Allowed values are ipv4(1), ipv6(2),
ipv4z(3), and ipv6z(4).
midcomRuleInternalIpVersion OBJECT-TYPE SYNTAX InetAddressTypeマックス-ACCESSは「インターナルのIPバージョンは(A0)とインサイドアドレス(A1)を扱う」STATUSの現在の記述を読書して作成します。 値が許容されているのは、ipv4(1)と、ipv6(2)と、ipv4z(3)と、ipv6z(4)です。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to specify the IP version
required at the inside of the middlebox. Writing to this
object in any state other than newEntry(1) or setting(2)
will always fail with an 'inconsistentValue' error.
同じエントリーのオブジェクトmidcomRuleOperStatusに値のnewEntry(1)があるなら、(2)を設定して、マネージャは、middleboxの内部で必要であるIPバージョンを指定するためにこのオブジェクトを書くことができます。 'inconsistentValue'誤りに応じて、newEntry(1)以外のどんな状態のこのオブジェクトにも書くか、または(2)を設定するのがいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object
indicates the internal/inside IP version.
同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトは内部の、または、内面のIPバージョンを示します。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { ipv4 }
::= { midcomRuleEntry 14 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL ipv4:、:= midcomRuleEntry14
midcomRuleExternalIpVersion OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"IP version of the external address (A3) and the outside
address (A2). Allowed values are ipv4(1) and ipv6(2).
midcomRuleExternalIpVersion OBJECT-TYPE SYNTAX InetAddressTypeマックス-ACCESSは「外部アドレス(A3)と外部のIPバージョンは(A2)を扱う」STATUSの現在の記述を読書して作成します。 値が許容されているのは、ipv4(1)とipv6(2)です。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。
Quittek, et al. Standards Track [Page 55] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[55ページ]。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to specify the IP version
required at the outside of the middlebox. Writing to
this object in any state other than newEntry(1) or
setting(2) will always fail with an 'inconsistentValue'
error.
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
同じエントリーのオブジェクトmidcomRuleOperStatusに値のnewEntry(1)があるなら、(2)を設定して、マネージャは、middleboxの外部で必要であるIPバージョンを指定するためにこのオブジェクトを書くことができます。 'inconsistentValue'誤りに応じて、newEntry(1)以外のどんな状態のこのオブジェクトにも書くか、または(2)を設定するのがいつも失敗するでしょう。 このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object
indicates the external/outside IP version.
同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトは外部の、または、外のIPバージョンを示します。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7) or
enabled(8), then the value of this object is irrelevant."
DEFVAL { ipv4 }
::= { midcomRuleEntry 15 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL ipv4:、:= midcomRuleEntry15
midcomRuleInternalIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The internal IP address (A0).
midcomRuleInternalIpAddr OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「内部のIPは(A0)を扱う」STATUSの現在の記述を読書して作成します。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to specify the internal IP
address for which a reserve policy rule or a enable policy
rule is requested to be established. Writing to this
object in any state other than newEntry(1) or setting(2)
will always fail with an 'inconsistentValue' error.
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
同じエントリーのオブジェクトmidcomRuleOperStatusに値のnewEntry(1)があるなら、(2)を設定して、マネージャは、どのa蓄えの政策ルールかaが政策ルールを可能にするかが設立されるよう要求されているので内部のIPアドレスを指定するためにこのオブジェクトを書くことができます。 'inconsistentValue'誤りに応じて、newEntry(1)以外のどんな状態のこのオブジェクトにも書くか、または(2)を設定するのがいつも失敗するでしょう。 このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object will
have the value which it had before the transition to this
このオブジェクトには、同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は、(7)を予約したか、または(8)を可能にして、次に、それがこれへの変遷の前に持っていた値があるでしょう。
Quittek, et al. Standards Track [Page 56] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[56ページ]。
state.
状態。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7) or
enabled(8), then the value of this object is irrelevant."
::= { midcomRuleEntry 16 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 ::= midcomRuleEntry16
midcomRuleInternalIpPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The prefix length of the internal IP address used for
wildcarding. A value of 0 indicates a full wildcard;
in this case, the value of midcomRuleInternalIpAddr is
irrelevant. If midcomRuleInternalIpVersion has a value
of ipv4(1), then a value > 31 indicates no wildcarding
at all. If midcomRuleInternalIpVersion has a value
of ipv4(2), then a value > 127 indicates no wildcarding
at all. A MIDCOM-MIB implementation that does not
support IP address wildcarding MUST implement this object
as read-only with a value of 128. A MIDCOM that does
not support wildcarding based on prefix length MAY
restrict allowed values for this object to 0 and 128.
midcomRuleInternalIpPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLengthマックス-ACCESSは「内部のIPアドレスの接頭語の長さはwildcardingするのに使用した」STATUSの現在の記述を読書して作成します。 0の値は完全なワイルドカードを示します。 この場合、midcomRuleInternalIpAddrの値は無関係です。 midcomRuleInternalIpVersionにipv4(1)の値があるなら、値の>31は全くwildcardingを示しません。 midcomRuleInternalIpVersionにipv4(2)の値があるなら、値の>127は全くwildcardingを示しません。 IPアドレスwildcardingをサポートしないMIDCOM-MIB実装は書き込み禁止として128の値でこのオブジェクトを実装しなければなりません。 接頭語の長さに基づくwildcardingをサポートしないMIDCOMはこのオブジェクトのために許容値を0と128に制限するかもしれません。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to specify the prefix length
of the internal IP address for which a reserve policy rule
or an enable policy rule is requested to be established.
Writing to this object in any state other than newEntry(1)
or setting(2) will always fail with an 'inconsistentValue'
error.
政策ルールを可能にしてください。または、次に、(2)を設定して、同じエントリーのオブジェクトmidcomRuleOperStatusに値のnewEntry(1)があるなら、マネージャが内部のIPアドレスの接頭語の長さをどのa蓄えの政策ルールに指定するかためにこのオブジェクトを書くことができる、設立されるよう要求されています。 'inconsistentValue'誤りに応じて、newEntry(1)以外のどんな状態のこのオブジェクトにも書くか、または(2)を設定するのがいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object will
have the value which it had before the transition to this
state.
このオブジェクトには、同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は、(7)を予約したか、または(8)を可能にして、次に、それがこの状態への変遷の前に持っていた値があるでしょう。
Quittek, et al. Standards Track [Page 57] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[57ページ]。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 128 }
::= { midcomRuleEntry 17 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL128:、:= midcomRuleEntry17
midcomRuleInternalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The internal port number. A value of 0 is a wildcard.
midcomRuleInternalPort OBJECT-TYPE SYNTAX InetPortNumberマックス-ACCESSは「内部のポートは付番する」STATUSの現在の記述を読書して作成します。 0の値はワイルドカードです。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule. It is relevant to the
operation of the MIDCOM-MIB implementation only if the
value of object midcomTransportProtocol in the same entry
has a value other than 0.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。 同じエントリーにおける、オブジェクトmidcomTransportProtocolの値に0以外の値がある場合にだけ、MIDCOM-MIB実装の操作に関連しています。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1) or setting(2), then this object can be
written by a manager in order to specify the internal port
number for which a reserve policy rule or an enable policy
rule is requested to be established. Writing to this
object in any state other than newEntry(1) or setting(2)
will always fail with an 'inconsistentValue' error.
政策ルールを可能にしてください。または、次に、(2)を設定して、同じエントリーのオブジェクトmidcomRuleOperStatusに値のnewEntry(1)があるなら、マネージャがどのa蓄えの政策ルールに内部のポートナンバーを指定するかためにこのオブジェクトを書くことができる、設立されるよう要求されています。 'inconsistentValue'誤りに応じて、newEntry(1)以外のどんな状態のこのオブジェクトにも書くか、または(2)を設定するのがいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value reserved(7) or enabled(8), then this object will
have the value that it had before the transition to this
state.
このオブジェクトには、同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は、(7)を予約したか、または(8)を可能にして、次に、それがこの状態への変遷の前に持っていた値があるでしょう。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 0 }
::= { midcomRuleEntry 18 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL0:、:= midcomRuleEntry18
midcomRuleExternalIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
midcomRuleExternalIpAddr OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSはSTATUS海流を読書して引き起こします。
Quittek, et al. Standards Track [Page 58] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[58ページ]。
DESCRIPTION
"The external IP address (A3).
「外部のIPは(A3)を扱う」記述。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1), setting(2), or reserved(7), then this
object can be written by a manager in order to specify the
external IP address for which an enable policy rule is
requested to be established. Writing to this object in
any state other than newEntry(1), setting(2), or reserved(7)
will always fail with an 'inconsistentValue' error.
政策ルールを可能にしてください。同じエントリーのmidcomRuleOperStatusが値newEntry(1)、設定(2)、または予約された(7)、マネージャが外部のIPアドレスを指定するためにこのオブジェクトを書くことができるその時を持っているオブジェクトである、どれ、設立されるよう要求されているか。 newEntry(1)以外のどんな状態のこのオブジェクトにも書くと、'inconsistentValue'誤りに応じて、(2)を設定するか、または予約された(7)がいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object will have the value
that it had before the transition to this state.
このオブジェクトには、同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は(8)を可能にして、次に、それがこの状態への変遷の前に持っていた値があるでしょう。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
::= { midcomRuleEntry 19 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 ::= midcomRuleEntry19
midcomRuleExternalIpPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The prefix length of the external IP address used for
wildcarding. A value of 0 indicates a full wildcard;
in this case, the value of midcomRuleExternalIpAddr is
irrelevant. If midcomRuleExternalIpVersion has a value
of ipv4(1), then a value > 31 indicates no wildcarding
at all. If midcomRuleExternalIpVersion has a value
of ipv4(2), then a value > 127 indicates no wildcarding
at all. A MIDCOM-MIB implementation that does not
support IP address wildcarding MUST implement this object
as read-only with a value of 128. A MIDCOM that does
not support wildcarding based on prefix length MAY
restrict allowed values for this object to 0 and 128.
midcomRuleExternalIpPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLengthマックス-ACCESSは「外部のIPアドレスの接頭語の長さはwildcardingするのに使用した」STATUSの現在の記述を読書して作成します。 0の値は完全なワイルドカードを示します。 この場合、midcomRuleExternalIpAddrの値は無関係です。 midcomRuleExternalIpVersionにipv4(1)の値があるなら、値の>31は全くwildcardingを示しません。 midcomRuleExternalIpVersionにipv4(2)の値があるなら、値の>127は全くwildcardingを示しません。 IPアドレスwildcardingをサポートしないMIDCOM-MIB実装は書き込み禁止として128の値でこのオブジェクトを実装しなければなりません。 接頭語の長さに基づくwildcardingをサポートしないMIDCOMはこのオブジェクトのために許容値を0と128に制限するかもしれません。
This object is used as input to a request for establishing
このオブジェクトは設立を求める要求に入力されるように使用されています。
Quittek, et al. Standards Track [Page 59] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[59ページ]。
a policy rule as well as for indicating the properties of
an established policy rule.
また、既定方針規則の特性を示すような政策ルール。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1), setting(2), or reserved(7), then this
object can be written by a manager in order to specify the
prefix length of the external IP address for which an
enable policy rule is requested to be established.
Writing to this object in any state other than
newEntry(1), setting(2), or reserved(7) will always fail
with an 'inconsistentValue' error.
政策ルールを可能にしてください。同じエントリーのmidcomRuleOperStatusが値newEntry(1)、設定(2)、または予約された(7)、マネージャが外部のIPアドレスの接頭語の長さを指定するためにこのオブジェクトを書くことができるその時を持っているオブジェクトである、どれ、設立されるよう要求されているか。 newEntry(1)以外のどんな状態のこのオブジェクトにも書くと、'inconsistentValue'誤りに応じて、(2)を設定するか、または予約された(7)がいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object will have the value
that it had before the transition to this state.
このオブジェクトには、同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は(8)を可能にして、次に、それがこの状態への変遷の前に持っていた値があるでしょう。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 128 }
::= { midcomRuleEntry 20 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL128:、:= midcomRuleEntry20
midcomRuleExternalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The external port number. A value of 0 is a wildcard.
midcomRuleExternalPort OBJECT-TYPE SYNTAX InetPortNumberマックス-ACCESSは「外部のポートは付番する」STATUSの現在の記述を読書して作成します。 0の値はワイルドカードです。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule. It is relevant to the
operation of the MIDCOM-MIB implementation only if the
value of object midcomTransportProtocol in the same entry
has a value other than 0.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。 同じエントリーにおける、オブジェクトmidcomTransportProtocolの値に0以外の値がある場合にだけ、MIDCOM-MIB実装の操作に関連しています。
If object midcomRuleOperStatus of the same entry has the
value newEntry(1), setting(2) or reserved(7), then this
object can be written by a manager in order to specify the
external port number for which an enable policy rule is
requested to be established. Writing to this object in
any state other than newEntry(1), setting(2) or reserved(7)
will always fail with an 'inconsistentValue' error.
政策ルールを可能にしてください。同じエントリーのmidcomRuleOperStatusが値newEntry(1)、設定(2)または予約された(7)、マネージャが外部のポートナンバーを指定するためにこのオブジェクトを書くことができるその時を持っているオブジェクトである、どれ、設立されるよう要求されているか。 newEntry(1)以外のどんな状態のこのオブジェクトにも書くと、'inconsistentValue'誤りに応じて、(2)か予約された(7)を設定するのはいつも失敗するでしょう。
Quittek, et al. Standards Track [Page 60] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[60ページ]。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has the
value enabled(8), then this object will have the value
which it had before the transition to this state.
このオブジェクトには、同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、値は(8)を可能にして、次に、それがこの状態への変遷の前に持っていた値があるでしょう。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7) or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 0 }
::= { midcomRuleEntry 21 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL0:、:= midcomRuleEntry21
midcomRuleInsideIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The inside IP address at the middlebox (A1).
「内面のIPはmiddlebox(A1)で扱う」midcomRuleInsideIpAddr OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
The value of this object is relevant only if
object midcomRuleOperStatus of the same entry has
a value of either reserved(7) or enabled(8)."
::= { midcomRuleEntry 22 }
「同じエントリーのmidcomRuleOperStatusが値を持っているオブジェクトが(7)を予約したか、または(8)を可能にした場合にだけ、このオブジェクトの値は関連しています。」 ::= midcomRuleEntry22
midcomRuleInsidePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The inside port number at the middlebox.
A value of 0 is a wildcard.
「内面のポートはmiddleboxで付番する」midcomRuleInsidePort OBJECT-TYPE SYNTAX InetPortNumberのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 0の値はワイルドカードです。
The value of this object is relevant only if
object midcomRuleOperStatus of the same entry has
a value of either reserved(7) or enabled(8)."
::= { midcomRuleEntry 23 }
「同じエントリーのmidcomRuleOperStatusが値を持っているオブジェクトが(7)を予約したか、または(8)を可能にした場合にだけ、このオブジェクトの値は関連しています。」 ::= midcomRuleEntry23
midcomRuleOutsideIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The outside IP address at the middlebox (A2).
「外のIPはmiddlebox(A2)で扱う」midcomRuleOutsideIpAddr OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
The value of this object is relevant only if
このオブジェクトの値が関連している、唯一
Quittek, et al. Standards Track [Page 61] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[61ページ]。
object midcomRuleOperStatus of the same entry has
a value of either reserved(7) or enabled(8)."
::= { midcomRuleEntry 24 }
「エントリーが値を持っている同じくらいのオブジェクトmidcomRuleOperStatusは(7)を予約したか、または(8)を可能にしました。」 ::= midcomRuleEntry24
midcomRuleOutsidePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The outside port number at the middlebox.
A value of 0 is a wildcard.
「外のポートはmiddleboxで付番する」midcomRuleOutsidePort OBJECT-TYPE SYNTAX InetPortNumberのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 0の値はワイルドカードです。
The value of this object is relevant only if
object midcomRuleOperStatus of the same entry has
a value of either reserved(7) or enabled(8)."
::= { midcomRuleEntry 25 }
「同じエントリーのmidcomRuleOperStatusが値を持っているオブジェクトが(7)を予約したか、または(8)を可能にした場合にだけ、このオブジェクトの値は関連しています。」 ::= midcomRuleEntry25
midcomRuleLifetime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The remaining lifetime in seconds of this policy rule.
midcomRuleLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS「秒」マックス-ACCESSは「この方針の秒の残っている寿命は統治する」STATUSの現在の記述を読書して作成します。
Lifetime of a policy rule starts when object
midcomRuleOperStatus in the same entry enters either
state reserved(7) or state enabled(8).
同じエントリーにおけるオブジェクトmidcomRuleOperStatusが入るとき、始めが予約された(7)を述べるという政策ルールか状態の寿命は(8)を可能にしました。
This object is used as input to a request for establishing
a policy rule as well as for indicating the properties of
an established policy rule.
このオブジェクトは、政策ルールを確立するのを求める要求に入力されて既定方針規則の特性を示すのに使用されます。
If object midcomRuleOperStatus of the same entry has a
value of either newEntry(1) or setting(2), then this
object can be written by a manager in order to specify
the requested lifetime of a policy rule to be established.
同じエントリーのオブジェクトmidcomRuleOperStatusにnewEntry(1)か設定(2)のどちらかの値があるなら、マネージャは、証明されるために政策ルールの要求された生涯を指定するためにこのオブジェクトを書くことができます。
If object midcomRuleOperStatus of the same entry has a
value of either reserved(7) or enabled(8), then this
object indicates the (continuously decreasing) remaining
lifetime of the established policy rule. Note that when
entering state reserved(7) or enabled(8), the MIDCOM-MIB
implementation can choose a lifetime shorter than the one
requested.
同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、どちらかの値は、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトは既定方針規則の(絶え間なく減少しています)の残っている生涯を示します。 入る州が(7)を予約したか、または(8)を可能にしたとき、MIDCOM-MIB実装が要求されたものより短い生涯を選ぶことができることに注意してください。
Unlike other parameters of the policy rule, this parameter
can still be written in state reserved(7) and enabled(8).
政策ルールの他のパラメタと異なって、これは、状態で(7)を予約して、(8)を可能にしましたまだパラメタを書くことができる。
Quittek, et al. Standards Track [Page 62] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[62ページ]。
Writing to this object is processed by the MIDCOM-MIB
implementation by choosing a lifetime value that is
greater than 0 and less than or equal to the minimum of
the requested value and the value specified by object
midcomConfigMaxLifetime:
このオブジェクトに書くのはMIDCOM-MIB実装によって0以上である生涯値と要求された値とオブジェクトmidcomConfigMaxLifetimeによって指定された価値の、より最小限を選ぶことによって、処理されます:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <はMINIMUMと等しいのを_を<に与えるltと等しいです。(_が要求したlt、lt_最大)
where:
- lt_granted is the actually granted lifetime by the
MIDCOM-MIB implementation
- lt_requested is the requested lifetime of the MIDCOM
client
- lt_maximum is the value of object
midcomConfigMaxLifetime
どこ: - _が与えたltはMIDCOM-MIB実装による実際に与えられた生涯です--_が要求したltはMIDCOMクライアントの要求された生涯です--lt_最大はオブジェクトmidcomConfigMaxLifetimeの値です。
SNMP SET requests to this object may be rejected or the
value of the object after an accepted SET operation may be
less than the value that was contained in the SNMP SET
request.
このオブジェクトへのSNMP SET要求が拒絶されるかもしれないか、受け入れられたSET操作の後のオブジェクトの値はSNMP SET要求に含まれた値以下であるかもしれません。
Successfully writing a value of 0 terminates the policy
rule. Note that after a policy rule is terminated, still
the entry will exist as long as indicated by the value of
midcomRuleStorageTime.
首尾よく0の値を書くと、政策ルールは終えられます。 それでも、midcomRuleStorageTimeの値によって示されて、政策ルールが終えられた後にエントリーが存在することに注意してください。
Writing to this object in any state other than
newEntry(1), setting(2), reserved(7), or enabled(7)
will always fail with an 'inconsistentValue' error.
(2)を設定して、newEntry(1)以外のどんな状態のこのオブジェクトにも書くのが(7)を予約したか、または可能にされて、'inconsistentValue'誤りに応じて、(7)はいつも失敗するでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
If object midcomRuleOperStatus of the same entry has a
value other than newEntry(1), setting(2), reserved(7), or
enabled(8), then the value of this object is irrelevant."
DEFVAL { 180 }
::= { midcomRuleEntry 26 }
「同じエントリーのオブジェクトmidcomRuleOperStatusがそうしたなら、newEntry(1)以外の値は、(2)を設定して、(7)を予約したか、または(8)を可能にして、次に、このオブジェクトの値は無関係です。」 DEFVAL180:、:= midcomRuleEntry26
midcomRuleRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A control that allows entries to be added and removed from
this table.
midcomRuleRowStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「エントリーがこのテーブルから加えられて、取り除かれるのを許容するコントロール。」
Quittek, et al. Standards Track [Page 63] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[63ページ]。
Entries can also be removed from this table by setting
objects midcomRuleLifetime and midcomRuleStorageTime of
an entry to 0.
また、このテーブルからエントリーのオブジェクトのmidcomRuleLifetimeとmidcomRuleStorageTimeを0に設定することによって、エントリーを取り除くことができます。
Attempts to set a row notInService(2) where the value
of the midcomRuleStorageType object is permanent(4) or
readOnly(5) will result in an 'notWritable' error.
midcomRuleStorageTypeオブジェクトの値が永久的な(4)である行notInService(2)かreadOnly(5)を設定する試みは'notWritable'誤りをもたらすでしょう。
Note that this error code is SNMP specific. If the MIB
module is used with other protocols than SNMP, errors with
similar semantics specific to those protocols should be
returned.
このエラーコードがSNMP特有であることに注意してください。 MIBモジュールがSNMP以外のプロトコルと共に使用されるなら、それらのプロトコルに特定の同様の意味論がある誤りは返されるべきです。
The value of this object has no effect on whether other
objects in this conceptual row can be modified."
::= { midcomRuleEntry 27 }
「このオブジェクトの値はこの概念的な行の他のオブジェクトを変更できるかどうかに関して効き目がありません。」 ::= midcomRuleEntry27
-- -- Policy rule group subtree -- -- The midcomGroupTable lists all current policy rule groups. --
-- -- 政策ルールグループ下位木----midcomGroupTableはすべての通貨政策規則グループを記載します。 --
midcomGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists all current policy rule groups.
「このテーブルのリスト通貨政策規則は分類する」midcomGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomGroupEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
Entries in this table are created or removed
implicitly when entries in the midcomRuleTable are
created or removed, respectively. A group entry
in this table only exists as long as there are
member rules of this group in the midcomRuleTable.
このテーブルのエントリーをmidcomRuleTableのエントリーを作成するとき、それとなく作成するか、取り除く、またはそれぞれ取り除きます。 このグループのメンバー規則がmidcomRuleTableにある限り、このテーブルのグループエントリーは存在するだけです。
The table serves for listing the existing groups and
their remaining lifetimes and for changing lifetimes
of groups and implicitly of all group members.
Groups and all their member policy rules can only be
deleted by deleting all member policies in the
midcomRuleTable.
テーブルは、既存のグループと彼らの残っている生涯を記載して、それとなくグループの生涯を変えるためにすべてのグループのメンバーにサービスされます。 midcomRuleTableのすべてのメンバー方針を削除することによって、グループとそれらのすべてのメンバー政策ルールを削除できるだけです。
Setting midcomGroupLifetime will result in setting
the lifetime of all policy members to the same value."
::= { midcomTransaction 4 }
「midcomGroupLifetimeを設定するのはすべての方針メンバーの生涯を同じ値に決めるのに結果として生じるでしょう。」 ::= midcomTransaction4
midcomGroupEntry OBJECT-TYPE
midcomGroupEntryオブジェクト・タイプ
Quittek, et al. Standards Track [Page 64] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[64ページ]。
SYNTAX MidcomGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing properties of a particular
MIDCOM policy rule group."
INDEX { midcomRuleOwner, midcomGroupIndex }
::= { midcomGroupTable 1 }
SYNTAX MidcomGroupEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定のMIDCOM政策ルールグループの特性について説明するエントリー。」 midcomRuleOwner、midcomGroupIndexに索引をつけてください:、:= midcomGroupTable1
MidcomGroupEntry ::= SEQUENCE {
midcomGroupIndex Unsigned32,
midcomGroupLifetime Unsigned32
}
MidcomGroupEntry:、:= 系列midcomGroupIndex Unsigned32、midcomGroupLifetime Unsigned32
midcomGroupIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of this group for the midcomRuleOwner.
A group is identified by the combination of
midcomRuleOwner and midcomGroupIndex.
midcomGroupIndex OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「midcomRuleOwnerのためのこのグループのインデックス。」 グループはmidcomRuleOwnerとmidcomGroupIndexの組み合わせで特定されます。
The value of this index must be unique per
midcomRuleOwner."
::= { midcomGroupEntry 2 }
「このインデックスの値はmidcomRuleOwner単位でユニークであるに違いありません。」 ::= midcomGroupEntry2
midcomGroupLifetime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When retrieved, this object delivers the maximum
lifetime in seconds of all member rules of this group,
i.e., of all rows in the midcomRuleTable that have the
same values for midcomRuleOwner and midcomGroupIndex.
midcomGroupLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS「秒」マックス-ACCESSは「検索されると、このオブジェクトはすなわち、このグループのすべてのメンバー規則、midcomRuleOwnerとmidcomGroupIndexのための同じ値を持っているmidcomRuleTableのすべての行の秒に最大の生涯を提供すること」をSTATUSの現在の記述に読書して書きます。
Successfully writing to this object modifies the
lifetime of all member policies. Successfully
writing a value of 0 terminates all member policies
and implicitly deletes the group as soon as all member
entries are removed from the midcomRuleTable.
首尾よくこのオブジェクトに書くのはすべてのメンバー方針の生涯を変更します。 首尾よく0の値を書くと、midcomRuleTableからすべてのメンバーエントリーを取り除くとすぐに、すべてのメンバー方針が終えられて、グループはそれとなく削除されます。
Note that after a group's lifetime is expired or is
set to 0, still the corresponding entry in the
midcomGroupTable will exist as long as terminated
member policy rules are stored as entries in the
グループの寿命が満期である、または0に決められた後にそれでも、終えられたメンバー政策ルールがエントリーとして中に保存される限り、midcomGroupTableの対応するエントリーが存在することに注意してください。
Quittek, et al. Standards Track [Page 65] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[65ページ]。
midcomRuleTable.
midcomRuleTable。
Writing to this object is processed by the MIDCOM-MIB
implementation by choosing a lifetime value that is
greater than 0 and less than or equal to the minimum of
the requested value and the value specified by object
midcomConfigMaxLifetime:
このオブジェクトに書くのはMIDCOM-MIB実装によって0以上である生涯値と要求された値とオブジェクトmidcomConfigMaxLifetimeによって指定された価値の、より最小限を選ぶことによって、処理されます:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <はMINIMUMと等しいのを_を<に与えるltと等しいです。(_が要求したlt、lt_最大)
where:
- lt_granted is the actually granted lifetime by the
MIDCOM-MIB implementation
- lt_requested is the requested lifetime of the MIDCOM
client
- lt_maximum is the value of object
midcomConfigMaxLifetime
どこ: - _が与えたltはMIDCOM-MIB実装による実際に与えられた生涯です--_が要求したltはMIDCOMクライアントの要求された生涯です--lt_最大はオブジェクトmidcomConfigMaxLifetimeの値です。
SNMP SET requests to this object may be rejected or the
value of the object after an accepted SET operation may be
less than the value that was contained in the SNMP SET
request."
::= { midcomGroupEntry 3 }
「このオブジェクトへのSNMP SET要求は拒絶されるかもしれませんか、受け入れられたSET操作の後のオブジェクトの値はSNMP SET要求に含まれた値以下であるかもしれません。」 ::= midcomGroupEntry3
-- -- Configuration Objects -- -- Configuration objects that can be used for retrieving -- middlebox capability information (mandatory) and for -- setting parameters of the implementation of transaction -- objects (optional). -- -- Note that typically configuration objects are not intended -- to be written by MIDCOM clients. In general, write access -- to these objects needs to be restricted more strictly than -- write access to transaction objects. --
-- -- 構成Objects----検索、middlebox能力情報(義務的な)と--トランザクションの実装のパラメタを設定します--オブジェクト(任意の)に使用できる構成オブジェクト。 -- -- 通常、構成オブジェクトが意図しないことに注意してください--MIDCOMクライアントによって書かれているように。 一般に、より厳密に部外秘になるこれらのオブジェクトの必要性へのアクセスを書いてください、--トランザクションオブジェクトへのアクセスを書いてください。 --
-- -- Capabilities subtree -- -- This subtree contains objects to which MIDCOM clients should -- have read access. --
-- -- 能力下位木は----この下位木がMIDCOMクライアントがそうするべきであるオブジェクトを含んでいる--アクセサリーを読みました。 --
midcomConfigMaxLifetime OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
midcomConfigMaxLifetimeオブジェクト・タイプ構文Unsigned32ユニット「秒」
Quittek, et al. Standards Track [Page 66] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[66ページ]。
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When retrieved, this object returns the maximum lifetime,
in seconds, that this middlebox allows policy rules to
have."
::= { midcomConfig 1 }
マックス-ACCESSは「検索されると、このオブジェクトは秒のこのmiddleboxが政策ルールを持たせる最大の生涯を返すこと」をSTATUSの現在の記述に読書して書きます。 ::= midcomConfig1
midcomConfigPersistentRules OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When retrieved, this object returns true(1) if the
MIDCOM-MIB implementation can store policy rules
persistently. Otherwise, it returns false(2).
midcomConfigPersistentRules OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「検索されると、MIDCOM-MIB実装が政策ルールを持続して保存できるなら、このオブジェクトは本当の(1)を返すこと」をSTATUSの現在の記述に読書して書きます。 さもなければ、それは誤った(2)を返します。
A value of true(1) indicates that there may be
entries in the midcomRuleTable with object
midcomRuleStorageType set to value nonVolatile(3)."
::= { midcomConfig 2 }
「本当の(1)の値は、エントリーがnonVolatile(3)を評価するように用意ができているオブジェクトmidcomRuleStorageTypeと共にmidcomRuleTableにあるかもしれないのを示します。」 ::= midcomConfig2
midcomConfigIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomConfigIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table indicates capabilities of the MIDCOM-MIB
implementation per IP interface.
「このテーブルはMIDCOM-MIB実装のIPインタフェースあたりの能力に示す」midcomConfigIfTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomConfigIfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
The table is indexed by the object midcomConfigIfIndex.
テーブルはオブジェクトmidcomConfigIfIndexによって索引をつけられます。
For indexing a single interface, this object contains
the value of the ifIndex object that is associated
with the interface. If an entry with
midcomConfigIfIndex = 0 occurs, then bits set in
objects of this entry apply to all interfaces for which
there is no entry in this table with the interface's
index."
::= { midcomConfig 3 }
単一のインタフェースに索引をつけるために、このオブジェクトはインタフェースに関連しているifIndexオブジェクトの値を含んでいます。 「midcomConfigIfIndex=0があるエントリーが現れるなら、このエントリーの目的に設定されたビットはエントリーが全くインタフェースのインデックスと共にこのテーブルにないすべてのインタフェースに適用されます。」 ::= midcomConfig3
midcomConfigIfEntry OBJECT-TYPE
SYNTAX MidcomConfigIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing the capabilities of a middlebox
with respect to the indexed IP interface."
midcomConfigIfEntry OBJECT-TYPE SYNTAX MidcomConfigIfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「索引をつけられたIPインタフェースに関してmiddleboxの能力について説明するエントリー。」
Quittek, et al. Standards Track [Page 67] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[67ページ]。
INDEX { midcomConfigIfIndex }
::= { midcomConfigIfTable 1 }
midcomConfigIfIndexに索引をつけてください:、:= midcomConfigIfTable1
MidcomConfigIfEntry ::= SEQUENCE {
midcomConfigIfIndex InterfaceIndexOrZero,
midcomConfigIfBits BITS,
midcomConfigIfEnabled TruthValue
}
MidcomConfigIfEntry:、:= 系列midcomConfigIfIndex InterfaceIndexOrZero、midcomConfigIfBitsビット、midcomConfigIfEnabled TruthValue
midcomConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of an entry in the midcomConfigIfTable.
midcomConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZeroのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「midcomConfigIfTableのエントリーのインデックス。」
For values different from zero, this object
identifies an IP interface by containing the same
value as the ifIndex object associated with the
interface.
ゼロと異なった値のために、このオブジェクトは、インタフェースに関連しているifIndexオブジェクトと同じ値を含むことによって、IPインタフェースを特定します。
Note that the index of a particular interface in the
ifTable may change after a re-initialization of the
middlebox, for example, after adding another interface to
it. In such a case, the value of this object may change,
but the interface referred to by the MIDCOM-MIB MUST still
be the same. If, after a re-initialization of the
middlebox, the interface referred to before
re-initialization cannot be uniquely mapped anymore to a
particular entry in the ifTable, then the value of object
midcomConfigIfEnabled of the same entry MUST be changed to
false(2).
例えば、別のインタフェースをそれに加えた後にifTableの特定のインタフェースのインデックスがmiddleboxの再初期化の後に変化するかもしれないことに注意してください。 インタフェースだけが、MIDCOM-MIB MUSTでこのような場合には、このオブジェクトの値が変化するかもしれないと言及しました、それでも、同じであってください。 それ以上middleboxの再初期化の後に唯一再初期化の前に言及されたインタフェースをifTableの特定のエントリーに写像できないなら、同じエントリーのオブジェクトmidcomConfigIfEnabledの値は誤った(2)に変わらなければなりません。
If the object has a value of 0, then values
specified by further objects of the same entry
apply to all interfaces for which there is no
explicit entry in the midcomConfigIfTable."
::= { midcomConfigIfEntry 1 }
「オブジェクトに0の値があるなら、同じエントリーの一層の目的によって指定された値はどんな明白なエントリーもmidcomConfigIfTableにないすべてのインタフェースに適用されます。」 ::= midcomConfigIfEntry1
midcomConfigIfBits OBJECT-TYPE
SYNTAX BITS {
ipv4(0),
ipv6(1),
addressWildcards(2),
portWildcards(3),
firewall(4),
nat(5),
portTranslation(6),
midcomConfigIfBits OBJECT-TYPE SYNTAX BITS、ipv4(0)、ipv6(1)、addressWildcards(2)、portWildcards(3)、ファイアウォール(4)、nat(5)、portTranslation(6)
Quittek, et al. Standards Track [Page 68] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[68ページ]。
protocolTranslation(7),
twiceNat(8),
inside(9)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"When retrieved, this object returns a set of bits
indicating the capabilities (or configuration) of
the middlebox with respect to the referenced IP interface.
If the index equals 0, then all set bits apply to all
interfaces.
protocolTranslation(7)、(9)のtwiceNat(8) 「検索されていて、このオブジェクトは参照をつけられたIPインタフェースに関してmiddleboxの能力(または、構成)を示すビットのセットを返す」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 インデックスが0と等しいなら、すべてのセット・ビットがすべてのインタフェースに適用されます。
If the ipv4(0) bit is set, then the middlebox supports
IPv4 at the indexed IP interface.
ipv4(0)ビットが設定されるなら、middleboxは索引をつけられたIPインタフェースでIPv4をサポートします。
If the ipv6(1) bit is set, then the middlebox supports
IPv6 at the indexed IP interface.
ipv6(1)ビットが設定されるなら、middleboxは索引をつけられたIPインタフェースでIPv6をサポートします。
If the addressWildcards(2) bit is set, then the
middlebox supports IP address wildcarding at the indexed
IP interface.
addressWildcards(2)ビットが設定されるなら、middleboxは索引をつけられたIPインタフェースでwildcardingされるIPアドレスをサポートします。
If the portWildcards(3) bit is set, then the
middlebox supports port wildcarding at the indexed
IP interface.
portWildcards(3)ビットが設定されるなら、middleboxは索引をつけられたIPインタフェースでwildcardingされるポートを支えます。
If the firewall(4) bit is set, then the middlebox offers
firewall functionality at the indexed interface.
ファイアウォール(4)ビットが設定されるなら、middleboxは索引をつけられたインタフェースにおけるファイアウォールの機能性を提供します。
If the nat(5) bit is set, then the middlebox offers
network address translation service at the indexed
interface.
nat(5)ビットが設定されるなら、middleboxは索引をつけられたインタフェースでネットワーク・アドレス翻訳サービスを提供します。
If the portTranslation(6) bit is set, then the middlebox
offers port translation service at the indexed interface.
This bit is only relevant if nat(5) is set.
portTranslation(6)ビットが設定されるなら、middlebox申し出は索引をつけられたインタフェースで翻訳サービスを移植します。 nat(5)が用意ができている場合にだけ、このビットは関連しています。
If the protocolTranslation(7) bit is set, then the
middlebox offers protocol translation service between
IPv4 and IPv6 at the indexed interface. This bit is only
relevant if nat(5) is set.
protocolTranslation(7)ビットが設定されるなら、middleboxは索引をつけられたインタフェースでIPv4とIPv6の間にプロトコル変換サービスを提供します。 nat(5)が用意ができている場合にだけ、このビットは関連しています。
If the twiceNat(8) bit is set, then the middlebox offers
twice network address translation service at the indexed
interface. This bit is only relevant if nat(5) is set.
twiceNat(8)ビットが設定されるなら、middlebox申し出は索引をつけられたインタフェースで二度アドレス変換サービスをネットワークでつなぎます。 nat(5)が用意ができている場合にだけ、このビットは関連しています。
If the inside(9) bit is set, then the indexed interface is
内部(9)ビットが設定されるなら、索引をつけられたインタフェースはそうです。
Quittek, et al. Standards Track [Page 69] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[69ページ]。
an inside interface with respect to NAT functionality.
Otherwise, it is an outside interface. This bit is only
relevant if nat(5) is set. An SNMP agent supporting both
the MIDCOM-MIB module and the NAT-MIB module SHOULD ensure
that the value of this object is consistent with the values
of corresponding objects in the NAT-MIB module."
::= { midcomConfigIfEntry 2 }
NATの機能性に関する内面のインタフェース。 さもなければ、それは外のインタフェースです。 nat(5)が用意ができている場合にだけ、このビットは関連しています。 「両方がMIDCOM-MIBモジュールであるとサポートするSNMPエージェントとNAT-MIBモジュールSHOULDは、このオブジェクトの値がNAT-MIBモジュールによる対応するオブジェクトの値と一致しているのを確実にします。」 ::= midcomConfigIfEntry2
midcomConfigIfEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value of this object indicates the availability of
the middlebox service described by midcomConfigIfBits
at the indexed IP interface.
midcomConfigIfEnabled OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「このオブジェクトの値は索引をつけられたIPインタフェースのmidcomConfigIfBitsによって説明されたmiddleboxサービスの有用性を示すこと」をSTATUSの現在の記述に読書して書きます。
By writing to this object, the MIDCOM support for the
entire IP interface can be switched on or off. Setting
this object to false(2) immediately stops middlebox
support at the indexed IP interface. This implies that
all policy rules that use NAT or firewall resources at
the indexed IP interface are terminated immediately.
In this case, the MIDCOM agent MUST send
midcomUnsolicitedRuleEvent to all MIDCOM clients that
have access to one of the terminated rules."
DEFVAL { true }
::= { midcomConfigIfEntry 3 }
このオブジェクトに書くことによって、オンかオフに全体のIPインタフェースのMIDCOMサポートを切り換えることができます。 すぐに誤った(2)にこのオブジェクトを設定すると、middleboxサポートは索引をつけられたIPインタフェースに止まります。 これは、索引をつけられたIPインタフェースでNATかファイアウォールリソースを使用するすべての政策ルールがすぐに終えられるのを含意します。 「この場合、MIDCOMエージェントは終えられた規則の1つに近づく手段を持っているすべてのMIDCOMクライアントにmidcomUnsolicitedRuleEventを送らなければなりません。」 DEFVAL、本当:、:= midcomConfigIfEntry3
-- -- Firewall subtree -- -- This subtree contains the firewall configuration table --
-- -- ファイアウォール下位木----この下位木はファイアウォール構成テーブルを含んでいます--
midcomConfigFirewallTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomConfigFirewallEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists the firewall configuration per IP interface.
「このテーブルはIPインタフェースあたりのファイアウォール構成に記載する」midcomConfigFirewallTable OBJECT-TYPEのSYNTAX SEQUENCE OF MidcomConfigFirewallEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
It can be used for configuring how policy rules created by
MIDCOM clients are realized as firewall rules of a firewall
implementation. Particularly, the priority used for MIDCOM
policy rules can be configured. For a single firewall
implementation at a particular IP interface, all MIDCOM
policy rules are realized as firewall rules with the same
MIDCOMクライアントによって作成された政策ルールがファイアウォール実装のファイアウォール規則としてどのように実現されるかを構成するのにそれを使用できます。 特に、MIDCOM政策ルールに使用される優先権は構成できます。 特定のIPインタフェースのただ一つのファイアウォール実装において、すべてのMIDCOM政策ルールがファイアウォール規則として同じくらいで実現されます。
Quittek, et al. Standards Track [Page 70] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[70ページ]。
priority. Also, a firewall rule group name can be
configured.
優先権。 また、ファイアウォール規則グループ名を構成できます。
The table is indexed by the object midcomConfigFirewallIndex.
For indexing a single interface, this object contains the
value of the ifIndex object that is associated with the
interface. If an entry with midcomConfigFirewallIndex = 0
occurs, then bits set in objects of this entry apply to all
interfaces for which there is no entry in this table for the
interface's index."
::= { midcomConfig 4 }
テーブルはオブジェクトmidcomConfigFirewallIndexによって索引をつけられます。 単一のインタフェースに索引をつけるために、このオブジェクトはインタフェースに関連しているifIndexオブジェクトの値を含んでいます。 「midcomConfigFirewallIndex=0があるエントリーが現れるなら、このエントリーの目的に設定されたビットはエントリーが全くインタフェースのインデックスのためのこのテーブルにないすべてのインタフェースに適用されます。」 ::= midcomConfig4
midcomConfigFirewallEntry OBJECT-TYPE
SYNTAX MidcomConfigFirewallEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular set of
firewall resources."
INDEX { midcomConfigFirewallIndex }
::= { midcomConfigFirewallTable 1 }
midcomConfigFirewallEntry OBJECT-TYPE SYNTAX MidcomConfigFirewallEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定のセットのファイアウォールリソースについて説明するエントリー。」 midcomConfigFirewallIndexに索引をつけてください:、:= midcomConfigFirewallTable1
MidcomConfigFirewallEntry ::= SEQUENCE {
midcomConfigFirewallIndex InterfaceIndexOrZero,
midcomConfigFirewallGroupId SnmpAdminString,
midcomConfigFirewallPriority Unsigned32
}
MidcomConfigFirewallEntry:、:= 系列midcomConfigFirewallIndex InterfaceIndexOrZero、midcomConfigFirewallGroupId SnmpAdminString、midcomConfigFirewallPriority Unsigned32
midcomConfigFirewallIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The index of an entry in the midcomConfigFirewallTable.
midcomConfigFirewallIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZeroのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「midcomConfigFirewallTableのエントリーのインデックス。」
For values different from 0, this object identifies an
IP interface by containing the same value as the ifIndex
object associated with the interface.
0と異なった値のために、このオブジェクトは、インタフェースに関連しているifIndexオブジェクトと同じ値を含むことによって、IPインタフェースを特定します。
Note that the index of a particular interface in the
ifTable may change after a re-initialization of the
middlebox, for example, after adding another interface to
it. In such a case, the value of this object may change,
but the interface referred to by the MIDCOM-MIB MUST still
be the same. If, after a re-initialization of the
middlebox, the interface referred to before
re-initialization cannot be uniquely mapped anymore to a
particular entry in the ifTable, then the entry in the
例えば、別のインタフェースをそれに加えた後にifTableの特定のインタフェースのインデックスがmiddleboxの再初期化の後に変化するかもしれないことに注意してください。 インタフェースだけが、MIDCOM-MIB MUSTでこのような場合には、このオブジェクトの値が変化するかもしれないと言及しました、それでも、同じであってください。 それ以上middleboxの再初期化の後に唯一再初期化の前に言及されたインタフェースはifTableの特定のエントリーに写像できないで、その時は中のエントリーであるかどうか。
Quittek, et al. Standards Track [Page 71] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[71ページ]。
midcomConfigFirewallTable MUST be deleted.
midcomConfigFirewallTableを削除しなければなりません。
If the object has a value of 0, then values specified by
further objects of the same entry apply to all interfaces
for which there is no explicit entry in the
midcomConfigFirewallTable."
::= { midcomConfigFirewallEntry 1 }
「オブジェクトに0の値があるなら、同じエントリーの一層の目的によって指定された値はどんな明白なエントリーもmidcomConfigFirewallTableにないすべてのインタフェースに適用されます。」 ::= midcomConfigFirewallEntry1
midcomConfigFirewallGroupId OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The firewall rule group to which all firewall rules are
assigned that the MIDCOM server creates for the interface
indicated by object midcomConfigFirewallIndex. If the
value of object midcomConfigFirewallIndex is 0, then all
firewall rules of the MIDCOM server that are created for
interfaces with no specific entry in the
midcomConfigFirewallTable are assigned to the firewall
rule group indicated by the value of this object."
::= { midcomConfigFirewallEntry 2 }
midcomConfigFirewallGroupId OBJECT-TYPE SYNTAX SnmpAdminStringマックス-ACCESSは「MIDCOMサーバがオブジェクトmidcomConfigFirewallIndexによって示されたインタフェースに創設するすべてのファイアウォール規則がどれであるかに割り当てられたファイアウォール規則グループ」をSTATUSの現在の記述に読書して書きます。 「オブジェクトmidcomConfigFirewallIndexの値が0であるなら、midcomConfigFirewallTableで特定のエントリーなしでインタフェースに作成されるMIDCOMサーバのすべてのファイアウォール規則がこのオブジェクトの値によって示されたファイアウォール規則グループに配属されます。」 ::= midcomConfigFirewallEntry2
midcomConfigFirewallPriority OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The priority assigned to all firewall rules that the
MIDCOM server creates for the interface indicated by
object midcomConfigFirewallIndex. If the value of object
midcomConfigFirewallIndex is 0, then this priority is
assigned to all firewall rules of the MIDCOM server that
are created for interfaces for which there is no specific
entry in the midcomConfigFirewallTable."
::= { midcomConfigFirewallEntry 3 }
midcomConfigFirewallPriority OBJECT-TYPE SYNTAX Unsigned32マックス-ACCESSは「MIDCOMサーバがオブジェクトmidcomConfigFirewallIndexによって示されたインタフェースに作成するすべてのファイアウォール規則に割り当てられた優先権」をSTATUSの現在の記述に読書して書きます。 「オブジェクトmidcomConfigFirewallIndexの値が0であるなら、この優先権はどんな特定のエントリーもmidcomConfigFirewallTableにないインタフェースに作成されるMIDCOMサーバのすべてのファイアウォール規則に割り当てられます。」 ::= midcomConfigFirewallEntry3
-- -- Monitoring Objects -- -- Monitoring objects are structured into two groups, -- the midcomResourceGroup providing information about used -- resources and the midcomStatisticsGroup providing information -- about MIDCOM transaction statistics.
-- -- モニターしているObjects----モニターしているオブジェクトは2つのグループに構造化されます--MIDCOMに関して中古(情報を提供するリソースとmidcomStatisticsGroup)のトランザクション統計の情報を提供するmidcomResourceGroup。
-- -- Resources subtree --
-- -- リソース下位木--
Quittek, et al. Standards Track [Page 72] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[72ページ]。
-- The MIDCOM resources subtree contains a set of managed -- objects describing the currently used resources of NAT -- and firewall implementations. --
-- MIDCOMリソース下位木は1セットの管理(NATの現在中古のリソースについて説明するオブジェクト)にされるのとファイアウォール実装を含んでいます。 --
-- -- Textual conventions for objects of the resource subtree --
-- -- リソース下位木のオブジェクトのための原文のコンベンション--
MidcomNatBindMode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An indicator of the kind of NAT resources used by a policy
rule. This definition corresponds to the definition of
NatBindMode in the NAT-MIB (RFC 4008). Value none(3) can
be used to indicate that the policy rule does not use
any NAT binding.
"
SYNTAX INTEGER {
addressBind(1),
addressPortBind(2),
none(3)
}
MidcomNatBindMode:、:= 「NATリソースの種類のインディケータは政策ルールで使用した」TEXTUAL-CONVENTION STATUSの現在の記述。 この定義はNAT-MIB(RFC4008)とのNatBindModeの定義に対応しています。 なにも評価しないでください。政策ルールが少しのNAT結合も使用しないのを示すのに(3)は使用できます。 「構文整数」addressBind(1)、addressPortBind(2)、なにも、(3)
MidcomNatSessionIdOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique ID that is assigned to each NAT session by
a NAT implementation. This definition corresponds to
the definition of NatSessionId in the NAT-MIB (RFC 4008).
Value 0 can be used to indicate that the policy rule does
not use any NAT binding."
SYNTAX Unsigned32
MidcomNatSessionIdOrZero:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「d」STATUSの現在の記述「NAT実装によってそれぞれのNATセッションまで割り当てられるユニークなID。」 この定義はNAT-MIB(RFC4008)とのNatSessionIdの定義に対応しています。 「政策ルールが少しのNAT結合も使用しないのを示すのに値0を使用できます。」 構文Unsigned32
-- -- The MIDCOM resource table --
-- -- MIDCOMリソーステーブル--
midcomResourceTable OBJECT-TYPE
SYNTAX SEQUENCE OF MidcomResourceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table lists all used middlebox resources per
MIDCOM policy rule.
「このテーブルはすべてのMIDCOM政策ルールあたりの中古のmiddleboxリソースに記載する」midcomResourceTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomResourceEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
The midcomResourceTable augments the
midcomResourceTableは増大します。
Quittek, et al. Standards Track [Page 73] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[73ページ]。
midcomRuleTable."
::= { midcomMonitoring 1 }
"midcomRuleTable"。 ::= midcomMonitoring1
midcomResourceEntry OBJECT-TYPE
SYNTAX MidcomResourceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry describing a particular set of middlebox
resources."
AUGMENTS { midcomRuleEntry }
::= { midcomResourceTable 1 }
midcomResourceEntry OBJECT-TYPE SYNTAX MidcomResourceEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定のセットのmiddleboxリソースについて説明するエントリー。」 midcomRuleEntryを増大させます:、:= midcomResourceTable1
MidcomResourceEntry ::= SEQUENCE {
midcomRscNatInternalAddrBindMode MidcomNatBindMode,
midcomRscNatInternalAddrBindId NatBindIdOrZero,
midcomRscNatInsideAddrBindMode MidcomNatBindMode,
midcomRscNatInsideAddrBindId NatBindIdOrZero,
midcomRscNatSessionId1 MidcomNatSessionIdOrZero,
midcomRscNatSessionId2 MidcomNatSessionIdOrZero,
midcomRscFirewallRuleId Unsigned32
}
MidcomResourceEntry:、:= 系列midcomRscNatInternalAddrBindMode MidcomNatBindMode、midcomRscNatInternalAddrBindId NatBindIdOrZero、midcomRscNatInsideAddrBindMode MidcomNatBindMode、midcomRscNatInsideAddrBindId NatBindIdOrZero、midcomRscNatSessionId1 MidcomNatSessionIdOrZero、midcomRscNatSessionId2 MidcomNatSessionIdOrZero、midcomRscFirewallRuleId Unsigned32
midcomRscNatInternalAddrBindMode OBJECT-TYPE
SYNTAX MidcomNatBindMode
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of whether this policy rule uses an address
NAT bind or an address-port NAT bind for binding the
internal address.
「この政策ルールがアドレスNATひもかアドレス港のNATを使用するかどうかしるしは内部のアドレスを縛るのにおいて縛る」midcomRscNatInternalAddrBindMode OBJECT-TYPE SYNTAX MidcomNatBindModeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
If the MIDCOM-MIB module is operated together with
the NAT-MIB module (RFC 4008) then object
midcomRscNatInternalAddrBindMode contains the same
value as the corresponding object
natSessionPrivateSrcEPBindMode of the NAT-MIB module."
::= { midcomResourceEntry 4 }
「MIDCOM-MIBモジュールがNAT-MIBモジュール(RFC4008)と共に操作されるなら、オブジェクトmidcomRscNatInternalAddrBindModeはNAT-MIBモジュールの対応するオブジェクトnatSessionPrivateSrcEPBindModeと同じ値を含んでいます。」 ::= midcomResourceEntry4
midcomRscNatInternalAddrBindId OBJECT-TYPE
SYNTAX NatBindIdOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object references to the allocated internal NAT
bind that is used by this policy rule. A NAT bind
describes the mapping of internal addresses to
outside addresses. MIDCOM-MIB implementations can
「このオブジェクトはこの政策ルールで使用される割り当てられた内部のNATひもに参照をつける」midcomRscNatInternalAddrBindId OBJECT-TYPE SYNTAX NatBindIdOrZeroのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 NATひもは内部のアドレスに関するマッピングについてアドレスの外に説明します。 MIDCOM-MIB実装はそうすることができます。
Quittek, et al. Standards Track [Page 74] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[74ページ]。
read this object to learn the corresponding NAT bind
resource for this particular policy rule.
このオブジェクトを読んで、この特定の政策ルールのための対応するNATひものリソースを学んでください。
If the MIDCOM-MIB module is operated together with
the NAT-MIB module (RFC 4008) then object
midcomRscNatInternalAddrBindId contains the same
value as the corresponding object
natSessionPrivateSrcEPBindId of the NAT-MIB module."
::= { midcomResourceEntry 5 }
「MIDCOM-MIBモジュールがNAT-MIBモジュール(RFC4008)と共に操作されるなら、オブジェクトmidcomRscNatInternalAddrBindIdはNAT-MIBモジュールの対応するオブジェクトnatSessionPrivateSrcEPBindIdと同じ値を含んでいます。」 ::= midcomResourceEntry5
midcomRscNatInsideAddrBindMode OBJECT-TYPE
SYNTAX MidcomNatBindMode
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of whether this policy rule uses an address
NAT bind or an address-port NAT bind for binding the
external address.
「この政策ルールがアドレスNATひもかアドレス港のNATを使用するかどうかしるしは外部アドレスを縛るのにおいて縛る」midcomRscNatInsideAddrBindMode OBJECT-TYPE SYNTAX MidcomNatBindModeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
If the MIDCOM-MIB module is operated together with
the NAT-MIB module (RFC 4008), then object
midcomRscNatInsideAddrBindMode contains the same
value as the corresponding object
natSessionPrivateDstEPBindMode of the NAT-MIB module."
::= { midcomResourceEntry 6 }
「MIDCOM-MIBモジュールがNAT-MIBモジュール(RFC4008)と共に操作されるなら、オブジェクトmidcomRscNatInsideAddrBindModeはNAT-MIBモジュールの対応するオブジェクトnatSessionPrivateDstEPBindModeと同じ値を含んでいます。」 ::= midcomResourceEntry6
midcomRscNatInsideAddrBindId OBJECT-TYPE
SYNTAX NatBindIdOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object refers to the allocated external NAT
bind that is used by this policy rule. A NAT bind
describes the mapping of external addresses to
inside addresses. MIDCOM-MIB implementations can
read this object to learn the corresponding NAT bind
resource for this particular policy rule.
midcomRscNatInsideAddrBindId OBJECT-TYPE SYNTAX NatBindIdOrZeroのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「この政策ルールで使用される割り当てられた外部のNATひもについて言及これが反対するします」。 NATひもは外部アドレスに関するマッピングについてインサイドアドレスに説明します。 MIDCOM-MIB実装は、この特定の政策ルールのための対応するNATひものリソースを学ぶためにこのオブジェクトを読むことができます。
If the MIDCOM-MIB module is operated together with the
NAT-MIB module (RFC 4008), then object
midcomRscNatInsideAddrBindId contains the same
value as the corresponding object
natSessionPrivateDstEPBindId of the NAT-MIB module."
::= { midcomResourceEntry 7 }
「MIDCOM-MIBモジュールがNAT-MIBモジュール(RFC4008)と共に操作されるなら、オブジェクトmidcomRscNatInsideAddrBindIdはNAT-MIBモジュールの対応するオブジェクトnatSessionPrivateDstEPBindIdと同じ値を含んでいます。」 ::= midcomResourceEntry7
midcomRscNatSessionId1 OBJECT-TYPE
SYNTAX MidcomNatSessionIdOrZero
MAX-ACCESS read-only
midcomRscNatSessionId1 OBJECT-TYPE SYNTAX MidcomNatSessionIdOrZeroマックス-ACCESS書き込み禁止
Quittek, et al. Standards Track [Page 75] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[75ページ]。
STATUS current
DESCRIPTION
"This object refers to the first allocated NAT session for
this policy rule. MIDCOM-MIB implementations can read this
object to learn whether or not a NAT session for a
particular policy rule is used. A value of 0 means that no
NAT session is allocated for this policy rule. A value
other than 0 refers to the NAT session."
::= { midcomResourceEntry 8 }
STATUSの現在の記述は「この政策ルールのための最初の割り当てられたNATセッションを参照これが反対するします」。 MIDCOM-MIB実装は、特定の政策ルールのためのNATセッションが使用されているかどうか学ぶためにこのオブジェクトを読むことができます。 0の値は、NATセッションが全くこの政策ルールのために割り当てられないことを意味します。 「0以外の値はNATセッションを参照します。」 ::= midcomResourceEntry8
midcomRscNatSessionId2 OBJECT-TYPE
SYNTAX MidcomNatSessionIdOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object refers to the second allocated NAT session for
this policy rule. MIDCOM-MIB implementations can read this
object to learn whether or not a NAT session for a
particular policy rule is used. A value of 0 means that no
NAT session is allocated for this policy rule. A value
other than 0 refers to the NAT session."
::= { midcomResourceEntry 9 }
「このオブジェクトはこの方針のための割り当てられたNATセッションが統治される秒に言及する」midcomRscNatSessionId2 OBJECT-TYPE SYNTAX MidcomNatSessionIdOrZeroのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 MIDCOM-MIB実装は、特定の政策ルールのためのNATセッションが使用されているかどうか学ぶためにこのオブジェクトを読むことができます。 0の値は、NATセッションが全くこの政策ルールのために割り当てられないことを意味します。 「0以外の値はNATセッションを参照します。」 ::= midcomResourceEntry9
midcomRscFirewallRuleId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object refers to the allocated firewall
rule in the firewall engine for this policy rule.
MIDCOM-MIB implementations can read this value to
learn whether a firewall rule for this particular
policy rule is used or not. A value of 0 means that
no firewall rule is allocated for this policy rule.
A value other than 0 refers to the firewall rule
number within the firewall engine."
::= { midcomResourceEntry 10 }
midcomRscFirewallRuleId OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「この政策ルールについてファイアウォールエンジンの割り当てられたファイアウォール規則を示これが反対するします」。 MIDCOM-MIB実装は、この特定の政策ルールのためのファイアウォール規則が使用されているかどうか学ぶためにこの値を読むことができます。 0の値は、ファイアウォール規則が全くこの政策ルールのために割り当てられないことを意味します。 「0以外の値はファイアウォールエンジンの中のファイアウォール規則番号を示します。」 ::= midcomResourceEntry10
-- -- Statistics subtree -- -- The MIDCOM statistics subtree contains a set of managed -- objects providing statistics about the usage of transaction -- objects. --
-- -- 統計下位木----MIDCOM統計下位木は1セットの管理された(トランザクションの用法に関する統計を提供するオブジェクト)オブジェクトを含んでいます。 --
midcomStatistics OBJECT IDENTIFIER ::= { midcomMonitoring 2 }
midcomStatisticsオブジェクト識別子:、:= midcomMonitoring2
Quittek, et al. Standards Track [Page 76] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[76ページ]。
midcomCurrentOwners OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of different values for midcomRuleOwner
for all current entries in the midcomRuleTable."
::= { midcomStatistics 1 }
「異なることの数はmidcomRuleOwnerのためにmidcomRuleTableのすべての現在のエントリーに評価する」midcomCurrentOwners OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= midcomStatistics1
midcomTotalRejectedRuleEntries OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of failed attempts to create an entry
in the midcomRuleTable."
::= { midcomStatistics 2 }
midcomTotalRejectedRuleEntries OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「失敗されることの総数は、midcomRuleTableでエントリーを作成するのを試みます」。 ::= midcomStatistics2
midcomCurrentRulesIncomplete OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current number of policy rules that are incomplete.
midcomCurrentRulesIncomplete OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「不完全な政策ルールの最新号。」
Policy rules are loaded via row entries in the
midcomRuleTable. This object counts policy rules that are
loaded but not fully specified, i.e., they are in state
newEntry(1) or setting(2)."
::= { midcomStatistics 3 }
政策ルールはmidcomRuleTableの行エントリーを通ってロードされます。 「このオブジェクトがロードされますが、完全に指定されるというわけではない政策ルールを数えて、すなわち、州のnewEntry(1)にあるか、または(2)を設定しています。」 ::= midcomStatistics3
midcomTotalIncorrectReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy reserve rules that failed
parameter check and entered state incorrectRequest(4)."
::= { midcomStatistics 4 }
midcomTotalIncorrectReserveRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「パラメタチェックに失敗して、入った責任準備金規則の総数はincorrectRequest(4)を述べます」。 ::= midcomStatistics4
midcomTotalRejectedReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy reserve rules that failed
while being processed and entered state requestRejected(6)."
::= { midcomStatistics 5 }
「責任準備金の総数は処理されて入られた州のrequestRejected(6)である間にそんなに失敗されていると裁決する」midcomTotalRejectedReserveRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= midcomStatistics5
Quittek, et al. Standards Track [Page 77] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[77ページ]。
midcomCurrentActiveReserveRules OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of currently active policy reserve rules."
::= { midcomStatistics 6 }
「現在の活発な責任準備金の数は統治する」midcomCurrentActiveReserveRules OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= midcomStatistics6
midcomTotalExpiredReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of expired policy reserve rules
(entered termination state timedOut(9))."
::= { midcomStatistics 7 }
midcomTotalExpiredReserveRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「満期の責任準備金の総数が統治される、(終了州のtimedOut(9))に入る、」 ::= midcomStatistics7
midcomTotalTerminatedOnRqReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy reserve rules that were
terminated on request (entered termination state
terminatedOnRequest(10))."
::= { midcomStatistics 8 }
midcomTotalTerminatedOnRqReserveRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「責任準備金の総数が、それが要求に応じて終えられたと裁決する、(終了州のterminatedOnRequest(10))に入る、」 ::= midcomStatistics8
midcomTotalTerminatedReserveRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy reserve rules that were
terminated, but not on request (entered termination state
terminated(11))."
::= { midcomStatistics 9 }
midcomTotalTerminatedReserveRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「責任準備金の総数がそれが終えられたと裁決しますが、要求に応じて裁決するというわけではない、(入られた終了州が(11))を終えた、」 ::= midcomStatistics9
midcomTotalIncorrectEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy enable rules that failed
parameter check and entered state incorrectRequest(4)."
::= { midcomStatistics 10 }
midcomTotalIncorrectEnableRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「方針の総数は規則のその失敗したパラメタチェックと入られた州のincorrectRequest(4)を有効にします」。 ::= midcomStatistics10
midcomTotalRejectedEnableRules OBJECT-TYPE
SYNTAX Counter32
midcomTotalRejectedEnableRulesオブジェクト・タイプ構文Counter32
Quittek, et al. Standards Track [Page 78] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[78ページ]。
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy enable rules that failed
while being processed and entered state requestRejected(6)."
::= { midcomStatistics 11 }
midcomCurrentActiveEnableRules OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of currently active policy enable rules."
::= { midcomStatistics 12 }
マックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「方針の総数は処理されている間、失敗して、州のrequestRejected(6)に入った規則を可能にします」。 ::= midcomStatistics11のmidcomCurrentActiveEnableRules OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「現在アクティブな方針の数は規則を可能にします」。 ::= midcomStatistics12
midcomTotalExpiredEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of expired policy enable rules
(entered termination state timedOut(9))."
::= { midcomStatistics 13 }
midcomTotalExpiredEnableRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「満期の方針の総数が規則を可能にする、(終了州のtimedOut(9))に入る、」 ::= midcomStatistics13
midcomTotalTerminatedOnRqEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy enable rules that were
terminated on request (entered termination state
terminatedOnRequest(10))."
::= { midcomStatistics 14 }
midcomTotalTerminatedOnRqEnableRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「方針の総数が要求に応じて終えられた規則を可能にする、(終了州のterminatedOnRequest(10))に入る、」 ::= midcomStatistics14
midcomTotalTerminatedEnableRules OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of policy enable rules that were
terminated, but not on request (entered termination state
terminated(11))."
::= { midcomStatistics 15 }
midcomTotalTerminatedEnableRules OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「方針の総数が終えられた規則を可能にしますが、要求に応じて可能にするというわけではない、(入られた終了州が(11))を終えた、」 ::= midcomStatistics15
-- -- Notifications. --
-- -- 通知。 --
midcomUnsolicitedRuleEvent NOTIFICATION-TYPE
midcomUnsolicitedRuleEvent通知タイプ
Quittek, et al. Standards Track [Page 79] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[79ページ]。
OBJECTS { midcomRuleOperStatus, midcomRuleLifetime }
STATUS current
DESCRIPTION
"This notification is generated whenever the value of
midcomRuleOperStatus enters any error state or any
termination state without an explicit trigger by a
MIDCOM client."
::= { midcomNotifications 1 }
OBJECTS、midcomRuleOperStatus、midcomRuleLifetime、「midcomRuleOperStatusの値がどんな誤り状態にも入るときはいつも、生成されたこの通知かどんな終了もMIDCOMクライアントで明白な引き金なしで述べる」STATUSの現在の記述。 ::= midcomNotifications1
midcomSolicitedRuleEvent NOTIFICATION-TYPE
OBJECTS { midcomRuleOperStatus, midcomRuleLifetime }
STATUS current
DESCRIPTION
"This notification is generated whenever the value
of midcomRuleOperStatus enters one of the states
{reserved, enabled, any error state, any termination state}
as a result of a MIDCOM agent writing successfully to
object midcomRuleAdminStatus.
midcomSolicitedRuleEvent NOTIFICATION-TYPE OBJECTS、midcomRuleOperStatus、midcomRuleLifetime、STATUSの現在の記述、「可能にされて、midcomRuleOperStatusの値が州の1つに入るときはいつも、生成されたこの通知はa MIDCOMエージェント書くことの結果、首尾よくどんな誤り状態、オブジェクトmidcomRuleAdminStatusへのどんな終了状態も予約しました」。
In addition, it is generated when the lifetime of
a rule was changed by successfully writing to object
midcomRuleLifetime."
::= { midcomNotifications 2 }
「首尾よくオブジェクトmidcomRuleLifetimeに書くことによって規則の生涯を変えたとき、さらに、それは発生しています。」 ::= midcomNotifications2
midcomSolicitedGroupEvent NOTIFICATION-TYPE
OBJECTS { midcomGroupLifetime }
STATUS current
DESCRIPTION
"This notification is generated for indicating that the
lifetime of all member rules of the group was changed by
successfully writing to object midcomGroupLifetime.
midcomSolicitedGroupEvent NOTIFICATION-TYPE OBJECTS midcomGroupLifetime、「この通知はグループのすべてのメンバー規則の寿命が首尾よくオブジェクトmidcomGroupLifetimeに書くことによって変えられたのを示すために生成される」STATUSの現在の記述。
Note that this notification is only sent if the lifetime
of a group was changed by successfully writing to object
midcomGroupLifetime. No notification is sent
- if a group's lifetime is changed by writing to object
midcomRuleLifetime of any of its member policies,
- if a group's lifetime expires (in this case,
notifications are sent for all member policies), or
- if the group is terminated by terminating the last
of its member policies without writing to object
midcomGroupLifetime."
::= { midcomNotifications 3 }
首尾よくオブジェクトmidcomGroupLifetimeに書くことによってグループの生涯を変えた場合にだけこの通知を送ることに注意してください。 または、「グループの寿命が期限が切れるなら(この場合、すべてのメンバー方針のために通知を送ります)メンバー方針のどれかのオブジェクトmidcomRuleLifetimeに書くことによってグループの生涯を変えるなら通知を全く送らない、グループがオブジェクトmidcomGroupLifetimeに書かないでメンバー方針の最終を終えることによって終えられる、」 ::= midcomNotifications3
-- -- Conformance information --
-- -- 順応情報--
Quittek, et al. Standards Track [Page 80] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[80ページ]。
midcomCompliances OBJECT IDENTIFIER ::= { midcomConformance 1 }
midcomGroups OBJECT IDENTIFIER ::= { midcomConformance 2 }
midcomCompliancesオブジェクト識別子:、:= midcomConformance1midcomGroupsオブジェクト識別子:、:= midcomConformance2
-- -- compliance statements --
-- -- 承諾声明--
-- This is the MIDCOM compliance definition ...
-- これはMIDCOM承諾定義です…
--
--
midcomCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for implementations of the
MIDCOM-MIB module.
midcomCompliance MODULE-COMPLIANCE STATUSの現在の記述、「MIDCOM-MIBモジュールの実装のための承諾声明。」
Note that compliance with this compliance
statement requires compliance with the
ifCompliance3 MODULE-COMPLIANCE statement of the
IF-MIB [RFC2863]."
MODULE -- this module
MANDATORY-GROUPS {
midcomRuleGroup,
midcomNotificationsGroup,
midcomCapabilitiesGroup,
midcomStatisticsGroup
}
GROUP midcomConfigFirewallGroup
DESCRIPTION
"A compliant implementation does not have to implement
the midcomConfigFirewallGroup."
GROUP midcomResourceGroup
DESCRIPTION
"A compliant implementation does not have to implement
the midcomResourceGroup."
OBJECT midcomRuleInternalIpPrefixLength
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. When write access is
not supported, return 128 as the value of this object.
A value of 128 means that the function represented by
this option is not supported."
OBJECT midcomRuleExternalIpPrefixLength
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. When write access is
not supported, return 128 as the value of this object.
「この承諾声明へのその承諾がifCompliance3 MODULE-COMPLIANCE声明への承諾に要求することに注意してください、-、MIB、[RFC2863]、」 MODULE--、このモジュールMANDATORY-GROUPS、midcomRuleGroup、midcomNotificationsGroup、midcomCapabilitiesGroup、midcomStatisticsGroup、「対応する実装はmidcomConfigFirewallGroupを実装するために持っていない」GROUP midcomConfigFirewallGroup記述。 「対応する実装はmidcomResourceGroupを実装するために持っていない」GROUP midcomResourceGroup記述。 OBJECT midcomRuleInternalIpPrefixLength MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 いつを書くか。アクセスはサポートされないで、このオブジェクトの値として128を返してください。 「128の値は、このオプションで表された機能がサポートされないことを意味します。」 OBJECT midcomRuleExternalIpPrefixLength MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 いつを書くか。アクセスはサポートされないで、このオブジェクトの値として128を返してください。
Quittek, et al. Standards Track [Page 81] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[81ページ]。
A value of 128 means that the function represented by
this option is not supported."
OBJECT midcomRuleMaxIdleTime
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. When write access is
not supported, return 0 as the value of this object.
A value of 0 means that the function represented by
this option is not supported."
OBJECT midcomRuleInterface
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigMaxLifetime
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigPersistentRules
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigIfEnabled
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigFirewallGroupId
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT midcomConfigFirewallPriority
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { midcomCompliances 1 }
「128の値は、このオプションで表された機能がサポートされないことを意味します。」 OBJECT midcomRuleMaxIdleTime MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 いつを書くか。アクセスはサポートされないで、このオブジェクトの値として0を返してください。 「0の値は、このオプションで表された機能がサポートされないことを意味します。」 OBJECT midcomRuleInterface MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 OBJECT midcomConfigMaxLifetime MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 OBJECT midcomConfigPersistentRules MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 OBJECT midcomConfigIfEnabled MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 OBJECT midcomConfigFirewallGroupId MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 OBJECT midcomConfigFirewallPriority MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 ::= midcomCompliances1
midcomRuleGroup OBJECT-GROUP
OBJECTS {
midcomRuleAdminStatus,
midcomRuleOperStatus,
midcomRuleStorageType,
midcomRuleStorageTime,
midcomRuleError,
midcomRuleInterface,
midcomRuleFlowDirection,
midcomRuleMaxIdleTime,
midcomRuleTransportProtocol,
midcomRulePortRange,
midcomRuleInternalIpVersion,
midcomRuleGroupオブジェクト群対象、midcomRuleAdminStatus、midcomRuleOperStatus、midcomRuleStorageType、midcomRuleStorageTime、midcomRuleError、midcomRuleInterface、midcomRuleFlowDirection、midcomRuleMaxIdleTime、midcomRuleTransportProtocol、midcomRulePortRange、midcomRuleInternalIpVersion
Quittek, et al. Standards Track [Page 82] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[82ページ]。
midcomRuleExternalIpVersion,
midcomRuleInternalIpAddr,
midcomRuleInternalIpPrefixLength,
midcomRuleInternalPort,
midcomRuleExternalIpAddr,
midcomRuleExternalIpPrefixLength,
midcomRuleExternalPort,
midcomRuleInsideIpAddr,
midcomRuleInsidePort,
midcomRuleOutsideIpAddr,
midcomRuleOutsidePort,
midcomRuleLifetime,
midcomRuleRowStatus,
midcomGroupLifetime
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
policy rules and policy rule groups."
::= { midcomGroups 1 }
midcomRuleExternalIpVersion、midcomRuleInternalIpAddr、midcomRuleInternalIpPrefixLength、midcomRuleInternalPort、midcomRuleExternalIpAddr、midcomRuleExternalIpPrefixLength、midcomRuleExternalPort、midcomRuleInsideIpAddr、midcomRuleInsidePort、midcomRuleOutsideIpAddr、midcomRuleOutsidePort、midcomRuleLifetime、midcomRuleRowStatus、midcomGroupLifetime 「オブジェクトが方針の情報を提供する収集は統治して、政策ルールは分類する」STATUSの現在の記述。 ::= midcomGroups1
midcomCapabilitiesGroup OBJECT-GROUP
OBJECTS {
midcomConfigMaxLifetime,
midcomConfigPersistentRules,
midcomConfigIfBits,
midcomConfigIfEnabled
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
the capabilities of a middlebox."
::= { midcomGroups 2 }
midcomCapabilitiesGroup OBJECT-GROUP OBJECTS、midcomConfigMaxLifetime、midcomConfigPersistentRules、midcomConfigIfBits、midcomConfigIfEnabled、STATUSの現在の記述、「middleboxの能力の情報を提供するオブジェクトの収集。」 ::= midcomGroups2
midcomConfigFirewallGroup OBJECT-GROUP
OBJECTS {
midcomConfigFirewallGroupId,
midcomConfigFirewallPriority
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
the firewall rule group and firewall rule priority to
be used by firewalls loaded through MIDCOM."
::= { midcomGroups 3 }
midcomConfigFirewallGroup OBJECT-GROUP OBJECTS、midcomConfigFirewallGroupId、midcomConfigFirewallPriority、STATUSの現在の記述、「ファイアウォールによって使用されるためにファイアウォール規則グループとファイアウォール規則優先権の情報を提供するオブジェクトの収集はMIDCOMを通してロードしました」。 ::= midcomGroups3
midcomResourceGroup OBJECT-GROUP
OBJECTS {
midcomResourceGroupオブジェクト群対象
Quittek, et al. Standards Track [Page 83] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[83ページ]。
midcomRscNatInternalAddrBindMode,
midcomRscNatInternalAddrBindId,
midcomRscNatInsideAddrBindMode,
midcomRscNatInsideAddrBindId,
midcomRscNatSessionId1,
midcomRscNatSessionId2,
midcomRscFirewallRuleId
}
STATUS current
DESCRIPTION
"A collection of objects providing information about
the used NAT and firewall resources."
::= { midcomGroups 4 }
midcomRscNatInternalAddrBindMode、midcomRscNatInternalAddrBindId、midcomRscNatInsideAddrBindMode、midcomRscNatInsideAddrBindId、midcomRscNatSessionId1、midcomRscNatSessionId2、midcomRscFirewallRuleId STATUSの現在の記述、「中古のNATとファイアウォールリソースの情報を提供するオブジェクトの収集。」 ::= midcomGroups4
midcomStatisticsGroup OBJECT-GROUP
OBJECTS {
midcomCurrentOwners,
midcomTotalRejectedRuleEntries,
midcomCurrentRulesIncomplete,
midcomTotalIncorrectReserveRules,
midcomTotalRejectedReserveRules,
midcomCurrentActiveReserveRules,
midcomTotalExpiredReserveRules,
midcomTotalTerminatedOnRqReserveRules,
midcomTotalTerminatedReserveRules,
midcomTotalIncorrectEnableRules,
midcomTotalRejectedEnableRules,
midcomCurrentActiveEnableRules,
midcomTotalExpiredEnableRules,
midcomTotalTerminatedOnRqEnableRules,
midcomTotalTerminatedEnableRules
}
STATUS current
DESCRIPTION
"A collection of objects providing statistical
information about the MIDCOM server."
::= { midcomGroups 5 }
midcomStatisticsGroupオブジェクト群対象; midcomCurrentOwners、midcomTotalRejectedRuleEntries、midcomCurrentRulesIncomplete、midcomTotalIncorrectReserveRules、midcomTotalRejectedReserveRules、midcomCurrentActiveReserveRules、midcomTotalExpiredReserveRules、midcomTotalTerminatedOnRqReserveRules、midcomTotalTerminatedReserveRules、midcomTotalIncorrectEnableRules、midcomTotalRejectedEnableRules、midcomCurrentActiveEnableRules、midcomTotalExpiredEnableRules、midcomTotalTerminatedOnRqEnableRules、midcomTotalTerminatedEnableRules; STATUSの現在の記述、「MIDCOMサーバに関する統計情報を提供するオブジェクトの収集」、:; := midcomGroups5
Quittek, et al. Standards Track [Page 84] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[84ページ]。
midcomNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
midcomUnsolicitedRuleEvent,
midcomSolicitedRuleEvent,
midcomSolicitedGroupEvent
}
STATUS current
DESCRIPTION
"The notifications emitted by the midcomMIB."
::= { midcomGroups 6 }
midcomNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS、midcomUnsolicitedRuleEvent、midcomSolicitedRuleEvent、midcomSolicitedGroupEvent、「通知はmidcomMIBで放った」STATUSの現在の記述。 ::= midcomGroups6
END
終わり
10. Security Considerations
10. セキュリティ問題
Obviously, securing access to firewall and NAT configuration is extremely important for maintaining network security. This section first describes general security issues of the MIDCOM-MIB module and then discusses three concrete security threats: unauthorized middlebox configuration, unauthorized access to middlebox configuration information, and unauthorized access to the MIDCOM service configuration.
明らかに、ネットワークセキュリティを維持するには、ファイアウォールとNAT構成へのアクセスを保証するのは非常に重要です。 このセクションは、最初に、MIDCOM-MIBモジュールの総合証券問題について説明して、次に、3つの具体的な軍事的脅威について論じます: 権限のないmiddlebox構成、middlebox設定情報への不正アクセス、およびMIDCOMへの不正アクセスは構成を修理します。
10.1. General Security Issues
10.1. 総合証券問題
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. But also access to managed objects with a MAX-ACCESS clause of read-only may be considered sensitive or vulnerable. The support for SET and GET operations in a non-secure environment without proper protection can have a negative effect on network operations.
aがあります。読書して書くことのマックス-ACCESS節でこのMIBモジュールで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 しかし、また、書き込み禁止のマックス-ACCESS節がある管理オブジェクトへのアクセスは敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSETのサポートとGET操作はネットワーク操作のときにマイナスの影響がある場合があります。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3の前のSNMPバージョンは十分な安全性を含んでいませんでした。 ネットワーク自体が安全であっても(例えば、IPsecを使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこのMIBモジュールでだれに許容されているかに関してコントロールが全くありません。
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.
SNMPv3の前のSNMPバージョンの展開はNOT RECOMMENDEDです。
Compliant MIDCOM-MIB implementations MUST support SNMPv3 security services including data integrity, identity authentication, data confidentiality, and replay protection.
対応するMIDCOM-MIB実装は、SNMPv3セキュリティがデータ保全、アイデンティティ認証、データの機密性、および反復操作による保護を含むサービスであるとサポートしなければなりません。
Quittek, et al. Standards Track [Page 85] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[85ページ]。
It is REQUIRED that the implementations support the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 3414 [RFC3414] and the View-based Access Control Model RFC 3415 [RFC3415] is RECOMMENDED.
実装が、SNMPv3フレームワークで提供するようにセキュリティが特徴であるとサポートするのは、REQUIREDです。 明確に、UserベースのSecurity Model RFC3414[RFC3414]とViewベースのAccess Control Model RFC3415[RFC3415]の使用はRECOMMENDEDです。
It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
そして、このMIBのインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
To facilitate the provisioning of access control by a security administrator using the View-based Access Control Model (VACM) defined in RFC 3415 [RFC3415] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". This is supported by the midcomRuleTable and the midcomGroupTable. Each of them uses midcomRuleOwner as the initial index. midcomRuleOwner has the syntax of SnmpAdminString, and can thus be trivially mapped to an SNMP securityName or a groupName as defined in VACM, in accordance with a security policy.
複数のユーザが独自にエントリーを作成するか、または変更する必要があるかもしれないテーブルのためにRFC3415[RFC3415]で定義されたViewベースのAccess Control Model(VACM)を使用することでセキュリティ管理者によるアクセスコントロールの食糧を供給することを容易にするために、初期のインデックスは「所有者インデックス」として使用されます。 これはmidcomRuleTableとmidcomGroupTableによってサポートされます。 それぞれの彼らは初期のインデックスとしてmidcomRuleOwnerを使用します。midcomRuleOwnerはSnmpAdminStringの構文を持って、その結果、VACMで定義されるようにSNMP securityNameかgroupNameに些細なことに写像できます、安全保障政策によると。
All entries in the two mentioned tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible.
2におけるすべてのエントリーが、特定のユーザのものであるテーブルがこの初期のインデックスのための同じ値を持つと言及しました。 特定のテーブルの与えられたユーザのエントリーに、これらのエントリーにおける情報のためのオブジェクト識別子は同じ「副-識別子」(「コラム」「副-識別子」を除いた)をコード化された所有者インデックスの終わりまで持つでしょう。 テーブルのこの一部へのアクセスを可能にするためにVACMを構成するために、1つはvacmViewTreeFamilySubtreeの値が所有者インデックス部分を含んでいて、vacmViewTreeFamilyMaskがコラム「副-識別子」を"wildcardingする"であるvacmViewTreeFamilyTableエントリーを作成するでしょう。 より入念な構成は可能です。
10.2. Unauthorized Middlebox Configuration
10.2. 権限のないMiddlebox構成
The most dangerous threat to network security related to the MIDCOM- MIB module is unauthorized access to facilities for establishing policy rules. In such a case, unauthorized principals would write to the midcomRuleTable for opening firewall pinholes and/or for creating NAT maps, bindings, and/or sessions. Establishing policies can be used to gain access to networks and systems that are protected by firewalls and/or NATs.
MIDCOM- MIBモジュールに関連するセキュリティをネットワークでつなぐ最も危険な脅威は制定方針規則のための施設への不正アクセスです。 ケース、権限のない主体がそうするそのようなものでは、初めのファイアウォールピンホールNAT地図、結合、そして/または、セッションを作成するためにmidcomRuleTableに書いてください。 ファイアウォール、そして/または、NATsによって保護されるネットワークとシステムへのアクセスを得るのに制定方針を使用できます。
If this protection is removed by unauthorized access to MIDCOM-MIB policies, then the resulting degradation of network security can be severe. Confidential information protected by a firewall might become accessible to unauthorized principals, attacks exploiting
MIDCOM-MIB方針への不正アクセスでこの保護を取り除くなら、ネットワークセキュリティの結果として起こる退行は厳しい場合があります。 ファイアウォールによって保護された秘密情報は権限のない主体にアクセスしやすくなるかもしれなくて、攻撃は利用です。
Quittek, et al. Standards Track [Page 86] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[86ページ]。
security leaks of systems in the protected network might become possible from external networks, and it might be possible to stop firewalls blocking denial-of-service attacks.
保護されたネットワークのシステムの安全保障機密の漏洩は外部のネットワークから可能になるかもしれません、そして、ファイアウォールがサービス不能攻撃を妨げるのを止めるのは可能であるかもしれません。
MIDCOM-MIB implementations MUST provide means for strict authentication, message integrity check, and write access control to managed objects that can be used for establishing policy rules. These are objects in the midcomRuleTable and midcomGroupTable with a MAX-ACCESS clause of read-write and/or read-create.
MIDCOM-MIB実装は、厳しい認証のための手段、メッセージの保全チェックを提供して、制定方針規則に使用できる管理オブジェクトにアクセスコントロールを書かなければなりません。 そして/または、これらが読書して書くことのマックス-ACCESS節があるmidcomRuleTableとmidcomGroupTableのオブジェクトである、読書して作成します。
Particularly sensitive is write access to the managed object midcomRuleAdminStatus, because writing it causes policy rules to be established.
特に敏感であるのは、それを書くのが政策ルールを確立させるので管理オブジェクトmidcomRuleAdminStatusへのアクセスを書くことです。
Also, writing to other managed objects in the two tables can make security vulnerable if it interferes with the authorized establishment of a policy rule, for example, by wildcarding a policy rule after the corresponding entry in the midcomRuleTable is created, but before the authorized owner establishes the rule by writing to midcomRuleAdminStatus.
また、2個のテーブルの他の管理オブジェクトに書くのに、例えば、midcomRuleTableの対応するエントリーが作成された後にもかかわらず、認可された所有者がmidcomRuleAdminStatusに書くことによって規則を確立する前を除いて、政策ルールをwildcardingすることによって政策ルールの認可された確立を妨げるなら、セキュリティは被害を受け易くなる場合があります。
Not only unauthorized establishment, but also unauthorized lifetime extension of an existing policy rule may be considered sensitive or vulnerable in some network environments. Therefore, means for strict authentication, message integrity check, and write access control to managed object midcomGroupLifetime MUST be provided by MIDCOM-MIB implementations.
権限のない設立だけではなく、既存の政策ルールの権限のない生涯拡大もいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 したがって、MIDCOM-MIB実装で提供しなければなりません厳しい認証、メッセージの保全のための手段が、管理オブジェクトmidcomGroupLifetimeへのアクセスコントロールをチェックして、書く。
10.3. Unauthorized Access to Middlebox Configuration
10.3. Middlebox構成への不正アクセス
Another threat to network security is unauthorized access to entries in the midcomRuleTable. The entries contain information about existing pinholes in the firewall and/or about the current NAT configuration. This information can be used for attacking the internal network from outside. Therefore, a MIDCOM-MIB implementation MUST also provide means for read access control to the midcomRuleTable.
セキュリティをネットワークでつなぐ別の脅威はmidcomRuleTableのエントリーへの不正アクセスです。 エントリーはファイアウォールの既存のピンホール現在のNAT構成の情報を含んでいます。 外部から内部のネットワークを攻撃するのにこの情報を使用できます。 したがって、また、読まれて、アクセスがmidcomRuleTableに制御されるので、MIDCOM-MIB実装は手段を提供しなければなりません。
Also, a MIDCOM-MIB implementation SHOULD provide means for protecting different authenticated MIDCOM agents from each other, such that, for example, an authenticated user can only read entries in the midcomRuleTable for which the initial index midcomRuleOwner matches the client's SNMP securityName or VACM groupName.
また、SHOULDが提供するMIDCOM-MIB実装は異なった認証されたMIDCOMを保護するために互いからエージェントを意味します、例えば、認証されたユーザが初期のインデックスmidcomRuleOwnerがクライアントのSNMP securityNameかVACM groupNameに合っているmidcomRuleTableでエントリーを読むことができるだけであるように。
Quittek, et al. Standards Track [Page 87] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[87ページ]。
10.4. Unauthorized Access to MIDCOM Service Configuration
10.4. MIDCOMサービス構成への不正アクセス
There are three objects with a MAX-ACCESS clause of read-write that configure the MIDCOM service: midcomConfigIfEnabled, midcomFirewallGroupId, and midcomFirewallPriority.
読書して書くことのマックス-ACCESS節があるMIDCOMサービスを構成する3個のオブジェクトがあります: midcomConfigIfEnabled、midcomFirewallGroupId、およびmidcomFirewallPriority。
Unauthorized writing to object midcomConfigIfEnabled can cause serious interruptions of network service.
オブジェクトmidcomConfigIfEnabledへの権限のない書くことはネットワーク・サービスの重大な中断を引き起こす場合があります。
Writing to midcomFirewallGroupId and/or midcomFirewallPriority can be used to increase or reduce the priority of firewall rules that are generated when a policy rule is established in the midcomRuleTable. Increasing the priority might permit firewall rules generated via the MIDCOM-MIB module to overrule basic security rules at the firewall that should have higher priority than the ones generated via the MIDCOM-MIB module.
政策ルールがmidcomRuleTableに確立されるとき発生しているファイアウォール規則の優先権を増強するか、または低下させるのにmidcomFirewallGroupId、そして/または、midcomFirewallPriorityに書くのを使用できます。 優先権を増強するのは、MIDCOM-MIBモジュールで生成されたファイアウォール規則がMIDCOM-MIBモジュールでものより高い優先度を生成するはずであるファイアウォールで基本的なセキュリティ規則を却下することを許可するかもしれません。
Therefore, also for these objects, means for strict control of write access MUST be provided by a MIDCOM-MIB implementation.
アクセスを書いてください。したがってこれらのオブジェクト、厳重な管理のための手段、もMIDCOM-MIB実装は提供しなければなりません。
11. Acknowledgements
11. 承認
This memo is based on a long history of discussion within the MIDCOM MIB design team. Many thanks to Mary Barnes, Jeff Case, Wes Hardaker, David Harrington, and Tom Taylor for fruitful comments and recommendations and to Juergen Schoenwaelder acting as a very constructive MIB doctor.
このメモはMIDCOM MIBデザインチームの中で議論の長い歴史に基づいています。 実り多いコメントと推薦のためのメアリ・バーンズ、ジェフCase、ウェスHardaker、デヴィッド・ハリントン、およびトム・テイラーと、そして、非常に建設的なMIB医師として務めるユルゲンSchoenwaelderをありがとうございます。
12. IANA Considerations
12. IANA問題
IANA has assigned an OID for the MIB module in this document:
IANAはMIBモジュールのために本書ではOIDを割り当てました:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
midcomMIB { mib-2 171 }
記述子OBJECT IDENTIFIER価値---------- ----------------------- midcomMIBmib-2 171
13. Normative References
13. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC5189] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
Communication (MIDCOM) Protocol Semantics", RFC 5189,
March 2008.
[RFC5189] Stiemerling、M.、Quittek、J.、およびT.テイラー、「Middleboxコミュニケーション(MIDCOM)プロトコル意味論」、RFC5189、2008年3月。
Quittek, et al. Standards Track [Page 88] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[88ページ]。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3411] ハリントンとD.とPresuhnとR.とB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理枠組みについて説明するための構造」、STD62、RFC3411、2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol Applications", STD 62, RFC 3413,
December 2002.
[RFC3413] レビとD.とマイヤー、P.とB.スチュワート、「簡単なネットワーク管理プロトコルアプリケーション」、STD62、RFC3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、STD62、RFC3414、2002年12月。
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
[RFC3418]Presuhn、R.(エド)、「簡単なネットワークマネージメントのための管理情報ベース(MIB)は(SNMP)について議定書の中で述べます」、STD62、RFC3418、2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
[RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and
C. Wang, "Definitions of Managed Objects for Network
Address Translators (NAT)", RFC 4008, March 2005.
[RFC4008] Rohit、R.、Srisuresh、P.、Raghunarayan、R.、パイ、N.、およびC.ワング、「ネットワークのための管理オブジェクトの定義は翻訳者(NAT)に演説します」、RFC4008、2005年3月。
Quittek, et al. Standards Track [Page 89] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[89ページ]。
14. Informative References
14. 有益な参照
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケースとJ.とマンディとR.とパーテイン、D.とB.スチュワート、「インターネットの標準の管理枠組みのための序論と適用性声明」RFC3410(2002年12月)。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3234]大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月2002日
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
そして、[RFC3303]Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリトル、A.、A.Rayhanと、「Middlebox通信アーキテクチャと枠組み」、RFC3303(2002年8月)
[RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (midcom) Protocol Requirements",
RFC 3304, August 2002.
[RFC3304]低湿地、R.、市場、P.、Sijben、P.、縁、S.、およびM.は、「Middleboxコミュニケーション(midcom)プロトコル要件」と支えます、RFC3304、2002年8月。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
[RFC3415] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス管理モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、2002年12月。
Quittek, et al. Standards Track [Page 90] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[90ページ]。
Authors' Addresses
作者のアドレス
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
ユルゲンQuittek NECヨーロッパLtd.Kurfuersten-原基36 69115ハイデルベルグドイツ
Phone: +49 6221 4342-115 EMail: quittek@nw.neclab.eu
以下に電話をしてください。 +49 6221 4342-115 メールしてください: quittek@nw.neclab.eu
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
マーチンStiemerling NECヨーロッパLtd.Kurfuersten-原基36 69115ハイデルベルグドイツ
Phone: +49 6221 4342-113 EMail: stiemerling@nw.neclab.eu
以下に電話をしてください。 +49 6221 4342-113 メールしてください: stiemerling@nw.neclab.eu
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 U.S.A.
Pyda Srisuresh KazeonシステムInc.1161サンアントニオ、通り マウンテンビュー、カリフォルニア94043米国
Phone: +1 408 836 4773 EMail: srisuresh@yahoo.com
以下に電話をしてください。 +1 4773年の408 836メール: srisuresh@yahoo.com
Quittek, et al. Standards Track [Page 91] RFC 5190 MIDCOM MIB March 2008
Quittek、他 規格は2008年のMIDCOM MIB行進のときにRFC5190を追跡します[91ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Quittek, et al. Standards Track [Page 92]
Quittek、他 標準化過程[92ページ]
一覧
スポンサーリンク
