RFC3415 日本語訳
3415 View-based Access Control Model (VACM) for the Simple NetworkManagement Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. December 2002. (Format: TXT=82046 bytes) (Obsoletes RFC2575) (Also STD0062) (Status: STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Wijnen
Request for Comments: 3415 Lucent Technologies
STD: 62 R. Presuhn
Obsoletes: 2575 BMC Software, Inc.
Category: Standards Track K. McCloghrie
Cisco Systems, Inc.
December 2002
Wijnenがコメントのために要求するワーキンググループB.をネットワークでつないでください: 3415ルーセントテクノロジーズSTD: 62 R.Presuhnは以下を時代遅れにします。 2575年のBMCソフトウェアInc.カテゴリ: 標準化過程K.McCloghrieシスコシステムズInc.2002年12月
View-based Access Control Model (VACM) for the
Simple Network Management Protocol (SNMP)
簡単なネットワーク管理プロトコルのための視点ベースのアクセス制御モデル(VACM)(SNMP)
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View-based Access Control Model. This document obsoletes RFC 2575.
このドキュメントはSimple Network Managementプロトコル(SNMP)アーキテクチャにおける使用のために、ViewベースのAccess Control Model(VACM)について説明します。 それは、経営情報へのアクセスを制御するためにProcedureのElementsを定義します。 また、このドキュメントはViewベースのAccess Control Modelのための設定パラメータを離れて管理するためのManagement Information基地(MIB)を含んでいます。 このドキュメントはRFC2575を時代遅れにします。
Wijnen, et al. Standards Track [Page 1] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ................................................. 2 1.2. Access Control ............................................. 3 1.3. Local Configuration Datastore .............................. 3 2. Elements of the Model ........................................ 4 2.1. Groups ..................................................... 4 2.2. securityLevel .............................................. 4 2.3. Contexts ................................................... 4 2.4. MIB Views and View Families ................................ 5 2.4.1. View Subtree ............................................. 5 2.4.2. ViewTreeFamily ........................................... 6 2.5. Access Policy .............................................. 6 3. Elements of Procedure ........................................ 7 3.1. Overview of isAccessAllowed Process ....................... 8 3.2. Processing the isAccessAllowed Service Request ............. 9 4. Definitions .................................................. 11 5. Intellectual Property ........................................ 28 6. Acknowledgements ............................................. 28 7. Security Considerations ...................................... 30 7.1. Recommended Practices ...................................... 30 7.2. Defining Groups ............................................ 30 7.3. Conformance ................................................ 31 7.4. Access to the SNMP-VIEW-BASED-ACM-MIB ...................... 31 8. References ................................................... 31 A. Installation ................................................. 33 B. Change Log ................................................... 36 Editors' Addresses ............................................... 38 Full Copyright Statement ......................................... 39
1. 序論… 2 1.2. コントロールにアクセスしてください… 3 1.3. 地方の構成Datastore… 3 2. モデルのElements… 4 2.1. グループ… 4 2.2securityLevel… 4 2.3. 文脈… 4 2.4. MIB視点と視点ファミリー… 5 2.4.1. 下位木を見てください… 5 2.4.2. ViewTreeFamily… 6 2.5. 方針にアクセスしてください… 6 3. 手順のElements… 7 3.1. isAccessAllowedプロセスの概要… 8 3.2. isAccessAllowedを処理して、要求を修理してください… 9 4. 定義… 11 5. 知的所有権… 28 6. 承認… 28 7. セキュリティ問題… 30 7.1. お勧めの習慣… 30 7.2. 定義は分類されます… 30 7.3. 順応… 31 7.4. SNMPの視点ベースのACM-MIBへのアクセス… 31 8. 参照… 31 A.インストール… 33 B. ログを変えてください… 36人のエディタのアドレス… 38 完全な著作権宣言文… 39
1. Introduction
1. 序論
The Architecture for describing Internet Management Frameworks [RFC3411] describes that an SNMP engine is composed of:
インターネットManagement Frameworks[RFC3411]について説明するためのArchitectureは、SNMPエンジンが以下で構成されると説明します。
1) a Dispatcher
2) a Message Processing Subsystem,
3) a Security Subsystem, and
4) an Access Control Subsystem.
1) 発送者2) メッセージ処理サブシステム、3) セキュリティサブシステム、および4) アクセス制御サブシステム。
Applications make use of the services of these subsystems.
アプリケーションはこれらのサブシステムのサービスを利用します。
It is important to understand the SNMP architecture and its terminology to understand where the View-based Access Control Model described in this document fits into the architecture and interacts with other subsystems within the architecture. The reader is expected to have read and understood the description and terminology of the SNMP architecture, as defined in [RFC3411].
SNMPアーキテクチャとその用語が、本書では説明されたViewベースのAccess Control Modelがどこでアーキテクチャに収まって、アーキテクチャの中で他のサブシステムと対話するかを理解しているのを理解しているのは重要です。 読者は、SNMPアーキテクチャの記述と用語を読んで、理解していたと予想されます、[RFC3411]で定義されるように。
Wijnen, et al. Standards Track [Page 2] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[2ページ]。
The Access Control Subsystem of an SNMP engine has the responsibility for checking whether a specific type of access (read, write, notify) to a particular object (instance) is allowed.
SNMPエンジンのAccess Control Subsystemには、特定のオブジェクト(インスタンス)への特定のタイプのアクセス(読んでください、そして、書いてください、そして、通知する)が許されているかどうかチェックすることへの責任があります。
It is the purpose of this document to define a specific model of the Access Control Subsystem, designated the View-based Access Control Model. Note that this is not necessarily the only Access Control Model.
ViewベースのAccess Control Modelに指定されたAccess Control Subsystemの特定のモデルを定義するのは、このドキュメントの目的です。 これが必ず唯一のAccess Control Modelであるというわけではないことに注意してください。
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 BCP 14, RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119)で説明されるように本書では解釈されることであるべきです。
1.2. Access Control
1.2. アクセス制御
Access Control occurs (either implicitly or explicitly) in an SNMP entity when processing SNMP retrieval or modification request messages from an SNMP entity. For example a Command Responder application applies Access Control when processing requests that it received from a Command Generator application. These requests contain Read Class and Write Class PDUs as defined in [RFC3411].
SNMP実体からSNMP検索か変更要求メッセージを処理するとき、アクセスControlはSNMP実体で起こります(それとなくか明らかに)。 Command Generatorアプリケーションから受信したという要求を処理するとき、例えば、Command ResponderアプリケーションはAccess Controlを当てはまります。 これらの要求は[RFC3411]で定義されるようにRead ClassとWrite Class PDUsを含んでいます。
Access Control also occurs in an SNMP entity when an SNMP notification message is generated (by a Notification Originator application). These notification messages contain Notification Class PDUs as defined in [RFC3411].
また、SNMP通知メッセージが発生しているとき(Notification Originatorアプリケーションによる)、アクセスControlはSNMP実体で起こります。 これらの通知メッセージは[RFC3411]で定義されるようにNotification Class PDUsを含んでいます。
The View-based Access Control Model defines a set of services that an application (such as a Command Responder or a Notification Originator application) can use for checking access rights. It is the responsibility of the application to make the proper service calls for access checking.
ViewベースのAccess Control Modelはアプリケーション(Command ResponderかNotification Originatorアプリケーションなどの)がアクセス権をチェックするのに利用できる1セットのサービスを定義します。 アクセスのための適切な業務通話をチェックするようにするのは、アプリケーションの責任です。
1.3. Local Configuration Datastore
1.3. 地方の構成Datastore
To implement the model described in this document, an SNMP entity needs to retain information about access rights and policies. This information is part of the SNMP engine's Local Configuration Datastore (LCD). See [RFC3411] for the definition of LCD.
本書では説明されたモデルを実装するために、SNMP実体は、アクセス権と方針の情報を保有する必要があります。 この情報はSNMPエンジンのLocal Configuration Datastore(LCD)の一部です。 LCDの定義に関して[RFC3411]を見てください。
In order to allow an SNMP entity's LCD to be remotely configured, portions of the LCD need to be accessible as managed objects. A MIB module, the View-based Access Control Model Configuration MIB, which defines these managed object types is included in this document.
SNMP実体のLCDが離れて構成されるのを許容するために、LCDの一部が、管理オブジェクトとしてアクセスしやすい必要があります。 MIBモジュールであり、ViewベースのAccess Control Model Configuration MIBでありどれがこれらの管理オブジェクトタイプを定義するかは本書では含まれています。
Wijnen, et al. Standards Track [Page 3] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[3ページ]。
2. Elements of the Model
2. モデルのElements
This section contains definitions to realize the access control service provided by the View-based Access Control Model.
このセクションはViewベースのAccess Control Modelによって提供されたアクセス制御サービスがわかる定義を含みます。
2.1. Groups
2.1. グループ
A group is a set of zero or more <securityModel, securityName> tuples on whose behalf SNMP management objects can be accessed. A group defines the access rights afforded to all securityNames which belong to that group. The combination of a securityModel and a securityName maps to at most one group. A group is identified by a groupName.
グループは1セットのゼロであるか、より多くの<がsecurityModel(だれの利益SNMP管理オブジェクトにアクセスできるかのsecurityName>tuples)です。 グループはそのグループのものすべてのsecurityNamesに提供されたアクセス権を定義します。 高々1つへの地図が分類するsecurityModelとsecurityNameの組み合わせ。 グループはgroupNameによって特定されます。
The Access Control module assumes that the securityName has already been authenticated as needed and provides no further authentication of its own.
Access Controlモジュールは、securityNameが必要に応じて既に認証されて、それ自身のさらなる認証を全く提供しないと仮定します。
The View-based Access Control Model uses the securityModel and the securityName as inputs to the Access Control module when called to check for access rights. It determines the groupName as a function of securityModel and securityName.
アクセス権のためにチェックするために呼ばれると、ViewベースのAccess Control Modelは入力としてAccess ControlモジュールにsecurityModelとsecurityNameを使用します。 それはsecurityModelとsecurityNameの機能としてgroupNameを決定します。
2.2. securityLevel
2.2. securityLevel
Different access rights for members of a group can be defined for different levels of security, i.e., noAuthNoPriv, authNoPriv, and authPriv. The securityLevel identifies the level of security that will be assumed when checking for access rights. See the SNMP Architecture document [RFC3411] for a definition of securityLevel.
異なったレベルのセキュリティ、すなわち、noAuthNoPriv、authNoPriv、およびauthPrivのためにグループのメンバーのための異なったアクセス権を定義できます。 securityLevelはアクセス権のためにチェックするとき想定されるセキュリティのレベルを特定します。 securityLevelの定義に関してSNMP Architectureドキュメント[RFC3411]を見てください。
The View-based Access Control Model requires that the securityLevel is passed as input to the Access Control module when called to check for access rights.
ViewベースのAccess Control Modelは、securityLevelがアクセス権のためにチェックするために呼ばれるとAccess Controlモジュールに入力されるように渡されるのを必要とします。
2.3. Contexts
2.3. 文脈
An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts. Details about the naming of management information can be found in the SNMP Architecture document [RFC3411].
SNMP文脈はSNMP実体によってアクセス可能な経営情報の収集です。 経営情報の項目は1つ以上の文脈に存在するかもしれません。 SNMP実体は潜在的に多くの文脈に近づく手段を持っています。 SNMP Architectureドキュメント[RFC3411]で経営情報の命名に関する詳細を見つけることができます。
The View-based Access Control Model defines a vacmContextTable that lists the locally available contexts by contextName.
ViewベースのAccess Control ModelはcontextNameで局所的に利用可能な文脈をリストアップするvacmContextTableを定義します。
Wijnen, et al. Standards Track [Page 4] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[4ページ]。
2.4. MIB Views and View Families
2.4. MIB視点と視点ファミリー
For security reasons, it is often valuable to be able to restrict the access rights of some groups to only a subset of the management information in the management domain. To provide this capability, access to a context is via a "MIB view" which details a specific set of managed object types (and optionally, the specific instances of object types) within that context. For example, for a given context, there will typically always be one MIB view which provides access to all management information in that context, and often there will be other MIB views each of which contains some subset of the information. So, the access allowed for a group can be restricted in the desired manner by specifying its rights in terms of the particular (subset) MIB view it can access within each appropriate context.
安全保障上の理由で、管理ドメインでいくつかのグループのアクセス権を経営情報の部分集合だけに制限できるのはしばしば貴重です。 この能力を提供するために、その文脈の中に特定の管理オブジェクトタイプ(任意に、オブジェクトの特定のインスタンスはタイプする)について詳述する「MIB視点」を通して文脈へのアクセスはあります。 例えば、与えられた文脈のために、その文脈にはすべての経営情報へのアクセスを提供する1つのMIB視点が通常いつもあるでしょう、そして、それのそれぞれが情報の何らかの部分集合を含む他のMIB視点がしばしばあるでしょう。 それで、グループのために許されたアクセスは、希望された方法でそれがそれぞれの適切な関係の中でアクセスできる特定の(部分集合)MIB視点に関して権利を指定することによって、制限される場合があります。
Since managed object types (and their instances) are identified via the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO- ASN.1, RFC2578], it is convenient to define a MIB view as the combination of a set of "view subtrees", where each view subtree is a subtree within the managed object naming tree. Thus, a simple MIB view (e.g., all managed objects within the Internet Network Management Framework) can be defined as a single view subtree, while more complicated MIB views (e.g., all information relevant to a particular network interface) can be represented by the union of multiple view subtrees.
管理オブジェクトタイプ(そして、彼らのインスタンス)がISOのOBJECT IDENTIFIERs[ISO- ASN.1、RFC2578]の木のような命名構造で特定されるので、それぞれの視点下位木が管理オブジェクト命名木の中の下位木である1セットの「視点下位木」の組み合わせとしてのMIB視点を定義するのは便利です。 したがって、簡単なMIB意見(インターネットNetwork Management Frameworkの中の例えばすべての管理オブジェクト)をただ一つの視点下位木と定義できます、複数の視点下位木の組合は、より複雑なMIB意見(特定のネットワーク・インターフェースに関連している例えばすべての情報)を表すことができますが。
While any set of managed objects can be described by the union of some number of view subtrees, situations can arise that would require a very large number of view subtrees. This could happen, for example, when specifying all columns in one conceptual row of a MIB table because they would appear in separate subtrees, one per column, each with a very similar format. Because the formats are similar, the required set of subtrees can easily be aggregated into one structure. This structure is named a family of view subtrees after the set of subtrees that it conceptually represents. A family of view subtrees can either be included or excluded from a MIB view.
何らかの数の視点下位木の組合がどんなセットの管理オブジェクトについても説明できる間、非常に多くの視点下位木を必要とする状況は起こることができます。 別々の下位木に現れるでしょう、したがって、MIBテーブルの1つの概念的な行のすべてのコラムを指定するとき、例えば、これは起こることができました、1コラムあたり1つ、それぞれ非常に同様の形式で。 形式が同様であるので、容易に必要なセットの下位木を1つの構造に集めることができます。 この構造はそれが概念的に表す下位木のセットにちなんで視点下位木のファミリーと命名されます。 MIB視点から視点下位木のファミリーを含んでいるか、または除くことができます。
2.4.1. View Subtree
2.4.1. 視点下位木
A view subtree is the set of all MIB object instances which have a common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is identified by the OBJECT IDENTIFIER value which is the longest OBJECT IDENTIFIER prefix common to all (potential) MIB object instances in that subtree.
視点下位木は一般的なASN.1OBJECT IDENTIFIER接頭語をそれらの名前に持っているすべてのMIBオブジェクトインスタンスのセットです。 視点下位木はその下位木におけるすべての(潜在的)のMIBオブジェクトインスタンスに共通の最も長いOBJECT IDENTIFIER接頭語であるOBJECT IDENTIFIER値によって特定されます。
Wijnen, et al. Standards Track [Page 5] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[5ページ]。
2.4.2. ViewTreeFamily
2.4.2. ViewTreeFamily
A family of view subtrees is a pairing of an OBJECT IDENTIFIER value (called the family name) together with a bit string value (called the family mask). The family mask indicates which sub-identifiers of the associated family name are significant to the family's definition.
視点下位木のファミリーはしばらくストリング価値(ファミリーマスクと呼ばれる)に伴うOBJECT IDENTIFIER価値(姓と呼ばれる)の組み合わせです。 ファミリーマスクは、関連姓のどのサブ識別子がファミリーの定義に重要であるかを示します。
For each possible managed object instance, that instance belongs to a particular ViewTreeFamily if both of the following conditions are true:
それぞれの可能な管理オブジェクトインスタンスのために、以下の条件の両方が本当であるなら、そのインスタンスは特定のViewTreeFamilyに属します:
- the OBJECT IDENTIFIER name of the managed object instance contains
at least as many sub-identifiers as does the family name, and
- そして管理オブジェクトインスタンスのOBJECT IDENTIFIER名が少なくとも姓と同じくらい多くのサブ識別子を含んでいる。
- each sub-identifier in the OBJECT IDENTIFIER name of the managed
object instance matches the corresponding sub-identifier of the
family name whenever the corresponding bit of the associated
family mask is non-zero.
- 管理オブジェクトインスタンスのOBJECT IDENTIFIER名のそれぞれのサブ識別子は関連ファミリーマスクの対応するビットが非ゼロであるときはいつも、姓の対応するサブ識別子に合っています。
When the configured value of the family mask is all ones, the view subtree family is identical to the single view subtree identified by the family name.
ファミリーマスクの構成された値がすべてものであるときに、視点下位木ファミリーは姓によって特定されたただ一つの視点下位木と同じです。
When the configured value of the family mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family having a family mask of zero length always corresponds to a single view subtree.
上のテストを実行するのが必要であるというよりもファミリーマスクの構成された値が短いときに、値はものでそれとなく広げられます。 その結果、ゼロ・レングスのファミリーマスクを持っている視点下位木ファミリーはいつもただ一つの視点下位木に文通します。
2.5. Access Policy
2.5. アクセス方針
The View-based Access Control Model determines the access rights of a group, representing zero or more securityNames which have the same access rights. For a particular context, identified by contextName, to which a group, identified by groupName, has access using a particular securityModel and securityLevel, that group's access rights are given by a read-view, a write-view and a notify-view.
ViewベースのAccess Control Modelはグループのアクセス権を決定します、同じアクセス権を持っているゼロか、より多くのsecurityNamesを表して。 groupNameによって特定されたグループが特定のsecurityModelとsecurityLevelを使用することでアクセスを持っているcontextNameによって特定された特定の文脈のために、そのグループのアクセス権は読書視点、aで視点を書いている当然のことであり、aは視点に通知します。
The read-view represents the set of object instances authorized for the group when reading objects. Reading objects occurs when processing a retrieval operation (when handling Read Class PDUs).
視点を読むのはオブジェクトを読むときグループのために認可されたオブジェクトインスタンスのセットを表します。 検索操作を処理するとき(Read Class PDUsを扱うとき)、オブジェクトを読むのは起こります。
The write-view represents the set of object instances authorized for the group when writing objects. Writing objects occurs when processing a write operation (when handling Write Class PDUs).
視点を書くのはオブジェクトを書くときグループのために認可されたオブジェクトインスタンスのセットを表します。 aを処理すると操作が書かれるとき(Write Class PDUsを扱うとき)、オブジェクトを書くのは起こります。
The notify-view represents the set of object instances authorized for the group when sending objects in a notification, such as when sending a notification (when sending Notification Class PDUs).
いつなどの通知でオブジェクトを送るかとき、視点に通知するのは、通知書を送りながら(Notification Class PDUsを送るとき)、グループのために認可されたオブジェクトインスタンスのセットを表します。
Wijnen, et al. Standards Track [Page 6] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[6ページ]。
3. Elements of Procedure
3. 手順のElements
This section describes the procedures followed by an Access Control module that implements the View-based Access Control Model when checking access rights as requested by an application (for example a Command Responder or a Notification Originator application). The abstract service primitive is:
このセクションは手順について説明します、続いて、アプリケーション(例えば、Command ResponderかNotification Originatorアプリケーション)で要求された通りアクセス権をチェックするときViewベースのAccess Control Modelを実装するAccess Controlモジュールを説明します。 抽象的なサービス基関数は以下の通りです。
statusInformation = -- success or errorIndication
isAccessAllowed(
securityModel -- Security Model in use
securityName -- principal who wants access
securityLevel -- Level of Security
viewType -- read, write, or notify view
contextName -- context containing variableName
variableName -- OID for the managed object
)
statusInformation=--成功かerrorIndication isAccessAllowed(securityModel(securityName(アクセスsecurityLevelが欲しい主体)が平らにするSecurity viewTypeの使用でのセキュリティModel)は管理オブジェクトのために視点contextName--variableName variableNameを含む文脈--OIDに読むか、書くか、または通知します)
The abstract data elements are:
抽象的なデータ要素は以下の通りです。
statusInformation - one of the following:
accessAllowed - a MIB view was found and access is granted.
notInView - a MIB view was found but access is denied.
The variableName is not in the configured
MIB view for the specified viewType (e.g., in
the relevant entry in the vacmAccessTable).
noSuchView - no MIB view found because no view has been
configured for specified viewType (e.g., in
the relevant entry in the vacmAccessTable).
noSuchContext - no MIB view found because of no entry in the
vacmContextTable for specified contextName.
noGroupName - no MIB view found because no entry has been
configured in the vacmSecurityToGroupTable
for the specified combination of
securityModel and securityName.
noAccessEntry - no MIB view found because no entry has been
configured in the vacmAccessTable for the
specified combination of contextName,
groupName (from vacmSecurityToGroupTable),
securityModel and securityLevel.
otherError - failure, an undefined error occurred.
securityModel - Security Model under which access is requested.
securityName - the principal on whose behalf access is requested.
securityLevel - Level of Security under which access is requested.
viewType - view to be checked (read, write or notify).
contextName - context in which access is requested.
variableName - object instance to which access is requested.
statusInformation--以下の1つ: accessAllowedされました--. notInViewをアクセスに与えます--MIB視点は見つけられました、そして、MIB視点は見つけられましたが、アクセスは拒絶されます。 variableNameは指定のために構成されたMIBでviewType(例えば、vacmAccessTableの関連エントリーにおける)noSuchViewを見ないことです--視点が全く指定されたviewType(例えば、vacmAccessTableの関連エントリーにおける)のために構成されていないので、視点はMIB見つけられませんでした; noSuchContext--エントリーがないことのためにvacmContextTableで指定されたcontextName. noGroupNameに関して見つけられなかったMIB視点全く--エントリーが全くsecurityModelとsecurityNameの指定された組み合わせのためにvacmSecurityToGroupTableで構成されていないので、視点はMIB見つけられませんでした; エントリーが全くcontextName、groupName(vacmSecurityToGroupTableからの)、securityModel、およびsecurityLevel. otherErrorの指定された組み合わせのためにvacmAccessTableで構成されていないので--失敗、未定義の誤りが発生したのは、MIB視点が見つけられませんでした。主体は利益アクセスのときに要求されます。noAccessEntry--securityModel--セキュリティModelがどのアクセスで要求されているか、securityName--. securityLevel--アクセスが要求されているSecurityのレベル、viewType--、viチェックされてください(読むか、書くか、または通知してください)。ewする. contextName--アクセスが要求されている文脈、variableName--オブジェクトインスタンスはどのアクセスに要求されているか。
Wijnen, et al. Standards Track [Page 7] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[7ページ]。
3.1. Overview of isAccessAllowed Process
3.1. isAccessAllowedプロセスの概要
The following picture shows how the decision for access control is made by the View-based Access Control Model.
以下の画像はアクセスコントロールのための決定がViewベースのAccess Control Modelによってどうされるかを示しています。
+--------------------------------------------------------------------+ | | | +-> securityModel -+ | | | (a) | | | who -+ +-> groupName ----+ | | (1) | | (x) | | | +-> securityName --+ | | | (b) | | | | | | where -> contextName ---------------------+ | | (2) (e) | | | | | | | | | +-> securityModel -------------------+ | | | (a) | | | how -+ +-> viewName -+ | | (3) | | (y) | | | +-> securityLevel -------------------+ | | | (c) | +-> yes/no | | | | decision | | why ---> viewType (read/write/notify) ----+ | (z) | | (4) (d) | | | | | | what --> object-type ------+ | | | (5) (m) | | | | +-> variableName (OID) ------+ | | | (f) | | which -> object-instance --+ | | (6) (n) | | | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | | | +->securityModel-+| | | (a) | | | だれ、-++->groupName----+ | | (1) | | (x) | | | +->securityName--+| | | (b) | | | | | | どこ->contextName---------------------+ | | (2) (e) | | | | | | | | | +->securityModel-------------------+ | | | (a) | | | どのように-++->viewName-+| | (3) | | (y) | | | +->securityLevel-------------------+ | | | (c) | +->はい/いいえ| | | | 決定| | なぜ--->viewType(読むか、書く、または通知します)----+ | (z) | | (4) (d) | | | | | | 何、-->がオブジェクトでタイプされる------+ | | | (5) (m) | | | | +->variableName(OID)------+ | | | (f) | | どの->オブジェクトインスタンス--+| | (6) (n) | | | +--------------------------------------------------------------------+
Wijnen, et al. Standards Track [Page 8] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[8ページ]。
How the decision for isAccessAllowed is made.
どうisAccessAllowedのための決定をするか。
1) Inputs to the isAccessAllowed service are:
1) isAccessAllowedサービスへの入力は以下の通りです。
(a) securityModel -- Security Model in use
(b) securityName -- principal who wants to access
(c) securityLevel -- Level of Security
(d) viewType -- read, write, or notify view
(e) contextName -- context containing variableName
(f) variableName -- OID for the managed object
-- this is made up of:
- object-type (m)
- object-instance (n)
(a) securityModel--使用(b)securityNameのセキュリティModel--(c) securityLevelにアクセスすることでありたい校長(Security(d)viewTypeのレベル)は管理オブジェクトのために視点(e)contextName--variableName(f)variableNameを含む文脈--OIDに読むか、書くか、または通知します--これは以下で作られます。 - オブジェクト・タイプ(m)--オブジェクトインスタンス(n)
2) The partial "who" (1), represented by the securityModel (a) and
the securityName (b), are used as the indices (a,b) into the
vacmSecurityToGroupTable to find a single entry that produces a
group, represented by groupName (x).
2) securityModel(a)とsecurityName(b)によって表された(1)がグループを製作する単一のエントリーを見つけるのにインデックスリスト(a、b)としてvacmSecurityToGroupTableに使用されて、表される「だれ」部分的なgroupName(x)。
3) The "where" (2), represented by the contextName (e), the "who",
represented by the groupName (x) from the previous step, and the
"how" (3), represented by securityModel (a) and securityLevel (c),
are used as indices (e,x,a,c) into the vacmAccessTable to find a
single entry that contains three MIB views.
3) contextName(e)、groupName(x)によって前のステップから表された「だれ」、およびsecurityModel(a)によって表された(3)とsecurityLevel(c)が単一のエントリーがそれであることがわかるのにインデックスリスト(e、x、a、c)としてvacmAccessTableに使用される「方法」によって表された「どこ」(2)は3つのMIB視点を含んでいるか。
4) The "why" (4), represented by the viewType (d), is used to select
the proper MIB view, represented by a viewName (y), from the
vacmAccessEntry selected in the previous step. This viewName (y)
is an index into the vacmViewTreeFamilyTable and selects the set
of entries that define the variableNames which are included in or
excluded from the MIB view identified by the viewName (y).
4) viewType(d)によって表された(4)が前のステップで選択されたvacmAccessEntryからviewName(y)によって表された適切なMIB視点を選択するのに使用される「理由。」 このviewName(y)はvacmViewTreeFamilyTableへのインデックスであり、(y)が含まれているか、またはviewNameによって特定されたMIB視点から除かれるvariableNamesを定義するエントリーのセットを選択します。
5) The "what" (5) type of management data and "which" (6) particular
instance, represented by the variableName (f), is then checked to
be in the MIB view or not, e.g., the yes/no decision (z).
5) 次に、variableName(f)によって表された(5) 「何」の業態データと「どれ」(6)の特定のインスタンスはMIB視点にはあるようにチェックされるか、例えば、はい/いいえ決定(z)。
3.2. Processing the isAccessAllowed Service Request
3.2. isAccessAllowedサービスのリクエストを処理します。
This section describes the procedure followed by an Access Control module that implements the View-based Access Control Model whenever it receives an isAccessAllowed request.
このセクションは手順について説明します、続いて、isAccessAllowed要求を受け取るときはいつも、ViewベースのAccess Control Modelを実装するAccess Controlモジュールを説明します。
1) The vacmContextTable is consulted for information about the SNMP
context identified by the contextName. If information about this
SNMP context is absent from the table, then an errorIndication
(noSuchContext) is returned to the calling module.
1) vacmContextTableはcontextNameによって特定されたSNMP文脈の情報のために相談されます。 このSNMP文脈の情報がテーブルから欠けるなら、errorIndication(noSuchContext)を呼ぶモジュールに返します。
Wijnen, et al. Standards Track [Page 9] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[9ページ]。
2) The vacmSecurityToGroupTable is consulted for mapping the
securityModel and securityName to a groupName. If the information
about this combination is absent from the table, then an
errorIndication (noGroupName) is returned to the calling module.
2) vacmSecurityToGroupTableは、securityModelとsecurityNameをgroupNameに写像しながら、コンサルトを務められます。 この組み合わせの情報がテーブルから欠けるなら、errorIndication(noGroupName)を呼ぶモジュールに返します。
3) The vacmAccessTable is consulted for information about the
groupName, contextName, securityModel and securityLevel. If
information about this combination is absent from the table, then
an errorIndication (noAccessEntry) is returned to the calling
module.
3) vacmAccessTableはgroupName、contextName、securityModel、およびsecurityLevelの情報のために相談されます。 この組み合わせの情報がテーブルから欠けるなら、errorIndication(noAccessEntry)を呼ぶモジュールに返します。
4) a) If the viewType is "read", then the read view is used for
checking access rights.
4) a) viewTypeが「読んでください」であるなら、そして、読みます視点がアクセス権をチェックしながら使用される。
b) If the viewType is "write", then the write view is used for
checking access rights.
b) viewTypeが次に、「書く」ことである、アクセス権をチェックするために使用される視点を書いてください。
c) If the viewType is "notify", then the notify view is used for
checking access rights.
c) viewTypeが次に、「通知する」ことである、アクセス権をチェックするために使用される視点に通知してください。
If the view to be used is the empty view (zero length viewName)
then an errorIndication (noSuchView) is returned to the calling
module.
使用されるべき視点が空の意見(ゼロ・レングスviewName)であるなら、errorIndication(noSuchView)を呼ぶモジュールに返します。
5) a) If there is no view configured for the specified viewType, then
an errorIndication (noSuchView) is returned to the calling
module.
5) a) 指定されたviewTypeのために構成された視点が全くなければ、errorIndication(noSuchView)を呼ぶモジュールに返します。
b) If the specified variableName (object instance) is not in the
MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in
section 4), then an errorIndication (notInView) is returned to
the calling module.
b) MIB視点に指定されたvariableName(オブジェクトインスタンス)がないなら(vacmViewTreeFamilyTableに関してセクション4の記述節を見てください)、errorIndication(notInView)を呼ぶモジュールに返します。
Otherwise,
そうでなければ
c) The specified variableName is in the MIB view. A
statusInformation of success (accessAllowed) is returned to the
calling module.
c) MIB視点には指定されたvariableNameがあります。 成功(accessAllowed)のstatusInformationを呼ぶモジュールに返します。
Wijnen, et al. Standards Track [Page 10] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[10ページ]。
4. Definitions
4. 定義
SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN
SNMPの視点ベースのACM-MIB定義:、:= 始まってください。
IMPORTS
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
MODULE-IDENTITY, OBJECT-TYPE,
snmpModules FROM SNMPv2-SMI
TestAndIncr,
RowStatus, StorageType FROM SNMPv2-TC
SnmpAdminString,
SnmpSecurityLevel,
SnmpSecurityModel FROM SNMP-FRAMEWORK-MIB;
SNMPフレームワークMIBからのSNMPv2-Tc SnmpAdminString、SnmpSecurityLevel、SnmpSecurityModelからSNMPv2-SMI TestAndIncr、RowStatus、StorageTypeからのSNMPv2-CONFモジュールアイデンティティ、オブジェクト・タイプ、snmpModulesからのモジュールコンプライアンス、オブジェクトグループをインポートします。
snmpVacmMIB MODULE-IDENTITY
LAST-UPDATED "200210160000Z" -- 16 Oct 2002, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
Subscribe: majordomo@lists.tislabs.com
In message body: subscribe snmpv3
snmpVacmMIB MODULE-IDENTITY LAST-UPDATED"200210160000Z"--2002年10月16日、真夜中の組織「SNMPv3ワーキンググループ」コンタクトインフォメーションは「以下をWGメールします」。 snmpv3@lists.tislabs.com は申し込まれます: メッセージ本体の majordomo@lists.tislabs.com : snmpv3を申し込んでください。
Co-Chair: Russ Mundy
Network Associates Laboratories
postal: 15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA
email: mundy@tislabs.com
phone: +1 301-947-7107
共同議長: ラスマンディNetwork Associates研究所、郵便: 15204 オメガDrive、Suite300MD20850-4601ロックビル(米国)はメールされます: mundy@tislabs.com 電話: +1 301-947-7107
Co-Chair: David Harrington
Enterasys Networks
Postal: 35 Industrial Way
P. O. Box 5004
Rochester, New Hampshire 03866-5005
USA
EMail: dbh@enterasys.com
Phone: +1 603-337-2614
共同議長: デヴィッドハリントンEnterasysがネットワークでつなぐ、郵便: 35の産業方法、私書箱5004ニューハンプシャー03866-5005ロチェスター(米国)はメールされます: dbh@enterasys.com 電話: +1 603-337-2614
Co-editor: Bert Wijnen
Lucent Technologies
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: bwijnen@lucent.com
phone: +31-348-480-685
共同エディタ: バートWijnenルーセントテクノロジーズ郵便: Schagen33 3461GLリンスホーテン・オランダはメールされます: bwijnen@lucent.com 電話: +31-348-480-685
Co-editor: Randy Presuhn
BMC Software, Inc.
共同エディタ: ランディPresuhn BMCソフトウェアInc.
Wijnen, et al. Standards Track [Page 11] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[11ページ]。
postal: 2141 North First Street
San Jose, CA 95131
USA
email: randy_presuhn@bmc.com
phone: +1 408-546-1006
郵便: 2141北に、First通りカリフォルニア95131サンノゼ(米国)はメールされます: randy_presuhn@bmc.com 電話: +1 408-546-1006
Co-editor: Keith McCloghrie
Cisco Systems, Inc.
postal: 170 West Tasman Drive
San Jose, CA 95134-1706
USA
email: kzm@cisco.com
phone: +1-408-526-5260
"
DESCRIPTION "The management information definitions for the
View-based Access Control Model for SNMP.
共同エディタ: キースMcCloghrieシスコシステムズInc.郵便: 170 西タスマン・Driveカリフォルニア95134-1706サンノゼ(米国)はメールされます: kzm@cisco.com 電話: +1-408-526-5260、「記述、「SNMPのためのViewベースのAccess Control Modelのための経営情報定義。」
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3415;
see the RFC itself for full legal notices.
"
-- Revision history
Copyright(C)インターネット協会(2002)。 このMIBモジュールのこのバージョンはRFC3415の一部です。 完全な法定の通知に関してRFC自身を見てください。 「--、改訂履歴、」
REVISION "200210160000Z" -- 16 Oct 2002, midnight
DESCRIPTION "Clarifications, published as RFC3415"
REVISION"200210160000Z"--2002年10月16日、「明確化であって、RFC3415として発行された」真夜中の記述
REVISION "199901200000Z" -- 20 Jan 1999, midnight
DESCRIPTION "Clarifications, published as RFC2575"
REVISION"199901200000Z"--1999年1月20日、「明確化であって、RFC2575として発行された」真夜中の記述
REVISION "199711200000Z" -- 20 Nov 1997, midnight
DESCRIPTION "Initial version, published as RFC2275"
REVISION"199711200000Z"--1997年11月20日、「初期のバージョンであって、RFC2275として発行された」真夜中の記述
::= { snmpModules 16 }
::= snmpModules16
-- Administrative assignments ****************************************
-- 管理課題****************************************
vacmMIBObjects OBJECT IDENTIFIER ::= { snmpVacmMIB 1 }
vacmMIBConformance OBJECT IDENTIFIER ::= { snmpVacmMIB 2 }
vacmMIBObjectsオブジェクト識別子:、:= snmpVacmMIB1vacmMIBConformanceオブジェクト識別子:、:= snmpVacmMIB2
-- Information about Local Contexts **********************************
-- 地方の文脈**********************************に関する情報
vacmContextTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmContextEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of locally available contexts.
vacmContextTable OBJECT-TYPE SYNTAX SEQUENCE OF VacmContextEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「局所的に利用可能な文脈のテーブル。」
This table provides information to SNMP Command
このテーブルは情報をSNMP Commandに供給します。
Wijnen, et al. Standards Track [Page 12] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[12ページ]。
Generator applications so that they can properly
configure the vacmAccessTable to control access to
all contexts at the SNMP entity.
ジェネレータアプリケーション、SNMP実体ですべての文脈へのアクセスを制御するために適切にvacmAccessTableを構成できるように。
This table may change dynamically if the SNMP entity
allows that contexts are added/deleted dynamically
(for instance when its configuration changes). Such
changes would happen only if the management
instrumentation at that SNMP entity recognizes more
(or fewer) contexts.
このテーブルは、SNMP実体が、文脈がダイナミックに加えられるか、または削除されるのを許容するかどうかを(例えば、構成はいつ変化しますか)ダイナミックに変えるかもしれません。 そのSNMP実体における管理計装が、より多く、(より少ない)の文脈を認識する場合にだけ、そのような変化は起こるでしょう。
The presence of entries in this table and of entries
in the vacmAccessTable are independent. That is, a
context identified by an entry in this table is not
necessarily referenced by any entries in the
vacmAccessTable; and the context(s) referenced by an
entry in the vacmAccessTable does not necessarily
currently exist and thus need not be identified by an
entry in this table.
vacmAccessTableでのこのテーブルのエントリーとエントリーの存在は独立しています。 vacmAccessTableのどんなエントリーでもすなわち、このテーブルでエントリーで特定された文脈は必ず参照をつけられるというわけではありません。 そして、vacmAccessTableのエントリーで参照をつけられる文脈は、現在、必ず存在するというわけではなくて、その結果、このテーブルでエントリーで特定される必要はありません。
This table must be made accessible via the default
context so that Command Responder applications have
a standard way of retrieving the information.
Command Responderアプリケーションには情報を検索する標準の方法があるように、このテーブルをデフォルト文脈でアクセスしやすくしなければなりません。
This table is read-only. It cannot be configured via
SNMP.
"
::= { vacmMIBObjects 1 }
このテーブルは書き込み禁止です。 SNMPを通してそれを構成できません。 " ::= vacmMIBObjects1
vacmContextEntry OBJECT-TYPE
SYNTAX VacmContextEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information about a particular context."
INDEX {
vacmContextName
}
::= { vacmContextTable 1 }
vacmContextEntry OBJECT-TYPE SYNTAX VacmContextEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の文脈に関する情報。」 vacmContextNameに索引をつけてください:、:= vacmContextTable1
VacmContextEntry ::= SEQUENCE
{
vacmContextName SnmpAdminString
}
VacmContextEntry:、:= 系列vacmContextName SnmpAdminString
vacmContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-only
STATUS current
vacmContextName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))マックス-ACCESS書き込み禁止STATUS海流
Wijnen, et al. Standards Track [Page 13] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[13ページ]。
DESCRIPTION "A human readable name identifying a particular
context at a particular SNMP entity.
記述、「特定のSNMP実体で特定の文脈を特定する人間の読み込み可能な名前。」
The empty contextName (zero length) represents the
default context.
"
::= { vacmContextEntry 1 }
空のcontextName(ゼロ・レングス)はデフォルト文脈を表します。 " ::= vacmContextEntry1
-- Information about Groups ******************************************
-- グループ******************************************に関する情報
vacmSecurityToGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmSecurityToGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "This table maps a combination of securityModel and
securityName into a groupName which is used to define
an access control policy for a group of principals.
"
::= { vacmMIBObjects 2 }
vacmSecurityToGroupTable OBJECT-TYPEのSYNTAX SEQUENCE OF VacmSecurityToGroupEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このテーブルは主体のグループのためにアクセス制御方針を定義するのに使用されるgroupNameにsecurityModelとsecurityNameの組み合わせを写像します」。 " ::= vacmMIBObjects2
vacmSecurityToGroupEntry OBJECT-TYPE
SYNTAX VacmSecurityToGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in this table maps the combination of a
securityModel and securityName into a groupName.
"
INDEX {
vacmSecurityModel,
vacmSecurityName
}
::= { vacmSecurityToGroupTable 1 }
vacmSecurityToGroupEntry OBJECT-TYPE SYNTAX VacmSecurityToGroupEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このテーブルのエントリーはsecurityModelとsecurityNameの組み合わせをgroupNameに写像します」。 「vacmSecurityModel、vacmSecurityNameに索引をつけてください:、:、」= vacmSecurityToGroupTable1
VacmSecurityToGroupEntry ::= SEQUENCE
{
vacmSecurityModel SnmpSecurityModel,
vacmSecurityName SnmpAdminString,
vacmGroupName SnmpAdminString,
vacmSecurityToGroupStorageType StorageType,
vacmSecurityToGroupStatus RowStatus
}
VacmSecurityToGroupEntry:、:= 系列vacmSecurityModel SnmpSecurityModel、vacmSecurityName SnmpAdminString、vacmGroupName SnmpAdminString、vacmSecurityToGroupStorageType StorageType、vacmSecurityToGroupStatus RowStatus
vacmSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel(1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The Security Model, by which the vacmSecurityName
referenced by this entry is provided.
「Security Modelであって、このエントリーで参照をつけられるvacmSecurityNameがどれであるかによって提供された」vacmSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModel(1 .2147483647)マックス-ACCESSアクセスしやすくないSTATUS現在の記述。
Wijnen, et al. Standards Track [Page 14] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[14ページ]。
Note, this object may not take the 'any' (0) value.
"
::= { vacmSecurityToGroupEntry 1 }
注意、このオブジェクトは'いくらか'という(0)値を取らないかもしれません。 " ::= vacmSecurityToGroupEntry1
vacmSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The securityName for the principal, represented in a
Security Model independent format, which is mapped by
this entry to a groupName.
"
::= { vacmSecurityToGroupEntry 2 }
vacmSecurityName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .32))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「groupNameへのこのエントリーで写像されるSecurity Modelの独立している形式で表された主体のためのsecurityName。」 " ::= vacmSecurityToGroupEntry2
vacmGroupName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The name of the group to which this entry (e.g., the
combination of securityModel and securityName)
belongs.
vacmGroupName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .32))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このエントリー(例えば、securityModelとsecurityNameの組み合わせ)が属するグループの名前。」
This groupName is used as index into the
vacmAccessTable to select an access control policy.
However, a value in this table does not imply that an
instance with the value exists in table vacmAccesTable.
"
::= { vacmSecurityToGroupEntry 3 }
このgroupNameは、アクセス制御方針を選択するのにインデックスとしてvacmAccessTableに使用されます。 しかしながら、このテーブルの値は、値があるインスタンスがテーブルvacmAccesTableに存在するのを含意しません。 " ::= vacmSecurityToGroupEntry3
vacmSecurityToGroupStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
DEFVAL { nonVolatile }
::= { vacmSecurityToGroupEntry 4 }
vacmSecurityToGroupStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「これに、概念的なストレージタイプはこぐ」STATUSの現在の記述を読書して作成します。 '永久的'に値を持っている概念的な行は行でいずれにもアクセスを書いている円柱状のオブジェクトを許容する必要はありません。 「DEFVAL、不揮発性:、:、」= vacmSecurityToGroupEntry4
vacmSecurityToGroupStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
vacmSecurityToGroupStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「これほど概念的の状態はこぐ」STATUSの現在の記述を読書して作成します。
Until instances of all corresponding columns are
appropriately configured, the value of the
すべての対応のインスタンスまで、コラムが適切に構成される、価値
Wijnen, et al. Standards Track [Page 15] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[15ページ]。
corresponding instance of the vacmSecurityToGroupStatus
column is 'notReady'.
vacmSecurityToGroupStatusコラムの対応するインスタンスは'notReady'です。
In particular, a newly created row cannot be made
active until a value has been set for vacmGroupName.
新たに作成された行はアクティブに特に、値がvacmGroupNameに設定されるまですることができません。
The RowStatus TC [RFC2579] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:
RowStatus TC[RFC2579]は、この記述節が、どの状況でこの行の他のオブジェクトを変更できるかを述べるのを必要とします:
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { vacmSecurityToGroupEntry 5 }
このオブジェクトの値はこの概念的な行の他のオブジェクトを変更できるかどうかに関して効き目がありません。 " ::= vacmSecurityToGroupEntry5
-- Information about Access Rights ***********************************
-- アクセス権***********************************に関する情報
vacmAccessTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of access rights for groups.
vacmAccessTable OBJECT-TYPE SYNTAX SEQUENCE OF VacmAccessEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「グループのためのアクセス権のテーブル。」
Each entry is indexed by a groupName, a contextPrefix,
a securityModel and a securityLevel. To determine
whether access is allowed, one entry from this table
needs to be selected and the proper viewName from that
entry must be used for access control checking.
各エントリーはgroupName、contextPrefix、securityModel、およびsecurityLevelによって索引をつけられます。 アクセスが許されているかどうか決定するのに、このテーブルからの1つのエントリーが、選択される必要があります、そして、アクセス制御の照合にそのエントリーからの適切なviewNameを使用しなければなりません。
To select the proper entry, follow these steps:
適切なエントリーを選択するには、これらの方法に従ってください:
1) the set of possible matches is formed by the
intersection of the following sets of entries:
1) 可能なマッチのセットは以下のセットのエントリーの交差点によって形成されます:
the set of entries with identical vacmGroupName
the union of these two sets:
- the set with identical vacmAccessContextPrefix
- the set of entries with vacmAccessContextMatch
value of 'prefix' and matching
vacmAccessContextPrefix
intersected with the union of these two sets:
- the set of entries with identical
vacmSecurityModel
- the set of entries with vacmSecurityModel
value of 'any'
intersected with the set of entries with
vacmAccessSecurityLevel value less than or equal
to the requested securityLevel
これらの2人の組合が設定する同じvacmGroupNameとのエントリーのセット: - 同じvacmAccessContextPrefixがあるセット--'接頭語'と合っているvacmAccessContextPrefixのvacmAccessContextMatch値があるエントリーのセットはこれらの2セットの組合と交差しました: - 同じvacmSecurityModelとのエントリーのセット--'いずれ'のvacmSecurityModel値がvacmAccessSecurityLevelと共にエントリーのセットと交差したことでのエントリーのセットは要求されたよりsecurityLevelを評価します。
Wijnen, et al. Standards Track [Page 16] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[16ページ]。
2) if this set has only one member, we're done
otherwise, it comes down to deciding how to weight
the preferences between ContextPrefixes,
SecurityModels, and SecurityLevels as follows:
a) if the subset of entries with securityModel
matching the securityModel in the message is
not empty, then discard the rest.
b) if the subset of entries with
vacmAccessContextPrefix matching the contextName
in the message is not empty,
then discard the rest
c) discard all entries with ContextPrefixes shorter
than the longest one remaining in the set
d) select the entry with the highest securityLevel
2) このセットに1人のメンバーしかいないなら、別の方法で私たちをして、ContextPrefixesと、SecurityModelsと、以下のSecurityLevelsの間の好みに重みを加える方法を決めるまで来ます: 空です、次に、残りを捨ててください。a) securityModelがメッセージでsecurityModelに合っているエントリーの部分集合がvacmAccessContextPrefixがメッセージでcontextNameに合っているエントリーの部分集合であるならb)が休息c)破棄を空にして、次に、捨てないことであるということでないなら、ContextPrefixesがセットd)に残っている最も長い方より短いすべてのエントリーが最も高いsecurityLevelとのエントリーを選択します。
Please note that for securityLevel noAuthNoPriv, all
groups are really equivalent since the assumption that
the securityName has been authenticated does not hold.
"
::= { vacmMIBObjects 4 }
securityLevel noAuthNoPrivに関して、securityNameが認証されたという仮定が成立しないので、すべてのグループが本当に同等です。 " ::= vacmMIBObjects4
vacmAccessEntry OBJECT-TYPE
SYNTAX VacmAccessEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An access right configured in the Local Configuration
Datastore (LCD) authorizing access to an SNMP context.
「アクセス権はSNMP文脈へのアクセスを認可するLocal Configuration Datastore(LCD)で構成した」vacmAccessEntry OBJECT-TYPE SYNTAX VacmAccessEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
Entries in this table can use an instance value for
object vacmGroupName even if no entry in table
vacmAccessSecurityToGroupTable has a corresponding
value for object vacmGroupName.
"
INDEX { vacmGroupName,
vacmAccessContextPrefix,
vacmAccessSecurityModel,
vacmAccessSecurityLevel
}
::= { vacmAccessTable 1 }
テーブルvacmAccessSecurityToGroupTableでどんなエントリーにもオブジェクトvacmGroupNameのための換算値がなくても、このテーブルのエントリーはオブジェクトvacmGroupNameにインスタンス値を使用できます。 「vacmGroupName、vacmAccessContextPrefix、vacmAccessSecurityModel、vacmAccessSecurityLevelに索引をつけてください:、:、」= vacmAccessTable1
VacmAccessEntry ::= SEQUENCE
{
vacmAccessContextPrefix SnmpAdminString,
vacmAccessSecurityModel SnmpSecurityModel,
vacmAccessSecurityLevel SnmpSecurityLevel,
vacmAccessContextMatch INTEGER,
vacmAccessReadViewName SnmpAdminString,
vacmAccessWriteViewName SnmpAdminString,
VacmAccessEntry:、:= 系列、vacmAccessContextPrefix SnmpAdminString、vacmAccessSecurityModel SnmpSecurityModel、vacmAccessSecurityLevel SnmpSecurityLevel、vacmAccessContextMatch整数、vacmAccessReadViewName SnmpAdminString、vacmAccessWriteViewName SnmpAdminString
Wijnen, et al. Standards Track [Page 17] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[17ページ]。
vacmAccessNotifyViewName SnmpAdminString,
vacmAccessStorageType StorageType,
vacmAccessStatus RowStatus
}
vacmAccessNotifyViewName SnmpAdminString、vacmAccessStorageType StorageType、vacmAccessStatus RowStatus
vacmAccessContextPrefix OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "In order to gain the access rights allowed by this
conceptual row, a contextName must match exactly
(if the value of vacmAccessContextMatch is 'exact')
or partially (if the value of vacmAccessContextMatch
is 'prefix') to the value of the instance of this
object.
"
::= { vacmAccessEntry 1 }
vacmAccessContextPrefix OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「この概念的な行によって許容されたアクセス権を獲得するために、contextNameはこのオブジェクトのインスタンスの値にちょうど(vacmAccessContextMatchの値が'正確である'なら)か部分的(vacmAccessContextMatchの値が'接頭語'であるなら)に合わなければなりません」。 " ::= vacmAccessEntry1
vacmAccessSecurityModel OBJECT-TYPE
SYNTAX SnmpSecurityModel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "In order to gain the access rights allowed by this
conceptual row, this securityModel must be in use.
"
::= { vacmAccessEntry 2 }
vacmAccessSecurityModel OBJECT-TYPE SYNTAX SnmpSecurityModelのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「この概念的な行によって許容されたアクセス権を獲得するために、このsecurityModelは使用中でなければなりません」。 " ::= vacmAccessEntry2
vacmAccessSecurityLevel OBJECT-TYPE
SYNTAX SnmpSecurityLevel
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The minimum level of security required in order to
gain the access rights allowed by this conceptual
row. A securityLevel of noAuthNoPriv is less than
authNoPriv which in turn is less than authPriv.
「セキュリティの最低水準がこの概念的な行によって許容されたアクセス権を獲得するのに必要だった」vacmAccessSecurityLevel OBJECT-TYPE SYNTAX SnmpSecurityLevelのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 noAuthNoPrivのsecurityLevelが順番に少ないauthNoPrivよりauthPrivあります。
If multiple entries are equally indexed except for
this vacmAccessSecurityLevel index, then the entry
which has the highest value for
vacmAccessSecurityLevel is selected.
"
::= { vacmAccessEntry 3 }
このvacmAccessSecurityLevelインデックスを除いて、多回入国が等しく索引をつけられるなら、vacmAccessSecurityLevelに、最も高い値を持っているエントリーは選択されます。 " ::= vacmAccessEntry3
vacmAccessContextMatch OBJECT-TYPE
SYNTAX INTEGER
{ exact (1), -- exact match of prefix and contextName
prefix (2) -- Only match to the prefix
}
vacmAccessContextMatchオブジェクト・タイプ構文整数正確な(1)(接頭語とcontextName接頭語(2)の完全な一致)は接頭語に合っているだけです。
Wijnen, et al. Standards Track [Page 18] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[18ページ]。
MAX-ACCESS read-create
STATUS current
DESCRIPTION "If the value of this object is exact(1), then all
rows where the contextName exactly matches
vacmAccessContextPrefix are selected.
マックス-ACCESSは「このオブジェクトの値は(1)を強要してください、次に、contextNameがまさにvacmAccessContextPrefixに合っているすべての行が選択されるということです」ならSTATUSの現在の記述を読書して作成します。
If the value of this object is prefix(2), then all
rows where the contextName whose starting octets
exactly match vacmAccessContextPrefix are selected.
This allows for a simple form of wildcarding.
"
DEFVAL { exact }
::= { vacmAccessEntry 4 }
このオブジェクトの値が接頭語(2)であるなら、すべてが始めの八重奏がまさにvacmAccessContextPrefixに合っているcontextNameが選択されるところで船をこぎます。 これはwildcardingの単純形を考慮します。 「DEFVALは以下を強要します」= vacmAccessEntry4
vacmAccessReadViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The value of an instance of this object identifies
the MIB view of the SNMP context to which this
conceptual row authorizes read access.
vacmAccessReadViewName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))マックス-ACCESSがSTATUSの現在の記述を読書して作成する、「このオブジェクトのインスタンスの値はこの概念的な行が読書アクセサリーを認可するSNMP文脈のMIB視点を特定します」。
The identified MIB view is that one for which the
vacmViewTreeFamilyViewName has the same value as the
instance of this object; if the value is the empty
string or if there is no active MIB view having this
value of vacmViewTreeFamilyViewName, then no access
is granted.
"
DEFVAL { ''H } -- the empty string
::= { vacmAccessEntry 5 }
特定されたMIB視点はvacmViewTreeFamilyViewNameにはこのオブジェクトのインスタンスと同じ値があるそのものです。 値が空のストリングであるかvacmViewTreeFamilyViewNameのこの値を持っているどんなアクティブなMIB視点もなければ、アクセスは全く承諾されません。 「DEFVAL、「H、--空は以下を結びます:、」= vacmAccessEntry5
vacmAccessWriteViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The value of an instance of this object identifies
the MIB view of the SNMP context to which this
conceptual row authorizes write access.
vacmAccessWriteViewName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))マックス-ACCESSがSTATUSの現在の記述を読書して作成する、「このオブジェクトのインスタンスの値がこの概念的な行が認可するものにSNMP文脈のMIB視点を特定する、アクセサリーを書いてください、」
The identified MIB view is that one for which the
vacmViewTreeFamilyViewName has the same value as the
instance of this object; if the value is the empty
string or if there is no active MIB view having this
value of vacmViewTreeFamilyViewName, then no access
is granted.
"
DEFVAL { ''H } -- the empty string
特定されたMIB視点はvacmViewTreeFamilyViewNameにはこのオブジェクトのインスタンスと同じ値があるそのものです。 値が空のストリングであるかvacmViewTreeFamilyViewNameのこの値を持っているどんなアクティブなMIB視点もなければ、アクセスは全く承諾されません。 「DEFVAL、「H、--、空のストリング、」
Wijnen, et al. Standards Track [Page 19] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[19ページ]。
::= { vacmAccessEntry 6 }
::= vacmAccessEntry6
vacmAccessNotifyViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The value of an instance of this object identifies
the MIB view of the SNMP context to which this
conceptual row authorizes access for notifications.
vacmAccessNotifyViewName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトのインスタンスの値はこの概念的な行が通知のためのアクセスを認可するSNMP文脈のMIB視点を特定します」。
The identified MIB view is that one for which the
vacmViewTreeFamilyViewName has the same value as the
instance of this object; if the value is the empty
string or if there is no active MIB view having this
value of vacmViewTreeFamilyViewName, then no access
is granted.
"
DEFVAL { ''H } -- the empty string
::= { vacmAccessEntry 7 }
特定されたMIB視点はvacmViewTreeFamilyViewNameにはこのオブジェクトのインスタンスと同じ値があるそのものです。 値が空のストリングであるかvacmViewTreeFamilyViewNameのこの値を持っているどんなアクティブなMIB視点もなければ、アクセスは全く承諾されません。 「DEFVAL、「H、--空は以下を結びます:、」= vacmAccessEntry7
vacmAccessStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
vacmAccessStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「これに、概念的なストレージタイプはこぐ」STATUSの現在の記述を読書して作成します。
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
DEFVAL { nonVolatile }
::= { vacmAccessEntry 8 }
'永久的'に値を持っている概念的な行は行でいずれにもアクセスを書いている円柱状のオブジェクトを許容する必要はありません。 「DEFVAL、不揮発性:、:、」= vacmAccessEntry8
vacmAccessStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
vacmAccessStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「これほど概念的の状態はこぐ」STATUSの現在の記述を読書して作成します。
The RowStatus TC [RFC2579] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:
RowStatus TC[RFC2579]は、この記述節が、どの状況でこの行の他のオブジェクトを変更できるかを述べるのを必要とします:
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { vacmAccessEntry 9 }
このオブジェクトの値はこの概念的な行の他のオブジェクトを変更できるかどうかに関して効き目がありません。 " ::= vacmAccessEntry9
-- Information about MIB views ***************************************
-- MIB視点***************************************に関する情報
Wijnen, et al. Standards Track [Page 20] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[20ページ]。
-- Support for instance-level granularity is optional. -- -- In some implementations, instance-level access control -- granularity may come at a high performance cost. Managers -- should avoid requesting such configurations unnecessarily.
-- サポート例えば、レベル粒状は任意です。 -- -- いくつかの実装では、アクセスコントロールをインスタンスで平らにしてください--粒状は高性能費用で来るかもしれません。 マネージャ--不必要にそのような構成を要求するのを避けるべきです。
vacmMIBViews OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }
vacmMIBViewsオブジェクト識別子:、:= vacmMIBObjects5
vacmViewSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow cooperating SNMP
Command Generator applications to coordinate their
use of the Set operation in creating or modifying
views.
vacmViewSpinLock OBJECT-TYPE SYNTAX TestAndIncrマックス-ACCESSは「通知ロックは視点を作成するか、または変更することにおける彼らのSet操作の使用を調整するために以前はよくSNMP Command Generatorアプリケーションを協力に許容していたこと」をSTATUSの現在の記述に読書して書きます。
When creating a new view or altering an existing
view, it is important to understand the potential
interactions with other uses of the view. The
vacmViewSpinLock should be retrieved. The name of
the view to be created should be determined to be
unique by the SNMP Command Generator application by
consulting the vacmViewTreeFamilyTable. Finally,
the named view may be created (Set), including the
advisory lock.
If another SNMP Command Generator application has
altered the views in the meantime, then the spin
lock's value will have changed, and so this creation
will fail because it will specify the wrong value for
the spin lock.
新しい視点を作成するか、または既存の視点を変更するとき、視点の他の用途との潜在的相互作用を理解しているのは重要です。 vacmViewSpinLockは検索されるべきです。 作成されるべき視点の名前は特有であることをvacmViewTreeFamilyTableに相談するのによるSNMP Command Generatorアプリケーションで決定しているべきです。 通知ロックを含んでいて、最終的に、命名された視点は作成されるかもしれません(設定します)。 別のSNMP Command Generatorアプリケーションが差し当たり視点を変更しているならスピン・ロックの値が変化してしまうだろうので、間違った値をスピン・ロックに指定するので、この作成は失敗するでしょう。
Since this is an advisory lock, the use of this lock
is not enforced.
"
::= { vacmMIBViews 1 }
これが通知ロックであるので、この錠の使用は励行されません。 " ::= vacmMIBViews1
vacmViewTreeFamilyTable OBJECT-TYPE
SYNTAX SEQUENCE OF VacmViewTreeFamilyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Locally held information about families of subtrees
within MIB views.
vacmViewTreeFamilyTable OBJECT-TYPEのSYNTAX SEQUENCE OF VacmViewTreeFamilyEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「局所的に、MIB視点の中に下位木のファミリーの情報を保持しました」。
Each MIB view is defined by two sets of view subtrees:
- the included view subtrees, and
- the excluded view subtrees.
Every such view subtree, both the included and the
それぞれのMIB視点は2セットの視点下位木によって定義されます: - そして、含まれている視点下位木、--除かれた視点下位木。 そしてあらゆるそのような視点下位木、両方の含み。
Wijnen, et al. Standards Track [Page 21] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[21ページ]。
excluded ones, is defined in this table.
ものを除いて、このテーブルで定義されます。
To determine if a particular object instance is in
a particular MIB view, compare the object instance's
OBJECT IDENTIFIER with each of the MIB view's active
entries in this table. If none match, then the
object instance is not in the MIB view. If one or
more match, then the object instance is included in,
or excluded from, the MIB view according to the
value of vacmViewTreeFamilyType in the entry whose
value of vacmViewTreeFamilySubtree has the most
sub-identifiers. If multiple entries match and have
the same number of sub-identifiers (when wildcarding
is specified with the value of vacmViewTreeFamilyMask),
then the lexicographically greatest instance of
vacmViewTreeFamilyType determines the inclusion or
exclusion.
特定のMIB視点で特定のオブジェクトインスタンスがあるかを決定するには、このテーブルでそれぞれのMIB視点の活発なエントリーとオブジェクトインスタンスのOBJECT IDENTIFIERを比べてください。 なにも合っていないなら、MIB視点にはオブジェクトインスタンスがありません。 1個以上のマッチ、オブジェクトインスタンスが含まれているか、または除かれるその時なら、vacmViewTreeFamilySubtreeの値がサブ識別子であるのに大部分持っているエントリーにおける、vacmViewTreeFamilyTypeの値に従って、MIB視点です。 多回入国が同じ数のサブ識別子(wildcardingがvacmViewTreeFamilyMaskの値で指定される)を合わせて、持っているなら、vacmViewTreeFamilyTypeの辞書編集に最もすばらしいインスタンスは包含か除外を決定します。
An object instance's OBJECT IDENTIFIER X matches an
active entry in this table when the number of
sub-identifiers in X is at least as many as in the
value of vacmViewTreeFamilySubtree for the entry,
and each sub-identifier in the value of
vacmViewTreeFamilySubtree matches its corresponding
sub-identifier in X. Two sub-identifiers match
either if the corresponding bit of the value of
vacmViewTreeFamilyMask for the entry is zero (the
'wild card' value), or if they are equal.
Xのサブ識別子の数がエントリーへのvacmViewTreeFamilySubtreeの値と少なくとも同じくらい多いときに、オブジェクトインスタンスのOBJECT IDENTIFIER Xはこのテーブルで活発なエントリーに合っています、そして、エントリーへのvacmViewTreeFamilyMaskの価値の対応するビットがゼロ('ワイルドカード'値)であるかそれらが等しいなら、vacmViewTreeFamilySubtreeの値におけるそれぞれのサブ識別子はサブ識別子が合っているX.Twoの対応するサブ識別子に合っています。
A 'family' of subtrees is the set of subtrees defined
by a particular combination of values of
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask.
下位木の'ファミリー'はvacmViewTreeFamilySubtreeとvacmViewTreeFamilyMaskの値の特定の組み合わせで定義された下位木のセットです。
In the case where no 'wild card' is defined in the
vacmViewTreeFamilyMask, the family of subtrees reduces
to a single subtree.
'ワイルドカード'が全くvacmViewTreeFamilyMaskで定義されない場合では、下位木のファミリーはただ一つの下位木に減少します。
When creating or changing MIB views, an SNMP Command
Generator application should utilize the
vacmViewSpinLock to try to avoid collisions. See
DESCRIPTION clause of vacmViewSpinLock.
MIB意見を作成するか、または変えるとき、SNMP Command Generatorアプリケーションは、衝突を避けようとするためにvacmViewSpinLockを利用するべきです。 vacmViewSpinLockの記述節を見てください。
When creating MIB views, it is strongly advised that
first the 'excluded' vacmViewTreeFamilyEntries are
created and then the 'included' entries.
MIB視点を作成して、いつ最初に、'除かれた'vacmViewTreeFamilyEntriesが作成されると強く忠告されるか、そして、そして、'含まれている'エントリー。
When deleting MIB views, it is strongly advised that
first the 'included' vacmViewTreeFamilyEntries are
MIB視点を削除するとき、最初に、'含まれている'vacmViewTreeFamilyEntriesがそうであると強く忠告されます。
Wijnen, et al. Standards Track [Page 22] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[22ページ]。
deleted and then the 'excluded' entries.
'除外'削除されて当時のエントリー。
If a create for an entry for instance-level access
control is received and the implementation does not
support instance-level granularity, then an
inconsistentName error must be returned.
"
::= { vacmMIBViews 2 }
aが例えば、平らなアクセスをエントリーに作成するなら、コントロールは受け取られています、そして、実装はインスタンスレベル粒状をサポートしません、そして、次に、inconsistentName誤りを返さなければなりません。 " ::= vacmMIBViews2
vacmViewTreeFamilyEntry OBJECT-TYPE
SYNTAX VacmViewTreeFamilyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Information on a particular family of view subtrees
included in or excluded from a particular SNMP
context's MIB view.
「視点下位木の特定のファミリーに関する情報は、含まれていたか、または特定のSNMP文脈のMIB視点から除いた」vacmViewTreeFamilyEntry OBJECT-TYPE SYNTAX VacmViewTreeFamilyEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
Implementations must not restrict the number of
families of view subtrees for a given MIB view,
except as dictated by resource constraints on the
overall number of entries in the
vacmViewTreeFamilyTable.
実装は与えられたMIB視点のために視点下位木のファミリーの数を制限してはいけません、vacmViewTreeFamilyTableのエントリーの総合的な数にリソース規制で書き取られるのを除いて。
If no conceptual rows exist in this table for a given
MIB view (viewName), that view may be thought of as
consisting of the empty set of view subtrees.
"
INDEX { vacmViewTreeFamilyViewName,
vacmViewTreeFamilySubtree
}
::= { vacmViewTreeFamilyTable 1 }
どんな概念的な行も与えられたMIB意見(viewName)のためにこのテーブルに存在していないなら、その視点は視点下位木の空集合から成ると考えられるかもしれません。 「vacmViewTreeFamilyViewName、vacmViewTreeFamilySubtreeに索引をつけてください:、:、」= vacmViewTreeFamilyTable1
VacmViewTreeFamilyEntry ::= SEQUENCE
{
vacmViewTreeFamilyViewName SnmpAdminString,
vacmViewTreeFamilySubtree OBJECT IDENTIFIER,
vacmViewTreeFamilyMask OCTET STRING,
vacmViewTreeFamilyType INTEGER,
vacmViewTreeFamilyStorageType StorageType,
vacmViewTreeFamilyStatus RowStatus
}
VacmViewTreeFamilyEntry:、:= 系列vacmViewTreeFamilyViewName SnmpAdminString、vacmViewTreeFamilySubtreeオブジェクト識別子、vacmViewTreeFamilyMask八重奏ストリング、vacmViewTreeFamilyType整数、vacmViewTreeFamilyStorageType StorageType、vacmViewTreeFamilyStatus RowStatus
vacmViewTreeFamilyViewName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The human readable name for a family of view subtrees.
"
vacmViewTreeFamilyViewName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .32))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「視点下位木のファミリーにおける人間の読み込み可能な名前。」 "
Wijnen, et al. Standards Track [Page 23] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[23ページ]。
::= { vacmViewTreeFamilyEntry 1 }
::= vacmViewTreeFamilyEntry1
vacmViewTreeFamilySubtree OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The MIB subtree which when combined with the
corresponding instance of vacmViewTreeFamilyMask
defines a family of view subtrees.
"
::= { vacmViewTreeFamilyEntry 2 }
vacmViewTreeFamilySubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「vacmViewTreeFamilyMaskの対応するインスタンスに結合されると視点下位木のファミリーを定義するMIB下位木。」 " ::= vacmViewTreeFamilyEntry2
vacmViewTreeFamilyMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The bit mask which, in combination with the
corresponding instance of vacmViewTreeFamilySubtree,
defines a family of view subtrees.
vacmViewTreeFamilyMask OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0 .16))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「vacmViewTreeFamilySubtreeの対応するインスタンスと組み合わせて視点下位木のファミリーを定義するビットマスク。」
Each bit of this bit mask corresponds to a
sub-identifier of vacmViewTreeFamilySubtree, with the
most significant bit of the i-th octet of this octet
string value (extended if necessary, see below)
corresponding to the (8*i - 7)-th sub-identifier, and
the least significant bit of the i-th octet of this
octet string corresponding to the (8*i)-th
sub-identifier, where i is in the range 1 through 16.
この噛み付いているマスクの各ビットが大部分が重要のvacmViewTreeFamilySubtreeに関するサブ識別子ビットに対応している、i、-、この八重奏ストリングの八重奏が対応を第評価する、(必要なら、広げられて、下を見てください)(8*i--7)、-、サブ識別子、および第最下位ビット、i、-、(8*i)に対応するこの八重奏ストリングの第八重奏、-、サブ識別子の1〜16番目。そこに、iが範囲にあります。
Each bit of this bit mask specifies whether or not
the corresponding sub-identifiers must match when
determining if an OBJECT IDENTIFIER is in this
family of view subtrees; a '1' indicates that an
exact match must occur; a '0' indicates 'wild card',
i.e., any sub-identifier value matches.
この噛み付いているマスクの各ビットは、視点下位木のこのファミリーでOBJECT IDENTIFIERがあるかを決定するとき、対応するサブ識別子が合わなければならないかどうか指定します。 '1'は、完全な一致が現れなければならないのを示します。 '0は''ワイルドカード'、すなわち、どんなサブ識別子値のマッチも示します。
Thus, the OBJECT IDENTIFIER X of an object instance
is contained in a family of view subtrees if, for
each sub-identifier of the value of
vacmViewTreeFamilySubtree, either:
したがって、オブジェクトインスタンスのOBJECT IDENTIFIER XはvacmViewTreeFamilySubtreeの価値に関するそれぞれのサブ識別子のためのどちらかなら視点下位木のファミリーに含まれています:
the i-th bit of vacmViewTreeFamilyMask is 0, or
またはi、-、vacmViewTreeFamilyMaskのビットが0番目である。
the i-th sub-identifier of X is equal to the i-th
sub-identifier of the value of
vacmViewTreeFamilySubtree.
i、-、Xのサブ識別子が第等しい、i、-、vacmViewTreeFamilySubtreeの価値に関するサブ第識別子。
If the value of this bit mask is M bits long and
そしてこの噛み付いているマスクの値が長さビットのMである。
Wijnen, et al. Standards Track [Page 24] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[24ページ]。
there are more than M sub-identifiers in the
corresponding instance of vacmViewTreeFamilySubtree,
then the bit mask is extended with 1's to be the
required length.
vacmViewTreeFamilySubtreeの対応するインスタンスにおけるサブ識別子のM以上があって、次に、噛み付いているマスクは1で広げられて、必要な長さにします。
Note that when the value of this object is the
zero-length string, this extension rule results in
a mask of all-1's being used (i.e., no 'wild card'),
and the family of view subtrees is the one view
subtree uniquely identified by the corresponding
instance of vacmViewTreeFamilySubtree.
このオブジェクトの値がゼロ長ストリングであるときに、この拡大規則が使用されるall-1のマスク(すなわち、'ワイルドカード'がない)をもたらして、視点下位木のファミリーがvacmViewTreeFamilySubtreeの対応するインスタンスによって唯一特定された1つの視点下位木であることに注意してください。
Note that masks of length greater than zero length
do not need to be supported. In this case this
object is made read-only.
"
DEFVAL { ''H }
::= { vacmViewTreeFamilyEntry 3 }
ゼロ・レングスより大きい長さのマスクがサポートされる必要はないことに注意してください。 この場合、このオブジェクトは人工の書き込み禁止です。 「DEFVAL、「H、:、:、」= vacmViewTreeFamilyEntry3
vacmViewTreeFamilyType OBJECT-TYPE
SYNTAX INTEGER { included(1), excluded(2) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Indicates whether the corresponding instances of
vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask
define a family of view subtrees which is included in
or excluded from the MIB view.
"
DEFVAL { included }
::= { vacmViewTreeFamilyEntry 4 }
vacmViewTreeFamilyType OBJECT-TYPE SYNTAX INTEGERは(1)を含んで、(2)を除きました。マックス-ACCESSは現在の記述が「vacmViewTreeFamilySubtreeとvacmViewTreeFamilyMaskの対応するインスタンスが視点下位木のファミリーを定義する(MIB視点から中に含まれているか、または除かれます)か否かに関係なく、示す」STATUSを読書して作成します。 「DEFVALを含んでいます:、:、」= vacmViewTreeFamilyEntry4
vacmViewTreeFamilyStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
vacmViewTreeFamilyStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「これに、概念的なストレージタイプはこぐ」STATUSの現在の記述を読書して作成します。
Conceptual rows having the value 'permanent' need not
allow write-access to any columnar objects in the row.
"
DEFVAL { nonVolatile }
::= { vacmViewTreeFamilyEntry 5 }
'永久的'に値を持っている概念的な行は行でいずれにもアクセスを書いている円柱状のオブジェクトを許容する必要はありません。 「DEFVAL、不揮発性:、:、」= vacmViewTreeFamilyEntry5
vacmViewTreeFamilyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
vacmViewTreeFamilyStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「これほど概念的の状態はこぐ」STATUSの現在の記述を読書して作成します。
Wijnen, et al. Standards Track [Page 25] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[25ページ]。
The RowStatus TC [RFC2579] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:
RowStatus TC[RFC2579]は、この記述節が、どの状況でこの行の他のオブジェクトを変更できるかを述べるのを必要とします:
The value of this object has no effect on whether
other objects in this conceptual row can be modified.
"
::= { vacmViewTreeFamilyEntry 6 }
このオブジェクトの値はこの概念的な行の他のオブジェクトを変更できるかどうかに関して効き目がありません。 " ::= vacmViewTreeFamilyEntry6
-- Conformance information *******************************************
-- 順応情報*******************************************
vacmMIBCompliances OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
vacmMIBGroups OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }
vacmMIBCompliancesオブジェクト識別子:、:= vacmMIBConformance1vacmMIBGroupsオブジェクト識別子:、:= vacmMIBConformance2
-- Compliance statements *********************************************
-- 承諾声明*********************************************
vacmMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines which
implement the SNMP View-based Access Control Model
configuration MIB.
"
MODULE -- this module
MANDATORY-GROUPS { vacmBasicGroup }
vacmMIBCompliance MODULE-COMPLIANCE STATUSの現在の記述、「SNMP ViewベースのAccess Control Model構成がMIBであると実装するSNMPエンジンのための承諾声明。」 「MODULE--、このモジュールMANDATORY-GROUPS、」vacmBasicGroup
OBJECT vacmAccessContextMatch
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessContextMatch MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT vacmAccessReadViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessReadViewName MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT vacmAccessWriteViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessWriteViewName MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT vacmAccessNotifyViewName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessNotifyViewName MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT vacmAccessStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmAccessStorageType MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT vacmAccessStatus
MIN-ACCESS read-only
DESCRIPTION "Create/delete/modify access to the
OBJECT vacmAccessStatus MIN-ACCESS書き込み禁止記述、「アクセスを作成するか、削除する、または変更する、」
Wijnen, et al. Standards Track [Page 26] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[26ページ]。
vacmAccessTable is not required.
"
vacmAccessTableは必要ではありません。 "
OBJECT vacmViewTreeFamilyMask
WRITE-SYNTAX OCTET STRING (SIZE (0))
MIN-ACCESS read-only
DESCRIPTION "Support for configuration via SNMP of subtree
families using wild-cards is not required.
"
OBJECT vacmViewTreeFamilyMask WRITE-SYNTAX OCTET STRING、(SIZE(0))MIN-ACCESS書き込み禁止記述、「ワイルドカードを使用している下位木ファミリーのSNMPを通した構成のサポートは必要ではありません」。 "
OBJECT vacmViewTreeFamilyType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmViewTreeFamilyType MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT vacmViewTreeFamilyStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vacmViewTreeFamilyStorageType MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT vacmViewTreeFamilyStatus
MIN-ACCESS read-only
DESCRIPTION "Create/delete/modify access to the
vacmViewTreeFamilyTable is not required.
"
::= { vacmMIBCompliances 1 }
OBJECT vacmViewTreeFamilyStatus MIN-ACCESS書き込み禁止記述、「vacmViewTreeFamilyTableへのアクセスを作成するか、削除する、または変更してください、必要でない、」 " ::= vacmMIBCompliances1
-- Units of conformance **********************************************
-- ユニットの順応**********************************************
vacmBasicGroup OBJECT-GROUP
OBJECTS {
vacmContextName,
vacmGroupName,
vacmSecurityToGroupStorageType,
vacmSecurityToGroupStatus,
vacmAccessContextMatch,
vacmAccessReadViewName,
vacmAccessWriteViewName,
vacmAccessNotifyViewName,
vacmAccessStorageType,
vacmAccessStatus,
vacmViewSpinLock,
vacmViewTreeFamilyMask,
vacmViewTreeFamilyType,
vacmViewTreeFamilyStorageType,
vacmViewTreeFamilyStatus
}
STATUS current
DESCRIPTION "A collection of objects providing for remote
configuration of an SNMP engine which implements
vacmBasicGroupオブジェクト群対象、vacmContextName、vacmGroupName、vacmSecurityToGroupStorageType、vacmSecurityToGroupStatus、vacmAccessContextMatch、vacmAccessReadViewName、vacmAccessWriteViewName、vacmAccessNotifyViewName、vacmAccessStorageType、vacmAccessStatus、vacmViewSpinLock、vacmViewTreeFamilyMask、vacmViewTreeFamilyType、vacmViewTreeFamilyStorageType、vacmViewTreeFamilyStatus; STATUSの現在の記述は「SNMPエンジンのリモート構成にどの道具を提供するオブジェクトの収集」です。
Wijnen, et al. Standards Track [Page 27] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[27ページ]。
the SNMP View-based Access Control Model.
"
::= { vacmMIBGroups 1 }
SNMPの視点ベースのアクセス制御モデル。 " ::= vacmMIBGroups1
END
終わり
5. Intellectual Property
5. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
6. Acknowledgements
6. 承認
This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members:
このドキュメントはSNMPv3作業部会の取り組みの結果です。 いくつかの特別な感謝がそうである、以下のSNMPv3 WGメンバー:
Harald Tveit Alvestrand (Maxware)
Dave Battle (SNMP Research, Inc.)
Alan Beard (Disney Worldwide Services)
Paul Berrevoets (SWI Systemware/Halcyon Inc.)
Martin Bjorklund (Ericsson)
Uri Blumenthal (IBM T.J. Watson Research Center)
Jeff Case (SNMP Research, Inc.)
John Curran (BBN)
Mike Daniele (Compaq Computer Corporation)
T. Max Devlin (Eltrax Systems)
John Flick (Hewlett Packard)
Rob Frye (MCI)
Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
David Harrington (Cabletron Systems Inc.)
ハラルドTveit Alvestrand(Maxware)デーヴBattle(SNMP研究Inc.) アランBeard(ディズニーの世界的なServices)ポールBerrevoets(SWI Systemware/アルキュオーン株式会社) マーチンBjorklund(エリクソン)ユリ・ブルーメンソル(IBM T.J.ワトソン研究所) ジェフCase(SNMP研究Inc.) ジョン・カラン(BBN)・マイク・ダニエル(コンパックコンピュータ社)・T.マックス・デブリン(Eltraxシステム)ジョンFlick(ヒューレットパッカード)ロブフライ(MCI)ウェスHardaker、(U.C.デイヴィス、情報技術--直流、A.S.) デヴィッド・ハリントン(CabletronシステムInc.)
Wijnen, et al. Standards Track [Page 28] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[28ページ]。
Lauren Heintz (BMC Software, Inc.)
N.C. Hien (IBM T.J. Watson Research Center)
Michael Kirkham (InterWorking Labs, Inc.)
Dave Levi (SNMP Research, Inc.)
Louis A Mamakos (UUNET Technologies Inc.)
Joe Marzot (Nortel Networks)
Paul Meyer (Secure Computing Corporation)
Keith McCloghrie (Cisco Systems)
Bob Moore (IBM)
Russ Mundy (TIS Labs at Network Associates)
Bob Natale (ACE*COMM Corporation)
Mike O'Dell (UUNET Technologies Inc.)
Dave Perkins (DeskTalk)
Peter Polkinghorne (Brunel University)
Randy Presuhn (BMC Software, Inc.)
David Reeder (TIS Labs at Network Associates)
David Reid (SNMP Research, Inc.)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (TU Braunschweig)
Bob Stewart (Cisco Systems)
Mike Thatcher (Independent Consultant)
Bert Wijnen (IBM T.J. Watson Research Center)
ローレン・ハインツ(BMCソフトウェアInc.) ノースカロライナ州Hien(IBM T.J.ワトソン研究所) マイケル・カーカム(研究室Inc.を織り込みます) デーヴ・レビ(SNMP研究Inc.) ルイスはMamakos(UUNET技術Inc.)です。 ジョーMarzot(ノーテルネットワーク)ポール・マイヤー(安全なコンピューティング社)キースMcCloghrie(シスコシステムズ)ボブ・ムーア(IBM)・ラス・マンディ(ネットワーク関連のTIS研究室)ボブNatale(ACE*COMM社)マイク・オデル(UUNET技術Inc.) デーヴ・パーキンス(DeskTalk)・ピーター・ポーキングホーン(Brunel大学)ランディPresuhn(BMCソフトウェアInc.) デヴィッド・リーダー(ネットワーク関連のTIS研究室)・デヴィッド・リード(SNMP研究Inc.) アレックセイ・ロマーノフ(上質の定足数)ショーンRouthier(エピローグ)ユルゲンSchoenwaelder(TUブラウンシュバイク)ボブ・スチュワート(シスコシステムズ)マイク屋根を葺く人(独立しているコンサルタント)バートWijnen(IBM T.J.ワトソン研究所)
The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were:
ドキュメントはSNMP Advisory TeamのためのIETF SecurityとAdministrative Framework Evolutionの推薦に基づいています。 そのAdvisory Teamのメンバーは以下の通りでした。
David Harrington (Cabletron Systems Inc.)
Jeff Johnson (Cisco Systems)
David Levi (SNMP Research Inc.)
John Linn (Openvision)
Russ Mundy (Trusted Information Systems) chair
Shawn Routhier (Epilogue)
Glenn Waters (Nortel)
Bert Wijnen (IBM T. J. Watson Research Center)
デヴィッド・ハリントン(CabletronシステムInc.) ジェフ・ジョンソン(シスコシステムズ)・デヴィッド・レビ(SNMP研究Inc.) ジョン・リン(Openvision)・ラス・マンディ(情報システムを信じる)いすショーンRouthier(エピローグ)グレンWaters(ノーテル)バートWijnen(IBM T.J.ワトソン研究所)
As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*:
Advisory TeamとSNMPv3作業部会憲章によって推薦されるように、デザインは前のRFCsと草稿によって実用的であるのと同じくらい多くを取り入れます。 その結果、特別な感謝はSNMPv2uとSNMPv2*として知られている前のデザインの作者のためです:
Jeff Case (SNMP Research, Inc.)
David Harrington (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
Keith McCloghrie (Cisco Systems)
Brian O'Keefe (Hewlett Packard)
Marshall T. Rose (Dover Beach Consulting)
ジェフCase(SNMP研究Inc.) デヴィッド・ハリントン(CabletronシステムInc.) デヴィッド・レビ(SNMP研究Inc.) キースMcCloghrie(シスコシステムズ)ブライアン・オキーフ(ヒューレットパッカード)・マーシャルT.は上昇しました。(ドーヴァーのビーチコンサルティング)
Wijnen, et al. Standards Track [Page 29] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[29ページ]。
Jon Saperia (BGS Systems Inc.)
Steve Waldbusser (International Network Services)
Glenn W. Waters (Bell-Northern Research Ltd.)
ジョンSaperia(BGSシステムInc.) スティーブWaldbusser(国際ネットワークサービス)グレンW.水域(ベル-北研究株式会社)
7. Security Considerations
7. セキュリティ問題
7.1. Recommended Practices
7.1. 推奨案
This document is meant for use in the SNMP architecture. The View- based Access Control Model described in this document checks access rights to management information based on:
このドキュメントはSNMPアーキテクチャにおける使用のために意味されます。 本書では説明されたViewのベースのAccess Control Modelは以下に基づいて経営情報にアクセス権をチェックします。
- contextName, representing a set of management information at the
managed system where the Access Control module is running.
- Access Controlモジュールが稼働している管理されたシステムに1セットの経営情報を表すcontextName。
- groupName, representing a set of zero or more securityNames. The
combination of a securityModel and a securityName is mapped into a
group in the View-based Access Control Model.
- 1セットのゼロを表すgroupNameか、より多くのsecurityNames。 securityModelとsecurityNameの組み合わせはViewベースのAccess Control Modelのグループに写像されます。
- securityModel under which access is requested.
- securityModelはどのアクセスで要求されているか。
- securityLevel under which access is requested.
- securityLevelはどのアクセスで要求されているか。
- operation performed on the management information.
- 操作は経営情報に働きました。
- MIB views for read, write or notify access.
- MIBはアクセサリーに読書に関して見るか、書くか、または通知します。
When the User-based Access Control module is called for checking access rights, it is assumed that the calling module has ensured the authentication and privacy aspects as specified by the securityLevel that is being passed.
UserベースのAccess Controlモジュールがアクセス権をチェックするために呼ばれるとき、呼ぶモジュールが渡されているsecurityLevelによる指定されるとしての局面を認証とプライバシーに確実にしたと思われます。
When creating entries in or deleting entries from the vacmViewTreeFamilyTable it is important to do such in the sequence as recommended in the DESCRIPTION clause of the vacmViewTreeFamilyTable definition. Otherwise unwanted access may be granted while changing the entries in the table.
vacmViewTreeFamilyTableからエントリーを作成するか、またはエントリーを削除するとき、vacmViewTreeFamilyTable定義の記述節で推薦される系列でそのようなものをするのは重要です。 そうでなければ、求められていないアクセスはテーブルでエントリーを変えている間、承諾されるかもしれません。
7.2. Defining Groups
7.2. グループを定義します。
The groupNames are used to give access to a group of zero or more securityNames. Within the View-Based Access Control Model, a groupName is considered to exist if that groupName is listed in the vacmSecurityToGroupTable.
groupNamesは、ゼログループか、より多くのsecurityNamesへのアクセスを与えるのに使用されます。 ベースのView Access Control Modelの中では、そのgroupNameがvacmSecurityToGroupTableに記載されるなら、groupNameが存在すると考えられます。
By mapping the combination of a securityModel and securityName into a groupName, an SNMP Command Generator application can add/delete securityNames to/from a group, if proper access is allowed.
securityModelとsecurityNameの組み合わせをgroupNameに写像することによって、SNMP Command Generatorアプリケーションは、グループからの/にsecurityNamesを加えるか、または削除できます、適切なアクセスが許されているなら。
Wijnen, et al. Standards Track [Page 30] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[30ページ]。
Further it is important to realize that the grouping of <securityModel, securityName> tuples in the vacmSecurityToGroupTable does not take securityLevel into account. It is therefore important that the security administrator uses the securityLevel index in the vacmAccessTable to separate noAuthNoPriv from authPriv and/or authNoPriv access.
さらに、<securityModel、vacmSecurityToGroupTableのtuplesがするsecurityName>の組分けがsecurityLevelを考慮に入れないとわかるのは重要です。 したがって、セキュリティ管理者がauthPriv、そして/または、authNoPrivアクセサリーとnoAuthNoPrivを切り離すのにvacmAccessTableのsecurityLevelインデックスを使用するのは、重要です。
7.3. Conformance
7.3. 順応
For an implementation of the View-based Access Control Model to be conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB according to the vacmMIBCompliance. It also SHOULD implement the initial configuration, described in appendix A.
ViewベースのAccess Control Modelの実装がconformantであるために、vacmMIBComplianceによると、それはSNMP-VIEWベースのACM-MIBを実装しなければなりません。 それ、また、SHOULDは付録Aで説明された初期の構成を実装します。
7.4. Access to the SNMP-VIEW-BASED-ACM-MIB
7.4. SNMPの視点ベースのACM-MIBへのアクセス
The objects in this MIB control the access to all MIB data that is accessible via the SNMP engine and they may be considered sensitive in many environments. It is important to closely control (both read and write) access to these to these MIB objects by using appropriately configured Access Control models (for example the View-based Access Control Model as specified in this document).
このMIBの目的はすべてのSNMPエンジンを通してアクセス可能なMIBデータへのアクセスを制御します、そして、それらは多くの環境で敏感であると考えられるかもしれません。 適切に構成されたAccess Controlモデル(例えば、このドキュメントの指定されるとしてのViewベースのAccess Control Model)を使用することによってしっかりとこれらのMIBオブジェクトにこれらへのアクセスを制御するのは(読んで、書きます)重要です。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[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月。
[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月のための順応声明。」
[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、「Simple Network Managementプロトコル(SNMP)管理Frameworksについて説明するためのArchitecture」、STD62、RFC3411、2002年12月。
Wijnen, et al. Standards Track [Page 31] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[31ページ]。
[SNMP3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
[SNMP3412] ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、STD62、RFC3412、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月。
8.2. Informative References
8.2. 有益な参照
[ISO-ASN.1] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[ISO-ASN.1] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)
Wijnen, et al. Standards Track [Page 32] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[32ページ]。
Appendix A - Installation
付録A--インストール
A.1. Installation Parameters
A.1。 インストールパラメタ
During installation, an authoritative SNMP engine which supports this View-based Access Control Model SHOULD be configured with several initial parameters. These include for the View-based Access Control Model:
インストール、このViewベースのAccess Control Model SHOULDをサポートする正式のSNMPエンジンの間、いくつかの初期値パラメタで、構成されてください。 これらはViewベースのAccess Control Modelのために以下を含んでいます。
1) A security configuration
1) セキュリティ設定
The choice of security configuration determines if initial
configuration is implemented and if so how. One of three possible
choices is selected:
セキュリティ設定の選択は、初期の構成が実装されるかどうか決定します、そして、そうだとすれば、どのようにですか? 3つの可能な選択の1つは選択されます:
- initial-minimum-security-configuration
- initial-semi-security-configuration
- initial-no-access-configuration
- 初期の最小のセキュリティ設定--準セキュリティ設定に頭文字をつけてください--アクセス構成に全く頭文字をつけないでください。
In the case of a initial-no-access-configuration, there is no
initial configuration, and so the following steps are irrelevant.
aの場合では、アクセス構成に全く頭文字をつけないでください、そして、どんな初期の構成もないので、以下のステップは無関係です。
2) A default context
2) デフォルト文脈
One entry in the vacmContextTable with a contextName of "" (the
empty string), representing the default context. Note that this
table gets created automatically if a default context exists.
contextNameとvacmContextTableの1つのエントリー、「「デフォルト文脈を表す(空のストリング)。」 デフォルト文脈が存在しているならこのテーブルが自動的に作成されることに注意してください。
vacmContextName ""
vacmContextName、「」
3) An initial group
3) 初期のグループ
One entry in the vacmSecurityToGroupTable to allow access to group
"initial".
アクセスが「初期」で分類されるのを許容するvacmSecurityToGroupTableの1つのエントリー。
vacmSecurityModel 3 (USM)
vacmSecurityName "initial"
vacmGroupName "initial"
vacmSecurityToGroupStorageType anyValidStorageType
vacmSecurityToGroupStatus active
vacmSecurityModel3(USM)のvacmSecurityNameの「初期」のvacmGroupName「初期」のvacmSecurityToGroupStorageType anyValidStorageType vacmSecurityToGroupStatusアクティブです。
Wijnen, et al. Standards Track [Page 33] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[33ページ]。
4) Initial access rights
4) 初期のアクセス権
Three entries in the vacmAccessTable as follows:
以下のvacmAccessTableの3つのエントリー:
- read-notify access for securityModel USM, securityLevel
"noAuthNoPriv" on behalf of securityNames that belong to the
group "initial" to the <restricted> MIB view in the default
context with contextName "".
- securityModel USM、contextNameと共にデフォルト文脈の<の部外秘な>MIB視点へのグループ「イニシャル」に属すsecurityNamesを代表したsecurityLevel"noAuthNoPriv"のためのアクセスに読書して通知してください、「「.」
- read-write-notify access for securityModel USM, securityLevel
"authNoPriv" on behalf of securityNames that belong to the
group "initial" to the <internet> MIB view in the default
context with contextName "".
- securityModel USMのための通知している読書が、書くアクセス、グループのものsecurityNamesを代表したsecurityLevel"authNoPriv"がMIBがcontextNameと共にデフォルト文脈で見る>に<インターネットに「頭文字をつける」、「「.」
- if privacy is supported, read-write-notify access for
securityModel USM, securityLevel "authPriv" on behalf of
securityNames that belong to the group "initial" to the
<internet> MIB view in the default context with contextName "".
- グループのものsecurityNamesを代表したsecurityLevel"authPriv"がプライバシーがsecurityModel USMのためのサポートしていて、通知している読書が、書くアクセスであるなら、MIBがcontextNameと共にデフォルト文脈で見る>に<インターネットに「頭文字をつける」、「「.」
That translates into the following entries in the vacmAccessTable.
それはvacmAccessTableの以下のエントリーに翻訳されます。
- One entry to be used for unauthenticated access (noAuthNoPriv):
- 1つの非認証されたアクセス(noAuthNoPriv)に使用されるべきエントリー:
vacmGroupName "initial"
vacmAccessContextPrefix ""
vacmAccessSecurityModel 3 (USM)
vacmAccessSecurityLevel noAuthNoPriv
vacmAccessContextMatch exact
vacmAccessReadViewName "restricted"
vacmAccessWriteViewName ""
vacmAccessNotifyViewName "restricted"
vacmAccessStorageType anyValidStorageType
vacmAccessStatus active
vacmGroupNameがvacmAccessContextPrefixに「頭文字をつける」、「「vacmAccessSecurityModel3(USM)のvacmAccessSecurityLevel noAuthNoPriv vacmAccessContextMatchの正確なvacmAccessReadViewNameがvacmAccessWriteViewNameを「制限した」、「「「制限されて」vacmAccessNotifyViewName vacmAccessStorageType anyValidStorageType vacmAccessStatusアクティブ」
- One entry to be used for authenticated access (authNoPriv) with
optional privacy (authPriv):
- 1つの認証されたアクセス(authNoPriv)に任意のプライバシー(authPriv)で使用されるべきエントリー:
vacmGroupName "initial"
vacmAccessContextPrefix ""
vacmAccessSecurityModel 3 (USM)
vacmAccessSecurityLevel authNoPriv
vacmAccessContextMatch exact
vacmAccessReadViewName "internet"
vacmAccessWriteViewName "internet"
vacmAccessNotifyViewName "internet"
vacmAccessStorageType anyValidStorageType
vacmAccessStatus active
vacmGroupNameがvacmAccessContextPrefixに「頭文字をつける」、「「vacmAccessSecurityModel3(USM)のvacmAccessSecurityLevel authNoPriv vacmAccessContextMatchの正確なvacmAccessReadViewName「インターネット」vacmAccessWriteViewName「インターネット」vacmAccessNotifyViewName「インターネット」vacmAccessStorageType anyValidStorageType vacmAccessStatusアクティブ」
Wijnen, et al. Standards Track [Page 34] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[34ページ]。
5) Two MIB views, of which the second one depends on the security
configuration.
5) 2つのMIB視点。(それに関する2番目のものはその視点のためにセキュリティ構成に依存します)。
- One view, the <internet> view, for authenticated access:
- 1つの視点、認証されたアクセスのための<インターネット>視点:
- the <internet> MIB view is the following subtree:
"internet" (subtree 1.3.6.1)
- <インターネット>MIB視点は以下の下位木です: 「インターネット」(下位木1.3.6、.1)
- A second view, the <restricted> view, for unauthenticated
access. This view is configured according to the selected
security configuration:
- 2番目の視点であり、<は非認証されたアクセサリーのために>視点を制限しました。 選択されたセキュリティ構成に従って、この視点は構成されます:
- For the initial-no-access-configuration there is no default
initial configuration, so no MIB views are pre-scribed.
- 初期のノーが構成にアクセスしているように、どんなデフォルトの初期の構成もないので、MIB視点は全く定められません。
- For the initial-semi-secure-configuration:
- 初期の準安全な構成のために:
the <restricted> MIB view is the union of these subtrees:
(a) "system" (subtree 1.3.6.1.2.1.1) [RFC3918]
(b) "snmp" (subtree 1.3.6.1.2.1.11) [RFC3918]
(c) "snmpEngine" (subtree 1.3.6.1.6.3.10.2.1) [RFC3411]
(d) "snmpMPDStats" (subtree 1.3.6.1.6.3.11.2.1) [RFC3412]
(e) "usmStats" (subtree 1.3.6.1.6.3.15.1.1) [RFC3414]
制限された>MIBが見る<はこれらの下位木の組合です: (a) 「システム」、(下位木1.3.6.1.2.1.1[RFC3918])(b)"snmp"、(下位木1.3.6.1.2.1.11[RFC3918])(c)"snmpEngine"、(下位木1.3.6.1.6.3.10.2.1[RFC3411])(d)「snmpMPDStats」、(下位木1.3.6.1.6.3.11.2.1[RFC3412])(e)「usmStats」、(下位木1.3.6、.1、.6、.3、.15、.1、.1)[RFC3414]
- For the initial-minimum-secure-configuration:
- 初期の最小の安全な構成のために:
the <restricted> MIB view is the following subtree.
"internet" (subtree 1.3.6.1)
制限された>MIBが見る<は以下の下位木です。 「インターネット」(下位木1.3.6、.1)
This translates into the following "internet" entry in the vacmViewTreeFamilyTable:
これはvacmViewTreeFamilyTableの以下の「インターネット」エントリーに翻訳されます:
minimum-secure semi-secure
---------------- ---------------
vacmViewTreeFamilyViewName "internet" "internet"
vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1
vacmViewTreeFamilyMask "" ""
vacmViewTreeFamilyType 1 (included) 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
vacmViewTreeFamilyStatus active active
最小に安全である、準安全---------------- --------------- vacmViewTreeFamilyViewName「インターネット」「インターネット」vacmViewTreeFamilySubtree1.3.6.1 1.3.6.1vacmViewTreeFamilyMask、「「「「1(含まれている)vacmViewTreeFamilyStorageType anyValidStorageTypeのvacmViewTreeFamilyType1(含まれています)のanyValidStorageType vacmViewTreeFamilyStatusのアクティブな能動態」
Wijnen, et al. Standards Track [Page 35] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[35ページ]。
In addition it translates into the following "restricted" entries in the vacmViewTreeFamilyTable:
さらに、vacmViewTreeFamilyTableの以下の「制限された」エントリーに翻訳します:
minimum-secure semi-secure
---------------- ---------------
vacmViewTreeFamilyViewName "restricted" "restricted"
vacmViewTreeFamilySubtree 1.3.6.1 1.3.6.1.2.1.1
vacmViewTreeFamilyMask "" ""
vacmViewTreeFamilyType 1 (included) 1 (included)
vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
vacmViewTreeFamilyStatus active active
最小に安全である、準安全---------------- --------------- vacmViewTreeFamilyViewName「制限された」「制限された」vacmViewTreeFamilySubtree1.3.6.1 1.3.6.1.2.1、.1vacmViewTreeFamilyMask、「「「「1(含まれている)vacmViewTreeFamilyStorageType anyValidStorageTypeのvacmViewTreeFamilyType1(含まれています)のanyValidStorageType vacmViewTreeFamilyStatusのアクティブな能動態」
vacmViewTreeFamilyViewName "restricted" vacmViewTreeFamilySubtree 1.3.6.1.2.1.11 vacmViewTreeFamilyMask "" vacmViewTreeFamilyType 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName「制限された」vacmViewTreeFamilySubtree1.3.6.1、.2、.1、.11vacmViewTreeFamilyMask、「「vacmViewTreeFamilyType1(含まれています)vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatusアクティブ」
vacmViewTreeFamilyViewName "restricted" vacmViewTreeFamilySubtree 1.3.6.1.6.3.10.2.1 vacmViewTreeFamilyMask "" vacmViewTreeFamilyType 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName「制限された」vacmViewTreeFamilySubtree1.3.6.1、.6、.3、.10、.2、.1vacmViewTreeFamilyMask、「「vacmViewTreeFamilyType1(含まれています)vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatusアクティブ」
vacmViewTreeFamilyViewName "restricted" vacmViewTreeFamilySubtree 1.3.6.1.6.3.11.2.1 vacmViewTreeFamilyMask "" vacmViewTreeFamilyType 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName「制限された」vacmViewTreeFamilySubtree1.3.6.1、.6、.3、.11、.2、.1vacmViewTreeFamilyMask、「「vacmViewTreeFamilyType1(含まれています)vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatusアクティブ」
vacmViewTreeFamilyViewName "restricted" vacmViewTreeFamilySubtree 1.3.6.1.6.3.15.1.1 vacmViewTreeFamilyMask "" vacmViewTreeFamilyType 1 (included) vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatus active
vacmViewTreeFamilyViewName「制限された」vacmViewTreeFamilySubtree1.3.6.1、.6、.3、.15、.1、.1vacmViewTreeFamilyMask、「「vacmViewTreeFamilyType1(含まれています)vacmViewTreeFamilyStorageType anyValidStorageType vacmViewTreeFamilyStatusアクティブ」
B. Change Log
B。 チェンジログ
Changes made since RFC 2575:
変化は以来、RFCを2575にしました:
- Removed reference from abstract as per RFC-Editor guidelines
- Updated references
- RFC-エディタガイドラインに従って要約からの取り除かれた参照--アップデートされた参照
Wijnen, et al. Standards Track [Page 36] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[36ページ]。
Changes made since RFC 2275:
変化は以来、RFCを2275にしました:
- Added text to vacmSecurityToGroupStatus DESCRIPTION clause to
clarify under which conditions an entry in the
vacmSecurityToGroupTable can be made active.
- Added REVISION clauses to MODULE-IDENTITY
- Clarified text in vacmAccessTable DESCRIPTION clause.
- Added a DEFVAL clause to vacmAccessContextMatch object.
- Added missing columns in Appendix A and re-arranged for
clarity.
- Fixed oids in appendix A.
- Use the PDU Class terminology instead of RFC1905 PDU types.
- Added section 7.4 about access control to the MIB.
- Fixed references to new/revised documents
- Fix Editor contact information.
- fixed spelling errors
- removed one vacmAccesEntry from sample in appendix A.
- made some more clarifications.
- updated acknowledgement section.
- vacmSecurityToGroupTableでどの条件のもとでエントリーをはっきりさせるかvacmSecurityToGroupStatus記述節への加えられたテキストをアクティブにすることができます。 - MODULE-IDENTITYへの付記されたREVISION節--vacmAccessTable記述節のテキストをはっきりさせました。 - DEFVAL節をvacmAccessContextMatch物に追加しました。 - Appendix Aでなくなったコラムを加えて、明快ために転位しました。 - 付録A.の固定oids--RFC1905 PDUタイプの代わりにPDU Class用語を使用してください。 - アクセスに関する加えられたセクション7.4はMIBに制御されます。 - 新しいか改訂されたドキュメントの固定参照--Editorに問い合わせ先を固定してください。 - 固定スペルミス(付録A.のサンプルからの1取り外されたvacmAccesEntry)はそれ以上の明確化をしました。 - 承認部をアップデートしました。
Wijnen, et al. Standards Track [Page 37] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[37ページ]。
Editors' Addresses
エディタのアドレス
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands
バートWijnenルーセントテクノロジーズSchagen33 3461GLリンスホーテン・オランダ
Phone: +31-348-480-685 EMail: bwijnen@lucent.com
以下に電話をしてください。 +31-348-480-685 メールしてください: bwijnen@lucent.com
Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA
ランディPresuhn BMCソフトウェアInc.2141の北の最初に、通りサンノゼ、カリフォルニア95131米国
Phone: +1 408-546-1006 EMail: randy_presuhn@bmc.com
以下に電話をしてください。 +1 408-546-1006 メールしてください: randy_presuhn@bmc.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
西タスマン・DriveキースMcCloghrieシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Phone: +1-408-526-5260 EMail: kzm@cisco.com
以下に電話をしてください。 +1-408-526-5260 メールしてください: kzm@cisco.com
Wijnen, et al. Standards Track [Page 38] RFC 3415 VACM for the SNMP December 2002
Wijnen、他 規格は2002年12月にSNMPのためにRFC3415VACMを追跡します[38ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Wijnen, et al. Standards Track [Page 39]
Wijnen、他 標準化過程[39ページ]
一覧
スポンサーリンク
