RFC3318 日本語訳
3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K.Chan, K. McCloghrie. March 2003. (Format: TXT=144530 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Sahita, Ed.
Request for Comments: 3318 S. Hahn
Category: Informational Intel Labs
K. Chan
Nortel Networks
K. McCloghrie
Cisco Systems
March 2003
ワーキンググループR.Sahita、エドをネットワークでつないでください。コメントのために以下を要求してください。 3318秒間ハーンCategory: 情報のインテル研究室K.チェンノーテルは2003年のシスコシステムズの行進のときにK.McCloghrieをネットワークでつなぎます。
Framework Policy Information Base
フレームワーク方針Information基地
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning.
このドキュメントは1セットの支給方針がCommonオープンPolicy Service(COPS)を使用して、Provisioningのために議定書を作るすべてのクライアントにとって、一般的なPRovisioning Classes(PRCs)と原文のコンベンションを定義します。
Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well- defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB).
Policy Provisioning情報(SPPI)の構造は、次にそのデバイスで方針を構成する目的のためにネットワークデバイスに伝えることができる方針情報を指定するために構造について説明します。 この構造の基礎となるモデルはPolicy Information基地(PIB)と呼ばれる仮想情報店にある定義された井戸(PRCs)とこれらのクラスのインスタンス(PRIs)の1つです。
One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security.
支給方針への1つの方法が食糧を供給する拡大を伴う(COPS)プロトコルによってあります。 このプロトコルは複数のクライアントをサポートします。それはそれぞれQoS、仮想私設網、またはセキュリティなどの特定保険証券ドメインへの支給方針がそうするかもしれません。
As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject- categories (client-types) and need to be present in each.
Policy Provisioning(COPS-PR)のためにCOPS用法で説明されるように、各クライアントは非重なっていて独立しているセットのPIBモジュールをサポートします。 しかしながら、いくつかのPRovisioning Classesが、すべての対象カテゴリ(クライアントタイプ)に共通であり、それぞれに存在している必要があります。
Sahita, et. al. Informational [Page 1] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[1ページ]情報のRFC3318フレームワーク方針情報基地の行進
Table of Contents
目次
Conventions used in this document.................................2
1. Glossary.......................................................2
2. General PIB Concepts...........................................3
2.1. Roles......................................................3
2.1.1. An Example.............................................5
2.2. Management of Role-Combinations from the PDP...............6
2.3. Updating a Request State...................................7
2.3.1 Full Request State......................................8
2.3.2 Installing PRIs in a Request............................8
2.3.3 Updating PRIs in a Request..............................8
2.3.4 Removing PRIs from a Request............................9
2.3.5 Removing EXTENDED, AUGMENTED PRIs.......................9
2.3.6 Error Handling in Request updates.......................9
2.4. Multiple PIB Instances....................................10
2.5. Reporting and Configuring of Device Capabilities..........11
2.6. Reporting of Device Limitations...........................12
3. The Framework TC PIB module...................................12
4. Summary of the Framework PIB..................................17
4.1. Base PIB classes Group....................................17
4.2. Device Capabilities group.................................19
4.3. Classifier group..........................................20
4.4. Marker group..............................................20
5. The Framework PIB Module......................................21
6. Security Considerations.......................................66
7. IANA Considerations...........................................67
8. References....................................................67
8.1 Normative References.......................................67
8.2 Informative References.....................................68
9. Acknowledgments...............................................68
10. Authors' Addresses...........................................69
11. Full Copyright Statement.....................................70
このドキュメントで中古のコンベンション…2 1. 用語集…2 2. 一般PIB概念…3 2.1. 役割…3 2.1.1. 例…5 2.2. PDPからの役割組み合わせの管理…6 2.3. 要求状態をアップデートします…7 2.3 .1 完全な要求状態…8 2.3 .2 PRIsを要求にインストールします…8 2.3 .3 要求でPRIsをアップデートします…8 2.3 .4 要求からPRIsを取り外します…9 2.3 .5 広げられて、増大しているPRIsを取り外します…9 2.3 .6 Requestアップデートにおける誤りHandling…9 2.4. 複数のPIBインスタンス…10 2.5. デバイス能力の報告と構成…11 2.6. デバイス制限について報告します…12 3. Framework TC PIBモジュール…12 4. フレームワークPIBの概要…17 4.1. 基地のPIBはGroupを分類します…17 4.2. デバイスCapabilitiesは分類します…19 4.3. クラシファイアグループ…20 4.4. マーカーグループ…20 5. フレームワークPIBモジュール…21 6. セキュリティ問題…66 7. IANA問題…67 8. 参照…67 8.1 標準の参照…67 8.2 有益な参照…68 9. 承認…68 10. 作者のアドレス…69 11. 完全な著作権宣言文…70
Conventions used in this document
本書では使用されるコンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1. Glossary
1. 用語集
PRC PRovisioning Class. A type of policy data. See [POLTERM].
PRI PRovisioning Instance. An instance of a PRC. See [POLTERM].
PIB Policy Information Base. The database of policy information.
See [POLTERM]
PDP Policy Decision Point. See [RAP-FRAMEWORK].
PEP Policy Enforcement Point. See [RAP-FRAMEWORK].
クラスに食糧を供給するPRC。 一種の方針データ。 [POLTERM]を見てください。 インスタンスに食糧を供給するPRI。 PRCのインスタンス。 [POLTERM]を見てください。 PIB方針Information基地。 方針情報に関するデータベース。 [POLTERM]PDP政策決定点がわかってください。 [ラップフレームワーク]を見てください。 方針実施ポイントを元気づけてください。 [ラップフレームワーク]を見てください。
Sahita, et. al. Informational [Page 2] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[2ページ]情報のRFC3318フレームワーク方針情報基地の行進
2. General PIB Concepts
2. 一般PIB概念
2.1. Roles
2.1. 役割
The policy to apply to an interface may depend on many factors, such as immutable characteristics of the interface (e.g., Ethernet or frame relay), the status of the interface (e.g., half or full duplex), or user configuration (e.g., branch office or headquarters interface). Rather than specifying policies explicitly for each interface of all devices in the network, policies are specified in terms of interface functionality.
インタフェースに付ける方針を多くの要素に依存するかもしれません、インタフェース(例えば、イーサネットかフレームリレー)の不変の特性、インタフェース(例えば、半分か全二重)、またはユーザ構成の状態などのように(例えば、支店か本部が連結します)。 明らかにネットワークにおけるすべてのデバイスの各インタフェースに方針を指定するよりむしろ、方針はインタフェースの機能性で指定されます。
To describe these functionalities of an interface, we use the concept of "Roles". A Role is simply a string that is associated with an interface. A given interface may have any number of roles simultaneously. Provisioning classes have an attribute called a "RoleCombination" which is a lexicographically ordered set of roles. Instances of a given PRovisioning Class are applied to an interface if and only if the set of roles in the role combination matches the set of the roles of the interface.
インタフェースのこれらの機能性について説明するために、私たちは「役割」の概念を使用します。 Roleは単にインタフェースに関連しているストリングです。 与えられたインタフェースには、同時に、いろいろな役割があるかもしれません。 クラスに食糧を供給して、辞書編集の順序集合の役割である"RoleCombination"と呼ばれる属性を持ってください。 そして、与えられたPRovisioning Classのインスタンスがインタフェースに付けられる、役割の組み合わせにおける役割のセットがインタフェースの役割のセットに合っている場合にだけ。
Thus, roles provide a way to bind policy to interfaces without having to explicitly identify interfaces in a consistent manner across all network devices. That is, roles provide a level of indirection to the application of a set of policies to specific interfaces. This separates the policy definition from device implementation specific interface identification. Furthermore, if the same policy is being applied to several interfaces, that policy needs to be pushed to the device only once, rather than once per interface, as long as the interfaces are configured with the same role combination.
したがって、役割はすべてのネットワークデバイスの向こう側に一貫した方法で明らかにインタフェースを特定する必要はなくてインタフェースに方針を縛る方法を提供します。 すなわち、役割は特定のインタフェースへの1セットの方針の適用に間接指定のレベルを提供します。 これはデバイスの実装の特定のインタフェース識別と方針定義を切り離します。 その上、同じ方針がいくつかのインタフェースに付けることにされるのであるなら、その方針は、インタフェース単位で一度であるというよりむしろ一度だけデバイスに押される必要があります、インタフェースが同じ役割の組み合わせによって構成される限り。
We point out that, in the event that the administrator needs to have a unique policy for each interface, the administrator can configure each interface with a unique role.
私たちは、管理者が各インタフェースへのユニークな方針を必要とする場合管理者がユニークな役割との各インタフェースを構成できると指摘します。
The PEP sends all its Capability Set Names, Role Combinations, Policy Controlled Interfaces, and their relationships to the PDP in the first COPS request (REQ) message for a handle, and whenever any updates or deletes occur. The PDP can install new instances or change existing instances of these PRIs. This operation can also occur in subsequent request messages generated in response to COPS state synchronization (SSQ) requests and local configuration changes.
そして、PEPがハンドルへの最初のCOPS要求(REQ)メッセージのPDPとのすべてのCapability Set Names、Role Combinations、Policy Controlled Interfaces、および彼らの関係を送る、いつ、いずれもアップデートするか、または削除するか、起こってください。 PDPは新しいインスタンスをインストールするか、またはこれらのPRIsの既存のインスタンスを変えることができます。 また、この操作はCOPS州の同期(SSQ)要求に対応して発生しているその後の要求メッセージと地方の構成変更で起こることができます。
The comparing of roles (or role combinations) is case sensitive.
役割(または、役割の組み合わせ)の比較は大文字と小文字を区別しています。
Sahita, et. al. Informational [Page 3] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[3ページ]情報のRFC3318フレームワーク方針情報基地の行進
By convention, when formatting the role-combination for exchange within a protocol message, within a PIB object's value, or as a printed value, the set is formatted in lexicographical order of the role's ASCII values; that is, the role that is first is formatted first. For example, "a+b" and "b+a" are NOT different role- combinations; rather, they are different formatting of the same role-combination, and hence for this example:
PIBオブジェクトの値の中でプロトコルメッセージの中で交換のための役割組み合わせをフォーマットするときのコンベンションか、印刷された値として、セットは役割のASCII値の辞書編集の注文でフォーマットされます。 すなわち、1番目である役割は最初に、フォーマットされます。 例えば、「a+b」と「b+a」は異なった役割の組み合わせではありません。 むしろ、それらは、同じ役割組み合わせの異なった形式であり、したがって、この例のためにそうです:
- "a+b" is the valid formatting of that role-combination, - "b+a" is an invalid formatting of that role-combination.
- 「a+b」はその役割組み合わせの有効な形式です--「b+a」はその役割組み合わせの無効の形式です。
The role-combination of interfaces to which no roles have been assigned is known as the "null" role-combination. (Note the deliberate use of lower-case letters for "null" so that it avoids confusion with the ASCII NULL character that has a value of zero but a length of one.)
役割が全く割り当てられていないインタフェースの役割組み合わせは「ヌル」の役割組み合わせとして知られています。 (ゼロの値にもかかわらず、1の長さを持っているASCII NULLキャラクタへの混乱を避けるように、小文字アルファベットの「ヌル」の慎重な使用に注意してください。)
In an "install" or an "install-notify" class, the wildcard role- combination "*" can be used. In addition to providing for interface-specific roles, it also allows for other optimizations in reducing the number of role-combinations for which a policy has to be specified. For example:
「インストール」か「インストールで通知している」クラス、ワイルドカード役割では、組み合わせ「*」を使用できます。 また、インタフェース特有の役割に備えることに加えて、それは方針が指定されなければならない役割組み合わせの数を減少させる際に他の最適化を考慮します。 例えば:
Suppose we have three interfaces:
私たちには3つのインタフェースがあると仮定してください:
Roles A, B and R1 are assigned to interface I1
Roles A, B and R2 are assigned to interface I2
Roles A, B and R3 are assigned to interface I3
役割のA、B、およびR1はI1 Roles Aを連結するように割り当てられます、B、R2はI2 Roles Aを連結するように割り当てられます、B、R3は、I3を連結するように割り当てられます。
Then, a PRI of a fictional IfDscpAssignTable that has the following values for its attributes:
そして、以下を持っている作り事のIfDscpAssignTableのPRIは属性のために以下を評価します。
ifDscpAssignPrid = 1
ifDscpAssignRoles = "*+A+B"
ifDscpAssignName = "4queues"
ifDscpAssignDscpMap = 1
「1ifDscpAssignPrid=ifDscpAssignRolesが」 *+A+Bと等しく」ifDscpAssignNameは"4queues"ifDscpAssignDscpMap=1と等しいです。
will apply to all three interfaces, because "*" matches with R1, R2 and R3. The policies can be assigned to an interface due to more than one wild-carded role combo matching a given interface's role combo string. The PDP should attempt to resolve conflicts between policies before sending policies to the PEP. In the situation where the PDP sends multiple policies to a PEP and they do conflict, either because of an error by the PDP or because of a device specific conflict, the PEP MUST reject the installation of the conflicting policies and return an error.
「*」がR1、R2、およびR3に合わせるので、すべての3つのインタフェースに適用するでしょう。 1つ以上の荒野でcardedされた役割のコンボのため与えられたインタフェースの役割のコンボストリングを合わせながら、方針をインタフェースに割り当てることができます。 PDPは、方針をPEPに送る前に方針の間の闘争を解決するのを試みるはずです。 PDPが複数の方針をPEPに送って、それらがPDPによる誤りのためデバイスの特定の闘争ので闘争する状況で、PEP MUSTは闘争方針のインストールを拒絶して、誤りを返します。
Sahita, et. al. Informational [Page 4] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[4ページ]情報のRFC3318フレームワーク方針情報基地の行進
Formally,
- The wildcard Role is denoted by "*",
- The "*" Role is not allowed to be defined as part of the role-
combination of an interface as notified by the PEP to the PDP; it
is only allowed in policies installed/deleted via COPS-PR from the
PDP to the PEP.
- For a policy to apply to an interface when the policy's role-
combination is "*+a+b", the interface's role-combination:
- Must include "a" and "b", and
- Can include zero or more other roles.
- The wildcard character "*" is listed before the other roles as "*"
is lexicographically before "a"; however, the wildcard matches any
zero or more roles, irrespective of lexicographical order. For
example: "*+b+e+g" would match "a+b+c+e+f+g".
正式に、ワイルドカードRoleは「*」によって指示されます--「*」の役割はPDPへの気力によって通知されるようにインタフェースの役割の組み合わせの一部と定義できません。 それはPDPからPEPまでのCOPS-PRでインストールされるか、または削除された方針で許容されているだけです。 - 「方針役割の組み合わせが適用するとき、方針はインタフェースに適用されます」*+a+b」、インタフェースの役割組み合わせ: - そして、“a"を含まなければならない、「b、」 --缶のインクルードゼロか他の、より多くの役割。 - 「*」が“a"の前で辞書編集であるときに、ワイルドカードキャラクタ「*」は他の役割の前に記載されます。 しかしながら、ワイルドカードは役割で、辞書編集のオーダーにおいて関係ない状態でどんなゼロか以上にも合っています。 例えば: 「*+b+e+g」は「+b+c+e+f+g」に合っているでしょう。
Note that the characters "+" and "*" MUST not be used in an
interface Role. The Framework Role PIB module in section 4 of this
document contains the Role and RoleCombination Textual Conventions.
インタフェースの役割にキャラクタ「+」と「*」を使用してはいけないことに注意してください。 このドキュメントのセクション4のFramework Role PIBモジュールはRoleとRoleCombination Textual Conventionsを含んでいます。
2.1.1. An Example
2.1.1. 例
The functioning of roles might be best understood by an example. Suppose I have a device with three interfaces, with roles as follows:
役割の機能は例に特に解釈されるかもしれません。 3つのインタフェース、役割は以下の通りで私がデバイスを持っていると仮定してください:
IF1: "finance"
IF2: "finance"
IF3: "manager"
IF1: 「財政」IF2: 「財政」IF3: 「マネージャ」
Suppose, I also have a PDP with two policies:
思ってください、そして、また、私は2つの方針があるPDPを持っています:
P1: Packets from finance department (role "finance") get DSCP 5
P2: Packets from managers (role "manager") get DSCP 6
P1: 大蔵省(役割の「財政」)からのパケットはDSCP5P2を手に入れます: マネージャ(役割の「マネージャ」)からのパケットはDSCP6を手に入れます。
To obtain policy, the PEP reports to the PDP that it has some interfaces with role combination "finance" and some with role combination "manager". In response, the PDP downloads policy P1 associated with role combination "finance" and downloads a second policy P2 associated with role combination "manager".
方針を得るために、PEPは、それには役割の組み合わせ「財政」といくつかとのいくつかのインタフェースが役割の組み合わせ「マネージャ」と共にあるとPDPに報告します。 応答では、PDPは役割の組み合わせ「財政」に関連している方針P1をダウンロードして、P2が役割の組み合わせ「マネージャ」に関連づけた2番目の方針をダウンロードします。
Now suppose the finance person attached to IF2 is promoted to manager and so the system administrator adds the role "manager" to IF2. The PEP now reports to the PDP that it has three role combinations: some interfaces with role combination "finance", some with role combination "manager" and some with role combination "finance+manager". In response, the PDP downloads an additional third policy associated with the new role combination "finance+manager".
今度は、システム管理者が役割の「マネージャ」をIF2に加えるようにIF2に付けられた財政人がマネージャに昇進すると仮定してください。 PEPは、現在、それには3つの役割の組み合わせがあるとPDPに報告します: 役割の組み合わせ「財政」とのいくつかのインタフェース、役割の組み合わせ「マネージャ」があるいくつか、および役割の組み合わせ「財政+マネージャ」があるいくつか。 応答では、PDPは新しい役割の組み合わせ「財政+マネージャ」に関連している3番目の追加方針をダウンロードします。
Sahita, et. al. Informational [Page 5] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[5ページ]情報のRFC3318フレームワーク方針情報基地の行進
How the PDP determines the policy for this new role combination is entirely the responsibility of the PDP. It could do so algorithmically or by rule. For example, there might be a rule that specifies that manager policy takes preference over department policy. Or there might be a third policy installed in the PDP as follows:
PDPがどうこの新しい役割の組み合わせのための方針を決定するかは、完全にPDPの責任です。 それがalgorithmicallyか規則でそうできるでしょう。 例えば、マネージャ方針が部の方針の上に好みを取ると指定する規則があるかもしれません。 または、以下のPDPにインストールされた3番目の方針があるかもしれません:
P3: Packets from finance managers (role "finance" and role
"manager") get DSCP 7
P3: 財政マネージャ(役割の「財政」と役割の「マネージャ」)からのパケットはDSCP7を手に入れます。
The point here is that the PDP is required to determine what policy applies to this new role combination and to download a third policy to the PEP for the role combination "finance+manager", even if that policy is the same as one already downloaded. The PEP is not required (or allowed) to construct policy for new role combinations from existing policy.
PDPがどんな方針がこの新しい役割の組み合わせに適用されるかを決定して、役割の組み合わせ「財政+マネージャ」で3番目の方針をPEPにダウンロードしなければならないというポイントがここにあります、その方針が1つが既にダウンロードされたのと同じであっても。 PEPは既存の方針から新しい役割の組み合わせのための方針を構成する必要はありません(または、許容されています)。
2.2. Management of Role-Combinations from the PDP
2.2. PDPからの役割組み合わせの管理
The PEP notifies the PDP of the Role-Combination assigned to each interface and capability set name in a COPS configuration request (instances of the frwkIfRoleComboTable). The first request sent to the PDP must be a 'full state' request. A 'full state' request for a PEP includes notify and install-notify table PRIs for the PEP which must be interpreted as the complete state of the PEP and must not be interpreted as updates to any previous set of PRIs sent in a previous message. Any previous PRIs from the PEP should be discarded when a 'full state' request is received for the particular request handle. A request is specified as a 'full state' request by setting the frwkPibIncarnationFullState attribute in the frwkPibIncarnation PRI sent in the request.
PEPはCOPS構成要求(frwkIfRoleComboTableのインスタンス)におけるそれぞれのインタフェースと能力セット名に割り当てられたRole-組み合わせについてPDPに通知します。 PDPに送られた最初の要求は'完全な状態'要求であるに違いありません。 a PEPインクルードがPEPの完全な州として解釈しなければならなくて、アップデートとしてPRIsのどんな前のセットにも解釈されてはいけないPEPはテーブルPRIsに通知して、インストールで通知するので、'完全な状態'要求は前のメッセージを送りました。 特定の要求ハンドルのために'完全な状態'要求を受け取るとき、PEPからのどんな前のPRIsも捨てるべきです。 frwkPibIncarnationFullState属性をfrwkPibIncarnation PRIにはめ込むのによる'完全な状態'要求が要求を送ったので、要求は指定されます。
All existing frwkIfRoleCombo instances must be sent to the PDP in the
first configuration request for a request handle. If the Role-
Combinations are not assigned specific values, default ('null')
Role-Combinations must be sent to the PDP for all ifIndices active on
the PEP and updates must be sent every time the IfIndices are
updated. The PEP may notify the PDP of the Capability sets (if any)
via the frwkCapabilitySetTable. If the PEP does not need to notify
the PDP of capability sets, it must set the capability set name in
the frwkIfRoleComboTable instances to a zero length string.
要求ハンドルを求める最初の構成要求におけるPDPにすべての既存のfrwkIfRoleComboインスタンスを送らなければなりません。 特定の値をRole組み合わせに割り当てないなら、PEPでアクティブなすべてのifIndicesのためにデフォルト('ヌル')役割組み合わせをPDPに送らなければなりません、そして、IfIndicesをアップデートするときはいつも、アップデートを送らなければなりません。 PEPはfrwkCapabilitySetTableを通してCapabilityセット(もしあれば)についてPDPに通知するかもしれません。 PEPが能力セットについてPDPに通知する必要はないなら、それはゼロ長ストリングへのfrwkIfRoleComboTableインスタンスに能力セット名をはめ込まなければなりません。
In response to this configuration request, if applicable, the PDP may send policies for the PEP in a solicited decision or must send a null decision. The PEP must then send a solicited report message for the decision.
この構成要求に対応して、適切であるなら、PDPはPEPのために請求された決定で方針を送らなければならないかもしれないか、またはヌル決定を送らなければなりません。 そして、PEPは決定への請求されたレポートメッセージを送らなければなりません。
Sahita, et. al. Informational [Page 6] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[6ページ]情報のRFC3318フレームワーク方針情報基地の行進
At any later time, the PDP can update the Role-Combinations assigned to a specific interface, identified by IfIndex, or for an aggregate, identified by the capability set name, via an unsolicited decision to the PEP on any open request handle. The PDP does this by sending updated PRIs for the frwkIfRoleComboTable.
後の何時でも、PDPはどんな開いている要求ハンドルの上のPEPとの求められていない決定でIfIndexによって特定された特定のインタフェースか能力セット名によって特定された集合のために割り当てられたRole-組み合わせをアップデートできます。 PDPはfrwkIfRoleComboTableのために送付のアップデートされたPRIsでこれをします。
When the Interface Role Combination associations are updated by the PDP, the PEP SHOULD send updated 'full state' requests for all open contexts. A context is an instantiation of the PIB module(s) namespace identified by a unique COPS handle for a particular COPS client type. This is true even if the PEP's request state changes due to an internal event or if the state is changed by the PDP. If the role-combination updates were sent by the PDP, the PEP SHOULD send these updated requests only if it can process the unsolicited decision containing the frwkIfRoleCombo PRIs successfully, and it MUST do so after sending the success report for the unsolicited decision. If the PEP failed to process the decision (i.e., the frwkIfRoleCombo PRIs), it MUST only send a failure report to the PDP.
Interface Role Combination協会がPDPによってアップデートされるとき、PEP SHOULDはすべての開いている文脈に関するアップデートされた'完全な状態'要求を送ります。 文脈は特定のCOPSクライアントタイプのためにユニークなCOPSハンドルによって特定されたPIBモジュール名前空間の具体化です。 PEPの要求状態が内部のイベントのため変化するか、または状態がPDPによって変えられるなら、これは本当です。 役割組み合わせアップデートがPDPによって送られたなら、それが首尾よくfrwkIfRoleCombo PRIsを含む求められていない決定を処理できる場合にだけ、PEP SHOULDはこれらのアップデートされた要求を求められていない決定のための成功レポートを送ります、そして、それは次々とそうしなければなりません。 PEPが決定(すなわち、frwkIfRoleCombo PRIs)を処理しなかったなら、それは異常報告書をPDPに送るだけでよいです。
On the other hand, the PDP must not expect to receive the updated requests with the revised role-combination information until after it receives a success report for these updates from the PEP. If the PDP does not receive updated requests on some request handles, the PEP must not be sent decision updates for that frwkIfRoleCombo updates, i.e., the PDP must have the previous request state that it maintained for that request handle.
他方では、PDPは、PEPからこれらのアップデートのための成功レポートを受け取った後まで改訂された役割組み合わせ情報でアップデートされた要求を受け取ると予想してはいけません。 それのための送られた決定アップデートがfrwkIfRoleComboアップデートであり、PDPがいくつかの要求ハンドルに関するアップデートされた要求を受け取らないなら、PEPは受け取ってはいけません、すなわち、PDPには、それがその要求ハンドルのために維持した前の要求状態がなければなりません。
Note that, any unsolicited decisions received by the PEP in the time period after it receives updates to its Role-Combination associations and before receiving solicited decisions for the updated requests it sent for all context handles, could possibly contain outdated policies corresponding to the old Role-Combination associations as notified by this PEP in a previous request state.
前の要求状態でこのPEPによって通知されるようにそれ(Role-組み合わせ協会とそれがすべての文脈ハンドルのために送ったアップデートされた要求のための請求された決定を受ける前にアップデートを受けた後に期間にPEPによって受けられたどんな求められていない決定)が古いRole-組み合わせ協会に対応する時代遅れの方針を含むかもしれないことに注意してください。
The PDP must respond to the updated requests by solicited decisions, sending policies if applicable or null decisions. The PEP must respond to these solicited decisions with solicited reports to complete the transaction.
適切であるかヌルの決定であるなら方針を送って、PDPは請求された決定でアップデートされた要求に応じなければなりません。 PEPは、取引を完了するために請求されたレポートでこれらの請求された決定に応じなければなりません。
2.3. Updating a Request State
2.3. 要求状態をアップデートします。
This section describes the messages exchanged between the PEP and PDP when the PEP is updating a previously sent request for a particular COPS handle. Note that a PEP can incrementally update a request only if the frwkPibIncarnationFullState attribute is shown to be supported via the supported PRC table. If this attribute is not supported, the PDP must treat all PEP requests as the full request state.
このセクションはPEPが特定のCOPSハンドルを求める以前に送られた要求をアップデートしているときPEPとPDPの間で交換されたメッセージについて説明します。 frwkPibIncarnationFullState属性がサポートしているPRCテーブルを通してサポートされるために示される場合にだけPEPが要求を増加してアップデートできることに注意してください。 この属性がサポートされないなら、PDPは完全な要求状態としてすべてのPEP要求を扱わなければなりません。
Sahita, et. al. Informational [Page 7] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[7ページ]情報のRFC3318フレームワーク方針情報基地の行進
2.3.1 Full Request State
2.3.1 完全な要求状態
When the PEP wants to send the entire request state to the PDP (for example, in response to a Synchronize State Request from the PDP), the PEP MUST send the incarnation instance with the frwkPibIncarnationFullState attribute set to 'true'.
PEPがPDP(例えばPDPからのSynchronize州Requestに対応して)に全体の要求州を送りたがっているとき、PEP MUSTはfrwkPibIncarnationFullState属性セットがある肉体化インスタンスを'本当に'送ります。
A PDP that receives an incarnation instance in the request message with this attribute set to 'true', must clear the request information it maintains for this request handle and re-install the information received.
この属性セットで'本当に'要求メッセージの肉体化インスタンスを受けて、それがこの要求ハンドルのために保守する要求情報をクリアして、情報を再インストールしなければならないPDPは受信しました。
If this attribute is set to 'false' or if the incarnation instance is missing in the request message, the request must be interpreted as an incremental update to the previous request message.
'虚偽'か肉体化インスタンスがアップデート増加としてメッセージ、要求を解釈しなければならないという要求で前の要求メッセージになくなるならこの属性が設定されるなら。
2.3.2 Installing PRIs in a Request
2.3.2 PRIsを要求にインストールすること。
If the PEP wants to install additional PRIs for a request handle, the PEP MUST ensure that the frwkPibIncarnationFullState attribute is set to 'false', and the PEP MUST use new (unused in this context) InstanceIds [SPPI] for these PRIs.
PEPが要求ハンドルのために追加PRIsをインストールしたいなら、PEP MUSTは、frwkPibIncarnationFullState属性が'誤っていること'に設定されるのを確実にします、そして、PEP MUSTはこれらのPRIsに、新しい(この文脈の未使用の)InstanceIds[SPPI]を使用します。
When a PDP receives instances with new InstanceIds for a request with the frwkPibIncarnationFullState in the incarnation instance set to 'false', or if the request has no incarnation information, it must interpret these PRIs as an incremental update to the request state and add them to the request state it maintains for this handle.
PDPがfrwkPibIncarnationFullStateとの要求のために新しいInstanceIdsと共に肉体化インスタンスセットで'誤っていること'にインスタンスを受けるとき、要求に肉体化情報が全くないなら、それは、アップデート増加として要求状態にこれらのPRIsを解釈して、このハンドルのために維持する要求状態に彼らを追加しなければなりません。
2.3.3 Updating PRIs in a Request
2.3.3 要求でPRIsをアップデートすること。
If the PEP wants to update previously installed PRIs for a request handle, the PEP MUST ensure that the frwkPibIncarnationFullState attribute is set to 'false' for these PRIs. Note that the PEP must send the same InstanceIds for the PRIs being updated. If the PEP uses new InstanceIds, the PDP must interpret them as Install's for this request state.
PEPが要求ハンドルのために以前にインストールされたPRIsをアップデートしたいなら、PEP MUSTは、frwkPibIncarnationFullState属性がこれらのPRIsにおいて'誤っていること'に設定されるのを確実にします。 PEPがアップデートされるPRIsのために同じInstanceIdsを送らなければならないことに注意してください。 PEPが新しいInstanceIdsを使用するなら、PDPは、この要求状態にInstallを解釈するので、彼らを解釈しなければなりません。
When a PDP receives a request with instances having InstanceIds that exist in its state for that handle with the frwkPibIncarnationFullState in the incarnation instance set to 'false' or if the request has no incarnation information, it must interpret these PRIs as an update to the PRIs in the request state it maintains for this handle.
PDPがそのハンドルのためにfrwkPibIncarnationFullStateと共に州に存在するInstanceIdsを持っているインスタンスで肉体化インスタンスセットで'誤っていること'に要求を受け取るとき、要求に肉体化情報が全くないなら、それはアップデートとしてそれがこのハンドルのために維持する要求状態のPRIsにこれらのPRIsを解釈しなければなりません。
Sahita, et. al. Informational [Page 8] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[8ページ]情報のRFC3318フレームワーク方針情報基地の行進
2.3.4 Removing PRIs from a Request
2.3.4 要求からPRIsを取り外すこと。
If the PEP wants to remove previously installed PRIs for a request handle, the PEP MUST ensure that the frwkPibIncarnationFullState attribute is set to 'false', and MUST send the PRI bindings with the PRID set to the InstanceId of the PRI to be removed, and the length field in the EPD object header set to the header length only, effectively setting the data length to zero.
PEPが要求ハンドルのために以前にインストールされたPRIsを取り外したいなら、PEP MUSTはfrwkPibIncarnationFullState属性が'誤っていること'に設定されて、取り除くためにPRIDセットによるPRI結合をPRIのInstanceIdに送らなければならなくて、EPDオブジェクトヘッダーの長さの分野がヘッダ長だけにセットしたのを確実にします、事実上、データの長さをゼロに設定して。
Note that the PEP must send the same InstanceIds for the PRIs being removed. If the PEP sends new InstanceIds and the length field in the EPD object header is set to the header length only (implying the data length is zero), the PEP is attempting to remove an unknown/non-existent PRI. This SHOULD result in the PDP sending error PRIs in the solicited decision (see section 2.3.6 for a description of the frwkErrorTable).
PEPが取り外されるPRIsのために同じInstanceIdsを送らなければならないことに注意してください。 PEPが新しいInstanceIdsを送って、EPDオブジェクトヘッダーの長さの分野がヘッダ長だけに設定されるなら(データの長さを含意するのは、ゼロです)、PEPは、未知の、または、実在しないPRIを取り外すのを試みています。 このSHOULDは請求された決定でPDP送付誤りPRIsをもたらします(frwkErrorTableの記述に関してセクション2.3.6を見てください)。
If the PEP sends new InstanceIds, and the length field in the EPD object header is greater than the header length only (implying the EPD object has some attributes encoded in it), the PDP will interpret this as an install of the PRI if it can decode the EPD successfully.
PEPが新しいInstanceIdsを送って、EPDオブジェクトヘッダーの長さの分野がヘッダ長だけより大きいなら、首尾よくEPDを解読できると、PDPはPRIのインストールとしてこれを解釈するでしょう。
When a PDP receives a request with instances having InstanceIds that exist in its state for that handle with the frwkPibIncarnationFullState in the incarnation instance set to 'false', or if the request has no incarnation information, and the length field in the EPD object header is set to the header length only (implying the data length is zero), it must remove these PRIs from the request state it maintains for this handle.
PDPがそのハンドルのためにfrwkPibIncarnationFullStateと共に州に存在するInstanceIdsを持っているインスタンスで肉体化インスタンスセットで'誤っていること'に要求を受け取るとき、要求には肉体化情報が全くなくて、EPDオブジェクトヘッダーの長さの分野がヘッダ長だけに設定されるなら(データの長さを含意するのは、ゼロです)、それはこのハンドルのために維持する要求状態からこれらのPRIsを取り外さなければなりません。
2.3.5 Removing EXTENDED, AUGMENTED PRIs
2.3.5 広げられて、増大しているPRIsを取り外すこと。
The PEP should remove the extended/augmented PRIs when it removes the base PRIs in the same COPS message. See [SPPI] for a description of EXTENDED/AUGMENTED PRCs. A PDP that receives removes for a base PRI must implicitly remove the extensions.
同じCOPSメッセージでベースPRIsを取り外すとき、PEPは広げられたか増大しているPRIsを取り外すはずです。 EXTENDED/AUGMENTED PRCsの記述に関して[SPPI]を見てください。 ベースPRIがそれとなく拡大を取り除かなければならないので、受信するPDPは取り外します。
2.3.6 Error Handling in Request updates
2.3.6 Requestアップデートにおける誤りHandling
If the PDP cannot process all the request installs/updates/removes in the COPS request message successfully, it MUST rollback to its previous request state and it MUST send a solicited decision to the PEP that contains frwkErrorTable instances. These instances contain an error code and a sub-code as defined in the [COPS-PR] CPERR object. For example, if the PEP tries to remove an instance that does not exist, the 'priInstanceInvalid' error code must be sent to the PEP in a frwkError PRI. The frwkError PRIs also contain the PRC and the InstanceId of the error-causing PRI. The PEP may then
PDPが要求がCOPS要求メッセージで首尾よくインストールするか、アップデートする、または取り除くすべてを処理できないなら、それはfrwkErrorTableインスタンスを含むPEPに請求された決定を送らなければならないという前の要求へのロールバックを処理しなければなりません。 これらのインスタンスは[COPS-PR]CPERRオブジェクトで定義されるようにエラーコードとサブコードを含んでいます。 例えば、PEPが存在しないインスタンスを取り除こうとするなら、'priInstanceInvalid'エラーコードをfrwkError PRIのPEPに送らなければなりません。 また、frwkError PRIsは誤りを引き起こすPRIのPRCとInstanceIdを含んでいます。 PEPはそしてときにそうするかもしれません。
Sahita, et. al. Informational [Page 9] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[9ページ]情報のRFC3318フレームワーク方針情報基地の行進
examine these error PRIs and resend the modified request. Note that, until the PEP resends the request updates/removes, it will have configuration information for the last successful request state it sent to the PDP.
これらの誤りPRIsを調べてください、そして、変更された要求を再送してください。 それにはPEPが/が取り除く要求最新版を再送するまでそれがPDPに送った最後のうまくいっている要求状態のための設定情報があることに注意してください。
2.4. Multiple PIB Instances
2.4. 複数のPIBインスタンス
[COPS-PR] supports multiple, disjoint, independent instances of the PIB to represent multiple instances of configured policy. The intent is to allow for the pre-provisioning of policy that can then be made active by a single, short decision from the PDP.
独立者は[COPS-PR]が倍数をサポートして、ばらばらになると例証します。構成された方針の複数のインスタンスを表すPIBについて。 意図は次にPDPからの単一の、そして、短い決定でアクティブにすることができる方針のプレの食糧を供給することを考慮することです。
A COPS context can be defined as an independent COPS request state for a particular subject category (client-type). A context may be an outsourcing context or a configuration context. A configuration context is an instance of the PIB triggered and controlled by the PDP, which contains device setup information. This device configuration information dictates the device behavior as specified by the PDP. An outsourcing context on the other hand, is a PIB instance that is triggered from the PEP side and is a request to the PDP for action. The action requested will be interpreted in the domain of the client-type. Configuration contexts belong to a set of configuration contexts for a specific client type - out of which one configuration context may be active. However, multiple outsourcing contexts can be active simultaneously.
特定の対象のカテゴリ(クライアントタイプ)のための独立しているCOPS要求状態とCOPS文脈を定義できます。 文脈は、アウトソーシング文脈か構成文脈であるかもしれません。 構成文脈はPDPによって引き起こされて、制御されたPIBのインスタンスです。PDPはデバイスセットアップ情報を含みます。 このデバイス設定情報はPDPによる指定されるとしてのデバイスの振舞いを決めます。 アウトソーシング文脈、他方では、PEP側から引き起こされて、動作のためのPDPへの要求であるPIBインスタンスはそうです。 要求された動作はクライアントタイプのドメインで解釈されるでしょう。 構成文脈は特定のクライアントタイプへの1セットの構成文脈に属します--どの1つの構成文脈がアクティブであるかもしれないかから。 しかしながら、複数のアウトソーシング文脈が同時に、アクティブである場合があります。
With the [COPS-PR] protocol, each of these states is identified by a unique client handle. The creation and deletion of these PIB instances can be controlled by the PDP as described in [COPS-PR] or can be triggered by an event by the PEP. A PEP must open at least one "request-state" for configuration for a given subject-category (client type). Additional "request-states" at the PEP may be initiated by the PDP or asynchronously generated by the PEP for outsourcing due to local events, which will be fully specified by the PRID/EPD data carried in the request.
[COPS-PR]プロトコルで、それぞれのこれらの州はそうです。ユニークなクライアントハンドルで、特定されます。 これらのPIBインスタンスの作成と削除をPDPが[COPS-PR]で説明されるように制御できるか、またはPEPはイベントで引き起こすことができます。 PEPは与えられた受けることがあるカテゴリ(クライアントタイプ)のための構成のために少なくとも1「要求状態」を開かなければなりません。 PEPの追加「要求州」は、PDPによって開始されるか、またはローカルイベントのためアウトソーシングのためにPEPによって非同期に生成されるかもしれません。ローカルイベントは要求で運ばれたPRID/EPDデータによって完全に指定されるでしょう。
The frwkPibIncarnationInCtxtSet flag defines a set of contexts out of which only one context can be active at any given time. This set is called the 'configuration contexts' set. At most, one context may be active from this 'configuration context' set at any given time. Contexts that have the frwkPibIncarnationInCtxtSet attribute set to 'true' belong to this set. Contexts that do not belong to this set have the frwkPibIncarnationInCtxtSet set to 'false' and belong to the set of 'outsourcing contexts'. Note that a PEP can have these two sets of contexts only if the frwkPibIncarnationInCtxtSet attribute is shown to be supported via the supported PRC table. If the
frwkPibIncarnationInCtxtSet旗は1つの文脈だけがその時々でアクティブである場合がある1セットの文脈を定義します。 このセットは'構成文脈'セットと呼ばれます。 1つの文脈がその時々でこの'構成文脈'セットから高々、アクティブであるかもしれません。 '本当に'frwkPibIncarnationInCtxtSet属性を設定する文脈はこのセットに属します。 このセットに属さない文脈が、'誤ること'に用意ができさせて、frwkPibIncarnationInCtxtSetを'アウトソーシング文脈'のセットに属します。 frwkPibIncarnationInCtxtSet属性がサポートしているPRCテーブルを通してサポートされるために示される場合にだけPEPがこれらの2セットの文脈を持つことができることに注意してください。 the
Sahita, et. al. Informational [Page 10] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[10ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkPibIncarnationInCtxtSet is not supported, a PEP must treat all contexts as belonging to the set of 'configuration contexts' i.e., at the most one context can be active at any given time.
frwkPibIncarnationInCtxtSetはサポートされないで、すなわち、最も1つで'構成文脈'のセットに属して、文脈がその時々でアクティブであることができるので、PEPはすべての文脈を扱わなければなりません。
Note that in the event that a PEP has a capability change such as a card hot swap or any other change in its notify information that may warrant a policy refresh, a subsequent complete or incremental request must be issued to the PDP containing the new/updated capabilities for all the configuration contexts. A request for re- configuration is issued for all request state configuration contexts, both for the active configuration context as well as any inactive configuration contexts. This is to ensure that when an inactive configuration context is activated, it has been pre-configured with policies compatible with the PEP's current capabilities.
PEPがカードホットスワップかいかなる他のも変化する能力変化を持っている場合それに注意してください、それ、方針がリフレッシュするのを保証するかもしれない情報に通知してください、そして、すべての構成文脈のために新しいかアップデートされた能力を含むPDPにその後の完全であるか増加の要求を出さなければなりません。 再構成を求める要求はすべての要求州の構成文脈のために出されます、ともにどんな不活発な構成関係と同様にアクティブな構成文脈のために。 これは、不活発な構成関係が活性であるときに、それがPEPの現在の能力とのコンパチブル方針であらかじめ設定されたのを保証するためのものです。
Although many PIB instances may be configured on a device (the maximum number of these instances being determined by the device itself), only one of the contexts from the 'configuration contexts' set can be active at any given time; the active one being selected by the PDP. The Framework PIB supports the attribute frwkPibIncarnationActive in the frwkPibIncarnationTable to allow the PDP to denote the PIB instance as being active in a COPS decision message, and similarly, to report the active state (active or not) of the PIB instance to the PDP in a COPS request message.
多くのPIBインスタンスがデバイス(デバイス自体で決定するこれらのインスタンスの最大数)で構成されるかもしれませんが、'構成文脈'セットからの文脈の唯一の1つがその時々でアクティブである場合があります。 PDPによって選択されるアクティブなもの。 Framework PIBは、PDPが活動的な状態がPIBインスタンスで(アクティブ)であると報告するためにCOPS決定メッセージと、同様にアクティブであるとしてPIBインスタンスを指示するのを許容するfrwkPibIncarnationTableで属性がfrwkPibIncarnationActiveであるとCOPS要求メッセージのPDPにサポートします。
When the PEP installs an attribute frwkPibIncarnationActive that is 'true' in one PIB instance which belongs to the 'configuration contexts' set, the PEP must ensure, re-setting the attribute if necessary, that the frwkPibIncarnationActive attribute is 'false' in all other installed contexts that belong to this set. To switch contexts, the PDP should set the frwkPibIncarnationActive attribute to 'true' in the context it wants to make the active context. The PDP should set this attribute in a context to 'false' only if it wants to send an inactive context to the PEP or deactivate the active context on the PEP. If an active context is made inactive without activating another context, the PEP must not have any policies enforced from any configuration contexts installed.
PEPが'構成文脈'セットに属す1つのPIBインスタンスで'本当'の属性frwkPibIncarnationActiveをインストールするとき、必要なら、属性をリセットして、PEPは、frwkPibIncarnationActive属性がこのセットに属す他のすべてのインストールされた文脈で'誤っていること'を確実にしなければなりません。 文脈を切り換えるために、PDPはそれがアクティブな文脈をしたがっている文脈で'本当に'frwkPibIncarnationActive属性を設定するはずです。 不活発な関係をPEPに送りたいか、またはアクティブな文脈をPEPに非活性化したい場合にだけ、PDPは'誤っていること'への文脈にこの属性をはめ込むはずです。 別の文脈を活性化しないでアクティブな文脈を不活発にするなら、PEPは、どんな方針も文脈がインストールしたどんな構成からも励行されるのを持ってはいけません。
2.5. Reporting and Configuring of Device Capabilities
2.5. デバイス能力の報告と構成
Each network device providing policy-based services has its own inherent capabilities. These capabilities can be hardware specific, e.g., an Ethernet interface supporting input classification, or can be statically configured, e.g., supported queuing disciplines. These capabilities are organized into Capability Sets, with each Capability Set given a unique name (frwkCapabilitySetName) and associated with a set of Role Combinations. In that way, each Role Combination may be associated with a set of interfaces. These capabilities are
方針ベースのサービスを提供するそれぞれのネットワークデバイスには、それ自身の固有機能があります。 これらの能力がハードウェア特有である場合がある、例えば、イーサネットインタフェースは、入力分類をサポートするか、または静的に構成できます、例えば、サポートしている待ち行列の規律。 これらの能力はCapability Setsに組織化されます、各Capability Setをユニークな名前(frwkCapabilitySetName)を与えて、Role Combinationsの1セットに関連づけていて。 そのように、それぞれのRole Combinationは1セットのインタフェースに関連しているかもしれません。 これらの能力はそうです。
Sahita, et. al. Informational [Page 11] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[11ページ]情報のRFC3318フレームワーク方針情報基地の行進
communicated to the PDP when policy is requested by the PEP. Knowing device capabilities, the PDP can send the PRIs relevant to the specific device, rather than sending the entire PIB.
方針がいつPEPによって要求されるかをPDPに伝えました。 デバイス能力を知っていて、PDPは全体のPIBを送るよりむしろ特定のデバイスに関連しているPRIsを送ることができます。
Specific capability PRCs may be defined in other PIBs. These capability instances are grouped via the frwkCapabilitySetTable. If the PEP wishes to send capability information to the PDP, the PIB must indicate which capabilities the PEP may send to the PDP by means of the 'notify' PIB-ACCESS clause as described in [SPPI]. If a PIB does not have any capabilities to communicate to the PDP, it must not send any instances for the frwkCapabilitySetTable. If in this case the frwkIfRoleCombo table is used to communicate role combinations assigned to interfaces (via IfIndex), the frwkRoleComboCapSetName attribute in the frwkIfRoleComboTable instances must be set to a zero length string.
特定の能力PRCsは他のPIBsで定義されるかもしれません。 これらの能力インスタンスはfrwkCapabilitySetTableを通して分類されます。 PEPが能力情報をPDPに送りたいなら、PIBは、PEPが'通知してください'PIB-ACCESS節によって[SPPI]で説明されるようにどの能力をPDPに送るかもしれないかを示さなければなりません。 PIBにPDPに交信する能力が少しのないなら、それはfrwkCapabilitySetTableのためにどんなインスタンスも送ってはいけません。 frwkIfRoleComboテーブルがこの場合インタフェース(IfIndexを通した)に割り当てられた役割の組み合わせを伝えるのに使用されるなら、frwkIfRoleComboTableインスタンスにおけるfrwkRoleComboCapSetName属性をゼロ長ストリングに設定しなければなりません。
2.6. Reporting of Device Limitations
2.6. デバイス制限の報告
To facilitate efficient policy installation, it is important to understand a device's limitations in relation to the advertised device capabilities. Limitations may be class-based, e.g., an "install" class is supported as a "notify" or only a limited number of class instances may be created, or attribute-based. Attribute limitations, such as supporting a restricted set of enumerations or requiring related attributes to have certain values, detail implementation limitations at a fine level of granularity.
効率的な方針インストールを容易にするために、広告を出しているデバイス能力と関連してデバイスの制限を理解しているのは重要です。 制限がクラスベースであるかもしれない、例えば、「通知してください」か限られた数だけのクラスインスタンスが作成されているか、または属性ベースであるときに、「インストールしてください」というクラスはサポートされます。 ある値(すばらしいレベルの粒状における詳細実装制限)を持つために制限されたセットの列挙をサポートするか、または関連する属性を必要とすることなどの制限を結果と考えてください。
A PDP can avoid certain installation issues in a proactive fashion by taking into account a device's limitations prior to policy installation rather than in a reactive mode during installation. As with device capabilities, device limitations are communicated to the PDP when policy is requested.
PDPは反応モードでというよりむしろ方針インストールの前にインストールの間、デバイスの制限を考慮に入れることによって、先を見越すファッションで、あるインストール問題を避けることができます。 方針が要求されているとき、デバイス能力のように、デバイス制限はPDPに伝えられます。
Reported device limitations may be accompanied by guidance values that can be used by a PDP to determine acceptable values for the identified attributes.
報告されたデバイス制限はPDPが特定された属性のために許容値を決定するのに使用できる指導値によって伴われるかもしれません。
3. The Framework TC PIB module
3. Framework TC PIBモジュール
FRAMEWORK-TC-PIB PIB-DEFINITIONS ::= BEGIN
フレームワークTc PIB PIB定義:、:= 始まってください。
IMPORTS MODULE-IDENTITY, TEXTUAL-CONVENTION,
Unsigned32, pib FROM COPS-PR-SPPI;
IMPORTS MODULE-IDENTITY、TEXTUAL-CONVENTION、Unsigned32、pib FROM COPS PR SPPI。
frwkTcPib MODULE-IDENTITY
SUBJECT-CATEGORIES { all }
LAST-UPDATED "200302130000Z" -- 13 Feb 2003
ORGANIZATION "IETF RAP WG"
frwkTcPib MODULE-IDENTITY SUBJECT-CATEGORIESすべてのLAST-UPDATED"200302130000Z"--2003年2月13日の組織「IETFラップWG」
Sahita, et. al. Informational [Page 12] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[12ページ]情報のRFC3318フレームワーク方針情報基地の行進
CONTACT-INFO "Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose, CA 95134-1706 USA
Phone: +1 408 526 5260
Email: kzm@cisco.com
「キースMcCloghrieシスコシステムズInc.170の西タスマンDrive、サンノゼ、カリフォルニア95134-1706米国は以下に電話をする」というコンタクトインフォメーション +1 5260年の408 526メール: kzm@cisco.com
John Seligson
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95054 USA
Phone: +1 408 495 2992
Email: jseligso@nortelnetworks.com
ジョンSeligsonノーテルはグレート・アメリカParkwayカリフォルニア95054サンタクララ(米国)が電話をするInc.4401をネットワークでつなぎます: +1 2992年の408 495メール: jseligso@nortelnetworks.com
Ravi Sahita
Intel Labs.
2111 NE 25th Ave.
Hillsboro, OR 97124 USA
Phone: +1 503 712 1554
Email: ravi.sahita@intel.com
ラービーSahitaインテル研究室。 2111 Neの第25Ave。 ヒースボロー、または97124米国電話: +1 1554年の503 712メール: ravi.sahita@intel.com
RAP WG Mailing list: rap@ops.ietf.org "
DESCRIPTION
"The PIB module containing the Role and RoleCombination
Textual Conventions and other generic TCs.
RAP WG Mailingは記載します: rap@ops.ietf.org 、「記述「RoleとRoleCombination Textual Conventionsを含むPIBモジュールと他のジェネリックTCs。」
Copyright (C) The Internet Society (2003). This version of
this PIB module is part of RFC 3318; see the RFC itself for
full legal notices."
Copyright(C)インターネット協会(2003)。 このPIBモジュールのこのバージョンはRFC3318の一部です。 「完全な法定の通知に関してRFC自身を見てください。」
REVISION "200302130000Z" -- 13 Feb 2003
DESCRIPTION "Initial version, published in RFC 3318."
::= { pib 3 }
REVISION"200302130000Z"--「初期のバージョンであって、RFC3318で発行された」2003年2月13日の記述。 ::= pib3
Role ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A role represents a functionality characteristic or
capability of a resource to which policies are applied.
Examples of roles include Backbone_interface,
Frame_Relay_interface, BGP-capable-router, web-server,
firewall, etc.
The only valid character set is US-ASCII. Valid characters
are a-z, A-Z, 0-9, period, hyphen and underscore. A role
must always start with a letter (a-z or A-Z). A role must
not contain the US-ASCII characters '*' or '+' since they
have special meaning associated with them, explained in the
RoleCombination TEXTUAL CONVENTION."
役割:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「役割は方針が適用されている機能性の特性かリソースの能力を表します」。 役割に関する例はBackbone_インタフェース、Frame_Relay_インタフェース、BGPのできるルータ、ウェブサーバー、ファイアウォールなどを含んでいます。 唯一の有効な文字集合が米国-ASCIIです。 0-9、期間は、A-Z、有効なキャラクタが1zであることはハイフンで結んで、下線を引きます。 役割はいつも手紙(a-zかA-Z)から始まらなければなりません。 「'彼らが特別な意味を彼らに関連していて、RoleCombination TEXTUAL CONVENTIONで説明されるようにするので、役割は米国-ASCII文字''*'か+を含んではいけません。」
Sahita, et. al. Informational [Page 13] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[13ページ]情報のRFC3318フレームワーク方針情報基地の行進
SYNTAX OCTET STRING (SIZE (1..31))
構文八重奏ストリング(サイズ(1 .31))
RoleCombination ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An octet string containing concatenated Roles. For the
format specification of roles, refer to the 'Role' TEXTUAL-
CONVENTION. A valid Role Combination must be formed by a set
of valid Roles, concatenated by the US-ASCII character '+',
where the roles are in lexicographic order from minimum to
maximum. For example, 'a+b' and 'b+a' are NOT different
role-combinations; rather, they are different formatting of
the same (one) role-combination.
RoleCombination:、:= 「連結されたRolesを含んでいて、八重奏は結ぶ」TEXTUAL-CONVENTION STATUSの現在の記述。 役割の書式仕様について、'役割'TEXTUAL- CONVENTIONを参照してください。 辞書式順序には最小限から最大になりまで役割がある米国-ASCII文字'+'によって連結された有効なRolesの1セットは有効なRole Combinationを形成しなければなりません。 例えば、'a+b'と'b+a'はNOTの異なった役割組み合わせです。 むしろ、それらは同じ(1)役割組み合わせの異なった形式です。
Notice the roles within a role-combination are in
Lexicographic order from minimum to maximum, hence, we
declare:
'a+b' is the valid formatting of the role-combination,
'b+a' is an invalid formatting of the role-combination.
役割組み合わせの中の役割が最小限から最大になりまでのLexicographicオーダーにあるのに注意してください、そして、したがって、私たちは宣言します: 'a+b'は役割組み合わせの有効な形式です'b+a'は役割組み合わせの無効の形式です。
Notice the need of zero-length role-combination as the role-
combination of interfaces to which no roles have been
assigned. This role-combination is also known as the 'null'
role-combination. (Note the deliberate use of lower case
letters to avoid confusion with the US-ASCII NULL character
which has a value of zero but length of one.)
役割が全く割り当てられていないインタフェースの役割の組み合わせとしてゼロ・レングス役割組み合わせの必要性に注意してください。 また、この役割組み合わせは'ヌル'の役割組み合わせとして知られています。 (小文字の慎重な使用に注意して、ゼロの値にもかかわらず、1の長さを持っている米国-ASCII NULLキャラクタへの混乱を避けてください。)
The US-ASCII character '*' is used to specify a wild carded
Role Combination. '*' must not be used to wildcard Roles.
Hence, we declare:
'*+a+b' is a valid wild carded Role Combination.
'eth*+a+b' is not a valid wild carded Role Combination.
Note that since Roles are lexicographically listed in a Role
Combination, the following is an invalid role combination,
since '*' is lexicographically before 'a': 'a+b+*'."
SYNTAX OCTET STRING (SIZE (0..255))
米国-ASCII文字'*'は、ワイルドなcarded Role Combinationを指定するのに使用されます。 '*'をワイルドカードRolesに使用してはいけません。 したがって、私たちは宣言します: '*+ +b'は有効なワイルドなcarded Role Combinationです。 'eth*+a+b'は有効なワイルドなcarded Role Combinationではありません。 RolesがRole Combinationに辞書編集に記載されているので↓これが無効の役割の組み合わせであることに注意してください、'*'が'a'の前で辞書編集であるので: 「'+b+*'。」 構文八重奏ストリング(サイズ(0 .255))
PrcIdentifierOid ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An OID that identifies a PRC. The value MUST be an OID
assigned to a PRC's entry definition. The Entry definition
of a PRC has an OID value XxxTable.1 where XxxTable is the
OID assigned to the PRC table object.
PrcIdentifierOid:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「PRCを特定するOID。」 値はPRCのエントリー定義に割り当てられたOIDでなければなりません。 PRCのEntry定義はXxxTableがPRCテーブルオブジェクトに割り当てられたOIDであるOID値のXxxTable.1を持っています。
An attribute with this syntax MUST specify a PRC, which is
defined in the PIB module(s) registered in the context of
the client-type used.
この構文がある属性はPRCを指定しなければなりません。(PRCは使用されるクライアントタイプの文脈に登録されたPIBモジュールで定義されます)。
Sahita, et. al. Informational [Page 14] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[14ページ]情報のRFC3318フレームワーク方針情報基地の行進
An attribute with this syntax cannot have the value 0.0
(zeroDotZero). If the attribute using this syntax can be set
to 0.0 use the PrcIdentifierOidOrZero TEXTUAL-CONVENTION
which makes such use explicit."
SYNTAX OBJECT IDENTIFIER
この構文がある属性は値0.0(zeroDotZero)を持つことができません。 「この構文を使用する属性を0.0に設定できるなら、そのような使用を明白にするPrcIdentifierOidOrZero TEXTUAL-CONVENTIONを使用してください。」 構文オブジェクト識別子
PrcIdentifierOidOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An OID that identifies a PRC or zeroDotZero (0.0). The
value MUST be an OID assigned to a PRC's entry definition or
0.0 (zeroDotZero). The Entry definition of a PRC has an OID
value XxxTable.1 where XxxTable is the OID assigned to the
PRC table object.
PrcIdentifierOidOrZero:、:= TEXTUAL-CONVENTION STATUSの現在の記述「PRCを特定するOIDかzeroDotZero(0.0)。」 値はPRCのエントリー定義か0.0(zeroDotZero)に割り当てられたOIDでなければなりません。 PRCのEntry定義はXxxTableがPRCテーブルオブジェクトに割り当てられたOIDであるOID値のXxxTable.1を持っています。
An attribute with this syntax can have the value 0.0
(zeroDotZero) to indicate that it currently does not
identify a PRC."
SYNTAX OBJECT IDENTIFIER
「この構文がある属性は現在PRCを特定しないのを示すために、値0.0(zeroDotZero)を持つことができます。」 構文オブジェクト識別子
AttrIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A Unsigned32 value that identifies an attribute in a PRC by
its sub-id. The sub-id is the OID assigned to this attribute
in the PRC definition.
AttrIdentifier:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「PRCでサブイドで属性を特定するUnsigned32値。」 サブイドはPRC定義におけるこの属性に割り当てられたOIDです。
A AttrIdentifier value is always interpreted within the
context of an attribute of type PrcIdentifierOid or
PrcIdentifierOidOrZero. The PrcIdentifierOid (or
PrcIdentifierOidOrZero) object which defines the context
must be registered immediately before the object which uses
the AttrIdentifier textual convention. If the context
defining attribute is of type PrcIdentifierOidOrZero and has
the value 0.0, then in that case this attribute value has no
meaning.
AttrIdentifier値はタイプPrcIdentifierOidかPrcIdentifierOidOrZeroの属性の文脈の中でいつも解釈されます。 AttrIdentifierの原文のコンベンションを使用するオブジェクトの直前文脈を定義するPrcIdentifierOid(または、PrcIdentifierOidOrZero)オブジェクトを登録しなければなりません。 属性を定義する文脈がタイプPrcIdentifierOidOrZeroにはあって、値0.0を持っているなら、その場合、この属性値に意味がありません。
An attribute with this syntax MUST specify a sub-id which
MUST be defined in the PRC identified (if any) in the
PrcIdentifierOid (or PrcIdentifierOidOrZero) attribute. The
PrcIdentifierOid (orZero) and the AttrIdentifier attributes
together identify a particular attribute in a particular
PRC.
この構文がある属性はPrcIdentifierOid(または、PrcIdentifierOidOrZero)属性で特定された(もしあれば)PRCで定義しなければならないサブイドを指定しなければなりません。 PrcIdentifierOid(orZero)と一緒にAttrIdentifier属性は特定のPRCで特定の属性を特定します。
Sahita, et. al. Informational [Page 15] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[15ページ]情報のRFC3318フレームワーク方針情報基地の行進
An attribute with this syntax cannot have the value 0
(zero). If the attribute using this syntax can be set
to 0 use the AttrIdentifierOrZero TEXTUAL-CONVENTION which
makes that explicit."
SYNTAX Unsigned32 (1..4294967295)
この構文がある属性は値0(ゼロ)を持つことができません。 「この構文を使用する属性を0に設定できるなら、それを明白にするAttrIdentifierOrZero TEXTUAL-CONVENTIONを使用してください。」 構文Unsigned32(1..4294967295)
AttrIdentifierOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A Unsigned32 value that identifies an attribute in a PRC by
its sub-id or has the value 0 (zero). The sub-id if non-
zero, is the OID assigned to this attribute in the PRC
definition.
AttrIdentifierOrZero:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「PRCでサブイドで属性を特定するか、または値0(ゼロ)を持っているUnsigned32値。」 サブイドにもかかわらず、非ゼロはPRC定義におけるこの属性に割り当てられたOIDです。
An AttrIdentifierOrZero value is always interpreted within
the context of an attribute of type PrcIdentifierOid or
PrcIdentifierOidOrZero. The PrcIdentifierOid (or
PrcIdentifierOidOrZero) object that defines the context must
be registered immediately before the object which uses the
AttrIdentifierOrZero textual convention. If the context
defining attribute is of type PrcIdentifierOidOrZero and has
the value 0.0, then in that case this attribute value has no
meaning.
AttrIdentifierOrZero値はタイプPrcIdentifierOidかPrcIdentifierOidOrZeroの属性の文脈の中でいつも解釈されます。 AttrIdentifierOrZeroの原文のコンベンションを使用するオブジェクトの直前文脈を定義するPrcIdentifierOid(または、PrcIdentifierOidOrZero)オブジェクトを登録しなければなりません。 属性を定義する文脈がタイプPrcIdentifierOidOrZeroにはあって、値0.0を持っているなら、その場合、この属性値に意味がありません。
An attribute with this syntax can have the value 0 (zero) to
indicate that it currently does not identify a PRC
attribute. If it has a non-zero value, the
PrcIdentifierOid (orZero) and the AttrIdentifierOrZero
attributes together identify a particular attribute in a
particular PRC."
SYNTAX Unsigned32
この構文がある属性は現在PRC属性を特定しないのを示す値0の(ゼロ)を持つことができます。 「それに非ゼロ値があるなら、PrcIdentifierOid(orZero)と一緒にAttrIdentifierOrZero属性は特定のPRCで特定の属性を特定します。」 構文Unsigned32
AttrIdentifierOid ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An OID that identifies an attribute in a PRC. The value
MUST be an OID assigned to a PRC's attribute definition. The
last sub-id is the sub-id of the attribute as it is
defined in the PRC entry definition. The prefix OID (after
dropping the last sub-id) is the OID assigned to the Entry
object of a defined PRC. The Entry definition of a PRC has
an OID value XxxTable.1 where XxxTable is the OID assigned
to the PRC Table object.
AttrIdentifierOid:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「PRCで属性を特定するOID。」 値はPRCの属性定義に割り当てられたOIDでなければなりません。 それがPRCエントリー定義で定義されるとき、最後のサブイドは属性のサブイドです。 接頭語OID(最後のサブイドを下げた後の)は定義されたPRCのEntryオブジェクトに割り当てられたOIDです。 PRCのEntry定義はXxxTableがPRC Tableオブジェクトに割り当てられたOIDであるOID値のXxxTable.1を持っています。
An attribute with this syntax MUST not have the value 0.0
(zeroDotZero). If 0.0 is a valid value, the TEXTUAL
CONVENTION AttrIdentifierOidOrZero must be used which makes
such use explicit."
この構文がある属性に、値0.0(zeroDotZero)があってはいけません。 「0.0が有効値であるなら、そのような使用を明白にするTEXTUAL CONVENTION AttrIdentifierOidOrZeroを使用しなければなりません。」
Sahita, et. al. Informational [Page 16] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[16ページ]情報のRFC3318フレームワーク方針情報基地の行進
SYNTAX OBJECT IDENTIFIER
構文オブジェクト識別子
AttrIdentifierOidOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An OID that identifies an attribute in a PRC or has a value
0.0 (zeroDotZero). The value MUST be an OID assigned to a
PRC's attribute definition or the value 0.0.
AttrIdentifierOidOrZero:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「PRCで属性を特定するか、または値0.0(zeroDotZero)を持っているOID。」 値はPRCの属性定義か値0.0に割り当てられたOIDでなければなりません。
If not 0.0, the last sub-id MUST be the sub-id of the
attribute as it is defined in the PRC Entry object
definition. The prefix OID (after dropping the last sub-id)
is the OID assigned to the Entry object of a defined PRC.
The Entry definition of a PRC has an OID value XxxTable.1
Where, XxxTable is the OID assigned to the PRC Table
object.
まして、0.0、それがPRC Entryオブジェクト定義で定義されるとき、最後のサブイドは属性のサブイドであるに違いありません。 接頭語OID(最後のサブイドを下げた後の)は定義されたPRCのEntryオブジェクトに割り当てられたOIDです。 OIDはPRCのEntry定義でXxxTable.1Whereを評価して、XxxTableはPRC Tableオブジェクトに割り当てられたOIDです。
An attribute with this syntax can have the value 0.0
(zeroDotZero) to indicate that it currently does not
identify a PRC's attribute."
SYNTAX OBJECT IDENTIFIER
「この構文がある属性は現在PRCの属性を特定しないのを示すために、値0.0(zeroDotZero)を持つことができます。」 構文オブジェクト識別子
ClientType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An Unsigned32 value that identifies a COPS Client-type. An
attribute with this syntax must be set to zero if it does
not specify a COPS client-type for the PRI."
REFERENCE
"The COPS (Common Open Policy Service) Protocol, RFC 2748."
SYNTAX Unsigned32 (0..65535)
ClientType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「COPS Client-タイプを特定するUnsigned32値。」 「それがCOPSクライアントタイプをPRIに指定しないなら、この構文がある属性をゼロに設定しなければなりません。」 「巡査(一般的なオープンポリシーサービス)プロトコル、RFC2748」という参照。 構文Unsigned32(0..65535)
ClientHandle ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An octet string that identifies a COPS Client handle. A
zero length value implies the attribute does not specify a
valid client handle."
REFERENCE
"The COPS (Common Open Policy Service) Protocol, RFC 2748."
SYNTAX OCTET STRING (SIZE(0..65535))
ClientHandle:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「COPS Clientハンドルを特定する八重奏ストリング。」 「ゼロ・レングス値は、属性が有効なクライアントハンドルを指定しないのを含意します。」 「巡査(一般的なオープンポリシーサービス)プロトコル、RFC2748」という参照。 構文八重奏ストリング(サイズ(0 .65535))
END
終わり
Sahita, et. al. Informational [Page 17] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[17ページ]情報のRFC3318フレームワーク方針情報基地の行進
4. Summary of the Framework PIB
4. フレームワークPIBの概要
The Framework PIB defines four groups of PRCs:
Framework PIBはPRCsの4つのグループを定義します:
4.1. Base PIB classes Group
4.1. 基地のPIBはGroupを分類します。
This contains PRCs intended to describe the PRCs supported by the PEP, PRC and/or attribute limitations and its current configuration.
これはPEP、PRC、そして/または、属性制限とその現在の構成によってサポートされたPRCsについて説明することを意図するPRCsを含んでいます。
PRC Support Table
PRCサポートテーブル
As the technology evolves, we expect devices to be enhanced
with new PIBs, existing PIBs to add new PRCs and existing PRCs
to be augmented or extended with new attributes. Also, it is
likely that some existing PRCs or individual attributes of PRCs
will be deprecated. The PRC Support Table describes the PRCs
that the device supports as well as the individual attributes
of each PRC. Using this information the PDP can potentially
tailor the policy to more closely match the capabilities of the
device. The PRC Support Table instances are specific to the
particular Subject Category (Client-Type). That is, the PRC
Support Table for Subject Category 'A' will not include
instances for classes supported by the Subject Category 'B'.
Note that the COPS client-type [COPS] used for Framework PIB
PRIs sent/received over COPS-PR MUST be the unique SUBJECT-
CATEGORY number assigned for the area of policy being managed
(e.g., QoS, Security etc). The PEP MUST ignore the attributes
that it reports as not Supported in the decision from the PDP.
The PEP SHOULD not send duplicate PRC support instances in a
COPS Request and the PDP MUST ignore duplicate instances and
MUST use the first instance received for a supported PRC in a
COPS Request.
技術が発展するとき、私たちは、デバイスが新しいPIBs(新しい属性で増大するか、または広げられるために新しいPRCsと既存のPRCsを加える既存のPIBs)と共に機能アップされると予想します。 また、PRCsのいくつかの既存のPRCsか個々の属性が推奨しなくなるのも、ありそうです。 PRC Support TableはデバイスがそれぞれのPRCの個々の属性と同様にサポートするPRCsについて説明します。 この情報を使用して、PDPは、より密接にデバイスの能力を合わせるために潜在的に方針を合わせることができます。 PRC Support Tableインスタンスは特定のSubject Category(クライアントタイプ)に特定です。 すなわち、Subject Category''Subject Categoryによってサポートされたクラスのためにインスタンスを含まなく'B'のためのPRC Support Table。 Framework PIB PRIsに、中古のクライアントタイプ[COPS]が送ったか、または受け取ったCOPSがCOPS-PRの上の管理される方針(例えば、Security QoSなど)の領域に割り当てられたユニークなSUBJECT- CATEGORY番号であるに違いないことに注意してください。 PEP MUSTはそれがSupportedでないとしてPDPから決定で報告する属性を無視します。 PEP SHOULDはCOPS RequestとPDP MUSTのインスタンスが無視する写しPRCサポートに写しインスタンスを送って、COPS RequestでサポートしているPRCのために受け取られた最初のインスタンスを使用してはいけません。
PIB Incarnation Table
PIB顕現テーブル
This PRC contains exactly one row (corresponding to one PRI)
per context. It identifies the PDP that was the last to
download policy into the device and also contains an identifier
to identify the version of the policy currently downloaded.
This identifier, both its syntax and value, is meaningful only
to the PDPs. It is intended to be a mechanism whereby a PDP,
when accepting a connection from a PEP, can easily identify a
known incarnation of policy. This PRC defines a flag via which
the installed contexts are divided into a set of contexts
('configuration contexts') out of which only one context is
active and a the remaining contexts form a set of 'outsourcing
contexts' which are all active. The incarnation PRC also
defines an attribute to indicate which configuration context is
このPRCは文脈単位でまさに1つの行を含んでいます(1PRIに対応する)。 それは、デバイスへのダウンロード方針に最終であったPDPを特定して、また、現在ダウンロードされている方針のバージョンを特定する識別子を含んでいます。 この識別子(構文と値の両方)はPDPsだけに重要です。 PEPから接続を受け入れるときPDPが容易に方針の知られている肉体化を特定できるメカニズムであることは意図しています。 このPRCはを通したインストールされた文脈が1つの文脈だけがアクティブであり、残っている文脈が1セットのすべてアクティブな'アウトソーシング文脈'を形成する1セットの文脈('構成文脈')に分割される旗を定義します。 また、肉体化PRCは、構成文脈がどれであるかを示すために属性を定義します。
Sahita, et. al. Informational [Page 18] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[18ページ]情報のRFC3318フレームワーク方針情報基地の行進
the active one at the present time in the 'configuration
contexts' set. The incarnation instance is specific to the
particular Subject Category (Client-Type).
'構成文脈'の現在におけるアクティブなものはセットしました。 肉体化インスタンスは特定のSubject Category(クライアントタイプ)に特定です。
Component Limitations Table
コンポーネント制限テーブル
Some devices may not be able to implement the full range of
values for all attributes. In principle, each PRC supports a
set of errors that the PEP can report to the PDP in the event
that the specified policy is not implementable. It may be
preferable for the PDP to be informed of the device limitations
before actually attempting to install policy, and while the
error can indicate that a particular attribute value is
unacceptable to the PEP, this does not help the PDP ascertain
which values would be acceptable. To alleviate these
limitations, the PEP can report some limitations of attribute
values and/or classes and possibly guidance values for the
attribute in the Component Limitations Table
いくつかのデバイスはすべての属性のために最大限の範囲の値を実装することができないかもしれません。 原則として、特約保険証券が実装可能でない場合、各PRCはPEPがPDPに報告できる1セットの誤りをサポートします。 PDPは実際に方針をインストールするのを試みる前にデバイス制限において知識があるのが、望ましいかもしれなく、誤りが、特定の属性値がPEPに容認できないのを示すことができる間、これは、PDPが、どの値が許容できるかを確かめるのを助けません。 これらの制限を軽減するために、PEPはComponent Limitations Tableの属性のために属性値、そして/または、クラスとことによると指導値のいくつかの制限を報告できます。
Device Identification Table
デバイス識別テーブル
This PRC contains a single PRI that contains device-specific
information that is used to facilitate efficient policy
installation by a PDP. The instance of this PRC is reported to
the PDP in a COPS request message so that the PDP can take into
account certain device characteristics during policy
installation.
このPRCはPDPによる効率的な方針インストールを容易にするのに使用されるデバイス特殊情報を含む独身のPRIを含んでいます。 このPRCのインスタンスは、PDPが方針インストールの間、あるデバイスの特性を考慮に入れることができるように、COPS要求メッセージのPDPに報告されます。
4.2. Device Capabilities group
4.2. デバイスCapabilitiesグループ
This group contains the PRCs that describe the characteristics of interfaces of the device and the Role Combinations assigned to them.
このグループはデバイスのインタフェースの特性について説明するPRCsと彼らに割り当てられたRole Combinationsを含みます。
Capabilities Set Table
能力はテーブルの用意をします。
The capabilities the PEP supports are described by rows in this
PRC (frwkCapabilitySetTable). Each row, or instance of this
class, associates a unique capability name with a set of
capabilities that an entity on the PEP may support. The unique
name is used to form a set of capabilities that the name
represents. The capability references can specify instances in
relevant capability tables in any PIB. The PEP notifies the
PDP of these capability sets and then the PDP configures the
interfaces, per role combination. The unique name
(frwkCapabilitySetName) is not to be confused with the IfType
object in the Interfaces Group MIB [RFC2863].
PEPがサポートする能力はこのPRC(frwkCapabilitySetTable)の行によって説明されます。 各行、またはこのクラスのインスタンスがPEPの上の実体がサポートするかもしれない1セットの能力のユニークな能力名を関連づけます。 ユニークな名前は、名前が表す1セットの能力を形成するのに使用されます。 能力参照はどんなPIBの関連能力テーブルでもインスタンスを指定できます。 PEPはこれらの能力セットについてPDPに通知します、そして、次に、PDPは役割の組み合わせあたりのインタフェースを構成します。 ユニークな名前(frwkCapabilitySetName)はInterfaces Group MIB[RFC2863]のIfTypeオブジェクトに混乱しないことです。
Sahita, et. al. Informational [Page 19] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[19ページ]情報のRFC3318フレームワーク方針情報基地の行進
Interface and Role Combination Table
インタフェースと役割の組み合わせテーブル
The Capabilities Set Table (explained above) describes the
entities on the PEP (for example, interfaces) by their
capabilities, by assigning the capability sets a unique name
(frwkCapabilitySetName). It is possible to tailor the behavior
of interfaces by assigning specific role-combinations to the
capability sets. This allows interfaces with the same
capability sets to be assigned different policies, based on the
current roles assigned to them. At the PDP, configuration is
done in terms of these interface capability set names and the
role-combinations assigned to them. Thus, each row of this
class is a <Interface Index, interface capability set name,
Role Combo> tuple, that indicates the roles that have been
assigned to a particular capability set (as identified by
frwkRoleComboCapSetName) and to a particular interface. Note
that the uniqueness criteria for this PRC has all the
attributes, thus a frwkRoleComboCapSetName may have multiple
role-combinations that it is associated with. Via the IfIndex,
this PRC answers the questions of 'which interfaces have a
specific role combination?' and 'what role combination a
specific interface is a part of?'.
Capabilities Set Table(上で、説明される)はPEP(例えば、インタフェース)で彼らの能力で実体について説明します、ユニークな名前(frwkCapabilitySetName)を能力セットに配属することによって。 特定の役割組み合わせを能力セットに配属することによってインタフェースの振舞いを合わせるのは可能です。 これは、異なった方針が同じ能力セットとのインタフェースに割り当てられるのを許容します、それらに割り当てられた現在の役割に基づいて。 PDPに、これらのインタフェース能力セット名とそれらに割り当てられた役割組み合わせで、構成します。 したがって、このクラスの各行は<Interface Index、インタフェース能力セット名、特定の能力セット(frwkRoleComboCapSetNameによって特定されるように)と、そして、特定のインタフェースに配属された役割を示すRole Combo>tupleです。 このPRCがその結果、属性、frwkRoleComboCapSetNameが持っているすべてを持っているのでそれが関連している複数の役割組み合わせがユニークさの評価基準にあることに注意してください。 IfIndexを通して、このPRCは'どのインタフェースに特定の役割の組み合わせがあるかに関する質問に答えますか?''そして、部分がどんな役割の組み合わせのa特定のインタフェースをありますか?'?
4.3. Classifier group
4.3. クラシファイアグループ
This group contains the IP, IEEE 802 and Internal Label Classifier elements. The set of tables consist of a Base Filter table that contains the Index InstanceId and the Negation flag for the filter. This frwkBaseFilterTable is extended to form the IP Filter table, the 802 Filter table [802] and the Internal Label table. Filters may also be defined outside this document and used to extend the Base Filter table.
このグループはIP、IEEE802、およびInternal Label Classifier要素を含みます。 テーブルのセットはIndex InstanceIdを含む基地のFilterテーブルとフィルタのためのNegation旗から成ります。 このfrwkBaseFilterTableは、IP Filterテーブル、802Filterテーブル[802]、およびInternal Labelテーブルを形成するために広げられます。 また、フィルタは、このドキュメントの外で定義されて、基地のFilterテーブルを広げるのに使用されるかもしれません。
The Extended classes do not have a separate Index value. Instances of the extended classes have the same indices as their base class instance. Inheritance is achieved using the EXTENDS keyword as defined in [SPPI].
Extendedのクラスには、別々のIndex値がありません。 拡張クラスのインスタンスには、それらの基底クラスインスタンスと同じインデックスリストがあります。 継承は、[SPPI]で定義されるようにEXTENDSキーワードを使用することで達成されます。
4.4. Marker group
4.4. マーカーグループ
This group contains the 802 marker and internal label marker PRCs. The 802 marker may be applied to mark 802 packets with the required VLAN Id and/or priority value. The Internal Label marker is applied to traffic in order to label it with a network device specific label. Such a label is used to assist the differentiation of an input flow after it has been aggregated with other flows. The label is
このグループは802マーカーと内部のラベルマーカーPRCsを含みます。 802マーカーは、必要なVLAN Id、そして/または、優先順位の値を802のパケットに付けるために適用されるかもしれません。 Internal Labelマーカーは、ネットワークデバイス特有のラベルでそれをラベルするためにトラフィックに適用されます。 そのようなラベルは、他の流れでそれを集めてある後に入力流動の分化を促進するのに使用されます。 ラベルはそうです。
Sahita, et. al. Informational [Page 20] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[20ページ]情報のRFC3318フレームワーク方針情報基地の行進
implementation specific and may be used for other policy related functions like flow accounting purposes and/or other data path treatments.
実装特有である、流れ会計目的のような他の方針関連する機能に中古である、そして/または、他のデータ経路処理はそうです。
5. The Framework PIB Module
5. フレームワークPIBモジュール
FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN
フレームワークPIB PIB定義:、:= 始まってください。
IMPORTS
Unsigned32, Integer32, MODULE-IDENTITY,
MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib
FROM COPS-PR-SPPI
InstanceId, Prid
FROM COPS-PR-SPPI-TC
RoleCombination, PrcIdentifierOid, AttrIdentifierOrZero,
ClientType, ClientHandle
FROM FRAMEWORK-TC-PIB
InetAddress, InetAddressType,
InetAddressPrefixLength, InetPortNumber
FROM INET-ADDRESS-MIB
InterfaceIndex
FROM IF-MIB
DscpOrAny
FROM DIFFSERV-DSCP-TC
TruthValue, PhysAddress
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB;
IMPORTS Unsigned32、Integer32、MODULE-IDENTITY、MODULE-COMPLIANCE、OBJECT-TYPE、OBJECT-GROUP、pib FROM COPS PR SPPI InstanceId、Prid FROM COPS PR SPPI-TC RoleCombination、PrcIdentifierOid、AttrIdentifierOrZero、ClientType、ClientHandle FROM FRAMEWORK-TC-PIB InetAddress、InetAddressType、InetAddressPrefixLength、InetPortNumber FROM INET-ADDRESS-MIB InterfaceIndex FROM、-、MIB DscpOrAny FROM DIFFSERV-DSCP-TC TruthValue、PhysAddress FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB。
frameworkPib MODULE-IDENTITY
SUBJECT-CATEGORIES { all }
LAST-UPDATED "200302130000Z" -- 13 Feb 2003
ORGANIZATION "IETF RAP WG"
CONTACT-INFO "
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive,
San Jose, CA 95134-1706 USA
Phone: +1 408 526 5260
Email: kzm@cisco.com
frameworkPib MODULE-IDENTITY SUBJECT-CATEGORIESすべてのLAST-UPDATED"200302130000Z"--「キースMcCloghrieシスコシステムズInc.170の西タスマンDrive、サンノゼ、カリフォルニア95134-1706米国は以下に電話をする」という2003年2月13日の組織「IETFラップWG」コンタクトインフォメーション +1 5260年の408 526メール: kzm@cisco.com
John Seligson
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95054 USA
Phone: +1 408 495 2992
Email: jseligso@nortelnetworks.com
ジョンSeligsonノーテルはグレート・アメリカParkwayカリフォルニア95054サンタクララ(米国)が電話をするInc.4401をネットワークでつなぎます: +1 2992年の408 495メール: jseligso@nortelnetworks.com
Sahita, et. al. Informational [Page 21] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[21ページ]情報のRFC3318フレームワーク方針情報基地の行進
Ravi Sahita
Intel Labs.
2111 NE 25th Ave.
ラービーSahitaインテル研究室。 2111 Neの第25Ave。
Hillsboro, OR 97124 USA
Phone: +1 503 712 1554
Email: ravi.sahita@intel.com
ヒースボロー、または97124米国電話: +1 1554年の503 712メール: ravi.sahita@intel.com
RAP WG Mailing list: rap@ops.ietf.org"
RAP WG Mailingは記載します: " rap@ops.ietf.org "
DESCRIPTION
"A PIB module containing the base set of PRCs that
provide support for management of multiple PIB contexts,
association of roles to device capabilities and other
reusable PRCs. PEPs are required for to implement this
PIB if the above features are desired. This PIB defines
PRCs applicable to 'all' subject-categories.
記述「複数のPIB文脈の管理、役割の協会のサポートをデバイス能力に提供するPRCsの基底集合を含むPIBモジュールと他の再利用できるPRCs。」 PIBが上記の特徴であるならこれを実装するために望まれるので、PEPsが必要です。 このPIBは'all'の受けることがあるカテゴリに適切なPRCsを定義します。
Copyright (C) The Internet Society (2003). This version
of this PIB module is part of RFC 3318; see the RFC
itself for full legal notices."
REVISION "200302130000Z" -- 13 Feb 2003
DESCRIPTION
"Initial version, published in RFC 3318."
Copyright(C)インターネット協会(2003)。 このPIBモジュールのこのバージョンはRFC3318の一部です。 「完全な法定の通知に関してRFC自身を見てください。」 REVISION"200302130000Z"--「初期のバージョンであって、RFC3318で発行された」2003年2月13日の記述。
::= { pib 2 }
::= pib2
-- -- The root OID for PRCs in the Framework PIB --
-- -- Framework PIBのPRCsのための根のOID--
frwkBasePibClasses
OBJECT IDENTIFIER ::= { frameworkPib 1 }
frwkBasePibClassesオブジェクト識別子:、:= frameworkPib1
-- -- PRC Support Table --
-- -- PRCはテーブルを支えます--
Sahita, et. al. Informational [Page 22] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[22ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkPrcSupportTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkPrcSupportEntry
PIB-ACCESS notify
STATUS current
DESCRIPTION
"Each instance of this PRC specifies a PRC that the device
supports and a bit string to indicate the attributes of the
class that are supported. These PRIs are sent to the PDP to
indicate to the PDP which PRCs, and which attributes of
these PRCs, the device supports.
frwkPrcSupportTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkPrcSupportEntry PIB-ACCESSはSTATUS現在の記述に通知します。「このPRCの各インスタンスはデバイスがサポートされるクラスの属性を示すためにサポートして、少し結ぶPRCを指定します」。 どのPRCs、およびこれらのPRCs(デバイスサポート)のどの属性をPDPに示すかためにこれらのPRIsをPDPに送ります。
All install and install-notify PRCs supported by the device
must be represented in this PRC. Notify PRCs may be
represented for informational purposes."
すべてがインストールされます、そして、このPRCにデバイスによってサポートされたインストールで通知しているPRCsを表さなければなりません。 「通知、PRCsが情報の目的のために表されるかもしれない、」
::= { frwkBasePibClasses 1 }
::= frwkBasePibClasses1
frwkPrcSupportEntry OBJECT-TYPE
SYNTAX FrwkPrcSupportEntry
STATUS current
DESCRIPTION
"An instance of the frwkPrcSupport class that identifies a
specific PRC and associated attributes as supported
by the device."
frwkPrcSupportEntry OBJECT-TYPE SYNTAX FrwkPrcSupportEntry STATUSの現在の記述、「デバイスによってサポートされるように特定のPRCと関連属性を特定するfrwkPrcSupportのクラスのインスタンス。」
PIB-INDEX { frwkPrcSupportPrid }
UNIQUENESS { frwkPrcSupportSupportedPrc }
PIB-インデックスfrwkPrcSupportPrid、ユニークさfrwkPrcSupportSupportedPrc
::= { frwkPrcSupportTable 1 }
::= frwkPrcSupportTable1
FrwkPrcSupportEntry ::= SEQUENCE {
frwkPrcSupportPrid InstanceId,
frwkPrcSupportSupportedPrc PrcIdentifierOid,
frwkPrcSupportSupportedAttrs OCTET STRING
}
FrwkPrcSupportEntry:、:= 系列frwkPrcSupportPrid InstanceId、frwkPrcSupportSupportedPrc PrcIdentifierOid、frwkPrcSupportSupportedAttrs八重奏ストリング
frwkPrcSupportPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the frwkPrcSupport class."
frwkPrcSupportPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述、「唯一frwkPrcSupportのクラスのインスタンスを特定する任意の整数インデックス。」
::= { frwkPrcSupportEntry 1 }
::= frwkPrcSupportEntry1
Sahita, et. al. Informational [Page 23] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[23ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkPrcSupportSupportedPrc OBJECT-TYPE
SYNTAX PrcIdentifierOid
STATUS current
DESCRIPTION
"The object identifier of a supported PRC. The value is the
OID of the Entry object of the PRC definition. The Entry
Object definition of a PRC has an OID with value XxxTable.1
Where, XxxTable is the OID assigned to the PRC Table
Object definition. There may not be more than one instance
of the frwkPrcSupport class with the same value of
frwkPrcSupportSupportedPrc."
「aに関するオブジェクト識別子はPRCをサポートした」frwkPrcSupportSupportedPrc OBJECT-TYPE SYNTAX PrcIdentifierOid STATUSの現在の記述。 値はPRC定義のEntry目的のOIDです。 PRCの定義にはOIDがあるEntry ObjectはXxxTable.1Whereを評価して、XxxTableはPRC Table Object定義に割り当てられたOIDです。 「frwkPrcSupportのクラスの1つ以上のインスタンスがfrwkPrcSupportSupportedPrcの同じ値と共にないかもしれません。」
::= { frwkPrcSupportEntry 2 }
::= frwkPrcSupportEntry2
frwkPrcSupportSupportedAttrs OBJECT-TYPE
SYNTAX OCTET STRING
STATUS current
DESCRIPTION
"A bit string representing the supported attributes of the
class that is identified by the frwkPrcSupportSupportedPrc
object.
現在の記述が「frwkPrcSupportSupportedPrcオブジェクトによって特定されるクラスのサポートしている属性を表しながら、少し結ぶ」frwkPrcSupportSupportedAttrs OBJECT-TYPE SYNTAX OCTET STRING STATUS。
Each bit of this bit string corresponds to a class
attribute, with the most significant bit of the i-th octet
of this octet string corresponding to the (8*i - 7)-th
attribute, and the least significant bit of the i-th octet
corresponding to the (8*i)-th class attribute. Each bit
specifies whether or not the corresponding class attribute
is currently supported, with a '1' indicating support and a
'0' indicating no support.
このビット列の各ビットが大部分が重要な状態で噛み付かれたクラス属性に対応している、i、-、この八重奏の八重奏が対応を第結ぶ、(8*i--7)、-、属性、および第最下位ビット、i、-、(8*i)に対応する第八重奏、-、第クラス属性。 各ビットは、対応するクラス属性が現在サポートされるかどうか指定します、サポートを示す'1'とサポートを全く示さない'0'で。
If the value of this bit string is N bits long and there are
more than N class attributes then the bit string is
logically extended with 0's to the required length.
On the other hand, If the PDP receives a bit string of
length N and there are less that N class attributes then the
PDP should ignore the extra bits in the bit string, i.e.,
assume those attributes are unsupported."
REFERENCE
"COPS Usage for Policy Provisioning. RFC 3084, section
2.2.1."
このビット列の値がN長さビットであり、Nクラス属性があれば、ビット列は0で必要な長さに論理的に広げられます。 「他方では、If PDPが長さNのストリングを少し受けて、Nのクラスが結果と考える以下があって、次に、すなわち、PDPがビット列で付加的なビットを無視するはずである、それらの属性がサポートされないと仮定してください、」 参照は「方針の食糧を供給する用法を獲得します」。 「RFC3084、セクション2.2.1。」
::= { frwkPrcSupportEntry 3 }
::= frwkPrcSupportEntry3
-- -- PIB Incarnation Table --
-- -- PIB顕現テーブル--
Sahita, et. al. Informational [Page 24] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[24ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkPibIncarnationTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkPibIncarnationEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"This PRC contains a single PRovisioning Instance per
installed context that identifies the current incarnation
of the PIB and the PDP or network manager that installed
this incarnation. The instance of this PRC is reported to
the PDP in the REQ message so that the PDP can (attempt to)
ascertain the current state of the PIB. A network manager
may use the instance to determine the state of the device."
frwkPibIncarnationTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkPibIncarnationEntry PIB-ACCESSは「このPRCはこの肉体化をインストールしたPIBとPDPかネットワークマネージャの現在の肉体化を特定するインストールされた文脈あたり1独身のPRovisioning Instanceに含む」STATUSの現在の記述にインストールで通知します。 このPRCのインスタンスは、PDPがPIBの現状を確かめることができる(試みる)ように、REQメッセージのPDPに報告されます。 「ネットワークマネージャはデバイスの状態を決定するのにインスタンスを使用するかもしれません。」
::= { frwkBasePibClasses 2 }
::= frwkBasePibClasses2
frwkPibIncarnationEntry OBJECT-TYPE
SYNTAX FrwkPibIncarnationEntry
STATUS current
DESCRIPTION
"An instance of the frwkPibIncarnation class. Only
one instance of this PRC is ever instantiated per context"
「frwkPibIncarnationのインスタンスは分類する」frwkPibIncarnationEntry OBJECT-TYPE SYNTAX FrwkPibIncarnationEntry STATUSの現在の記述。 「このPRCの1つのインスタンスだけが今までに、文脈単位で例示されます」
PIB-INDEX { frwkPibIncarnationPrid }
PIB-インデックスfrwkPibIncarnationPrid
::= { frwkPibIncarnationTable 1 }
::= frwkPibIncarnationTable1
FrwkPibIncarnationEntry ::= SEQUENCE {
frwkPibIncarnationPrid InstanceId,
frwkPibIncarnationName SnmpAdminString,
frwkPibIncarnationId OCTET STRING,
frwkPibIncarnationLongevity INTEGER,
frwkPibIncarnationTtl Unsigned32,
frwkPibIncarnationInCtxtSet TruthValue,
frwkPibIncarnationActive TruthValue,
frwkPibIncarnationFullState TruthValue
}
FrwkPibIncarnationEntry:、:= 系列frwkPibIncarnationPrid InstanceId、frwkPibIncarnationName SnmpAdminString、frwkPibIncarnationId八重奏ストリング、frwkPibIncarnationLongevity整数、frwkPibIncarnationTtl Unsigned32、frwkPibIncarnationInCtxtSet TruthValue、frwkPibIncarnationActive TruthValue、frwkPibIncarnationFullState TruthValue
frwkPibIncarnationPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An index to uniquely identify an instance of this PRC."
frwkPibIncarnationPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述、「唯一このPRCのインスタンスを特定するインデックス。」
::= { frwkPibIncarnationEntry 1 }
::= frwkPibIncarnationEntry1
Sahita, et. al. Informational [Page 25] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[25ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkPibIncarnationName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
STATUS current
DESCRIPTION
"The name of the PDP that installed the current incarnation
of the PIB into the device. A zero-length string value for
this type implies the PDP has not assigned this type any
value. By default, it is the zero length string."
frwkPibIncarnationName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .255))のSTATUSの現在の記述、「PIBの現在の肉体化をデバイスにインストールしたPDPという名前。」 このタイプのためのゼロ長ストリング値は、PDPが少しの値もこのタイプに割り当てていないのを含意します。 「デフォルトで、それはゼロ長ストリングです。」
::= { frwkPibIncarnationEntry 2 }
::= frwkPibIncarnationEntry2
frwkPibIncarnationId OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
STATUS current
DESCRIPTION
"An ID to identify the current incarnation. It has meaning
to the PDP/manager that installed the PIB and perhaps its
standby PDPs/managers. A zero-length string value for
this type implies the PDP has not assigned this type any
value. By default, it is the zero-length string."
frwkPibIncarnationId OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0 .255))のSTATUSの現在の記述「現在の肉体化を特定するID。」 それはPIBをインストールしたPDP/マネージャと恐らくその予備PDPs/マネージャに意味を持っています。 このタイプのためのゼロ長ストリング値は、PDPが少しの値もこのタイプに割り当てていないのを含意します。 「デフォルトで、それはゼロ長ストリングです。」
::= { frwkPibIncarnationEntry 3 }
::= frwkPibIncarnationEntry3
frwkPibIncarnationLongevity OBJECT-TYPE
SYNTAX INTEGER {
expireNever(1),
expireImmediate(2),
expireOnTimeout(3)
}
STATUS current
DESCRIPTION
"This attribute controls what the PEP does with the
downloaded policy on a Client Close message or a loss of
connection to the PDP.
frwkPibIncarnationLongevity OBJECT-TYPE SYNTAX INTEGER、expireNever(1)、expireImmediate(2)、expireOnTimeout(3)、STATUSの現在の記述、「この属性はPEPがClient Closeメッセージに関するダウンロードされた方針か接続の損失でPDPにすることを制御します」。
If set to expireNever, the PEP continues to operate with the
installed policy indefinitely. If set to expireImmediate,
the PEP immediately expires the policy obtained from the PDP
and installs policy from local configuration. If set to
expireOnTimeout, the PEP continues to operate with the
policy installed by the PDP for a period of time specified
by frwkPibIncarnationTtl. After this time (and it has not
reconnected to the original or new PDP) the PEP expires this
policy and reverts to local configuration.
expireNeverに設定されるなら、PEPは、インストールされた方針で無期限に作動し続けています。 expireImmediateに設定されるなら、PEPはすぐに、PDPから得られた方針を吐き出して、地方の構成から方針をインストールします。 expireOnTimeoutに設定されるなら、PEPは、方針がしばらくfrwkPibIncarnationTtlによって指定されているPDPによってインストールされている状態で作動し続けています。 今回(それはオリジナルの、または、新しいPDPに再接続していない)以降、PEPはこの方針を吐き出して、地方の構成に戻ります。
For all cases, it is the responsibility of the PDP to check
the incarnation and download new policy, if necessary, on a
reconnect. On receiving a Remove-State for the active
すべてのケースのために、それは、PDPが肉体化をチェックする責任と必要ならaに関する新しい政策が再接続するダウンロードです。 アクティブためにRemove-状態を受けることに関して
Sahita, et. al. Informational [Page 26] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[26ページ]情報のRFC3318フレームワーク方針情報基地の行進
context, this attribute value MUST be ignored and the PEP
should expire the policy in that active context immediately.
Policy enforcement timing only applies to policies that have
been installed dynamically (e.g., by a PDP via COPS)."
REFERENCE
"COPS Usage for Policy Provisioning. RFC 3084."
文脈、この属性値を無視しなければなりません、そして、PEPはすぐに、そのアクティブな文脈の方針を吐き出すはずです。 「方針実施タイミングはダイナミック(例えば、COPSを通したPDP)にインストールされた方針に適用されるだけです。」 参照は「方針の食糧を供給する用法を獲得します」。 「RFC3084。」
::= { frwkPibIncarnationEntry 4 }
::= frwkPibIncarnationEntry4
frwkPibIncarnationTtl OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
STATUS current
DESCRIPTION
"The number of seconds after a Client Close or TCP timeout
for which the PEP continues to enforce the policy in the
PIB. After this interval, the PIB is considered expired and
the device no longer enforces the policy installed in the
PIB.
frwkPibIncarnationTtl OBJECT-TYPE SYNTAX Unsigned32 UNITSはSTATUSの現在の記述を「後援します」。「PEPがPIBの方針を実施し続けているClient CloseかTCPタイムアウトの後の秒数。」 この間隔の後に、PIBは満期であると考えられます、そして、デバイスはもうPIBにインストールされた方針を実施しません。
This attribute is only meaningful if
frwkPibIncarnationLongevity is set to expireOnTimeout."
「frwkPibIncarnationLongevityがexpireOnTimeoutに用意ができている場合にだけ、この属性は重要です。」
::= { frwkPibIncarnationEntry 5 }
::= frwkPibIncarnationEntry5
frwkPibIncarnationInCtxtSet OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"When the PDP installs a PRI with this flag set to 'true' it
implies this context belongs to the set of contexts out of
which at the most one context can be active at a given time.
If this attribute is set to 'false' this context is one of
the outsourcing (simultaneous active) contexts on the PEP.
「PDPはこの旗のセットで最も1つでは、文脈が一時にアクティブである場合があるセットに属するそれがこの文脈を含意する'本当に'文脈にPRIをインストールする」ときのfrwkPibIncarnationInCtxtSet OBJECT-TYPE SYNTAX TruthValue STATUSの現在の記述。 この属性が'偽'に設定されるなら、この文脈はPEPのアウトソーシング(同時の能動態)文脈の1つです。
This attribute is 'true' for all contexts belong to the set
of configuration contexts. Within the configuration context
set, one context can be active identified by the
frwkPibIncarnationActive attribute."
REFERENCE
"TruthValue Textual Convention, defined in RFC 2579."
::= { frwkPibIncarnationEntry 6 }
この属性はすべてに関して、'本当に'文脈が構成文脈のセットに属すということです。 「frwkPibIncarnationActive属性によって特定されて、構成文脈セットの中では、1つの文脈がアクティブである場合があります。」 「TruthValue Textual Conventionであって、RFC2579で定義された」REFERENCE。 ::= frwkPibIncarnationEntry6
Sahita, et. al. Informational [Page 27] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[27ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkPibIncarnationActive OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"When the PDP installs a PRI on the PEP with this attribute
set to 'true' and if this context belongs to the
'configuration contexts' set, i.e., the
frwkPibIncarnationInCtxtSet is set to 'true', then the PIB
instance to which this PRI belongs must become the active
PIB instance. In this case, the previous active instance
from this set MUST become inactive and the
frwkPibIncarnationActive attribute in that PIB instance MUST
be set to 'false'.
「'本当'へのこの属性セットとこの文脈が'構成文脈に属すかどうかでPDPはPEPの上にPRIをインストールする'とき、frwkPibIncarnationActive OBJECT-TYPE SYNTAX TruthValue STATUSの現在の記述がセットしました、すなわち、frwkPibIncarnationInCtxtSetが''そして、本当に、このPRIが属するPIBインスタンスはアクティブなPIBインスタンスにならなければならないこと」に用意ができています。 この場合、このセットからの前のアクティブなインスタンスは不活発にならなければなりません、そして、そのPIBインスタンスにおけるfrwkPibIncarnationActive属性を'誤っていること'に設定しなければなりません。
When the PDP installs an attribute frwkPibIncarnationActive
on the PEP that is 'true' in one PIB instance and if the
context belongs to the 'configuration contexts' set, the PEP
must ensure, re-setting the attribute if necessary, that the
frwkPibIncarnationActive attribute is 'false' in all other
contexts which belong to the 'configuration contexts' set."
「PDPが属性frwkPibIncarnationActiveをPEPの上にインストールするとき、それは1つのPIBインスタンスで'本当です'、そして、文脈が'構成文脈'セットに属すなら、必要なら、属性をリセットして、PEPはfrwkPibIncarnationActive属性が'構成文脈'セットに属す他のすべての文脈で'誤っていること'を確実にしなければなりません。」
::= { frwkPibIncarnationEntry 7 }
::= frwkPibIncarnationEntry7
frwkPibIncarnationFullState OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"This attribute is interpreted only when sent in a COPS
request message from the PEP to the PDP. It does not have
any meaning when sent from the PDP to the PEP.
frwkPibIncarnationFullState OBJECT-TYPE SYNTAX TruthValue STATUSの現在の記述、「PEPからPDPまでのCOPS要求メッセージで送る場合にだけ、この属性を解釈します」。 それには、PDPからPEPに送る場合、少しの意味もありません。
If this attribute is set to 'true' by the PEP, then the
request that the PEP sends to the PDP must be interpreted as
the complete configuration request for the PEP. The PDP must
in this case refresh the request information for the
handle that the request containing this PRI was received on.
If this attribute is set to 'false', then the
request PRIs sent in the request must be interpreted as
updates to the previous request PRIs sent using that handle.
See section 3.3 for details on updating request state
information."
REFERENCE
"RFC 3318 Section 2.3"
この属性がPEPによって'本当に'設定されるなら、PEPを求める完全な構成要求としてPEPがPDPに発信するという要求を解釈しなければなりません。 PDPはこの場合ハンドルのためのこのPRIを含む要求のときに受け取ったという要求情報をリフレッシュしなければなりません。 この属性が'誤っていること'に設定されるなら、要求PRIsは、前の要求PRIsへのアップデートがそのハンドルを使用することで発信したので要求を解釈しなければならないのを送りました。 「要求州の情報をアップデートすることに関する詳細に関してセクション3.3を見てください。」 「RFC3318は2.3インチを区分する」という参照
::= { frwkPibIncarnationEntry 8 }
::= frwkPibIncarnationEntry8
-- -- Device Identification Table
-- -- デバイス識別テーブル
Sahita, et. al. Informational [Page 28] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[28ページ]情報のRFC3318フレームワーク方針情報基地の行進
--
--
frwkDeviceIdTable OBJECT-TYPE
frwkDeviceIdTableオブジェクト・タイプ
SYNTAX SEQUENCE OF FrwkDeviceIdEntry
PIB-ACCESS notify
STATUS current
DESCRIPTION
"This PRC contains a single PRovisioning Instance that
contains general purpose device-specific information that is
used to facilitate efficient policy communication by a PDP.
The instance of this PRC is reported to the PDP in a COPS
request message so that the PDP can take into account
certain device characteristics during policy installation."
SYNTAX SEQUENCE OF FrwkDeviceIdEntry PIB-ACCESSはSTATUS現在の記述に通知します。「このPRCはPDPで効率的な方針コミュニケーションを容易にするのに使用される汎用デバイス特殊情報を含む独身のPRovisioning Instanceを含んでいます」。 「このPRCのインスタンスはPDPが方針インストールの間、あるデバイスの特性を考慮に入れることができるように、COPS要求メッセージのPDPに報告されます。」
::= { frwkBasePibClasses 3 }
::= frwkBasePibClasses3
frwkDeviceIdEntry OBJECT-TYPE
SYNTAX FrwkDeviceIdEntry
STATUS current
DESCRIPTION
"An instance of the frwkDeviceId class. Only one instance of
this PRC is ever instantiated."
「frwkDeviceIdのインスタンスは分類する」frwkDeviceIdEntry OBJECT-TYPE SYNTAX FrwkDeviceIdEntry STATUSの現在の記述。 「このPRCの1つのインスタンスだけが今までに、例示されます。」
PIB-INDEX { frwkDeviceIdPrid }
PIB-インデックスfrwkDeviceIdPrid
::= { frwkDeviceIdTable 1 }
::= frwkDeviceIdTable1
FrwkDeviceIdEntry ::= SEQUENCE {
frwkDeviceIdPrid InstanceId,
frwkDeviceIdDescr SnmpAdminString,
frwkDeviceIdMaxMsg Unsigned32,
frwkDeviceIdMaxContexts Unsigned32
}
FrwkDeviceIdEntry:、:= 系列frwkDeviceIdPrid InstanceId、frwkDeviceIdDescr SnmpAdminString、frwkDeviceIdMaxMsg Unsigned32、frwkDeviceIdMaxContexts Unsigned32
frwkDeviceIdPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An index to uniquely identify an instance of this PRC."
frwkDeviceIdPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述、「唯一このPRCのインスタンスを特定するインデックス。」
::= { frwkDeviceIdEntry 1 }
::= frwkDeviceIdEntry1
Sahita, et. al. Informational [Page 29] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[29ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkDeviceIdDescr OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..255))
STATUS current
DESCRIPTION
"A textual description of the PEP. This value should include
the name and version identification of the PEP's hardware
and software."
frwkDeviceIdDescr OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .255))のSTATUSの現在の記述、「PEPの原文の記述。」 「この値はPEPのハードウェアとソフトウェアの名前とバージョン識別を含むべきです。」
::= { frwkDeviceIdEntry 2 }
::= frwkDeviceIdEntry2
frwkDeviceIdMaxMsg OBJECT-TYPE
SYNTAX Unsigned32 (64..4294967295)
UNITS "octets"
STATUS current
DESCRIPTION
"The maximum COPS-PR message size, in octets, that the
device is capable of processing. Received messages with a
size in excess of this value must cause the PEP to return an
error to the PDP containing the global error code
'maxMsgSizeExceeded'. This is an additional error-avoidance
mechanism to allow the administrator to know the maximum
message size supported so that they have the ability to
control the message size of messages sent to the device.
This attribute must have a non-zero value. The device should
send the MAX value for Unsigned32 for this attribute if it
not defined."
DEFVAL { 4294967295 }
frwkDeviceIdMaxMsg OBJECT-TYPE SYNTAX Unsigned32(64 .4294967295)UNITS「八重奏」STATUSの現在の記述、「八重奏におけるデバイスが処理できる最大のCOPS-PRメッセージサイズ。」 この値を超えたサイズがある受信されたメッセージで、PEPはグローバルなエラーコード'maxMsgSizeExceeded'を含むPDPに誤りを返さなければなりません。 これが管理者が、最大のメッセージサイズがサポートしたのを知っているのを許容する追加誤り回避メカニズムであるので、彼らには、デバイスに送られたメッセージのメッセージサイズを制御する能力があります。 この属性に、非ゼロ値がなければなりません。 「定義されないで、デバイスはそれであるならこの属性のためのUnsigned32のためにMAX値を送るはずです。」 DEFVAL{ 4294967295 }
::= { frwkDeviceIdEntry 3 }
::= frwkDeviceIdEntry3
frwkDeviceIdMaxContexts OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
UNITS "contexts"
STATUS current
DESCRIPTION
"The maximum number of unique contexts supported by
the device. This is an additional error-avoidance mechanism
to allow the administrators to have the ability to know the
maximum number of contexts supported so that they can
control the number of configuration contexts they install on
the device. This attribute must have a non-zero value. The
device should send the MAX value for Unsigned32 for this
attribute if it not defined."
DEFVAL { 4294967295 }
「ユニークな文脈の最大数はデバイスでサポートした」frwkDeviceIdMaxContexts OBJECT-TYPE SYNTAX Unsigned32(1 .4294967295)UNITS「文脈」STATUSの現在の記述。 これは管理者にはそれらがデバイスにインストールする構成文脈の数を制御できるようにサポートされた文脈の最大数を知る能力があるのを許容する追加誤り回避メカニズムです。 この属性に、非ゼロ値がなければなりません。 「定義されないで、デバイスはそれであるならこの属性のためのUnsigned32のためにMAX値を送るはずです。」 DEFVAL{ 4294967295 }
::= { frwkDeviceIdEntry 4 }
::= frwkDeviceIdEntry4
--
--
Sahita, et. al. Informational [Page 30] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[30ページ]情報のRFC3318フレームワーク方針情報基地の行進
-- Component Limitations Table --
-- コンポーネント制限テーブル--
frwkCompLimitsTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkCompLimitsEntry
PIB-ACCESS notify
STATUS current
DESCRIPTION
"This PRC supports the ability to export information
detailing PRC/attribute implementation limitations to the
policy management system. Instances of this PRC apply only
for PRCs with access type 'install' or 'install-notify'.
frwkCompLimitsTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkCompLimitsEntry PIB-ACCESSは「このPRCはPRC/属性実装制限を政策管理システムに詳しく述べる情報をエクスポートする能力をサポートする」STATUSの現在の記述に通知します。 このPRCのインスタンスは、アクセス型'インストール'でPRCsだけに申し込むか、または'インストールで通知します'。
Each instance of this PRC identifies a PRovisioning Class
or attribute and a limitation related to the implementation
of the class/attribute in the device. Additional information
providing guidance related to the limitation may also be
present. These PRIs are sent to the PDP to indicate which
PRCs or PRC attributes the device supports in a restricted
manner."
このPRCの各インスタンスはデバイスでクラス/属性の実装に関連するPRovisioning Classか属性と制限を特定します。 また、指導が制限に関連したなら、追加情報も存在しているかもしれません。 「デバイスが制限された方法でどのPRCsかPRC属性をサポートするかを示すためにこれらのPRIsをPDPに送ります。」
::= { frwkBasePibClasses 4 }
::= frwkBasePibClasses4
frwkCompLimitsEntry OBJECT-TYPE
SYNTAX FrwkCompLimitsEntry
STATUS current
DESCRIPTION
"An instance of the frwkCompLimits class that identifies
a PRC or PRC attribute and a limitation related to the PRC
or PRC attribute implementation supported by the device.
COPS-PR lists the error codes that MUST be returned (if
applicable)for policy installation that don't abide by the
restrictions indicated by the limitations exported. [SPPI]
defines an INSTALL-ERRORS clause that allows PIB designers
to define PRC specific error codes that can be returned for
policy installation. This allows efficient debugging of PIB
implementations."
REFERENCE
"COPS Usage for Policy Provisioning. RFC 3084."
「PRCかPRC属性を特定するfrwkCompLimitsのクラスのインスタンスと制限はデバイスによってサポートされたPRCかPRC属性実装に関係づけた」frwkCompLimitsEntry OBJECT-TYPE SYNTAX FrwkCompLimitsEntry STATUSの現在の記述。 誤りがコード化する制限で示された制限を守らない方針インストールにおいて、返されて(適切)でなければならないCOPS-PRリストはエクスポートしました。 [SPPI]はPIBデザイナーが方針インストールのために返すことができるPRCの特定のエラーコードを定義できるINSTALL-ERRORS節を定義します。 「これはPIB実装の効率的なデバッグを許します。」 参照は「方針の食糧を供給する用法を獲得します」。 「RFC3084。」
PIB-INDEX { frwkCompLimitsPrid }
UNIQUENESS { frwkCompLimitsComponent,
frwkCompLimitsAttrPos,
frwkCompLimitsNegation,
frwkCompLimitsType,
frwkCompLimitsSubType,
frwkCompLimitsGuidance }
PIB-インデックスfrwkCompLimitsPrid、ユニークさfrwkCompLimitsComponent、frwkCompLimitsAttrPos、frwkCompLimitsNegation、frwkCompLimitsType、frwkCompLimitsSubType、frwkCompLimitsGuidance
Sahita, et. al. Informational [Page 31] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[31ページ]情報のRFC3318フレームワーク方針情報基地の行進
::= { frwkCompLimitsTable 1 }
::= frwkCompLimitsTable1
FrwkCompLimitsEntry ::= SEQUENCE {
frwkCompLimitsPrid InstanceId,
frwkCompLimitsComponent PrcIdentifierOid,
frwkCompLimitsAttrPos AttrIdentifierOrZero,
frwkCompLimitsNegation TruthValue,
frwkCompLimitsType INTEGER,
frwkCompLimitsSubType INTEGER,
frwkCompLimitsGuidance OCTET STRING
}
FrwkCompLimitsEntry:、:= 系列frwkCompLimitsPrid InstanceId、frwkCompLimitsComponent PrcIdentifierOid、frwkCompLimitsAttrPos AttrIdentifierOrZero、frwkCompLimitsNegation TruthValue、frwkCompLimitsType整数、frwkCompLimitsSubType整数、frwkCompLimitsGuidance八重奏ストリング
frwkCompLimitsPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the frwkCompLimits class."
frwkCompLimitsPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述、「唯一frwkCompLimitsのクラスのインスタンスを特定する任意の整数インデックス。」
::= { frwkCompLimitsEntry 1 }
::= frwkCompLimitsEntry1
frwkCompLimitsComponent OBJECT-TYPE
SYNTAX PrcIdentifierOid
STATUS current
DESCRIPTION
"The value is the OID of a PRC (the table entry) which is
supported in some limited fashion or contains an attribute
that is supported in some limited fashion with regard to
it's definition in the associated PIB module. The same OID
may appear in the table several times, once for each
implementation limitation acknowledged by the device."
frwkCompLimitsComponent OBJECT-TYPE SYNTAX PrcIdentifierOid STATUSの現在の記述、「値は何らかの限られたファッションでサポートされるか、または属性を含むPRC(テーブル項目)のOIDです、すなわち、それに関して何らかの限られたファッションでサポートされているのは、関連PIBモジュールへの定義です」。 「同じOIDはテーブルに何度か一度デバイスによって承諾されたそれぞれの実装制限に関して現れるかもしれません。」
::= { frwkCompLimitsEntry 2 }
::= frwkCompLimitsEntry2
frwkCompLimitsAttrPos OBJECT-TYPE
SYNTAX AttrIdentifierOrZero
STATUS current
DESCRIPTION
"The relative position of the attribute within the PRC
specified by the frwkCompLimitsComponent. A value of 1 would
represent the first columnar object in the PRC and a value
of N would represent the Nth columnar object in the PRC. A
value of zero (0) indicates that the limit applies to the
PRC itself and not to a specific attribute."
「PRCの中の属性の相対的な位置はfrwkCompLimitsComponentで指定した」frwkCompLimitsAttrPos OBJECT-TYPE SYNTAX AttrIdentifierOrZero STATUSの現在の記述。 1の値はPRCにおける最初の円柱状のオブジェクトを表すでしょう、そして、Nの値はPRCにNthの円柱状のオブジェクトを表すでしょう。 「(0)がない値は、限界が特定の属性ではなく、PRC自身に適用されるのを示します。」
::= { frwkCompLimitsEntry 3 }
::= frwkCompLimitsEntry3
Sahita, et. al. Informational [Page 32] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[32ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkCompLimitsNegation OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"A boolean value ,if 'true', negates the component limit
exported."
frwkCompLimitsNegation OBJECT-TYPE SYNTAX TruthValue STATUSの現在の記述は「'本当である'なら、エクスポートされたコンポーネント限界を否定論理演算子が評価するします」。
::= { frwkCompLimitsEntry 4 }
::= frwkCompLimitsEntry4
frwkCompLimitsType OBJECT-TYPE
SYNTAX INTEGER {
priSpaceLimited(1),
attrValueSupLimited(2),
attrEnumSupLimited(3),
attrLengthLimited(4),
prcLimitedNotify(5)
}
STATUS current
DESCRIPTION
"A value describing an implementation limitation for the
device related to the PRC or PRC attribute identified by
the frwkCompLimitsComponent and the frwkCompLimitsAttrPos
attributes.
frwkCompLimitsType OBJECT-TYPE SYNTAX INTEGER、priSpaceLimited(1)、attrValueSupLimited(2)、attrEnumSupLimited(3)、attrLengthLimited(4)、prcLimitedNotify(5)、「AはfrwkCompLimitsComponentとfrwkCompLimitsAttrPos属性によって特定されたPRCかPRC属性に関連するデバイスのための実装制限について説明しながら、評価する」STATUSの現在の記述。
Values for this object are one of the following:
このオブジェクトのための値は以下の1つです:
priSpaceLimited(1) - No more instances than that specified
by the guidance value may be installed in the given class.
The component identified MUST be a valid PRC. The SubType
used MUST be valueOnly(9).
priSpaceLimited(1)--指導値によって指定されたそれがインスタンスでないことのようなどんなインスタンスも与えられたクラスにインストールされないかもしれません。 特定されたコンポーネントは有効なPRCであるに違いありません。 使用されるSubTypeはvalueOnly(9)であるに違いありません。
attrValueSupLimited(2) - Limited values are acceptable for
the identified component. The component identified MUST be a
valid PRC attribute. The guidance OCTET STRING will be
decoded according to the attribute type.
attrValueSupLimited(2)--特定されたコンポーネントにおいて、株式会社値は許容できます。 特定されたコンポーネントは有効なPRC属性であるに違いありません。 属性タイプに従って、指導OCTET STRINGは解読されるでしょう。
attrEnumSupLimited(3) - Limited enumeration values are legal
for the identified component. The attribute identified MUST
be a valid enum type.
attrEnumSupLimited(3)--特定されたコンポーネントに、株式会社列挙値は法的です。 特定された属性は有効なenumタイプであるに違いありません。
attrLengthLimited(4) - The length of the specified
value for the identified component is limited. The component
identified MUST be a valid PRC attribute of base-type OCTET
STRING.
attrLengthLimited(4)--特定されたコンポーネントのための規定値の長さは限られています。 特定されたコンポーネントはベースタイプOCTET STRINGの有効なPRC属性であるに違いありません。
prcLimitedNotify (5) - The component is currently limited
for use by request or report messages prohibiting decision
installation. The component identified must be a valid PRC."
prcLimitedNotify(5)--コンポーネントは現在、使用のために決定施設を禁止する要求かレポートメッセージによって制限されます。 「特定されたコンポーネントは有効なPRCであるに違いありません。」
Sahita, et. al. Informational [Page 33] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[33ページ]情報のRFC3318フレームワーク方針情報基地の行進
::= { frwkCompLimitsEntry 5 }
::= frwkCompLimitsEntry5
frwkCompLimitsSubType OBJECT-TYPE
SYNTAX INTEGER {
none(1),
lengthMin(2),
lengthMax(3),
rangeMin(4),
rangeMax(5),
enumMin(6),
enumMax(7),
enumOnly(8),
valueOnly(9),
bitMask(10)
}
STATUS current
DESCRIPTION
"This object indicates the type of guidance related
to the noted limitation (as indicated by the
frwkCompLimitsType attribute) that is provided
in the frwkCompLimitsGuidance attribute.
frwkCompLimitsSubType OBJECT-TYPE SYNTAX INTEGER、なにも、(1)、lengthMin(2)、lengthMax(3)、rangeMin(4)、rangeMax(5)、enumMin(6)、enumMax(7)、enumOnly(8)、valueOnly(9)、bitMask(10)、「frwkCompLimitsGuidance属性に提供される有名な制限(frwkCompLimitsType属性によって示されるように)に関係づけこのオブジェクトが指導のタイプを示すした」STATUSの現在の記述。
A value of 'none(1)' means that no additional
guidance is provided for the noted limitation type.
値、'なにもでは、どんな追加指導もない(1)'手段が有名な制限タイプに備えました。
A value of 'lengthMin(2)' means that the guidance
attribute provides data related to the minimum
acceptable length for the value of the identified
component. A corresponding class instance
specifying the 'lengthMax(3)' value is required
in conjunction with this sub-type.
'lengthMin(2)'の値は、指導属性が最小の許容できる長さに関連するデータを特定されたコンポーネントの値に提供することを意味します。 'lengthMax(3)'値を指定する対応するクラスインスタンスがこのサブタイプに関連して必要です。
A value of 'lengthMax(3)' means that the guidance
attribute provides data related to the maximum
acceptable length for the value of the identified
component. A corresponding class instance
specifying the 'lengthMin(2)' value is required
in conjunction with this sub-type.
'lengthMax(3)'の値は、指導属性が最大の許容できる長さに関連するデータを特定されたコンポーネントの値に提供することを意味します。 'lengthMin(2)'値を指定する対応するクラスインスタンスがこのサブタイプに関連して必要です。
A value of 'rangeMin(4)' means that the guidance
attribute provides data related to the lower bound
of the range for the value of the identified
component. A corresponding class instance
specifying the 'rangeMax(5)' value is required
in conjunction with this sub-type.
'rangeMin(4)'の値は、指導属性が範囲の下界に関連するデータを特定されたコンポーネントの値に提供することを意味します。 'rangeMax(5)'値を指定する対応するクラスインスタンスがこのサブタイプに関連して必要です。
A value of 'rangeMax(5)' means that the guidance
attribute provides data related to the upper bound
'rangeMax(5)'の値は、指導属性が上限に関連するデータを提供することを意味します。
Sahita, et. al. Informational [Page 34] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[34ページ]情報のRFC3318フレームワーク方針情報基地の行進
of the range for the value of the identified
component. A corresponding class instance
specifying the 'rangeMin(4)' value is required
in conjunction with this sub-type.
特定されたコンポーネントの値のための範囲について。 'rangeMin(4)'値を指定する対応するクラスインスタンスがこのサブタイプに関連して必要です。
A value of 'enumMin(6)' means that the guidance
attribute provides data related to the lowest
enumeration acceptable for the value of the
identified component. A corresponding
class instance specifying the 'enumMax(7)'
value is required in conjunction with this sub-type.
'enumMin(6)'の値は、指導属性が特定されたコンポーネントの値において、許容できる最も低い列挙に関連するデータを提供することを意味します。 'enumMax(7)'値を指定する対応するクラスインスタンスがこのサブタイプに関連して必要です。
A value of 'enumMax(7)' means that the guidance
attribute provides data related to the largest
enumeration acceptable for the value of the
identified component. A corresponding
class instance specifying the 'enumMin(6)'
value is required in conjunction with this sub-type.
'enumMax(7)'の値は、指導属性が特定されたコンポーネントの値において、許容できる最も大きい列挙に関連するデータを提供することを意味します。 'enumMin(6)'値を指定する対応するクラスインスタンスがこのサブタイプに関連して必要です。
A value of 'enumOnly(8)' means that the guidance
attribute provides data related to a single
enumeration acceptable for the value of the
identified component.
'enumOnly(8)'の値は、指導属性が特定されたコンポーネントの値において、許容できるただ一つの列挙に関連するデータを提供することを意味します。
A value of 'valueOnly(9)' means that the guidance
attribute provides data related to a single
value that is acceptable for the identified
component.
'valueOnly(9)'の値は、指導属性が特定されたコンポーネントにおいて、許容できるただ一つの値に関連するデータを提供することを意味します。
A value of 'bitMask(10)' means that the guidance
attribute is a bit mask such that all the combinations of
bits set in the bitmask are acceptable values for the
identified component which should be an attribute of type
'bitMask(10)'の値は、指導属性がタイプの属性であるべきである特定されたコンポーネントのためにビットマスクで設定されたビットのすべての組み合わせが許容値であるようにものに少しマスクをかけることであることを意味します。
'BITS'.
'ビット'。
For example, an implementation of the frwkIpFilter class may
be limited in several ways, such as address mask, protocol
and Layer 4 port options. These limitations could be
exported using this PRC with the following instances:
例えば、frwkIpFilterのクラスの実装はいくつかの方法で制限されるかもしれません、アドレスマスクや、プロトコルやLayer4ポートオプションなどのように。 以下のインスタンスがあるこのPRCを使用することでこれらの制限をエクスポートすることができるでしょう:
Component Type Sub-Type Guidance
------------------------------------------------------------
DstPrefixLength attrValueSupLimited valueOnly 24
SrcPrefixLength attrValueSupLimited valueOnly 24
Protocol attrValueSupLimited rangeMin 10
Protocol attrValueSupLimited rangeMax 20
コンポーネント型サブタイプ指導------------------------------------------------------------ DstPrefixLength attrValueSupLimited valueOnly24SrcPrefixLength attrValueSupLimited valueOnly24プロトコルattrValueSupLimited rangeMin10プロトコルattrValueSupLimited rangeMax20
Sahita, et. al. Informational [Page 35] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[35ページ]情報のRFC3318フレームワーク方針情報基地の行進
The above entries describe a number of limitations that
may be in effect for the frwkIpFilter class on a given
device. The limitations include restrictions on acceptable
values for certain attributes.
上のエントリーは多くの与えられたデバイスのfrwkIpFilterのクラスに、有効であるかもしれない制限について説明します。 制限はある属性のための許容値における制限を含んでいます。
Also, an implementation of a PRC may be limited in the ways
it can be accessed. For instance, for a fictitious PRC
dscpMapEntry, which has a PIB-ACCESS of 'install-notify':
また、PRCの実装はそれにアクセスできる方法で制限されるかもしれません。 例えば、架空のPRC dscpMapEntryのために、どれに'インストールで通知してください'のPIB-ACCESSがあるか:
Component Type SubType Guidance
------------------------------------------------------------
dscpMapEntry prcLimitedNotify none zero-length string."
コンポーネント型SubType指導------------------------------------------------------------ 「dscpMapEntry prcLimitedNotify、無長さであるなにも結ばない、」
::= { frwkCompLimitsEntry 6 }
::= frwkCompLimitsEntry6
frwkCompLimitsGuidance OBJECT-TYPE
SYNTAX OCTET STRING
STATUS current
DESCRIPTION
"A value used to convey additional information related
to the implementation limitation. Note that a guidance
value will not necessarily be provided for all exported
limitations. If a guidance value is not provided, the
value must be a zero-length string.
「値は実装制限に関連する追加情報を伝えるのに使用した」frwkCompLimitsGuidance OBJECT-TYPE SYNTAX OCTET STRING STATUSの現在の記述。 指導値が必ず制限であるとエクスポートされたすべてに提供されるというわけではないことに注意してください。 指導値が提供されないなら、値はゼロ長ストリングでなければなりません。
The format of the guidance value, if one is present as
indicated by the frwkCompLimitsSubType attribute,
is described by the following table. Note that the
format of guidance value is dictated by the base-type of
the component whose limitation is being exported,
interpreted in the context of the frwkCompLimitsType and
frwkCompLimitsSubType values. Any other restrictions
(such as size/range/enumerated value) on the guidance
value MUST be complied with according to the definition
of the component for which guidance is being specified.
1つがfrwkCompLimitsSubType属性によって示されるように存在しているなら、指導価値の形式は以下のテーブルによって説明されます。 指導価値の書式が制限がfrwkCompLimitsTypeの文脈でエクスポートしていて、解釈された存在とfrwkCompLimitsSubType値であるコンポーネントのベースタイプによって決められることに注意してください。 指導が指定されているコンポーネントの定義に従って、指導値におけるいかなる他の制限(サイズ/範囲/列挙された値などの)にも従わなければなりません。
Note that numbers are encoded in network byte order.
数がネットワークバイトオーダーでコード化されることに注意してください。
Base Type Value
--------- -----
Unsigned32/Integer32/INTEGER 32-bit value.
Unsigned64/Integer64 64-bit Value.
OCTET STRING octets of data.
OID 32-bit OID components.
BITS Binary octets of length
same as Component specified."
基地のタイプ価値--------- ----- Unsigned32/Integer32/INTEGERの32ビットの値。 Unsigned64/Integer64 64-ビット値。 データのOCTET STRING八重奏。 OIDの32ビットのOIDの部品。 「Componentと同じ長さのBITS Binary八重奏は指定しました。」
::= { frwkCompLimitsEntry 7 }
::= frwkCompLimitsEntry7
Sahita, et. al. Informational [Page 36] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[36ページ]情報のRFC3318フレームワーク方針情報基地の行進
-- -- Complete Reference specification table --
-- -- Reference仕様テーブルを完成してください--
frwkReferenceTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkReferenceEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"Each instance of this PRC specifies a reference to a PRI
in a specific PIB context (handle) for a specific client-
type. This table gives the PDP the ability to set up
policies that span installed contexts and the PEP the
ability to reference instances in another, perhaps
configured context. The PEP must send a
'attrReferenceUnknown' COPS-PR error to the PDP if it
encounters an invalid reference. "
REFERENCE
"COPS Usage for Policy Provisioning. RFC 3084, error
codes section 4.5."
frwkReferenceTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkReferenceEntry PIB-ACCESSはSTATUS現在の記述にインストールで通知します。「このPRCの各インスタンスは特定のPIB文脈(扱う)のPRIの特定のクライアントタイプの参照を指定します」。 このテーブルは、インストールされた文脈にかかる方針をセットアップする能力をPDPに与えて、別のものの参照インスタンス、恐らく構成された文脈への能力をPEPに与えます。 それが無効の参照に遭遇するなら、PEPは'attrReferenceUnknown'COPS-PR誤りをPDPに送らなければなりません。 「「方針の食糧を供給する巡査用法。」という参照 「RFC3084、誤りはセクション4.5をコード化します。」
::= { frwkBasePibClasses 5 }
::= frwkBasePibClasses5
frwkReferenceEntry OBJECT-TYPE
SYNTAX FrwkReferenceEntry
STATUS current
DESCRIPTION
"Entry specification for the frwkReferenceTable."
frwkReferenceEntry OBJECT-TYPE SYNTAX FrwkReferenceEntry STATUSの現在の記述、「frwkReferenceTableのためのエントリー仕様。」
PIB-INDEX { frwkReferencePrid }
UNIQUENESS { }
PIB-インデックスfrwkReferencePrid、ユニークさ{ }
::= { frwkReferenceTable 1 }
::= frwkReferenceTable1
FrwkReferenceEntry ::= SEQUENCE {
frwkReferencePrid InstanceId,
frwkReferenceClientType ClientType,
frwkReferenceClientHandle ClientHandle,
frwkReferenceInstance Prid
}
FrwkReferenceEntry:、:= 系列frwkReferencePrid InstanceId、frwkReferenceClientType ClientType、frwkReferenceClientHandle ClientHandle、frwkReferenceInstance Prid
frwkReferencePrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the frwkReference class."
frwkReferencePrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述、「唯一frwkReferenceのクラスのインスタンスを特定する任意の整数インデックス。」
Sahita, et. al. Informational [Page 37] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[37ページ]情報のRFC3318フレームワーク方針情報基地の行進
::= { frwkReferenceEntry 1 }
::= frwkReferenceEntry1
frwkReferenceClientType OBJECT-TYPE
SYNTAX ClientType
STATUS current
DESCRIPTION
"Is unused if set to zero else specifies a client-type for
which the reference is to be interpreted. This non-zero
client-type must be activated explicitly via a separate
COPS client-open else this attribute is not valid."
frwkReferenceClientType OBJECT-TYPE SYNTAX ClientType STATUSの現在の記述は「ほかのゼロへのセットが解釈される参照がことであるクライアントタイプを指定するなら、未使用です」。 「この非ゼロクライアントタイプはほかにオープンな別々のCOPSクライアントを通して明らかに動かされて、この属性が有効でないということであるに違いありません。」
::= { frwkReferenceEntry 2 }
::= frwkReferenceEntry2
frwkReferenceClientHandle OBJECT-TYPE
SYNTAX ClientHandle
STATUS current
DESCRIPTION
"Must be set to specify a valid client-handle in the scope
of the client-type specified."
frwkReferenceClientHandle OBJECT-TYPE SYNTAX ClientHandle STATUSの現在の記述を「指定されたクライアントタイプの範囲で有効なクライアントハンドルを指定するように設定しなければなりません」。
::= { frwkReferenceEntry 3 }
::= frwkReferenceEntry3
frwkReferenceInstance OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
"References a PRI in the context identified by
frwkReferenceClientHandle for client-type identified by
frwkReferenceClientType."
frwkReferenceInstance OBJECT-TYPE SYNTAX Prid STATUSの現在の記述は「PRIに、frwkReferenceClientTypeによって特定されたクライアントタイプのためにfrwkReferenceClientHandleによって特定された文脈では、参照をつけます」。
::= { frwkReferenceEntry 4 }
::= frwkReferenceEntry4
-- -- Error specification table --
-- -- 誤り仕様テーブル--
frwkErrorTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkErrorEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"Each instance of this PRC specifies a class specific
error object. Instances of this PRC are transient, i.e.,
instances received in a COPS decision message must not be
maintained by the PEP in its copy of the PIB instances. This
PRC allows a PDP to send error information to the PEP if the
PDP cannot process updates to a Request successfully."
frwkErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkErrorEntry PIB-ACCESSはSTATUS現在の記述をインストールします。「このPRCの各インスタンスはクラス特有の誤りオブジェクトを指定します」。 このPRCのインスタンスが一時的である、すなわち、COPS決定メッセージに受け取られたインスタンスはPIBインスタンスのコピーでPEPによって維持されてはいけません。 「PDPが首尾よくRequestにアップデートを処理できないなら、このPRCはPDPにエラー情報をPEPに送らせます。」
Sahita, et. al. Informational [Page 38] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[38ページ]情報のRFC3318フレームワーク方針情報基地の行進
::= { frwkBasePibClasses 6 }
::= frwkBasePibClasses6
frwkErrorEntry OBJECT-TYPE
SYNTAX FrwkErrorEntry
STATUS current
DESCRIPTION
"Entry specification for the frwkErrorTable."
frwkErrorEntry OBJECT-TYPE SYNTAX FrwkErrorEntry STATUSの現在の記述、「frwkErrorTableのためのエントリー仕様。」
PIB-INDEX { frwkErrorPrid }
UNIQUENESS {
frwkErrorCode,
frwkErrorSubCode,
frwkErrorPrc,
frwkErrorInstance
}
PIB-インデックスfrwkErrorPrid、ユニークさfrwkErrorCode、frwkErrorSubCode、frwkErrorPrc、frwkErrorInstance
::= { frwkErrorTable 1 }
::= frwkErrorTable1
FrwkErrorEntry ::= SEQUENCE {
frwkErrorPrid InstanceId,
frwkErrorCode Unsigned32,
frwkErrorSubCode Unsigned32,
frwkErrorPrc PrcIdentifierOid,
frwkErrorInstance InstanceId
}
FrwkErrorEntry:、:= 系列frwkErrorPrid InstanceId、frwkErrorCode Unsigned32、frwkErrorSubCode Unsigned32、frwkErrorPrc PrcIdentifierOid、frwkErrorInstance InstanceId
frwkErrorPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the frwkError class."
frwkErrorPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述、「唯一frwkErrorのクラスのインスタンスを特定する任意の整数インデックス。」
::= { frwkErrorEntry 1 }
::= frwkErrorEntry1
frwkErrorCode OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
STATUS current
DESCRIPTION
"Error code defined in COPS-PR CPERR object."
REFERENCE
"COPS Usage for Policy Provisioning. RFC 3084."
「エラーコードはCOPS-PR CPERRオブジェクトで定義した」frwkErrorCode OBJECT-TYPE SYNTAX Unsigned32(0 .65535)のSTATUSの現在の記述。 参照は「方針の食糧を供給する用法を獲得します」。 「RFC3084。」
::= { frwkErrorEntry 2 }
::= frwkErrorEntry2
frwkErrorSubCode OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
STATUS current
frwkErrorSubCode OBJECT-TYPE SYNTAX Unsigned32(0 .65535)STATUS海流
Sahita, et. al. Informational [Page 39] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[39ページ]情報のRFC3318フレームワーク方針情報基地の行進
DESCRIPTION
"The class-specific error object is used to communicate
errors relating to specific PRCs."
記述は「特定のPRCsに関連する誤りを伝えるために、使用クラス特有の誤りが反対するされます」。
::= { frwkErrorEntry 3 }
::= frwkErrorEntry3
frwkErrorPrc OBJECT-TYPE
SYNTAX PrcIdentifierOid
STATUS current
DESCRIPTION
"The PRC due to which the error specified by codes
(frwkErrorCode , frwkErrorSubCode) occurred."
frwkErrorPrc OBJECT-TYPE SYNTAX PrcIdentifierOid STATUSの現在の記述、「コード(frwkErrorCode、frwkErrorSubCode)で誤りが指定したPRCは起こりました」。
::= { frwkErrorEntry 4 }
::= frwkErrorEntry4
frwkErrorInstance OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"The PRI of the identified PRC (frwkErrorPrc) due to which
the error specified by codes (frwkErrorCode ,
frwkErrorSubCode) occurred. Must be set to zero if unused."
frwkErrorInstance OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述、「コード(frwkErrorCode、frwkErrorSubCode)で誤りが指定した特定されたPRC(frwkErrorPrc)のPRIは起こりました」。 「未使用であるなら、ゼロに設定しなければなりません。」
::= { frwkErrorEntry 5 }
::= frwkErrorEntry5
-- -- The device capabilities and role combo classes group --
-- -- デバイス能力と役割のコンボのクラスは分類されます--
frwkDeviceCapClasses
OBJECT IDENTIFIER ::= { frameworkPib 2 }
--
-- Capability Set Table
--
frwkDeviceCapClassesオブジェクト識別子:、:= frameworkPib2----能力はテーブルの用意をしました--
frwkCapabilitySetTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkCapabilitySetEntry
PIB-ACCESS notify
STATUS current
DESCRIPTION
frwkCapabilitySetTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkCapabilitySetEntry PIB-ACCESSはSTATUSの現在の記述に通知します。
"This PRC describes the capability sets that exist on the
interfaces on the device. The capability set is given a
unique name that identifies a set. These capability set
names are used by the PDP to determine policy information to
be associated with interfaces that possess similar sets of
capabilities."
「このPRCはデバイスでインタフェースに存在する能力セットについて説明します。」 セットを特定するユニークな名前を能力セットに与えます。 「これらの能力セット名は方針情報が同様の能力を持っているインタフェースに関連していることを決定するのにPDPによって使用されます。」
Sahita, et. al. Informational [Page 40] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[40ページ]情報のRFC3318フレームワーク方針情報基地の行進
::= { frwkDeviceCapClasses 1 }
::= frwkDeviceCapClasses1
frwkCapabilitySetEntry OBJECT-TYPE
SYNTAX FrwkCapabilitySetEntry
STATUS current
DESCRIPTION
"An instance of this PRC describes a particular set of
capabilities and associates a unique name with the set."
frwkCapabilitySetEntry OBJECT-TYPE SYNTAX FrwkCapabilitySetEntry STATUSの現在の記述、「このPRCのインスタンスは、特定の能力について説明して、セットのユニークな名前を関連づけます」。
PIB-INDEX { frwkCapabilitySetPrid }
UNIQUENESS { frwkCapabilitySetName,
frwkCapabilitySetCapability }
PIB-インデックスfrwkCapabilitySetPrid、ユニークさfrwkCapabilitySetName、frwkCapabilitySetCapability
::= { frwkCapabilitySetTable 1 }
::= frwkCapabilitySetTable1
FrwkCapabilitySetEntry ::= SEQUENCE {
frwkCapabilitySetPrid InstanceId,
frwkCapabilitySetName SnmpAdminString,
frwkCapabilitySetCapability Prid
}
FrwkCapabilitySetEntry:、:= 系列frwkCapabilitySetPrid InstanceId、frwkCapabilitySetName SnmpAdminString、frwkCapabilitySetCapability Prid
frwkCapabilitySetPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies a
instance of the class."
frwkCapabilitySetPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述、「唯一クラスのインスタンスを特定する任意の整数インデックス。」
::= { frwkCapabilitySetEntry 1 }
::= frwkCapabilitySetEntry1
frwkCapabilitySetName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..255))
STATUS current
DESCRIPTION
"The name for the capability set. This name is the unique
identifier of a set of capabilities. This attribute must not
be assigned a zero-length string."
「能力のための名前は設定する」frwkCapabilitySetName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .255))のSTATUSの現在の記述。 この名前は1セットの能力のユニークな識別子です。 「この属性にゼロ長ストリングを割り当ててはいけません。」
::= { frwkCapabilitySetEntry 2 }
::= frwkCapabilitySetEntry2
frwkCapabilitySetCapability OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
frwkCapabilitySetCapability OBJECT-TYPE SYNTAX Prid STATUSの現在の記述
"The complete PRC OID and instance identifier specifying the
capability PRC instance for the interface. This attribute
references a specific instance of a capability table. The
「能力PRCインスタンスをインタフェースに指定する完全なPRC OIDとインスタンス識別子。」 これは能力の特定のインスタンスが見送る参照を結果と考えます。 The
Sahita, et. al. Informational [Page 41] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[41ページ]情報のRFC3318フレームワーク方針情報基地の行進
capability table whose instance is referenced must be
defined in the client type specific PIB that this PIB is
used with. The referenced capability instance becomes a part
of the set of capabilities associated with the specified
frwkCapabilitySetName."
このPIBが使用されるクライアントのタイプの特定のPIBでインスタンスが参照をつけられる能力テーブルを定義しなければなりません。 「参照をつけられた能力インスタンスは指定されたfrwkCapabilitySetNameに関連している能力のセットの一部になります。」
::= { frwkCapabilitySetEntry 3 }
::= frwkCapabilitySetEntry3
-- -- Interface and Role Combination Tables --
-- -- インタフェースと役割の組み合わせテーブル--
frwkRoleComboTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkRoleComboEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"This is an abstract PRC that may be extended or referenced
to enumerate the role combinations, capability set names
assigned to any interface on a PEP. The identification of
the interface is to be defined by its extensions or
referencing PRCs."
frwkRoleComboTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkRoleComboEntry PIB-ACCESSはSTATUS現在の記述にインストールで通知します。「これは役割の組み合わせを列挙するために広げられるか、または参照をつけられるかもしれない、抽象的なPRCです、PEPの上のどんなインタフェースにも割り当てられた能力セット名。」 「インタフェースの識別は、拡大で定義されるか、またはPRCsに参照をつけていることです。」
::= { frwkDeviceCapClasses 2 }
::= frwkDeviceCapClasses2
frwkRoleComboEntry OBJECT-TYPE
SYNTAX FrwkRoleComboEntry
STATUS current
DESCRIPTION
"An instance of this PRC describes one association of an
interface to a role-combination and capability set name .
Note that an interface can have multiple associations. This
constraint is controlled by the extending or referencing
PRC's uniqueness clause."
このPRCのインスタンスは役割組み合わせと能力セット名にインタフェースの1つの協会について説明します。frwkRoleComboEntry OBJECT-TYPE SYNTAX FrwkRoleComboEntry STATUSの現在の記述、「インタフェースが複数の協会を持つことができることに注意してください。」 「この規制は広げるかPRCのユニークさの節に参照をつけることによって、制御されます。」
PIB-INDEX { frwkRoleComboPrid }
UNIQUENESS { }
PIB-インデックスfrwkRoleComboPrid、ユニークさ{ }
::= { frwkRoleComboTable 1 }
::= frwkRoleComboTable1
FrwkRoleComboEntry ::= SEQUENCE {
frwkRoleComboPrid InstanceId,
frwkRoleComboRoles RoleCombination,
frwkRoleComboCapSetName SnmpAdminString
}
FrwkRoleComboEntry:、:= 系列frwkRoleComboPrid InstanceId、frwkRoleComboRoles RoleCombination、frwkRoleComboCapSetName SnmpAdminString
frwkRoleComboPrid OBJECT-TYPE
SYNTAX InstanceId
frwkRoleComboPridオブジェクト・タイプ構文InstanceId
Sahita, et. al. Informational [Page 42] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[42ページ]情報のRFC3318フレームワーク方針情報基地の行進
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the class."
STATUSの現在の記述、「唯一クラスのインスタンスを特定する任意の整数インデックス。」
::= { frwkRoleComboEntry 1 }
::= frwkRoleComboEntry1
frwkRoleComboRoles OBJECT-TYPE
SYNTAX RoleCombination
STATUS current
DESCRIPTION
"The role combination assigned to a specific interface."
「役割の組み合わせは特定のインタフェースに割り当てた」frwkRoleComboRoles OBJECT-TYPE SYNTAX RoleCombination STATUSの現在の記述。
::= { frwkRoleComboEntry 2 }
::= frwkRoleComboEntry2
frwkRoleComboCapSetName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
STATUS current
DESCRIPTION
"The name of the capability set associated with
the Role Combination specified in frwkRoleComboRoles. If
this is a zero length string it implies the PEP is not
exporting any capability set information for this
RoleCombination. The PDP must then use the RoleCombinations
provided as the only means of assigning policies
If a non-zero length string is specified, the name must
exist in frwkCapabilitySetTable."
「能力セットの名前はfrwkRoleComboRolesで指定されるRole Combinationに関連づけた」frwkRoleComboCapSetName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .255))のSTATUSの現在の記述。 これがゼロ長ストリングであるなら、それは、PEPが、どんな能力もこのRoleCombinationのための情報集合であるとエクスポートしていないのを含意します。 「そして、非ゼロ長ストリングを方針Ifに割り当てる唯一の手段が指定されるとき名前がfrwkCapabilitySetTableに存在しなければならないなら、PDPはRoleCombinationsを使用しなければなりません。」
::= { frwkRoleComboEntry 3 }
::= frwkRoleComboEntry3
-- -- Interface, Role Combination association via IfIndex --
-- -- インタフェース、IfIndexを通したRole Combination協会--
frwkIfRoleComboTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkIfRoleComboEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"This PRC enumerates the interface to role combination and
frwkRoleComboCapSetName mapping for all policy managed
interfaces of a device. Policy for an interface depends not
only on the capability set of an interface but also on its
roles. This table specifies all the <interface index,
interface capability set name, role combination> tuples
currently on the device"
frwkIfRoleComboTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkIfRoleComboEntry PIB-ACCESSはSTATUS現在の記述にインストールで通知します。「このPRCはすべての方針のためにデバイスの管理されたインタフェースを写像しながら、役割の組み合わせとfrwkRoleComboCapSetNameにインタフェースを列挙します」。 インタフェースへの方針はインタフェースの能力セットによるだけではなく、その役割にもよります。 「このテーブルは現在、デバイスですべての<インタフェースインデックス、インタフェース能力セット名、役割の組み合わせ>tuplesを指定します」
::= { frwkDeviceCapClasses 3 }
::= frwkDeviceCapClasses3
Sahita, et. al. Informational [Page 43] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[43ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkIfRoleComboEntry OBJECT-TYPE
SYNTAX FrwkIfRoleComboEntry
STATUS current
DESCRIPTION
"An instance of this PRC describes the association of
a interface to an capability set name and a role
combination.
Note that a capability set name can have multiple role
combinations assigned to it, but an IfIndex can have only
one role combination associated."
frwkIfRoleComboEntry OBJECT-TYPE SYNTAX FrwkIfRoleComboEntry STATUSの現在の記述、「このPRCのインスタンスは能力セット名と役割の組み合わせようにインタフェースの協会について説明します」。 「能力セット名で複数の役割の組み合わせをそれに割り当てることができますが、IfIndexが1つの役割の組み合わせしか関連づけさせることができないことに注意してください。」
EXTENDS { frwkRoleComboEntry }
UNIQUENESS { frwkIfRoleComboIfIndex,
frwkRoleComboCapSetName }
frwkRoleComboEntryを広げている、ユニークさfrwkIfRoleComboIfIndex、frwkRoleComboCapSetName
::= { frwkIfRoleComboTable 1 }
::= frwkIfRoleComboTable1
FrwkIfRoleComboEntry ::= SEQUENCE {
frwkIfRoleComboIfIndex InterfaceIndex
}
FrwkIfRoleComboEntry:、:= 系列frwkIfRoleComboIfIndex InterfaceIndex
frwkIfRoleComboIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
STATUS current
DESCRIPTION
"The value of this attribute is the ifIndex which is
associated with the specified RoleCombination and interface
capability set name."
frwkIfRoleComboIfIndex OBJECT-TYPE SYNTAX InterfaceIndex STATUSの現在の記述、「この属性の値は指定されたRoleCombinationとインタフェース能力セット名に関連しているifIndexです」。
::= { frwkIfRoleComboEntry 1 }
::= frwkIfRoleComboEntry1
-- -- The Classification classes group --
-- -- Classificationのクラスは分類されます--
frwkClassifierClasses
OBJECT IDENTIFIER ::= { frameworkPib 3 }
--
-- The Base Filter Table
--
frwkClassifierClassesオブジェクト識別子:、:= frameworkPib3----基地のフィルタテーブル--
frwkBaseFilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkBaseFilterEntry
PIB-ACCESS install
STATUS current
frwkBaseFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkBaseFilterEntry PIB-ACCESSはSTATUS海流をインストールします。
Sahita, et. al. Informational [Page 44] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[44ページ]情報のRFC3318フレームワーク方針情報基地の行進
DESCRIPTION
"The Base Filter class. A packet has to match all
fields in an Filter. Wildcards may be specified for those
fields that are not relevant."
「基地のFilterは分類する」記述。 パケットはFilterのすべての分野に合わなければなりません。 「ワイルドカードはそれらの関連していない分野に指定されるかもしれません。」
::= { frwkClassifierClasses 1 }
::= frwkClassifierClasses1
frwkBaseFilterEntry OBJECT-TYPE
SYNTAX FrwkBaseFilterEntry
STATUS current
DESCRIPTION
"An instance of the frwkBaseFilter class."
「frwkBaseFilterのインスタンスは分類する」frwkBaseFilterEntry OBJECT-TYPE SYNTAX FrwkBaseFilterEntry STATUSの現在の記述。
PIB-INDEX { frwkBaseFilterPrid }
PIB-インデックスfrwkBaseFilterPrid
::= { frwkBaseFilterTable 1 }
::= frwkBaseFilterTable1
FrwkBaseFilterEntry ::= SEQUENCE {
frwkBaseFilterPrid InstanceId,
frwkBaseFilterNegation TruthValue
}
FrwkBaseFilterEntry:、:= 系列frwkBaseFilterPrid InstanceId、frwkBaseFilterNegation TruthValue
frwkBaseFilterPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An integer index to uniquely identify this Filter among all
the Filters."
「整数はすべてのFiltersの中で唯一このFilterを特定するために索引をつける」frwkBaseFilterPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述。
::= { frwkBaseFilterEntry 1 }
::= frwkBaseFilterEntry1
frwkBaseFilterNegation OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"This attribute behaves like a logical NOT for the filter.
If the packet matches this filter and the value of this
attribute is 'true', the action associated with this filter
is not applied to the packet. If the value of this
attribute is 'false', then the action is applied to the
packet."
「この属性はフィルタのための論理的なNOTのように振る舞わせる」frwkBaseFilterNegation OBJECT-TYPE SYNTAX TruthValue STATUSの現在の記述。 パケットがこのフィルタに合って、この属性の値が'本当である'なら、このフィルタに関連している動作はパケットに適用されません。 「この属性の値が'誤っている'なら、動作はパケットに適用されます。」
::= { frwkBaseFilterEntry 2 }
::= frwkBaseFilterEntry2
-- -- The IP Filter Table --
-- -- IPフィルタテーブル--
Sahita, et. al. Informational [Page 45] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[45ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkIpFilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkIpFilterEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"Filter definitions. A packet has to match all fields in a
filter. Wildcards may be specified for those fields that
are not relevant."
frwkIpFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkIpFilterEntry PIB-ACCESSはSTATUSの現在の記述「フィルター定義」をインストールします。 パケットはフィルタのすべての分野に合わなければなりません。 「ワイルドカードはそれらの関連していない分野に指定されるかもしれません。」
INSTALL-ERRORS {
invalidDstL4PortData(1),
invalidSrcL4PortData(2)
}
::= { frwkClassifierClasses 2 }
誤りをインストールする、invalidDstL4PortData(1)、invalidSrcL4PortData(2):、:= frwkClassifierClasses2
frwkIpFilterEntry OBJECT-TYPE
SYNTAX FrwkIpFilterEntry
STATUS current
DESCRIPTION
"An instance of the frwkIpFilter class."
「frwkIpFilterのインスタンスは分類する」frwkIpFilterEntry OBJECT-TYPE SYNTAX FrwkIpFilterEntry STATUSの現在の記述。
EXTENDS { frwkBaseFilterEntry }
UNIQUENESS { frwkBaseFilterNegation,
frwkIpFilterAddrType,
frwkIpFilterDstAddr,
frwkIpFilterDstPrefixLength,
frwkIpFilterSrcAddr,
frwkIpFilterSrcPrefixLength,
frwkIpFilterDscp,
frwkIpFilterFlowId,
frwkIpFilterProtocol,
frwkIpFilterDstL4PortMin,
frwkIpFilterDstL4PortMax,
frwkIpFilterSrcL4PortMin,
frwkIpFilterSrcL4PortMax }
frwkBaseFilterEntryを広げている、ユニークさfrwkBaseFilterNegation、frwkIpFilterAddrType、frwkIpFilterDstAddr、frwkIpFilterDstPrefixLength、frwkIpFilterSrcAddr、frwkIpFilterSrcPrefixLength、frwkIpFilterDscp、frwkIpFilterFlowId、frwkIpFilterProtocol、frwkIpFilterDstL4PortMin、frwkIpFilterDstL4PortMax、frwkIpFilterSrcL4PortMin、frwkIpFilterSrcL4PortMax
::= { frwkIpFilterTable 1 }
::= frwkIpFilterTable1
FrwkIpFilterEntry ::= SEQUENCE {
frwkIpFilterAddrType InetAddressType,
frwkIpFilterDstAddr InetAddress,
frwkIpFilterDstPrefixLength InetAddressPrefixLength,
frwkIpFilterSrcAddr InetAddress,
frwkIpFilterSrcPrefixLength InetAddressPrefixLength,
frwkIpFilterDscp DscpOrAny,
frwkIpFilterFlowId Integer32,
frwkIpFilterProtocol Unsigned32,
frwkIpFilterDstL4PortMin InetPortNumber,
FrwkIpFilterEntry:、:= 系列、frwkIpFilterAddrType InetAddressType、frwkIpFilterDstAddr InetAddress、frwkIpFilterDstPrefixLength InetAddressPrefixLength、frwkIpFilterSrcAddr InetAddress、frwkIpFilterSrcPrefixLength InetAddressPrefixLength、frwkIpFilterDscp DscpOrAny、frwkIpFilterFlowId Integer32、frwkIpFilterProtocol Unsigned32、frwkIpFilterDstL4PortMin InetPortNumber
Sahita, et. al. Informational [Page 46] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[46ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkIpFilterDstL4PortMax InetPortNumber,
frwkIpFilterSrcL4PortMin InetPortNumber,
frwkIpFilterSrcL4PortMax InetPortNumber
}
frwkIpFilterDstL4PortMax InetPortNumber、frwkIpFilterSrcL4PortMin InetPortNumber、frwkIpFilterSrcL4PortMax InetPortNumber
frwkIpFilterAddrType OBJECT-TYPE
frwkIpFilterAddrTypeオブジェクト・タイプ
SYNTAX InetAddressType
STATUS current
DESCRIPTION
"The address type enumeration value to specify the type of
the packet's IP address.
「アドレスタイプ列挙はパケットのIPアドレスのタイプを指定するために評価する」SYNTAX InetAddressType STATUSの現在の記述。
While other types of addresses are defined in the
InetAddressType textual convention, an IP filter can only
use IPv4 and IPv6 addresses directly to classify traffic.
All other InetAddressTypes require mapping to the
corresponding Ipv4 or IPv6 address before being used to
classify traffic. Therefore, this object as such is not
limited to IPv4 and IPv6 addresses, i.e., it can be assigned
any of the valid values defined in the InetAddressType TC,
but the mapping of the address values to IPv4 or IPv6
addresses for the address attributes (frwkIpFilterDstAddr
and frwkIpFilterSrcAddr) must be done by the PEP. For
example when dns (16) is used, the PEP must resolve
the address to IPv4 or IPv6 at install time."
REFERENCE
"Textual Conventions for Internet Network Addresses.
RFC 3291."
他のタイプのアドレスがInetAddressTypeの原文のコンベンションで定義されている間、IPフィルタは、トラフィックを分類するのに直接IPv4とIPv6アドレスを使用できるだけです。 他のすべてのInetAddressTypesが、トラフィックを分類するのに使用される前に対応するIpv4かIPv6アドレスに写像するのを必要とします。 したがって、そういうもののこのオブジェクトはIPv4とIPv6アドレスに制限されませんが、InetAddressType TCで定義された有効値のどれかをすなわち、それに割り当てることができますが、PEPはIPv4へのアドレス値かアドレス属性のためのIPv6アドレス(frwkIpFilterDstAddrとfrwkIpFilterSrcAddr)に関するマッピングをしなければなりません。 「例えば、dns(16)がインストール時に使用されているとき、PEPはIPv4かIPv6にアドレスを決議しなければなりません。」 「インターネットネットワーク・アドレスのための原文のコンベンション」という参照。 「RFC3291。」
::= { frwkIpFilterEntry 1 }
::= frwkIpFilterEntry1
frwkIpFilterDstAddr OBJECT-TYPE
frwkIpFilterDstAddrオブジェクト・タイプ
SYNTAX InetAddress
STATUS current
DESCRIPTION
"The IP address to match against the packet's
destination IP address. If the address type is 'ipv4',
'ipv6', 'ipv4z' or 'ipv6z' then, the attribute
frwkIpFilterDstPrefixLength indicates the number of bits
that are relevant. "
REFERENCE
"Textual Conventions for Internet Network Addresses.
RFC 3291."
「IPはパケットの送付先IPアドレスに対して合うように扱う」SYNTAX InetAddress STATUSの現在の記述。 その時アドレスタイプが'ipv4'、'ipv6'、'ipv4z'または'ipv6z'であるなら、属性frwkIpFilterDstPrefixLengthは関連ビットの数を示します。 「「インターネットネットワーク・アドレスのための原文のコンベンション。」という参照 「RFC3291。」
::= { frwkIpFilterEntry 2 }
::= frwkIpFilterEntry2
Sahita, et. al. Informational [Page 47] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[47ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkIpFilterDstPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
STATUS current
DESCRIPTION
"The length of a mask for the matching of the destination
IP address. This attribute is interpreted only if the
InetAddressType is 'ipv4', 'ipv4z', 'ipv6' or 'ipv6z'.
Masks are constructed by setting bits in sequence from the
most-significant bit downwards for
frwkIpFilterDstPrefixLength bits length. All other bits in
the mask, up to the number needed to fill the length of
the address frwkIpFilterDstAddr are cleared to zero. A zero
bit in the mask then means that the corresponding bit in
the address always matches.
「目的地IPのマッチングのためのマスクの長さは扱う」frwkIpFilterDstPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength STATUSの現在の記述。 この属性はInetAddressTypeが'ipv4'、'ipv4z'、'ipv6'または'ipv6z'である場合にだけ解釈されます。 仮面は、frwkIpFilterDstPrefixLengthビットの長さのために最も多くの重要なビットから系列にビットを下向きにはめ込むことによって、構成されます。 マスクの他のすべてのビット、アドレスの長さをいっぱいにするのに必要である数までfrwkIpFilterDstAddrはゼロまできれいにされます。 そして、マスクのゼロ・ビットは、アドレスの対応するビットがいつも合っていることを意味します。
In IPv4 addresses, a length of 0 indicates a match of any
address; a length of 32 indicates a match of a single host
address, and a length between 0 and 32 indicates the use of
a CIDR Prefix. IPv6 is similar, except that prefix lengths
range from 0..128."
REFERENCE
"Textual Conventions for Internet Network Addresses.
RFC 3291."
DEFVAL { 0 }
IPv4アドレスで、0の長さはどんなアドレスのマッチも示します。 32の長さはただ一つのホスト・アドレスのマッチを示します、そして、0〜32の長さはCIDR Prefixの使用を示します。 接頭語の長さが0から変化するのを除いて、IPv6は同様です。128." 「インターネットネットワーク・アドレスのための原文のコンベンション」という参照。 「RFC3291。」 DEFVAL{ 0 }
::= { frwkIpFilterEntry 3 }
::= frwkIpFilterEntry3
frwkIpFilterSrcAddr OBJECT-TYPE
SYNTAX InetAddress
STATUS current
DESCRIPTION
"The IP address to match against the packet's source IP
address. If the address type is 'ipv4', 'ipv6', 'ipv4z' or
'ipv6z' then, the attribute frwkIpFilterSrcPrefixLength
indicates the number of bits that are relevant."
REFERENCE
"Textual Conventions for Internet Network Addresses.
RFC 3291."
「IPはパケットのソースIPアドレスに対して合うように扱う」frwkIpFilterSrcAddr OBJECT-TYPE SYNTAX InetAddress STATUSの現在の記述。 「その時アドレスタイプが'ipv4'、'ipv6'、'ipv4z'または'ipv6z'であるなら、属性frwkIpFilterSrcPrefixLengthは関連ビットの数を示します。」 「インターネットネットワーク・アドレスのための原文のコンベンション」という参照。 「RFC3291。」
::= { frwkIpFilterEntry 4 }
::= frwkIpFilterEntry4
frwkIpFilterSrcPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
UNITS "bits"
STATUS current
DESCRIPTION
"The length of a mask for the matching of the source IP
address. This attribute is interpreted only if the
「ソースIPのマッチングのためのマスクの長さは扱う」frwkIpFilterSrcPrefixLength OBJECT-TYPE SYNTAX InetAddressPrefixLength UNITS「ビット」STATUSの現在の記述。 この属性が解釈される、唯一
Sahita, et. al. Informational [Page 48] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[48ページ]情報のRFC3318フレームワーク方針情報基地の行進
InetAddressType is 'ipv4', 'ipv4z', 'ipv6' or 'ipv6z'.
Masks are constructed by setting bits in sequence from the
most-significant bit downwards for
frwkIpFilterSrcPrefixLength bits length. All other bits in
the mask, up to the number needed to fill the length of
the address frwkIpFilterSrcAddr are cleared to zero. A
zero bit in the mask then means that the corresponding bit
in the address always matches.
InetAddressTypeは'ipv4'、'ipv4z'、'ipv6'または'ipv6z'です。 仮面は、frwkIpFilterSrcPrefixLengthビットの長さのために最も多くの重要なビットから系列にビットを下向きにはめ込むことによって、構成されます。 マスクの他のすべてのビット、アドレスの長さをいっぱいにするのに必要である数までfrwkIpFilterSrcAddrはゼロまできれいにされます。 そして、マスクのゼロ・ビットは、アドレスの対応するビットがいつも合っていることを意味します。
In IPv4 addresses, a length of 0 indicates a match of any
address; a length of 32 indicates a match of a single host
address, and a length between 0 and 32 indicates the use of
a CIDR Prefix. IPv6 is similar, except that prefix lengths
range from 0..128."
REFERENCE
"Textual Conventions for Internet Network Addresses.
RFC 3291."
DEFVAL { 0 }
IPv4アドレスで、0の長さはどんなアドレスのマッチも示します。 32の長さはただ一つのホスト・アドレスのマッチを示します、そして、0〜32の長さはCIDR Prefixの使用を示します。 接頭語の長さが0から変化するのを除いて、IPv6は同様です。128." 「インターネットネットワーク・アドレスのための原文のコンベンション」という参照。 「RFC3291。」 DEFVAL{ 0 }
::= { frwkIpFilterEntry 5 }
::= frwkIpFilterEntry5
frwkIpFilterDscp OBJECT-TYPE
SYNTAX DscpOrAny
STATUS current
DESCRIPTION
"The value that the DSCP in the packet can have and
match this filter. A value of -1 indicates that a specific
DSCP value has not been defined and thus all DSCP values
are considered a match."
REFERENCE
"Management Information Base for the Differentiated Services
Architecture. RFC 3289."
DEFVAL { -1 }
frwkIpFilterDscp OBJECT-TYPE SYNTAX DscpOrAny STATUSの現在の記述、「パケット缶の中のDSCPが持っている値とこれがフィルターにかけるマッチ。」 「-1の値は、特定のDSCP値が定義されていなくて、その結果、すべてのDSCP値がマッチであると考えられるのを示します。」 「差別化されたサービスアーキテクチャのための管理情報ベース」という参照。 「RFC3289。」 DEFVAL{ -1 }
::= { frwkIpFilterEntry 6 }
::= frwkIpFilterEntry6
frwkIpFilterFlowId OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..1048575)
STATUS current
DESCRIPTION
"The flow label or flow identifier in an IPv6 header
that may be used to discriminate traffic flows.
The value of -1 for this attribute MUST imply that
any flow label value in the IPv6 header will match,
resulting in the flow label field of the IPv6 header
being ignored for matching this filter entry."
frwkIpFilterFlowId OBJECT-TYPE SYNTAX Integer32、(-1|0. .1048575の)STATUSの現在の記述、「トラフィックを差別するのに使用されるかもしれないIPv6ヘッダーの流れラベルか流れ識別子が流れます」。 「この属性のための-1の値は、IPv6ヘッダーのどんな流れラベル価値も合うのを含意しなければなりません、このフィルタエントリーに合うように無視されるIPv6ヘッダーの流れラベルフィールドをもたらして。」
::= { frwkIpFilterEntry 7 }
::= frwkIpFilterEntry7
Sahita, et. al. Informational [Page 49] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[49ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwkIpFilterProtocol OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
STATUS current
DESCRIPTION
"The layer-4 protocol Id to match against the IPv4 protocol
number or the IPv6 Next-Header number in the packet. A value
of 255 means match all. Note the protocol number of 255 is
reserved by IANA, and Next-Header number of 0 is used in
IPv6."
DEFVAL { 255 }
frwkIpFilterProtocol OBJECT-TYPE SYNTAX Unsigned32(0 .255)のSTATUSの現在の記述、「層-4はパケットでIPv4プロトコル番号かIPv6 Next-ヘッダー番号に対して合うようにIdについて議定書の中で述べます」。 255の値は、すべてを合わせることを意味します。 「255のプロトコル番号がIANAによって予約されて、0のNext-ヘッダー番号がIPv6で使用されるというメモ。」 DEFVAL{ 255 }
::= { frwkIpFilterEntry 8 }
::= frwkIpFilterEntry8
frwkIpFilterDstL4PortMin OBJECT-TYPE
SYNTAX InetPortNumber
STATUS current
DESCRIPTION
"The minimum value that the packet's layer 4 destination
port number can have and match this filter. This value must
be equal to or lesser that the value specified for this
filter in frwkIpFilterDstL4PortMax.
frwkIpFilterDstL4PortMin OBJECT-TYPE SYNTAX InetPortNumber STATUSの現在の記述、「パケットの層の4目的地ポートナンバーが持つことができる最小値とこれがフィルターにかけるマッチ。」 この値は、等しいか、または、より少ないに違いありません。値はfrwkIpFilterDstL4PortMaxのこのフィルタに指定しました。
COPS-PR error code 'attrValueInvalid' must be returned if
the frwkIpFilterSrcL4PortMin is greater than
frwkIpFilterSrcL4PortMax"
REFERENCE
"COPS Usage for Policy Provisioning. RFC 3084, error
codes section 4.5."
DEFVAL { 0 }
「frwkIpFilterSrcL4PortMinがfrwkIpFilterSrcL4PortMaxより大きいなら、COPS-PRエラーコード'attrValueInvalid'を返さなければならなく」REFERENCEは「方針の食糧を供給する用法を獲得します」。 「RFC3084、誤りはセクション4.5をコード化します。」 DEFVAL{ 0 }
::= { frwkIpFilterEntry 9 }
::= frwkIpFilterEntry9
frwkIpFilterDstL4PortMax OBJECT-TYPE
SYNTAX InetPortNumber
STATUS current
DESCRIPTION
"The maximum value that the packet's layer 4 destination
port number can have and match this filter. This value must
be equal to or greater that the value specified for this
filter in frwkIpFilterDstL4PortMin.
frwkIpFilterDstL4PortMax OBJECT-TYPE SYNTAX InetPortNumber STATUSの現在の記述、「最大は、パケットの層の4目的地ポートナンバーがこのフィルタを持っていて、合うことができるのを評価します」。 この値は、等しいか、または、より大きいに違いありません。値はfrwkIpFilterDstL4PortMinのこのフィルタに指定しました。
COPS-PR error code 'attrValueInvalid' must be returned if
the frwkIpFilterDstL4PortMax is less than
frwkIpFilterDstL4PortMin"
REFERENCE
"COPS Usage for Policy Provisioning. RFC 3084, error
codes section 4.5."
「frwkIpFilterDstL4PortMaxがfrwkIpFilterDstL4PortMin以下であるならCOPS-PRエラーコード'attrValueInvalid'を返さなければならなく」REFERENCEは「方針の食糧を供給する用法を獲得します」。 「RFC3084、誤りはセクション4.5をコード化します。」
Sahita, et. al. Informational [Page 50] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[50ページ]情報のRFC3318フレームワーク方針情報基地の行進
DEFVAL { 65535 }
DEFVAL{ 65535 }
::= { frwkIpFilterEntry 10 }
::= frwkIpFilterEntry10
frwkIpFilterSrcL4PortMin OBJECT-TYPE
SYNTAX InetPortNumber
STATUS current
DESCRIPTION
"The minimum value that the packet's layer 4 source port
number can have and match this filter. This value must
be equal to or lesser that the value specified for this
filter in frwkIpFilterSrcL4PortMax.
frwkIpFilterSrcL4PortMin OBJECT-TYPE SYNTAX InetPortNumber STATUSの現在の記述、「パケットの層の4ソースポート番号が持つことができる最小値とこれがフィルターにかけるマッチ。」 この値は、等しいか、または、より少ないに違いありません。値はfrwkIpFilterSrcL4PortMaxのこのフィルタに指定しました。
COPS-PR error code 'attrValueInvalid' must be returned if
the frwkIpFilterSrcL4PortMin is greated than
frwkIpFilterSrcL4PortMax"
REFERENCE
"COPS Usage for Policy Provisioning. RFC 3084, error
codes section 4.5."
DEFVAL { 0 }
「frwkIpFilterSrcL4PortMaxよりfrwkIpFilterSrcL4PortMinをgreatedするなら、COPS-PRエラーコード'attrValueInvalid'を返さなければならなく」REFERENCEは「方針の食糧を供給する用法を獲得します」。 「RFC3084、誤りはセクション4.5をコード化します。」 DEFVAL{ 0 }
::= { frwkIpFilterEntry 11 }
::= frwkIpFilterEntry11
frwkIpFilterSrcL4PortMax OBJECT-TYPE
SYNTAX InetPortNumber
STATUS current
DESCRIPTION
"The maximum value that the packet's layer 4 source port
number can have and match this filter. This value must be
equal to or greater that the value specified for this filter
in frwkIpFilterSrcL4PortMin.
frwkIpFilterSrcL4PortMax OBJECT-TYPE SYNTAX InetPortNumber STATUSの現在の記述、「最大は、パケットの層の4ソースポート番号がこのフィルタを持っていて、合うことができるのを評価します」。 この値は、等しいか、または、より大きいに違いありません。値はfrwkIpFilterSrcL4PortMinのこのフィルタに指定しました。
COPS-PR error code 'attrValueInvalid' must be returned if
the frwkIpFilterSrcL4PortMax is less than
frwkIpFilterSrcL4PortMin"
REFERENCE
"COPS Usage for Policy Provisioning. RFC error codes
section 4.5."
DEFVAL { 65535 }
「frwkIpFilterSrcL4PortMaxがfrwkIpFilterSrcL4PortMin以下であるならCOPS-PRエラーコード'attrValueInvalid'を返さなければならなく」REFERENCEは「方針の食糧を供給する用法を獲得します」。 「RFC誤りはセクション4.5をコード化します。」 DEFVAL{ 65535 }
::= { frwkIpFilterEntry 12 }
::= frwkIpFilterEntry12
-- -- The IEEE 802 Filter Table --
-- -- IEEE802はテーブルをフィルターにかけます--
frwk802FilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF Frwk802FilterEntry
Frwk802FilterEntryのfrwk802FilterTableオブジェクト・タイプ構文系列
Sahita, et. al. Informational [Page 51] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[51ページ]情報のRFC3318フレームワーク方針情報基地の行進
PIB-ACCESS install
STATUS current
DESCRIPTION
"IEEE 802-based filter definitions. A class that contains
attributes of IEEE 802 (e.g., 802.3) traffic that form
filters that are used to perform traffic classification."
REFERENCE
"IEEE Standards for Local and Metropolitan Area Networks.
Overview and Architecture, ANSI/IEEE Std 802, 1990."
::= { frwkClassifierClasses 3 }
PIB-ACCESSはSTATUSの現在の記述「IEEEの802ベースのフィルター定義」をインストールします。 「トラフィック分類を実行するのに使用されるフィルタを形成するIEEE802(例えば、802.3)トラフィックの属性を含むクラス。」 「地方とメトロポリタンエリアネットワークのIEEE規格」という参照。 そして、「概要、アーキテクチャ、ANSI/IEEE Std802、1990インチ。 ::= frwkClassifierClasses3
frwk802FilterEntry OBJECT-TYPE
SYNTAX Frwk802FilterEntry
STATUS current
DESCRIPTION
"IEEE 802-based filter definitions. An entry specifies
(potentially) several distinct matching components. Each
component is tested against the data in a frame
individually. An overall match occurs when all of the
individual components match the data they are compared
against in the frame being processed. A failure of any
one test causes the overall match to fail.
frwk802FilterEntry OBJECT-TYPE SYNTAX Frwk802FilterEntry STATUSの現在の記述「IEEEの802ベースのフィルター定義。」 エントリーは(潜在的に)いくつかの異なった合っているコンポーネントを指定します。 各コンポーネントは個別にフレームのデータに対してテストされます。 個々のコンポーネントのすべてがそれらが処理されるフレームで比較されるデータに合っていると、総合的なマッチは現れます。 どんなテストの失敗も総合的なマッチに失敗されます。
Wildcards may be specified for those fields that are not
relevant."
「ワイルドカードはそれらの関連していない分野に指定されるかもしれません。」
EXTENDS { frwkBaseFilterEntry }
UNIQUENESS { frwkBaseFilterNegation,
frwk802FilterDstAddr,
frwk802FilterDstAddrMask,
frwk802FilterSrcAddr,
frwk802FilterSrcAddrMask,
frwk802FilterVlanId,
frwk802FilterVlanTagRequired,
frwk802FilterEtherType,
frwk802FilterUserPriority }
frwkBaseFilterEntryを広げている、ユニークさfrwkBaseFilterNegation、frwk802FilterDstAddr、frwk802FilterDstAddrMask、frwk802FilterSrcAddr、frwk802FilterSrcAddrMask、frwk802FilterVlanId、frwk802FilterVlanTagRequired、frwk802FilterEtherType、frwk802FilterUserPriority
::= { frwk802FilterTable 1 }
::= frwk802FilterTable1
Frwk802FilterEntry ::= SEQUENCE {
frwk802FilterDstAddr PhysAddress,
frwk802FilterDstAddrMask PhysAddress,
frwk802FilterSrcAddr PhysAddress,
frwk802FilterSrcAddrMask PhysAddress,
frwk802FilterVlanId Integer32,
frwk802FilterVlanTagRequired INTEGER,
frwk802FilterEtherType Integer32,
frwk802FilterUserPriority BITS
Frwk802FilterEntry:、:= 系列、frwk802FilterDstAddr PhysAddress、frwk802FilterDstAddrMask PhysAddress、frwk802FilterSrcAddr PhysAddress、frwk802FilterSrcAddrMask PhysAddress、frwk802FilterVlanId Integer32、frwk802FilterVlanTagRequired整数、frwk802FilterEtherType Integer32、frwk802FilterUserPriorityビット
Sahita, et. al. Informational [Page 52] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[52ページ]情報のRFC3318フレームワーク方針情報基地の行進
}
}
frwk802FilterDstAddr OBJECT-TYPE
SYNTAX PhysAddress
STATUS current
DESCRIPTION
"The 802 address against which the 802 DA of incoming
traffic streams will be compared. Frames whose 802 DA
matches the physical address specified by this object,
taking into account address wildcarding as specified by the
frwk802FilterDstAddrMask object, are potentially subject to
the processing guidelines that are associated with this
entry through the related action class."
REFERENCE
"Textual Conventions for SMIv2, RFC 2579."
「入って来るトラフィックストリームの802DAがどれになるかに対して比べて、802は扱う」frwk802FilterDstAddr OBJECT-TYPE SYNTAX PhysAddress STATUSの現在の記述。 「frwk802FilterDstAddrMaskオブジェクトによって指定されるようにwildcardingされるアドレスを考慮に入れて、物理アドレスがこのオブジェクトで802個のDAマッチを指定したフレームは潜在的に関連する動作のクラスを通したこのエントリーに関連している処理ガイドラインを受けることがあります。」 「SMIv2、RFC2579年の原文のコンベンション」という参照。
::= { frwk802FilterEntry 1 }
::= frwk802FilterEntry1
frwk802FilterDstAddrMask OBJECT-TYPE
SYNTAX PhysAddress
STATUS current
DESCRIPTION
"This object specifies the bits in a 802 destination address
that should be considered when performing a 802 DA
comparison against the address specified in the
frwk802FilterDstAddr object.
frwk802FilterDstAddrMask OBJECT-TYPE SYNTAX PhysAddress STATUSの現在の記述は「に対して802DA比較を実行するとき考えられるべきである802送付先アドレスでビットを指定これが反対するします」。
The value of this object represents a mask that is logically
and'ed with the 802 DA in received frames to derive the
value to be compared against the frwk802FilterDstAddr
address. A zero bit in the mask thus means that the
corresponding bit in the address always matches. The
frwk802FilterDstAddr value must also be masked using this
value prior to any comparisons.
このオブジェクトの値はマスクを表します、すなわち、論理的に、中に802DAがあるand'edが、frwk802FilterDstAddrアドレスに対して比較されるために値を引き出すためにフレーム搬入しました。 その結果、マスクのゼロ・ビットは、アドレスの対応するビットがいつも合っていることを意味します。 また、frwk802FilterDstAddr値もどんな比較の前にもこの値を使用することにおいて仮面であるに違いありません。
The length of this object in octets must equal the length in
octets of the frwk802FilterDstAddr. Note that a mask with no
bits set (i.e., all zeroes) effectively wildcards the
frwk802FilterDstAddr object."
八重奏における、このオブジェクトの長さはfrwk802FilterDstAddrの八重奏における長さと等しくなければなりません。 「ビットのないマスクが有効にワイルドカードを設定することに(すなわちすべてのゼロ)注意してください、frwk802FilterDstAddrが反対する、」
::= { frwk802FilterEntry 2 }
::= frwk802FilterEntry2
frwk802FilterSrcAddr OBJECT-TYPE
SYNTAX PhysAddress
STATUS current
DESCRIPTION
"The 802 MAC address against which the 802 MAC SA of
incoming traffic streams will be compared. Frames whose 802
「入って来るトラフィックストリームの802MAC SAがどれになるかに対して比べて、802MACは扱う」frwk802FilterSrcAddr OBJECT-TYPE SYNTAX PhysAddress STATUSの現在の記述。 フレーム、802
Sahita, et. al. Informational [Page 53] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[53ページ]情報のRFC3318フレームワーク方針情報基地の行進
MAC SA matches the physical address specified by this
object, taking into account address wildcarding as specified
by the frwk802FilterSrcAddrMask object, are potentially
subject to the processing guidelines that are associated
with this entry through the related action class."
「frwk802FilterSrcAddrMaskオブジェクトによって指定されるようにwildcardingされるアドレスを考慮に入れて、物理アドレスがこのオブジェクトで指定したMAC SAマッチは潜在的に関連する動作のクラスを通したこのエントリーに関連している処理ガイドラインを受けることがあります。」
::= { frwk802FilterEntry 3 }
::= frwk802FilterEntry3
frwk802FilterSrcAddrMask OBJECT-TYPE
SYNTAX PhysAddress
STATUS current
DESCRIPTION
"This object specifies the bits in a 802 MAC source address
that should be considered when performing a 802 MAC SA
comparison against the address specified in the
frwk802FilterSrcAddr object.
frwk802FilterSrcAddrMask OBJECT-TYPE SYNTAX PhysAddress STATUSの現在の記述は「frwk802FilterSrcAddrオブジェクトで指定されたアドレスに対して802MAC SA比較を実行するとき考えられるべきである802MACソースアドレスでビットを指定これが反対するします」。
The value of this object represents a mask that is logically
and'ed with the 802 MAC SA in received frames to derive the
value to be compared against the frwk802FilterSrcAddr
address. A zero bit in the mask thus means that the
corresponding bit in the address always matches. The
frwk802FilterSrcAddr value must also be masked using this
value prior to any comparisons.
このオブジェクトの値はマスクを表します、すなわち、論理的に、中に802MAC SAがあるand'edが、frwk802FilterSrcAddrアドレスに対して比較されるために値を引き出すためにフレーム搬入しました。 その結果、マスクのゼロ・ビットは、アドレスの対応するビットがいつも合っていることを意味します。 また、frwk802FilterSrcAddr値もどんな比較の前にもこの値を使用することにおいて仮面であるに違いありません。
The length of this object in octets must equal the length in
octets of the frwk802FilterSrcAddr. Note that a mask with no
bits set (i.e., all zeroes) effectively wildcards the
frwk802FilterSrcAddr object."
八重奏における、このオブジェクトの長さはfrwk802FilterSrcAddrの八重奏における長さと等しくなければなりません。 「ビットのないマスクが有効にワイルドカードを設定することに(すなわちすべてのゼロ)注意してください、frwk802FilterSrcAddrが反対する、」
::= { frwk802FilterEntry 4 }
::= frwk802FilterEntry4
frwk802FilterVlanId OBJECT-TYPE
SYNTAX Integer32 (-1 | 1..4094)
STATUS current
DESCRIPTION
"The VLAN ID (VID) that uniquely identifies a VLAN
within the device. This VLAN may be known or unknown
(i.e., traffic associated with this VID has not yet
been seen by the device) at the time this entry
is instantiated.
frwk802FilterVlanId OBJECT-TYPE SYNTAX Integer32、(-1|1. .4094の)STATUSの現在の記述、「デバイスの中に唯一VLANを特定するVLAN ID(VID)。」 このエントリーが例示されるとき、このVLANは知られているか、または未知であるかもしれません(すなわち、このVIDに関連しているトラフィックはデバイスによってまだ見られていません)。
Setting the frwk802FilterVlanId object to -1 indicates that
VLAN data should not be considered during traffic
classification."
「frwk802FilterVlanIdオブジェクトを-1に設定するのは、VLANデータがトラフィック分類の間考えられるべきでないのを示します。」
::= { frwk802FilterEntry 5 }
::= frwk802FilterEntry5
Sahita, et. al. Informational [Page 54] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[54ページ]情報のRFC3318フレームワーク方針情報基地の行進
frwk802FilterVlanTagRequired OBJECT-TYPE
SYNTAX INTEGER {
taggedOnly(1),
priorityTaggedPlus(2),
untaggedOnly(3),
ignoreTag(4)
}
STATUS current
DESCRIPTION
"This object indicates whether the presence of an
IEEE 802.1Q VLAN tag in data link layer frames must
be considered when determining if a given frame
matches this 802 filter entry.
frwk802FilterVlanTagRequired OBJECT-TYPE SYNTAX INTEGER、taggedOnly(1)、priorityTaggedPlus(2)、untaggedOnly(3)、ignoreTag(4)、「与えられたフレームがこの802フィルタエントリーに合っているかどうか決定するとき、データ・リンク層フレームでのIEEE 802.1Q VLANタグの存在を考えなければならないか否かに関係なく、このオブジェクトは示す」STATUSの現在の記述。
A value of 'taggedOnly(1)' means that only frames
containing a VLAN tag with a non-Null VID (i.e., a
VID in the range 1..4094) will be considered a match.
'taggedOnly(1)'の値は、非ヌルVID(すなわち、範囲1.4094におけるVID)があるVLANタグを含むフレームだけがマッチであると考えられることを意味します。
A value of 'priorityTaggedPlus(2)' means that only
frames containing a VLAN tag, regardless of the value
of the VID, will be considered a match.
'priorityTaggedPlus(2)'の値は、VIDの値にかかわらずVLANタグを含むフレームだけがマッチであると考えられることを意味します。
A value of 'untaggedOnly(3)' indicates that only
untagged frames will match this filter component.
'untaggedOnly(3)'の値は、非タグ付けをされたフレームだけがこのフィルタの部品に合うのを示します。
The presence of a VLAN tag is not taken into
consideration in terms of a match if the value is
'ignoreTag(4)'."
「VLANタグの存在は値が'ignoreTag(4)'であるならマッチに関して考慮に入れられません。」
::= { frwk802FilterEntry 6 }
::= frwk802FilterEntry6
frwk802FilterEtherType OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..'ffff'h)
STATUS current
DESCRIPTION
"This object specifies the value that will be compared
against the value contained in the EtherType field of an
IEEE 802 frame. Example settings would include 'IP'
(0x0800), 'ARP' (0x0806) and 'IPX' (0x8137).
frwk802FilterEtherType OBJECT-TYPE SYNTAX Integer32、(-1|0 . . 'ffff'h) STATUSの現在の記述は「IEEE802フレームのEtherType分野に保管されていた値に対してたとえられる値を指定これが反対する」'。 例の設定は'IP'(0×0800)、'ARP'(0×0806)、および'IPX'(0×8137)を含んでいるでしょう。
Setting the frwk802FilterEtherTypeMin object to -1 indicates
that EtherType data should not be considered during traffic
classification.
frwk802FilterEtherTypeMinオブジェクトを-1に設定するのは、EtherTypeデータがトラフィック分類の間考えられるべきでないのを示します。
Note that the position of the EtherType field depends on
the underlying frame format. For Ethernet-II encapsulation,
the EtherType field follows the 802 MAC source address. For
802.2 LLC/SNAP encapsulation, the EtherType value follows
EtherType分野の位置を基本的なフレーム形式に依存することに注意してください。 イーサネットIIカプセル化のために、EtherType分野は802MACソースアドレスに従います。 カプセル化、EtherTypeが続くのを評価する802.2LLC/SNAPのために
Sahita, et. al. Informational [Page 55] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[55ページ]情報のRFC3318フレームワーク方針情報基地の行進
the Organization Code field in the 802.2 SNAP header. The
value that is tested with regard to this filter component
therefore depends on the data link layer frame format being
used. If this 802 filter component is active when there is
no EtherType field in a frame (e.g., 802.2 LLC), a match is
implied."
802.2SNAPヘッダーのOrganization Code分野。 したがって、このフィルタの部品に関してテストされる値は使用されるデータ・リンク層フレーム形式に依存します。 「EtherType分野が全くフレーム(例えば、802.2LLC)にないとき、この802フィルタの部品がアクティブであるなら、マッチは含意されます。」
::= { frwk802FilterEntry 7 }
::= frwk802FilterEntry7
frwk802FilterUserPriority OBJECT-TYPE
SYNTAX BITS {
matchPriority0(0),
matchPriority1(1),
matchPriority2(2),
matchPriority3(3),
matchPriority4(4),
matchPriority5(5),
matchPriority6(6),
matchPriority7(7)
}
STATUS current
DESCRIPTION
"The set of values, representing the potential range
of user priority values, against which the value contained
in the user priority field of a tagged 802.1 frame is
compared. A test for equality is performed when determining
if a match exists between the data in a data link layer
frame and the value of this 802 filter component. Multiple
values may be set at one time such that potentially several
different user priority values may match this 802 filter
component.
frwk802FilterUserPriority OBJECT-TYPE SYNTAX BITS、matchPriority0(0)、matchPriority1(1)、matchPriority2(2)、matchPriority3(3)、matchPriority4(4)、matchPriority5(5)、matchPriority6(6)、matchPriority7(7)、STATUSの現在の記述、「タグ付けをされた802.1フレームのユーザ優先権分野に保管されていた値がたとえられる潜在的範囲のユーザ優先順位の値を表す値のセット。」 マッチがデータ・リンク層フレームのデータとこの802フィルタの部品の値の間に存在するかどうか決定するとき、平等のためのテストは実行されます。 複数の値が、ひところ、潜在的にいくつかの異なったユーザ優先順位の値がこの802フィルタの部品に合うことができるように、設定されるかもしれません。
Setting all of the bits that are associated with this
object causes all user priority values to match this
attribute. This essentially makes any comparisons
with regard to user priority values unnecessary. Untagged
frames are treated as an implicit match."
優にこのオブジェクトに関連しているビットを設定するのに、すべてのユーザ優先順位の値がこの属性に合っています。 これで、ユーザ優先順位の値に関するどんな比較も本質的には不要になります。 「Untaggedフレームは内在しているマッチとして扱われます。」
::= { frwk802FilterEntry 8 }
::= frwk802FilterEntry8
-- -- The Internal label filter extension --
-- -- Internalはフィルタ拡大をラベルします--
frwkILabelFilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkILabelFilterEntry
PIB-ACCESS install
STATUS current
frwkILabelFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkILabelFilterEntry PIB-ACCESSはSTATUS海流をインストールします。
Sahita, et. al. Informational [Page 56] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[56ページ]情報のRFC3318フレームワーク方針情報基地の行進
DESCRIPTION
"Internal label filter Table. This PRC is used to achieve
classification based on the internal flow label set by the
PEP possibly after ingress classification to avoid
re-classification at the egress interface on the same PEP."
記述「内部のラベルフィルタTable。」 「このPRCはことによると同じPEPで出口のインタフェースで再分類を避けるためにPEPによって次々と内部の流れラベル・セットに基礎づけられたイングレス分類を達成するのに使用されます。」
::= { frwkClassifierClasses 4 }
::= frwkClassifierClasses4
frwkILabelFilterEntry OBJECT-TYPE
SYNTAX FrwkILabelFilterEntry
STATUS current
DESCRIPTION
"Internal label filter entry definition."
現在のfrwkILabelFilterEntry OBJECT-TYPE SYNTAX FrwkILabelFilterEntry STATUSの記述「内部のラベルフィルタエントリー定義。」
EXTENDS { frwkBaseFilterEntry }
UNIQUENESS { frwkBaseFilterNegation,
frwkILabelFilterILabel }
frwkBaseFilterEntryを広げている、ユニークさfrwkBaseFilterNegation、frwkILabelFilterILabel
::= { frwkILabelFilterTable 1 }
::= frwkILabelFilterTable1
FrwkILabelFilterEntry ::= SEQUENCE {
frwkILabelFilterILabel OCTET STRING
}
FrwkILabelFilterEntry:、:= 系列frwkILabelFilterILabel八重奏ストリング
frwkILabelFilterILabel OBJECT-TYPE
SYNTAX OCTET STRING
STATUS current
DESCRIPTION
"The Label that this flow uses for differentiating traffic
flows. The flow labeling is meant for network device
internal usage. A value of zero length string matches all
internal labels."
::= { frwkILabelFilterEntry 1 }
frwkILabelFilterILabel OBJECT-TYPE SYNTAX OCTET STRING STATUSの現在の記述、「この流れがトラフィックを差別化するのに使用するLabelは流れます」。 流れラベリングはネットワークデバイス内部の用法のために意味されます。 「ゼロ長ストリングの値はすべての内部のラベルに合っています。」 ::= frwkILabelFilterEntry1
-- -- The Marker classes group --
-- -- Markerのクラスは分類されます--
frwkMarkerClasses
OBJECT IDENTIFIER ::= { frameworkPib 4 }
--
-- The 802 Marker Table
--
frwkMarkerClassesオブジェクト識別子:、:= frameworkPib4----802マーカーテーブル--
frwk802MarkerTable OBJECT-TYPE
SYNTAX SEQUENCE OF Frwk802MarkerEntry
PIB-ACCESS install
STATUS current
frwk802MarkerTable OBJECT-TYPE SYNTAX SEQUENCE OF Frwk802MarkerEntry PIB-ACCESSはSTATUS海流をインストールします。
Sahita, et. al. Informational [Page 57] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[57ページ]情報のRFC3318フレームワーク方針情報基地の行進
DESCRIPTION
"The 802 Marker class. An 802 packet can be marked with the
specified VLAN id, priority level."
「802Markerは分類する」記述。 「指定されたVLANイド、優先順位で802パケットをマークできます。」
::= { frwkMarkerClasses 1 }
::= frwkMarkerClasses1
frwk802MarkerEntry OBJECT-TYPE
SYNTAX Frwk802MarkerEntry
STATUS current
DESCRIPTION
"frwk802Marker entry definition."
frwk802MarkerEntry OBJECT-TYPE SYNTAX Frwk802MarkerEntry STATUSの現在の記述「frwk802Markerエントリー定義。」
PIB-INDEX { frwk802MarkerPrid }
UNIQUENESS { frwk802MarkerVlanId,
frwk802MarkerPriority }
PIB-インデックスfrwk802MarkerPrid、ユニークさfrwk802MarkerVlanId、frwk802MarkerPriority
::= { frwk802MarkerTable 1 }
::= frwk802MarkerTable1
Frwk802MarkerEntry::= SEQUENCE {
frwk802MarkerPrid InstanceId,
frwk802MarkerVlanId Unsigned32,
frwk802MarkerPriority Unsigned32
}
Frwk802MarkerEntry:、:= 系列frwk802MarkerPrid InstanceId、frwk802MarkerVlanId Unsigned32、frwk802MarkerPriority Unsigned32
frwk802MarkerPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An integer index to uniquely identify this 802 Marker."
「整数は唯一この802Markerを特定するために索引をつける」frwk802MarkerPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述。
::= { frwk802MarkerEntry 1 }
::= frwk802MarkerEntry1
frwk802MarkerVlanId OBJECT-TYPE
SYNTAX Unsigned32 (1..4094)
STATUS current
DESCRIPTION
"The VLAN ID (VID) that uniquely identifies a VLAN within
the device."
frwk802MarkerVlanId OBJECT-TYPE SYNTAX Unsigned32(1 .4094)のSTATUSの現在の記述、「装置の中に唯一VLANを特定するVLAN ID(VID)。」
::= { frwk802MarkerEntry 2 }
::= frwk802MarkerEntry2
frwk802MarkerPriority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
STATUS current
DESCRIPTION
"The user priority field of a tagged 802.1 frame."
frwk802MarkerPriority OBJECT-TYPE SYNTAX Unsigned32(0 .7)のSTATUSの現在の記述、「タグ付けをされた802.1フレームのユーザ優先権分野。」
::= { frwk802MarkerEntry 3 }
::= frwk802MarkerEntry3
Sahita, et. al. Informational [Page 58] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[58ページ]情報のRFC3318枠組みの方針情報基地の行進
-- -- The Internal Label Marker Table --
-- -- 内部のラベルマーカーテーブル--
frwkILabelMarkerTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrwkILabelMarkerEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"The Internal Label Marker class. A flow in a PEP can be
marked with an internal label using this PRC."
frwkILabelMarkerTable OBJECT-TYPE SYNTAX SEQUENCE OF FrwkILabelMarkerEntry PIB-ACCESSは「Internal Label Markerは分類する」STATUSの現在の記述をインストールします。 「内部のラベルがこのPRCを使用している状態で、PEPの流れをマークできます。」
::= { frwkMarkerClasses 2 }
::= frwkMarkerClasses2
frwkILabelMarkerEntry OBJECT-TYPE
SYNTAX FrwkILabelMarkerEntry
STATUS current
DESCRIPTION
"frwkILabelkMarker entry definition."
frwkILabelMarkerEntry OBJECT-TYPE SYNTAX FrwkILabelMarkerEntry STATUSの現在の記述「frwkILabelkMarkerエントリー定義。」
PIB-INDEX { frwkILabelMarkerPrid }
UNIQUENESS { frwkILabelMarkerILabel }
PIB-インデックスfrwkILabelMarkerPrid、ユニークさfrwkILabelMarkerILabel
::= { frwkILabelMarkerTable 1 }
::= frwkILabelMarkerTable1
FrwkILabelMarkerEntry::= SEQUENCE {
frwkILabelMarkerPrid InstanceId,
frwkILabelMarkerILabel OCTET STRING
}
FrwkILabelMarkerEntry:、:= 系列frwkILabelMarkerPrid InstanceId、frwkILabelMarkerILabel八重奏ストリング
frwkILabelMarkerPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An integer index to uniquely identify this Label Marker."
「整数は唯一このLabel Markerを特定するために索引をつける」frwkILabelMarkerPrid OBJECT-TYPE SYNTAX InstanceId STATUSの現在の記述。
::= { frwkILabelMarkerEntry 1 }
::= frwkILabelMarkerEntry1
frwkILabelMarkerILabel OBJECT-TYPE
SYNTAX OCTET STRING
STATUS current
DESCRIPTION
"This internal label is implementation specific and may be
used for other policy related functions like flow
accounting purposes and/or other data path treatments."
frwkILabelMarkerILabel OBJECT-TYPE SYNTAX OCTET STRING STATUSの現在の記述、「この内部のラベルは、実現特有であり、流れ会計目的、そして/または、他のデータ経路処理のような他の方針関連する機能に使用されるかもしれません」。
::= { frwkILabelMarkerEntry 2 }
::= frwkILabelMarkerEntry2
Sahita, et. al. Informational [Page 59] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[59ページ]情報のRFC3318枠組みの方針情報基地の行進
-- -- Conformance Section --
-- -- 順応部--
frwkBasePibConformance
OBJECT IDENTIFIER ::= { frameworkPib 5 }
frwkBasePibConformance物の識別子:、:= frameworkPib5
frwkBasePibCompliances
OBJECT IDENTIFIER ::= { frwkBasePibConformance 1 }
frwkBasePibCompliances物の識別子:、:= frwkBasePibConformance1
frwkBasePibGroups
OBJECT IDENTIFIER ::= { frwkBasePibConformance 2 }
frwkBasePibGroups物の識別子:、:= frwkBasePibConformance2
frwkBasePibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance to the
Framework PIB."
frwkBasePibCompliance MODULE-COMPLIANCE STATUSの現在の記述は「順応のための要件についてFramework PIBに説明します」。
MODULE -- this module
MANDATORY-GROUPS { frwkPrcSupportGroup,
frwkPibIncarnationGroup,
frwkDeviceIdGroup,
frwkCompLimitsGroup,
frwkCapabilitySetGroup,
frwkRoleComboGroup,
frwkIfRoleComboGroup }
MODULE--このモジュールMANDATORY-GROUPSfrwkPrcSupportGroup、frwkPibIncarnationGroup、frwkDeviceIdGroup、frwkCompLimitsGroup、frwkCapabilitySetGroup、frwkRoleComboGroup、frwkIfRoleComboGroup
OBJECT frwkPibIncarnationLongevity
PIB-MIN-ACCESS notify
DESCRIPTION
"Install support is required if policy expiration is to
be supported."
OBJECT frwkPibIncarnationLongevity PIB-MIN-ACCESSは記述に通知します。「インストールサポートが方針満了が支持されることであるなら必要です」。
OBJECT frwkPibIncarnationTtl
PIB-MIN-ACCESS notify
DESCRIPTION
"Install support is required if policy expiration is to
be supported."
OBJECT frwkPibIncarnationTtl PIB-MIN-ACCESSは記述に通知します。「インストールサポートが方針満了が支持されることであるなら必要です」。
OBJECT frwkPibIncarnationInCtxtSet
PIB-MIN-ACCESS notify
DESCRIPTION
"Install support is required if configuration contexts
and outsourcing contexts are both to be supported."
OBJECT frwkPibIncarnationInCtxtSet PIB-MIN-ACCESSは記述に通知します。「インストールサポートが構成文脈とアウトソーシング文脈がともに支持されることであるなら必要です」。
OBJECT frwkPibIncarnationFullState
物のfrwkPibIncarnationFullState
Sahita, et. al. Informational [Page 60] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[60ページ]情報のRFC3318枠組みの方針情報基地の行進
PIB-MIN-ACCESS notify
DESCRIPTION
"Install support is required if incremental updates to
request states is to be supported."
PIB-MIN-ACCESSは記述に通知します。「インストールサポートが要求が支持されることになっているべきであると述べているアップデート増加であるなら必要です」。
GROUP frwkReferenceGroup
DESCRIPTION
"The frwkReferenceGroup is mandatory if referencing
across PIB contexts for specific client-types is to be
supported."
GROUP frwkReferenceGroup記述、「特定のクライアントタイプのためにPIBの向こう側に文脈に参照をつけるのが支持されるつもりであるなら、frwkReferenceGroupは義務的です」。
GROUP frwkErrorGroup
DESCRIPTION
"The frwkErrorGroup is mandatory sending errors in
decisions is to be supported."
GROUP frwkErrorGroup記述、「frwkErrorGroupは決定における誤りを送るのが支持されることになっているのが義務的です」。
GROUP frwkBaseFilterGroup
DESCRIPTION
"The frwkBaseFilterGroup is mandatory if filtering
based on traffic components is to be supported."
GROUP frwkBaseFilterGroup記述、「frwkBaseFilterGroupは交通コンポーネントに基づくフィルタリングが支持されることであるなら義務的です」。
GROUP frwkIpFilterGroup
DESCRIPTION
"The frwkIpFilterGroup is mandatory if filtering
based on IP traffic components is to be supported."
GROUP frwkIpFilterGroup記述、「frwkIpFilterGroupはIP交通コンポーネントに基づくフィルタリングが支持されることであるなら義務的です」。
GROUP frwk802FilterGroup
DESCRIPTION
"The frwk802FilterGroup is mandatory if filtering
based on 802 traffic criteria is to be supported."
GROUP frwk802FilterGroup記述、「frwk802FilterGroupは802の交通評価基準に基づくフィルタリングが支持されることであるなら義務的です」。
GROUP frwkILabelFilterGroup
DESCRIPTION
"The frwkILabelFilterGroup is mandatory if filtering
based on PEP internal label is to be supported."
GROUP frwkILabelFilterGroup記述、「frwkILabelFilterGroupはPEPの内部のラベルに基づくフィルタリングが支持されることであるなら義務的です」。
GROUP frwk802MarkerGroup
DESCRIPTION
"The frwk802MarkerGroup is mandatory if marking a packet
with 802 traffic criteria is to be supported."
GROUP frwk802MarkerGroup記述、「frwk802MarkerGroupはマークするなら802の交通評価基準があるパケットが支持されることになっているのが義務的です」。
GROUP frwkILabelMarkerGroup
DESCRIPTION
"The frwkILabelMarkerGroup is mandatory if marking a
flow with internal labels is to be supported."
GROUP frwkILabelMarkerGroup記述、「frwkILabelMarkerGroupは内部のラベルがある流れがマークするなら支持されることであることが義務的です」。
::= { frwkBasePibCompliances 1 }
::= frwkBasePibCompliances1
Sahita, et. al. Informational [Page 61] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[61ページ]情報のRFC3318枠組みの方針情報基地の行進
frwkPrcSupportGroup OBJECT-GROUP
OBJECTS {
frwkPrcSupportPrid,
frwkPrcSupportSupportedPrc,
frwkPrcSupportSupportedAttrs }
STATUS current
DESCRIPTION
"Objects from the frwkPrcSupportTable."
frwkPrcSupportGroup OBJECT-GROUP OBJECTS、frwkPrcSupportPrid、frwkPrcSupportSupportedPrc、STATUSの現在の記述が「frwkPrcSupportTableから反対させる」frwkPrcSupportSupportedAttrs。
::= { frwkBasePibGroups 1 }
::= frwkBasePibGroups1
frwkPibIncarnationGroup OBJECT-GROUP
OBJECTS {
frwkPibIncarnationPrid,
frwkPibIncarnationName,
frwkPibIncarnationId,
frwkPibIncarnationLongevity,
frwkPibIncarnationTtl,
frwkPibIncarnationInCtxtSet,
frwkPibIncarnationActive,
frwkPibIncarnationFullState
}
STATUS current
DESCRIPTION
"Objects from the frwkDevicePibIncarnationTable."
frwkPibIncarnationGroup OBJECT-GROUP OBJECTS、frwkPibIncarnationPrid、frwkPibIncarnationName、frwkPibIncarnationId、frwkPibIncarnationLongevity、frwkPibIncarnationTtl、frwkPibIncarnationInCtxtSet、frwkPibIncarnationActive、frwkPibIncarnationFullState、現在の記述が「frwkDevicePibIncarnationTableから反対させる」STATUS。
::= { frwkBasePibGroups 2 }
::= frwkBasePibGroups2
frwkDeviceIdGroup OBJECT-GROUP
OBJECTS {
frwkDeviceIdPrid,
frwkDeviceIdDescr,
frwkDeviceIdMaxMsg,
frwkDeviceIdMaxContexts }
STATUS current
DESCRIPTION
"Objects from the frwkDeviceIdTable."
frwkDeviceIdGroup OBJECT-GROUP OBJECTS、frwkDeviceIdPrid、frwkDeviceIdDescr、frwkDeviceIdMaxMsg、STATUSの現在の記述が「frwkDeviceIdTableから反対させる」frwkDeviceIdMaxContexts。
::= { frwkBasePibGroups 3 }
::= frwkBasePibGroups3
frwkCompLimitsGroup OBJECT-GROUP
OBJECTS {
frwkCompLimitsPrid,
frwkCompLimitsComponent,
frwkCompLimitsAttrPos,
frwkCompLimitsNegation,
frwkCompLimitsType,
frwkCompLimitsSubType,
frwkCompLimitsGroup物群対象、frwkCompLimitsPrid、frwkCompLimitsComponent、frwkCompLimitsAttrPos、frwkCompLimitsNegation、frwkCompLimitsType、frwkCompLimitsSubType
Sahita, et. al. Informational [Page 62] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[62ページ]情報のRFC3318枠組みの方針情報基地の行進
frwkCompLimitsGuidance }
STATUS current
DESCRIPTION
"Objects from the frwkCompLimitsTable."
frwkCompLimitsGuidance 現在の記述が「frwkCompLimitsTableから反対させる」STATUS。
::= { frwkBasePibGroups 4 }
::= frwkBasePibGroups4
frwkReferenceGroup OBJECT-GROUP
OBJECTS {
frwkReferencePrid,
frwkReferenceClientType,
frwkReferenceClientHandle,
frwkReferenceInstance }
STATUS current
DESCRIPTION
"Objects from the frwkReferenceTable."
frwkReferenceGroup OBJECT-GROUP OBJECTS、frwkReferencePrid、frwkReferenceClientType、frwkReferenceClientHandle、frwkReferenceInstance、現在の記述が「frwkReferenceTableから反対させる」STATUS。
::= { frwkBasePibGroups 5 }
::= frwkBasePibGroups5
frwkErrorGroup OBJECT-GROUP
OBJECTS {
frwkErrorPrid,
frwkErrorCode,
frwkErrorSubCode,
frwkErrorPrc,
frwkErrorInstance }
STATUS current
DESCRIPTION
"Objects from the frwkErrorTable."
frwkErrorGroup OBJECT-GROUP OBJECTS、frwkErrorPrid、frwkErrorCode、frwkErrorSubCode、frwkErrorPrc、frwkErrorInstance、現在の記述が「frwkErrorTableから反対させる」STATUS。
::= { frwkBasePibGroups 6 }
::= frwkBasePibGroups6
frwkCapabilitySetGroup OBJECT-GROUP
OBJECTS {
frwkCapabilitySetPrid,
frwkCapabilitySetName,
frwkCapabilitySetCapability }
STATUS current
DESCRIPTION
"Objects from the frwkCapabilitySetTable."
frwkCapabilitySetGroup OBJECT-GROUP OBJECTS、frwkCapabilitySetPrid、frwkCapabilitySetName、frwkCapabilitySetCapability、現在の記述が「frwkCapabilitySetTableから反対させる」STATUS。
::= { frwkBasePibGroups 7 }
::= frwkBasePibGroups7
frwkRoleComboGroup OBJECT-GROUP
OBJECTS {
frwkRoleComboPrid,
frwkRoleComboRoles,
frwkRoleComboCapSetName }
frwkRoleComboGroup物群対象frwkRoleComboPrid、frwkRoleComboRoles、frwkRoleComboCapSetName
Sahita, et. al. Informational [Page 63] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[63ページ]情報のRFC3318枠組みの方針情報基地の行進
STATUS current
DESCRIPTION
"Objects from the frwkRoleComboTable."
現在の記述が「frwkRoleComboTableから反対させる」STATUS。
::= { frwkBasePibGroups 8 }
::= frwkBasePibGroups8
frwkIfRoleComboGroup OBJECT-GROUP
OBJECTS { frwkIfRoleComboIfIndex }
STATUS current
DESCRIPTION
"Objects from the frwkIfRoleComboTable."
frwkIfRoleComboGroup OBJECT-GROUP OBJECTS frwkIfRoleComboIfIndex、現在の記述が「frwkIfRoleComboTableから反対させる」STATUS。
::= { frwkBasePibGroups 9 }
::= frwkBasePibGroups9
frwkBaseFilterGroup OBJECT-GROUP
OBJECTS {
frwkBaseFilterPrid,
frwkBaseFilterNegation }
STATUS current
DESCRIPTION
"Objects from the frwkBaseFilterTable."
frwkBaseFilterGroup OBJECT-GROUP OBJECTS、frwkBaseFilterPrid、frwkBaseFilterNegation、現在の記述が「frwkBaseFilterTableから反対させる」STATUS。
::= { frwkBasePibGroups 10 }
::= frwkBasePibGroups10
frwkIpFilterGroup OBJECT-GROUP
OBJECTS {
frwkIpFilterAddrType,
frwkIpFilterDstAddr,
frwkIpFilterDstPrefixLength,
frwkIpFilterSrcAddr,
frwkIpFilterSrcPrefixLength,
frwkIpFilterDscp,
frwkIpFilterFlowId,
frwkIpFilterProtocol,
frwkIpFilterDstL4PortMin,
frwkIpFilterDstL4PortMax,
frwkIpFilterSrcL4PortMin,
frwkIpFilterSrcL4PortMax }
STATUS current
DESCRIPTION
"Objects from the frwkIpFilterTable."
frwkIpFilterGroup OBJECT-GROUP OBJECTS、frwkIpFilterAddrType、frwkIpFilterDstAddr、frwkIpFilterDstPrefixLength、frwkIpFilterSrcAddr、frwkIpFilterSrcPrefixLength、frwkIpFilterDscp、frwkIpFilterFlowId、frwkIpFilterProtocol、frwkIpFilterDstL4PortMin、frwkIpFilterDstL4PortMax、frwkIpFilterSrcL4PortMin、frwkIpFilterSrcL4PortMax、現在の記述が「frwkIpFilterTableから反対させる」STATUS。
::= { frwkBasePibGroups 11 }
::= frwkBasePibGroups11
frwk802FilterGroup OBJECT-GROUP
OBJECTS {
frwk802FilterDstAddr,
frwk802FilterDstAddrMask,
frwk802FilterGroup物群対象、frwk802FilterDstAddr、frwk802FilterDstAddrMask
Sahita, et. al. Informational [Page 64] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[64ページ]情報のRFC3318枠組みの方針情報基地の行進
frwk802FilterSrcAddr,
frwk802FilterSrcAddrMask,
frwk802FilterVlanId,
frwk802FilterVlanTagRequired,
frwk802FilterEtherType,
frwk802FilterUserPriority }
STATUS current
DESCRIPTION
"Objects from the frwk802FilterTable."
frwk802FilterSrcAddr、frwk802FilterSrcAddrMask、frwk802FilterVlanId、frwk802FilterVlanTagRequired、frwk802FilterEtherType、frwk802FilterUserPriority 現在の記述が「frwk802FilterTableから反対させる」STATUS。
::= { frwkBasePibGroups 12 }
::= frwkBasePibGroups12
frwkILabelFilterGroup OBJECT-GROUP
OBJECTS { frwkILabelFilterILabel }
STATUS current
DESCRIPTION
"Objects from the frwkILabelFilterTable."
frwkILabelFilterGroup OBJECT-GROUP OBJECTS frwkILabelFilterILabel、現在の記述が「frwkILabelFilterTableから反対させる」STATUS。
::= { frwkBasePibGroups 13 }
::= frwkBasePibGroups13
frwk802MarkerGroup OBJECT-GROUP
OBJECTS {
frwk802MarkerPrid,
frwk802MarkerVlanId,
frwk802MarkerPriority }
STATUS current
DESCRIPTION
"Objects from the frwk802MarkerTable."
frwk802MarkerGroup OBJECT-GROUP OBJECTS、frwk802MarkerPrid、frwk802MarkerVlanId、frwk802MarkerPriority、現在の記述が「frwk802MarkerTableから反対させる」STATUS。
::= { frwkBasePibGroups 14 }
::= frwkBasePibGroups14
frwkILabelMarkerGroup OBJECT-GROUP
OBJECTS {
frwkILabelMarkerPrid,
frwkILabelMarkerILabel }
STATUS current
DESCRIPTION
"Objects from the frwkILabelMarkerTable."
frwkILabelMarkerGroup OBJECT-GROUP OBJECTS、frwkILabelMarkerPrid、frwkILabelMarkerILabel、現在の記述が「frwkILabelMarkerTableから反対させる」STATUS。
::= { frwkBasePibGroups 15 }
::= frwkBasePibGroups15
END
終わり
Sahita, et. al. Informational [Page 65] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[65ページ]情報のRFC3318枠組みの方針情報基地の行進
6. Security Considerations
6. セキュリティ問題
It is clear that this PIB is used for configuration using [COPS-PR], and anything that can be configured can be misconfigured, with a potentially disastrous effect. At this writing, no security holes have been identified beyond those that the COPS base protocol security is itself intended to address. These relate primarily to controlled access to sensitive information and the ability to configure a device - or which might result from operator error, which is beyond the scope of any security architecture.
構成に[COPS-PR]を使用することでこのPIBを使用して、構成できるものは何でもmisconfiguredすることができるのは明確です、潜在的に悲惨な効果で。 この文を草するときに、セキュリティーホールは全く記述するCOPSベースプロトコルセキュリティが意図するものを超えて特定されていません。 これらは主としてどんなセキュリティー体系の範囲にもあるオペレータエラーから生じるかもしれない機密情報への制御アクセスと装置を構成する能力に関連します。
There are a number of PRovisioning Classes defined in this PIB that have a PIB-ACCESS clause of install and install-notify (read-create). These are:
インストールのPIB-ACCESS節を持って、インストールで通知する(読書して作成します)このPIBで定義された多くのPRovisioning Classesがあります。 これらは以下の通りです。
frwkPibIncarnationTable: Malicious access of this PRC can cause the PEP to use an incorrect context of policies.
frwkPibIncarnationTable: このPRCの悪意があるアクセスで、PEPは方針の不正確な文脈を使用できます。
frwkReferenceTable: Malicious access of this PRC can cause the PEP to interpret the installed policy in an incorrect manner.
frwkReferenceTable: このPRCの悪意があるアクセスで、PEPは不正確な方法でインストールされた方針を解釈できます。
frwkErrorTable: Malicious access of this PRC can cause the PEP to incorrectly assume that the PDP could not process its messages.
frwkErrorTable: このPRCの悪意があるアクセスで、PEPは、PDPがメッセージを処理できなかったと不当に仮定できます。
FrwkCapabilitySetTable, frwkRoleComboTable and frwkIfRoleComboTable: Malicious access of these PRCs can cause the PEP to apply policies to the wrong interfaces.
FrwkCapabilitySetTable、frwkRoleComboTable、およびfrwkIfRoleComboTable: これらのPRCsの悪意があるアクセスで、PEPは間違ったインタフェースに方針を付けることができます。
FrwkBaseFilterTable, frwkIpFilterTable, frwk802FilterTable and frwkILabelFilterTable: Malicious access of these PRCs can cause unintended classification of traffic on the PEP potentially leading to incorrect policies being applied.
FrwkBaseFilterTable、frwkIpFilterTable、frwk802FilterTable、およびfrwkILabelFilterTable: これらのPRCsの悪意があるアクセスは、適用されていて、潜在的に不正確な方針に通じながら、PEPで交通の故意でない分類を引き起こす場合があります。
frwk802MarkerTable, frwkILabelMarkerTable: Malicious access of these PRCs can cause unintended marking of traffic on the PEP potentially leading to incorrect policies being applied.
frwk802MarkerTable、frwkILabelMarkerTable: これらのPRCsの悪意があるアクセスは、適用されていて、潜在的に不正確な方針に通じながら、PEPで交通の故意でないマークを引き起こす場合があります。
Such objects may be considered sensitive or vulnerable in some network environments. The support for "Install" or "Install-Notify" decisions sent over [COPS-PR] in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of PRovisioning Classes in this PIB that may contain information that may be sensitive from a business perspective, in that they may represent a customer's service contract or the filters that the service provider chooses to apply to a customer's ingress or egress traffic. There are no PRCs that are sensitive in their own right, such as passwords or monetary amounts. It may be important to control even "Notify"(read-only) access to
そのような物はいくつかのネットワーク環境で敏感であるか、または傷つきやすいと考えられるかもしれません。 「インストールしてください」か「インストールで通知してください」という適切な保護なしで非安全な環境で移動された[COPS-PR]決定のサポートはネットワーク操作のときにマイナスの影響がある場合があります。 多くのPRovisioning Classesがビジネス見解から機密であるかもしれない情報を含むかもしれないこのPIBにあります、彼らが顧客の役務契約かサービスプロバイダーが顧客のイングレスか出口交通に適用するのを選ぶフィルタを表すかもしれないので。 どんなパスワードや通貨の量のようにそのものとして敏感なPRCsもありません。 それは、「通知してください」という(書き込み禁止)アクセスさえ制御するために重要であるかもしれません。
Sahita, et. al. Informational [Page 66] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[66ページ]情報のRFC3318枠組みの方針情報基地の行進
these PRCs and possibly to even encrypt the values of these PRIs when sending them over the network via COPS-PR. The use of IPSEC between the PDP and the PEP, as described in [COPS], provides the necessary protection against security threats. However, even if the network itself is secure, there is no control as to who on the secure network is allowed to "Install/Notify" (read/change/create/delete) the PRIs in this PIB.
これらのPRCsでことによると同等に、COPS-PRでネットワークの上に彼らを送るときにはこれらのPRIsの値をコード化してください。 PDPとPEPの間のIPSECの[COPS]で説明される使用は軍事的脅威に対する必要な保護を提供します。 しかしながら、ネットワーク自体が安全であっても、安全なネットワークにだれがこのPIBでPRIsに「インストールするか、または通知すること」が(読むか、変える、作成する、または削除します)許容されているかに関してコントロールが全くありません。
It is then a customer/user responsibility to ensure that the PEP/PDP giving access to an instance of this PIB, is properly configured to give access to only the PRIs and principals (users) that have legitimate rights to indeed "Install" or "Notify" (change/create/ delete) them.
そして、本当に、それらに「インストールする」か、または「通知する」(変えるか、作成する、または削除します)正当な権利を持っているPRIsと校長だけ(ユーザ)へのアクセスを与えるために構成されて、それはこのPIBの例へのアクセスを与えるPEP/PDPが適切にそうであることを保証する顧客/ユーザ責任です。
7. IANA Considerations
7. IANA問題
This document describes the frameworkPib and frwkTcPib Policy Information Base (PIB) modules for registration under the "pib" branch registered with IANA. The IANA has assigned PIB numbers 2 and 3, respectively.
このドキュメントはIANAに登録された"pib"支店の下で登録のためのframeworkPibとfrwkTcPib Policy Information基地(PIB)のモジュールを説明します。 IANAはそれぞれNo.2と3をPIBに割り当てました。
Both these PIBs use "all" in the SUBJECT-CATEGORIES clause, i.e., they apply to all COPS client types. No new COPS client type is to be registered for these two PIB modules.
これらのPIBsの両方がSUBJECT-CATEGORIES節で「すべて」を使用します、すなわち、彼らはすべてのCOPSクライアントタイプに適用します。 これらの2つのPIBモジュールのためにどんな新しいCOPSクライアントタイプも示してはいけません。
8. References
8. 参照
8.1 Normative References
8.1 標準の参照
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan,
R. and A. Sastry, "The COPS (Common Open Policy
Service) Protocol", RFC 2748, January 2000.
[巡査]ボイル、J.、コーエン、R.、ダラム、D.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[COPS-PR] Chan, K., Durham, D., Gai, S., Herzog, S.,
McCloghrie, K., Reichmeyer, Seligson, J., Smith, A.
and R. Yavatkar, "COPS Usage for Policy
Provisioning", RFC 3084, March 2001.
[PRを獲得します]のチェン(K.、ダラム、D.、ガイ、S.、ハーツォグ、S.、McCloghrie、K.、Reichmeyer、Seligson、J.、スミス、A.、およびR.Yavatkar)は、「方針の食糧を供給する用法を獲得します」、RFC3084、2001年3月。
[SPPI] McCloghrie, K., Fine, M., Seligson, J., Chan, K.,
Hahn, S., Sahita, R., Smith, A. and F. Reichmeyer,
"Structure of Policy Provisioning Information", RFC
3159, August 2001.
[SPPI]McCloghrie、K.、おかげさまで元気です、M.、Seligson、J.、チェン、K.、ハーン、S.、Sahita、R.、スミス、A.、およびF.Reichmeyer、「方針の構造は情報に食糧を供給し」て、RFC3159、2001年8月。
[SNMP-SMI] 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.
[SNMP-SMI]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
Sahita, et. al. Informational [Page 67] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[67ページ]情報のRFC3318枠組みの方針情報基地の行進
[INETADDR] Daniele, M., Haberman, B., Routhier, S. and J.
Schoenwaelder, "Textual Conventions for Internet
Network Addresses", RFC 3291, May 2002.
[INETADDR] ダニエル、M.、ハーバーマン、B.、Routhier、S.、およびJ.Schoenwaelder(「インターネットネットワーク・アドレスのための原文のコンベンション」、RFC3291)は2002がそうするかもしれません。
[802] IEEE Standards for Local and Metropolitan Area
Networks: Overview and Architecture, ANSI/IEEE Std
802, 1990.
[802] 地方とメトロポリタンエリアネットワークのIEEE規格: 概観と構造、ANSI/IEEE Std802、1990
[SNMPFRWK] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.
[SNMPFRWK] ハリントンとD.とPresuhnとR.とB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理枠組みについて説明するための構造」、STD62、RFC3411、2002年12月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[DS-MIB] Baker, F., Chan, K. and A. Smith, "Management
Information Base for the Differentiated Services
Architecture", RFC 3289, May 2002.
[DS-MIB] ベイカー、F.、チェン、K.、およびA.スミス(「微分されたサービス構造のための管理情報ベース」、RFC3289)は2002がそうするかもしれません。
[SNMPv2TC] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.
[SNMPv2TC] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2279] Yergeau, F. "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
1998年1月のF. [RFC2279]Yergeau、「UTF-8、ISO10646の変化形式」RFC2279。
[RFC2119] Bradner, S., "Key words to use in the RFCs", BCP 14,
RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「RFCsで使用するキーワード」、BCP14、RFC2119、1997年3月。
8.2 Informative References
8.2 有益な参照
[RAP-FRAMEWORK] Yavatkar, R and D. Pendarakis, "A Framework for
Policy-based Admission Control", RFC 2753, January
2000.
[ラップ枠組み] YavatkarとRとD.Pendarakis、「方針ベースの入場コントロールのための枠組み」、RFC2753、2000年1月。
[POLTERM] Westerinen, A., Schnizlein, J., Strassner, J.,
Scherling, M., Quinn, B., Herzog, S., Huynh, A.,
Carlson, M., Perry, J. and S. Waldbusser,
"Terminology for Policy-Based Management", RFC 3198,
November 2001.
[POLTERM]WesterinenとA.とSchnizleinとJ.とStrassnerとJ.とScherlingとM.、クインとB.とハーツォグとS.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針を拠点とする管理のための用語」RFC3198(2001年11月)。
9. Acknowledgments
9. 承認
Early versions of this specification were also co-authored by Michael Fine, Francis Reichmeyer, John Seligson and Andrew Smith.
また、この仕様の早めのバージョンがマイケルがすばらしい状態で共同執筆されて、フランシスは、Reichmeyerと、ジョンSeligsonとアンドリュー・スミスです。
Sahita, et. al. Informational [Page 68] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[68ページ]情報のRFC3318枠組みの方針情報基地の行進
Special thanks to Carol Bell, David Durham and Bert Wijnen for their many significant comments.
キャロル・ベル、デヴィッド・ダラム、およびバートWijnenのおかげで、彼らの多くの重要なコメントにおいて、特別です。
Additional useful comments have been made by Diana Rawlins, Martin Bokaemper, Tina Iliff, Pedro Da Silva, Juergen Schoenwaelder, Noisette Yoann and Man Li.
追加役に立つコメントはダイアナ・ローリンズ、マーチンBokaemper、ティナIliff、ペドロ・Daシルヴァ、ユルゲンSchoenwaelder、Noisette Yoann、およびMan李によってされました。
10. Authors' Addresses
10. 作者のアドレス
Ravi Sahita Intel Labs. 2111 NE 25th Avenue Hillsboro, OR 97124 USA
ラービーSahitaインテル研究室。 2111 NE第25Avenueヒースボロー、または97124米国
Phone: +1 503 712 1554 EMail: ravi.sahita@intel.com
以下に電話をしてください。 +1 1554年の503 712メール: ravi.sahita@intel.com
Scott Hahn Intel Corp. 2111 NE 25th Avenue Hillsboro, OR 97124 USA
スコットハーンインテル社2111NE第25Avenueヒースボロー、または97124米国
Phone: +1 503 264 8231 EMail: scott.hahn@intel.com
以下に電話をしてください。 +1 8231年の503 264メール: scott.hahn@intel.com
Kwok Ho Chan Nortel Networks, Inc. 600 Technology Park Drive Billerica, MA 01821 USA
クォックおーい、チェンノーテルネットワークInc.600技術公園Driveビルリカ、MA01821米国
Phone: +1 978 288 8175 EMail: khchan@nortelnetworks.com
以下に電話をしてください。 +1 8175年の978 288メール: khchan@nortelnetworks.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 5260年の408 526メール: kzm@cisco.com
Sahita, et. al. Informational [Page 69] RFC 3318 Framework Policy Information Base March 2003
et Sahita、アル。 2003年の[69ページ]情報のRFC3318枠組みの方針情報基地の行進
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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機能のための基金は現在、インターネット協会によって提供されます。
Sahita, et. al. Informational [Page 70]
et Sahita、アル。 情報[70ページ]
一覧
スポンサーリンク
