RFC3159 日本語訳
3159 Structure of Policy Provisioning Information (SPPI). K.McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A.Smith, F. Reichmeyer. August 2001. (Format: TXT=78621 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. McCloghrie
Request for Comments: 3159 M. Fine
Category: Standards Track Cisco Systems
J. Seligson
K. Chan
Nortel Networks
S. Hahn
R. Sahita
Intel
A. Smith
Allegro Networks
F. Reichmeyer
PFN
August 2001
McCloghrieがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3159年のM.罰金カテゴリ: S.ハーンR.SahitaインテルA.スミスアレグロがF.Reichmeyer PFN2001年8月にネットワークでつなぐ標準化過程シスコシステムズJ.Seligson K.チェンノーテルネットワーク
Structure of Policy Provisioning Information (SPPI)
情報に食糧を供給する方針の構造(SPPI)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules.
このドキュメント(Policy Provisioning情報(SPPI)のStructure)はSNMPの(SMI)がInformation基地(PIB)のモジュールをPolicyに書くのに使用したManagement情報のStructureの適合している部分集合を定義します。
RFC 2748 defines the COPS protocol, and RFC 2749 describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in RFC 3084. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in a PIB module.
RFC2748はCOPSプロトコルを定義します、そして、RFC2749はCOPSプロトコルがRSVPのために政策決定のアウトソーシングに備えるのにどう使用されるかを説明します。 方針の食糧を供給するために、RFC3084でCOPSプロトコルの別の用法を導入します。 Policy Information基地(PIB)は、モデルに食糧を供給するこれの方針情報が仮想情報店に住みながらProvisioning Classes(PRCs)とProvisioning Instances(PRIs)の収集として見なされると呼びました。 関連するProvisioning Classesの収集はPIBモジュールで定義されます。
McCloghrie, et al. Standards Track [Page 1] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[1ページ]。
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]で説明されるように本書では解釈されることであるべきですか?
Table of Contents
目次
1 Use of the SMI ................................................. 3 1.1 Terminology Translation ...................................... 3 1.2 Overview ..................................................... 3 2 Structure of this Specification ................................ 4 3 Definitions .................................................... 5 4 PIB Modules .................................................... 17 4.1 Importing Definitions ........................................ 17 4.2 Reserved Keywords ............................................ 18 5 Naming Hierarchy ............................................... 18 6 Mapping of the MODULE-IDENTITY macro ........................... 18 6.1 Mapping of the SUBJECT-CATEGORIES clause ..................... 18 7 Mapping of the OBJECT-TYPE macro ............................... 19 7.1 Mapping of the SYNTAX clause ................................. 19 7.1.1 Counter32 .................................................. 19 7.1.2 Gauge32 .................................................... 20 7.1.3 Opaque ..................................................... 20 7.1.4 IpAddress .................................................. 20 7.1.5 Counter64 .................................................. 20 7.1.6 Integer64 .................................................. 20 7.1.7 Unsigned64 ................................................. 20 7.1.8 Provisioning Classes ....................................... 21 7.2 Mapping of the MAX-ACCESS clause ............................. 21 7.3 Mapping of the PIB-ACCESS clause ............................. 22 7.4 Mapping of the INSTALL-ERRORS clause ......................... 22 7.5 Mapping of the PIB-INDEX clause .............................. 22 7.6 Mapping of the INDEX clause .................................. 23 7.7 Mapping of the AUGMENTS clause ............................... 23 7.8 Mapping of the EXTENDS clause ................................ 24 7.8.1 Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses .. 24 7.9 Mapping of the UNIQUENESS clause ............................. 25 7.10 Mapping of the PIB-REFERENCES clause ........................ 25 7.11 Mapping of the PIB-TAG clause ............................... 25 8 Mapping of the OBJECT-IDENTITY macro ........................... 26 9 Mapping of the OBJECT-GROUP macro .............................. 26 9.1 Mapping of the OBJECTS clause ................................ 26 10 Mapping of the MODULE-COMPLIANCE macro ........................ 26 10.1 Mapping of the MODULE clause ................................ 26 10.1.1 Mapping of the MANDATORY-GROUPS clause .................... 27 10.1.2 Mapping of the GROUP clause ............................... 27 10.1.3 Mapping of the OBJECT clause .............................. 27
1 SMIの使用… 3 1.1 用語翻訳… 3 1.2概観… このSpecificationの3 2構造… 4 3の定義… 5 4のPIBモジュール… 17 4.1 定義を輸入します… 17 4.2 キーワードを予約します… 18 5 階層構造を命名します… 18 MODULE-IDENTITYマクロに関する6マッピング… 18 SUBJECT-CATEGORIES節に関する6.1マッピング… 18 OBJECT-TYPEマクロに関する7マッピング… 19 SYNTAX節に関する7.1マッピング… 19 7.1 .1Counter32… 19 7.1 .2Gauge32… 20 7.1 .3 不透明にします。 20 7.1 .4IpAddress… 20 7.1 .5Counter64… 20 7.1 .6Integer64… 20 7.1 .7Unsigned64… 20 7.1 .8 食糧を供給することは属します… 21 マックス-ACCESS節に関する7.2マッピング… 21 PIB-ACCESS節に関する7.3マッピング… 22 INSTALL-ERRORS節に関する7.4マッピング… 22 PIB-INDEX節に関する7.5マッピング… 22 INDEX節に関する7.6マッピング… 23 AUGMENTS節に関する7.7マッピング… 23 EXTENDS節に関する7.8マッピング… 24 7.8 .1 PIB-INDEXと、AUGMENTSとEXTENDS節との関係。 24 UNIQUENESS節に関する7.9マッピング… PIB-REFERENCES節に関する25 7.10マッピング… PIB-TAG節に関する25 7.11マッピング… 25 OBJECT-IDENTITYマクロに関する8マッピング… 26 OBJECT-GROUPマクロに関する9マッピング… 26 OBJECTS節に関する9.1マッピング… MODULE-COMPLIANCEマクロに関する26 10マッピング… MODULE節に関する26 10.1マッピング… 26 10.1.1 MANDATORY-GROUPS節に関するマッピング… 27 10.1.2 GROUP節に関するマッピング… 27 10.1.3 OBJECT節に関するマッピング… 27
McCloghrie, et al. Standards Track [Page 2] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[2ページ]。
10.1.3.1 Mapping of the SYNTAX clause ............................ 27 10.1.3.2 Mapping of the WRITE-SYNTAX clause ...................... 28 10.1.3.3 Mapping of the PIB-MIN-ACCESS clause .................... 28 11 Textual Conventions ........................................... 28 11.1 Mapping of the TEXTUAL-CONVENTION macro ..................... 28 11.1.1 Mapping of the DISPLAY-HINT clause ........................ 29 11.1.2 Mapping of the SYNTAX clause .............................. 29 11.1.2.1 Sub-typing of Textual Conventions ....................... 29 12 Extending a PIB Module ........................................ 29 12.1 PIB Modules ................................................. 29 12.2 Object Assignments .......................................... 30 12.3 Object Definitions .......................................... 30 Appendix A: Mapping a PIB to a MIB ............................... 32 Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses .. 33 Security Considerations .......................................... 35 IANA Considerations .............................................. 35 Authors' Addresses ............................................... 37 References ....................................................... 38 Full Copyright Statement ......................................... 40
10.1.3.1 SYNTAX節に関するマッピング… 27 10.1.3.2 WRITE-SYNTAX節に関するマッピング… 28 10.1.3.3 PIB-MIN-ACCESS節に関するマッピング… 28 11の原文のコンベンション… TEXTUAL-CONVENTIONマクロに関する28 11.1マッピング… 28 11.1.1 DISPLAY-ヒント節に関するマッピング… 29 11.1.2 SYNTAX節に関するマッピング… 29 11.1.2.1 原文のコンベンションのサブタイプ… PIBモジュールを広げる29 12… 29 12.1 PIBモジュール… 29 12.2 物の課題… 30 12.3 物の定義… 30 付録A: PIBをMIBに写像します… 32 付録B: PIB-REFERENCESとPIB-TAG節の例の用法。 33 セキュリティ問題… 35 IANA問題… 35人の作者のアドレス… 37の参照箇所… 38 完全な著作権宣言文… 40
1. Use of the SMI
1. SMIの使用
The SPPI and PIB modules are based on SNMP's SMI and MIB modules, which use an adapted subset of the ASN.1 data definition language [ASN1]. The decision to base the definition of PIB modules on this format allows for the leveraging of the community's knowledge, experience and tools of the SMI and MIB modules.
SPPIとPIBモジュールはSNMPのSMIとMIBモジュールに基づいています。(モジュールはASN.1データ定義言語[ASN1]の適合している部分集合を使用します)。 PIBモジュールの定義をこの形式に基礎づけるという決定はSMIとMIBモジュールの共同体の知識の力を入れ、経験、およびツールを考慮します。
1.1. Terminology Translation
1.1. 用語翻訳
The SMI uses the term "managed objects" to refer to object types, both tabular types with descriptors such as xxxTable and xxxEntry, as well as scalar and columnar object types. The SPPI does not use the term "object" so as to avoid confusion with COPS protocol objects. Instead, the SPPI uses the term Provisioning Class (PRC) for the table and row definitions (the xxxTable and xxxEntry objects, respectively), and Provisioning Instance (PRI) for an instantiation of a row definition. For a columnar object of a table definition, the SPPI uses the term "attribute" of a Provisioning Class. (The SPPI does not support the equivalent of the SMI's scalar objects.)
SMIはオブジェクト・タイプ、xxxTableなどの記述子がある表タイプとxxxEntryの両方について言及するのに「管理オブジェクト」という用語を使用します、スカラの、そして、円柱状のオブジェクト・タイプと同様に。 SPPIは、COPSプロトコル物への混乱を避けるのに「物」という用語を使用しません。 代わりに、SPPIはテーブルと列の定義(それぞれxxxTableとxxxEntry物)のための用語Provisioning Class(PRC)、および列の定義の具体化のためのProvisioning Instance(PRI)を使用します。 テーブル定義の円柱状の目的のために、SPPIは「属性」というProvisioning Classの用語を使用します。 (SPPIはSMIのスカラの物の同等物を支持しません。)
1.2. Overview
1.2. 概観
SNMP's SMI is divided into five parts: module definitions, object definitions, notification definitions [SMI], textual convention definitions [TC] and conformance definitions [CONF].
SNMPのSMIは5つの部品に分割されます: モジュール定義、オブジェクト定義、通知定義[SMI]、原文のコンベンション定義[TC]、および順応定義[CONF]。
McCloghrie, et al. Standards Track [Page 3] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[3ページ]。
- The SMI's MODULE-IDENTITY macro is used to convey the semantics of
a MIB module. The SPPI uses this macro to convey the semantics of
a PIB module.
- SMIのMODULE-IDENTITYマクロは、MIBモジュールの意味論を伝えるのに使用されます。 SPPIは、PIBモジュールの意味論を伝えるのにこのマクロを使用します。
- The SMI's OBJECT-TYPE macro is used to convey the syntax and
semantics of managed objects. The SPPI uses this macro to convey
the syntax and semantics of PRCs and their attributes.
- SMIのOBJECT-TYPEマクロは、管理オブジェクトの構文と意味論を伝えるのに使用されます。 SPPIは、PRCsと彼らの属性の構文と意味論を伝えるのにこのマクロを使用します。
- The SMI's notification definitions are not used (at this time) by
the SPPI. (Note that the use of the keyword 'notify' in the SPPI
is not related to the SMI's notifications).
- SMIの通知定義は(このとき、)SPPIによって使用されません。 (SPPIで'通知する'というキーワードの使用がSMIの通知に関連しないことに注意します。)
- The SMI's TEXTUAL CONVENTION macro allows new data types to be
defined. The SPPI uses this macro to define new data types having
particular syntax and semantics which is common to several
attributes of one of more PRCs.
- SMIのTEXTUAL CONVENTIONマクロは、新しいデータ型が定義されるのを許容します。 SPPIは、より多くのPRCsの1つのいくつかの属性に共通の特定の構文と意味論を持っている新しいデータ型を定義するのにこのマクロを使用します。
- The SMI's conformance definitions define several macros: the
OBJECT-GROUP macro, the NOTIFICATION-GROUP macro, the MODULE-
COMPLIANCE macro and the AGENT-CAPABILITIES macro. The SPPI uses
the OBJECT-GROUP and MODULE-COMPLIANCE macros to specify
acceptable lower-bounds of implementation of the attributes of
PRCs, and thereby indirectly, acceptable lower-bounds of
implementation of the PRCs themselves. The NOTIFICATION-GROUP
macro is not used (at this time) by the SPPI. Potential usage by
the SPPI of the AGENT- CAPABILITIES macro is for further study.
- SMIの順応定義はいくつかのマクロを定義します: OBJECT-GROUPマクロ、NOTIFICATION-GROUPマクロ、MODULE- COMPLIANCEマクロ、およびエージェント-CAPABILITIESマクロ。 SPPIはその結果、間接的にPRCsの属性の実現の許容できる下界を指定するのにOBJECT-GROUPとMODULE-COMPLIANCEマクロを使用します、PRCs自身の実現の許容できる下界。 NOTIFICATION-GROUPマクロは(このとき、)SPPIによって使用されません。 さらなる研究にはエージェントCAPABILITIESマクロのSPPIによる潜在的用法があります。
2. Structure of this Specification
2. このSpecificationの構造
The SMI is specified in terms of an ASN.1 definition together with descriptive text for each element introduced in that ASN.1 definition. This document specifies the SPPI also via a ASN.1 definition, which is a modified version of the SMI's definition, together with descriptive text for only those elements in the SPPI's ASN.1 definition which have differences from the SMI's. For elements in the ASN.1 definition which have no descriptive text in this specification, the reader is referred to the SMI's descriptive text for that element.
SMIは説明文と共にそのASN.1定義で紹介された各要素にASN.1定義で指定されます。 このドキュメントはASN.1定義を通してもSPPIを指定します、SPPIのASN.1定義におけるSMIのものからの違いを持っているそれらの要素だけのための説明文と共に。定義はSMIの定義の変更されたバージョンです。 ASN.1定義におけるこの仕様に説明文を全く持っていない要素において、読者はその要素についてSMIの説明文を参照されます。
McCloghrie, et al. Standards Track [Page 4] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[4ページ]。
3. Definitions
3. 定義
COPS-PR-SPPI DEFINITIONS ::= BEGIN
PR SPPIを盗んでいる定義:、:= 始まってください。
IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, mgmt
FROM SNMPv2-SMI;
IMPORTS ObjectName、SimpleSyntax、ExtUTCTime、管理FROM SNMPv2-SMI。
-- the root for PIB definitions
-- PIB定義のための根
pib OBJECT IDENTIFIER ::= { mgmt 2 }
pib OBJECT IDENTIFIER:、:= 管理2
-- definitions for PIB modules
-- PIBモジュールのための定義
MODULE-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::=
SubjectPart -- new
"LAST-UPDATED" value(Update ExtUTCTime)
"ORGANIZATION" Text
"CONTACT-INFO" Text
"DESCRIPTION" Text
RevisionPart
モジュールアイデンティティマクロ:、:= タイプ記法を始めてください:、:= SubjectPart--新しい「最終更新日」価値(アップデートExtUTCTime)の「組織」テキスト「コンタクトインフォメーション」テキスト「記述」テキストRevisionPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= 値(値の物の識別子)
SubjectPart ::= -- new
"SUBJECT-CATEGORIES" "{" Categories "}"
-- see IANA Considerations section
Categories ::= -- new
CategoryIDs
| "all"
CategoryIDs ::= -- new
CategoryID
| CategoryIDs "," CategoryID
CategoryID ::= -- new
identifier "(" number ")" -- number is positive
SubjectPart:、:= -- 新しい「受けることがあるカテゴリ」、「「カテゴリ」、」 --IANA問題セクションカテゴリを見てください:、:= -- 新しいCategoryIDs| 「all」のCategoryIDs:、:= -- 新しいCategoryID| 」 「CategoryIDs」、CategoryID CategoryID:、:= -- 「(「数」)」という新しい識別子--数は正です。
RevisionPart ::=
Revisions
| empty
Revisions ::=
Revision
| Revisions Revision
Revision ::=
"REVISION" value(Update ExtUTCTime)
"DESCRIPTION" Text
RevisionPart:、:= 改正| Revisionsを空にしてください:、:= 改正| 改正改正改正:、:= 「改正」価値(アップデートExtUTCTime)の「記述」というテキスト
McCloghrie, et al. Standards Track [Page 5] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[5ページ]。
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- キャラクタは定義されるとして[SMI]テキストで以下を結びます:= 値(IA5String)の終わり
--
--
OBJECT-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
物アイデンティティマクロ:、:= タイプ記法を始めてください:、:= 「状態」状態「記述」テキストReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= 値(値の物の識別子)
Status ::=
"current"
| "deprecated"
| "obsolete"
状態:、:= 「電流」| 「非難されます」。| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- キャラクタは定義されるとして[SMI]テキストで以下を結びます:= 値(IA5String)の終わり
-- syntax of attributes
-- 属性の構文
-- the "base types" defined here are: -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER -- 7 application-defined types: Integer32, IpAddress, Unsigned32, -- TimeTicks, Opaque, Integer64 and Unsigned64
-- ここで定義された「ベースタイプ」は以下の通りです。 -- 3 内蔵のASN.1はタイプします: INTEGER、OCTET STRING、OBJECT IDENTIFIER--7 アプリケーションで定義されたタイプ: Integer32、IpAddress、Unsigned32--TimeTicks、不透明なもの、Integer64、およびUnsigned64
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
ObjectSyntax:、:= CHOICE、簡単なSimpleSyntax
-- note that SEQUENCEs for table and row definitions
-- are not mentioned here...
-- テーブルと列の定義のためのそのSEQUENCEs--ここに言及されないことに注意してください…
application-wide
ApplicationSyntax
}
アプリケーション全体のApplicationSyntax
McCloghrie, et al. Standards Track [Page 6] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[6ページ]。
-- application-wide types
-- アプリケーション全体のタイプ
ApplicationSyntax ::=
CHOICE {
ipAddress-value
IpAddress,
ApplicationSyntax:、:= 特選、ipAddress-値のIpAddress
timeticks-value
TimeTicks,
timeticks-値のTimeTicks
arbitrary-value
Opaque,
任意の値のOpaque
unsigned-integer-value
Unsigned32,
無記名の整数価値のUnsigned32
large-integer-value -- new
Integer64,
大きい整数値--新しいInteger64
large-unsigned-integer-value -- new
Unsigned64
}
大きい無記名の整数値--、新しいUnsigned64
-- the following 5 types are copied from the SMI
-- 以下の5つのタイプがSMIからコピーされます。
-- indistinguishable from INTEGER, but never needs more than
-- 32-bits for a two's complement representation
Integer32 ::=
INTEGER (-2147483648..2147483647)
-- しかし、INTEGER、決して必要性でないのから区別できない以上、--2の補数表現のための32ビットのInteger32:、:= 整数(-2147483648..2147483647)
-- (this is a tagged type for historical reasons)
IpAddress ::=
[APPLICATION 0]
IMPLICIT OCTET STRING (SIZE (4))
-- ******* THIS TYPE DEFINITION IS DEPRECATED *******
-- The IpAddress type represents a 32-bit internet
-- IPv4 address. It is represented as an OctetString
-- of length 4, in network byte-order.
-- Note that the IpAddress type is present for
-- historical reasons. IPv4 and IPv6 addresses should
-- be represented using the INET-ADDRESS-MIB
-- defined in [INETADDR].
-- (これによるタグ付けをされたaが歴史的な理由) IpAddressのために以下をタイプするということです:= [APPLICATION0]IMPLICIT OCTET STRING、(SIZE(4))--*******THIS TYPE DEFINITION IS DEPRECATED*******--IpAddressタイプは32ビットのインターネットを表します--IPv4アドレス。 それはネットワークバイトオーダーにおける長さ4のOctetStringとして表されます。 -- IpAddressタイプが出席している注意--歴史的な理由。 IPv4とIPv6アドレスはそうするべきです--INET-ADDRESS-MIBを使用することで、表されてください--[INETADDR]では、定義されています。
-- an unsigned 32-bit quantity
Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
-- 未署名の32ビットの量のUnsigned32:、:= [アプリケーション2] 暗黙の整数(0..4294967295)
McCloghrie, et al. Standards Track [Page 7] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[7ページ]。
-- hundredths of seconds since an epoch
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)
-- 時代TimeTicks以来の秒の100分の1:、:= [アプリケーション3] 暗黙の整数(0..4294967295)
--for backward compatibility only
Opaque ::=
[APPLICATION 4]
IMPLICIT OCTET STRING
--後方の互換性Opaqueだけのために:、:= [アプリケーション4]内在している八重奏ストリング
-- the following 2 types are not present in the SMI
-- 以下の2つのタイプはSMIに出席していません。
Integer64 ::=
[APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Integer64:、:= [アプリケーション10] 暗黙の整数(-9223372036854775808..9223372036854775807)
Unsigned64 ::=
[APPLICATION 11]
IMPLICIT INTEGER (0..18446744073709551615)
Unsigned64:、:= [アプリケーション11] 暗黙の整数(0..18446744073709551615)
-- definition for Provisioning Classes and their attributes -- (differences from the SMI are noted in the ASN.1 comments)
-- Provisioning Classesのための定義と彼らの属性--(ASN.1コメントでSMIからの違いに注意します)
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
"SYNTAX" Syntax
UnitsPart
"PIB-ACCESS" Access -- modified
PibReferencesPart -- new
PibTagPart -- new
"STATUS" Status
"DESCRIPTION" Text
ErrorsPart -- new
ReferPart
IndexPart -- modified
MibIndexPart -- modified
UniquePart -- new
DefValPart
オブジェクト・タイプマクロ:、:= タイプ記法を始めてください:、:= "SYNTAX"Syntax UnitsPart「PIB-アクセス」アクセス--変更されたPibReferencesPart--新しいPibTagPart--新しい「状態」状態「記述」テキストErrorsPart(新しいReferPart IndexPart)はMibIndexPart--変更されたUniquePart--新しいDefValPartを変更しました。
VALUE NOTATION ::=
value(VALUE ObjectName)
記法を評価してください:、:= 値(値のObjectName)
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement),
-- a textual convention (or its refinement), or
-- a BITS pseudo-type
構文:、:= -- 以下の1つでなければなりません: -- または、ベースタイプ(または、気品)--原文のコンベンション(または、気品)、--、BITS偽型
McCloghrie, et al. Standards Track [Page 8] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[8ページ]。
type
| "BITS" "{" NamedBits "}"
タイプ| 「ビット」、「「NamedBits」、」
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBits:、:= NamedBit| 」 「NamedBits」、NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
NamedBit:、:= 「(「数」)」という識別子--数は非負です。
UnitsPart ::=
"UNITS" Text
| empty
UnitsPart:、:= 「ユニット」というテキスト| 空になってください。
Access ::= -- modified
"install"
| "notify"
| "install-notify"
| "report-only"
以下にアクセスしてください:= -- 「インストールしてください」変更されて、| 「通知してください」| 「インストールで通知してください」| 「レポート専用」
Status ::=
"current"
| "deprecated"
| "obsolete"
状態:、:= 「電流」| 「推奨しないです」。| 「時代遅れです」。
ErrorsPart ::= -- new
"INSTALL-ERRORS" "{" Errors "}"
| empty
ErrorsPart:、:= -- 新しい「インストール誤り」、「「誤り」、」| 空になってください。
Errors ::= -- new
Error
| Errors "," Error
Error ::= -- new
identifier "(" number ")" -- number is positive
誤り:、:= -- 新しいError| 」 「誤り」、誤り誤り:、:= -- 「(「数」)」という新しい識別子--数は正です。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
IndexPart ::=
"PIB-INDEX" "{" Index "}" -- new
| "AUGMENTS" "{" Entry "}"
| "EXTENDS" "{" Entry "}" -- new
| empty
Index ::=
-- the correspondent OBJECT-TYPE invocation
value(ObjectName)
Entry ::=
-- use the INDEX value of the
-- correspondent OBJECT-TYPE invocation
IndexPart:、:= "PIB-INDEX"は新しく「「インデックス」」です。| 「増大する」、「「エントリー」、」| 「EXTENDS」、「「エントリー」、」、新しく。| Indexを空にしてください:、:= -- 通信員OBJECT-TYPE実施の価値(ObjectName)のエントリー:、:= -- INDEX値を使用する、--、通信員OBJECT-TYPE実施
McCloghrie, et al. Standards Track [Page 9] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[9ページ]。
value(ObjectName)
MibIndexPart ::=
"INDEX" "{" IndexTypePart "}"
| empty
IndexTypePart ::=
IndexTypes
| IndexTypes "," ImpliedIndex
| ImpliedIndex
IndexTypes ::=
Index
| IndexTypes "," Index
ImpliedIndex ::=
"IMPLIED" Index
(ObjectName)MibIndexPartを評価してください:、:= 「索引をつけてください」、「"IndexTypePart"、」| IndexTypePartを空にしてください:、:= IndexTypes| 」 「IndexTypes」、ImpliedIndex| ImpliedIndex IndexTypes:、:= インデックス| 」 「IndexTypes」、インデックスImpliedIndex:、:= 「暗示している」インデックス
PibReferencesPart ::=
-- for use with ReferenceId TC
"PIB-REFERENCES" "{" Entry "}"
| empty
PibReferencesPart:、:= -- ReferenceId TC「PIB-参照」との使用、「「エントリー」、」| 空になってください。
PibTagPart ::=
-- for use with TagReferenceId TC
"PIB-TAG" "{" Attr "}"
| empty
PibTagPart:、:= -- TagReferenceId TC「PIB-タグ」との使用、「"Attr"、」| 空になってください。
Attr ::= -- specifies an attribute
value(ObjectName)
Attr:、:= -- 属性値を指定します。(ObjectName)
UniquePart ::= -- new
"UNIQUENESS" "{" UniqueTypes "}"
| "UNIQUENESS" "{" "}"
| empty
UniqueTypes ::=
UniqueType
| UniqueTypes "," UniqueType
UniqueType ::=
-- the correspondent OBJECT-TYPE invocation
value(ObjectName)
UniquePart:、:= -- 新しい「ユニークさ」、「「UniqueTypes」、」| 「ユニークさ」、「「「}」、」| UniqueTypesを空にしてください:、:= UniqueType| 」 「UniqueTypes」、UniqueType UniqueType:、:= -- 通信員OBJECT-TYPE実施の価値(ObjectName)
DefValPart ::= "DEFVAL" "{" Defvalue "}"
| empty
DefValPart:、:= "DEFVAL"、「"Defvalue"、」| 空になってください。
Defvalue ::= -- must be valid for the type specified in
-- SYNTAX clause of same OBJECT-TYPE macro
value(ObjectSyntax)
| "{" BitsValue "}"
Defvalue:、:= -- 中で指定されたタイプにおいて、有効であってください--同じOBJECT-TYPEマクロのSYNTAX節は(ObjectSyntax)を評価しなければなりません。| 「"BitsValue"、」
BitsValue ::= BitNames
BitsValue:、:= BitNames
McCloghrie, et al. Standards Track [Page 10] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[10ページ]。
| empty
| 空になってください。
BitNames ::= BitName
| BitNames "," BitName
BitNames:、:= BitName| 」 「BitNames」、BitName
BitName ::= identifier
BitName:、:= 識別子
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- キャラクタは定義されるとして[SMI]テキストで以下を結びます:= 値(IA5String)の終わり
-- definitions for conformance groups
-- 順応グループのための定義
OBJECT-GROUP MACRO ::=
BEGIN
TYPE NOTATION ::=
ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
オブジェクトグループマクロ:、:= タイプ記法を始めてください:、:= ObjectsPart「状態」状態「記述」テキストReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= 値(値のオブジェクト識別子)
ObjectsPart ::=
"OBJECTS" "{" Objects "}"
Objects ::=
Object
| Objects "," Object
Object ::=
value(ObjectName)
ObjectsPart:、:= 「オブジェクト」が「「反対」」というオブジェクト:、:= オブジェクト| 」 「オブジェクト」、オブジェクトオブジェクト:、:= 値(ObjectName)
Status ::=
"current"
| "deprecated"
| "obsolete"
状態:、:= 「電流」| 「推奨しないです」。| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- キャラクタは定義されるとして[SMI]テキストで以下を結びます:= 値(IA5String)の終わり
-- definitions for compliance statements
-- 承諾声明のための定義
McCloghrie, et al. Standards Track [Page 11] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[11ページ]。
MODULE-COMPLIANCE MACRO ::=
BEGIN
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
ModulePart
モジュールコンプライアンスマクロ:、:= タイプ記法を始めてください:、:= 「状態」状態「記述」テキストReferPart ModulePart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= 値(値のオブジェクト識別子)
Status ::=
"current"
| "deprecated"
| "obsolete"
状態:、:= 「電流」| 「推奨しないです」。| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
ModulePart ::=
Modules
Modules ::=
Module
| Modules Module
Module ::=
-- name of module --
"MODULE" ModuleName
MandatoryPart
CompliancePart
ModulePart:、:= モジュールモジュール:、:= モジュール| モジュールモジュールモジュール:、:= -- モジュールの名前--「モジュール」ModuleName MandatoryPart CompliancePart
ModuleName ::=
-- identifier must start with uppercase letter
identifier ModuleIdentifier
-- must not be empty unless contained
-- in MIB Module
| empty
ModuleIdentifier ::=
value(OBJECT IDENTIFIER)
| empty
ModuleName:、:= -- 識別子は、MIB Moduleで大文字識別子ModuleIdentifier--含まれていない場合空であるはずがないことを始まらなければなりません。| ModuleIdentifierを空にしてください:、:= 値(オブジェクト識別子)| 空になってください。
MandatoryPart ::=
"MANDATORY-GROUPS" "{" Groups "}"
| empty
MandatoryPart:、:= 「義務的なグループ」は「「分類」にされます」。| 空になってください。
Groups ::=
Group
| Groups "," Group
グループ:、:= グループ| 」 「グループ」、グループ
McCloghrie, et al. Standards Track [Page 12] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[12ページ]。
Group ::=
value(OBJECT IDENTIFIER)
以下を分類してください:= 値(オブジェクト識別子)
CompliancePart ::=
Compliances
| empty
CompliancePart:、:= 承諾| 空になってください。
Compliances ::=
Compliance
| Compliances Compliance
Compliance ::=
ComplianceGroup
| Object
コンプライアンス:、:= 承諾| コンプライアンス承諾コンプライアンス:、:= ComplianceGroup| オブジェクト
ComplianceGroup ::=
"GROUP" value(OBJECT IDENTIFIER)
"DESCRIPTION" Text
ComplianceGroup:、:= 「グループ」価値(オブジェクト識別子)の「記述」というテキスト
Object ::=
"OBJECT" value(ObjectName)
InstallSyntaxPart -- modified
AccessPart
"DESCRIPTION" Text
オブジェクト:、:= "OBJECT"価値(ObjectName)のInstallSyntaxPart--変更されたAccessPart「記述」というテキスト
-- must be a refinement for object's SYNTAX clause
InstallSyntaxPart ::= "SYNTAX" Syntax
| empty
-- オブジェクトのSYNTAX節InstallSyntaxPartのための気品でなければなりません:、:= 「構文」構文| 空になってください。
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement),
-- a textual convention (or its refinement), or
-- a BITS pseudo-type
type
| "BITS" "{" NamedBits "}"
構文:、:= -- 以下の1つでなければなりません: -- または、ベースタイプ(または、気品)--原文のコンベンション(または、気品)、--BITS偽型がタイプする| 「ビット」、「「NamedBits」、」
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBits:、:= NamedBit| 」 「NamedBits」、NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
NamedBit:、:= 「(「数」)」という識別子--数は非負です。
AccessPart ::=
"PIB-MIN-ACCESS" Access -- modified
| empty
Access ::= -- modified
"not-accessible"
| "install"
| "notify"
| "install-notify"
AccessPart:、:= 「PIB-MIN-ACCESS」Access--変更されます。| Accessを空にしてください:、:= -- 「アクセスしやすくない」、変更されます。| 「インストールしてください」| 「通知してください」| 「インストールで通知してください」
McCloghrie, et al. Standards Track [Page 13] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[13ページ]。
| "report-only"
| 「レポート専用」
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- キャラクタは定義されるとして[SMI]テキストで以下を結びます:= 値(IA5String)の終わり
-- definition of textual conventions
-- 原文のコンベンションの定義
TEXTUAL-CONVENTION MACRO ::=
BEGIN
TYPE NOTATION ::=
DisplayPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
"SYNTAX" Syntax
原文のコンベンションマクロ:、:= タイプ記法を始めてください:、:= DisplayPart「状態」状態「記述」テキストReferPart「構文」構文
VALUE NOTATION ::=
value(VALUE Syntax) -- adapted ASN.1
記法を評価してください:、:= 値(VALUE Syntax)--適合しているASN.1
DisplayPart ::=
"DISPLAY-HINT" Text
| empty
DisplayPart:、:= 「ディスプレイヒント」というテキスト| 空になってください。
Status ::=
"current"
| "deprecated"
| "obsolete"
状態:、:= 「電流」| 「推奨しないです」。| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
-- a character string as defined in [SMI]
Text ::= value(IA5String)
-- キャラクタは定義されるとして[SMI]テキストで以下を結びます:= 値(IA5String)
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement), or
-- a BITS pseudo-type
type
| "BITS" "{" NamedBits "}"
構文:、:= -- 以下の1つでなければなりません: -- または、ベースタイプ(または、気品)、--BITS偽型がタイプする| 「ビット」、「「NamedBits」、」
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBits:、:= NamedBit| 」 「NamedBits」、NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
NamedBit:、:= 「(「数」)」という識別子--数は非負です。
END
終わり
McCloghrie, et al. Standards Track [Page 14] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[14ページ]。
END
終わり
COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN
PR SPPI Tcを獲得しているPIB-定義:、:= 始まってください。
IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION, pib
FROM COPS-PR-SPPI;
IMPORTS Unsigned32、MODULE-IDENTITY、TEXTUAL-CONVENTION、pib FROM COPS PR SPPI。
copsPrSppiTc MODULE-IDENTITY
SUBJECT-CATEGORIES { all }
LAST-UPDATED "200108160000Z"
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
copsPrSppiTc MODULE-IDENTITY SUBJECT-CATEGORIESすべてのLAST-UPDATED"200108160000Z"組織「IETFラップWG」コンタクトインフォメーション、「キースMcCloghrieシスコシステムズInc.170の西タスマンDrive、サンノゼ、カリフォルニア95134-1706米国は以下に電話をします」。 +1 5260年の408 526メール: kzm@cisco.com
Ravi Sahita
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124 USA
Phone: +1 503 712 1554
Email: ravi.sahita@intel.com "
DESCRIPTION
"The PIB module containing a set of Textual Conventions
which have general applicability to all PIB modules."
REVISION "200108160000Z"
DESCRIPTION
"Initial version, published in RFC 3159."
::= { pib 1 }
第25ラービーSahitaインテル2111Ne Avenueヒースボロー、または97124米国電話: +1 1554年の503 712メール: ravi.sahita@intel.com 、「記述、「すべてのPIBモジュールに一般的な適用性を持っているTextual Conventionsの1セットを含むPIBモジュール。」、」 「初期のバージョンであって、RFC3159で発行された」REVISION"200108160000Z"記述。 ::= pib1
InstanceId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The textual convention for use by an attribute which is used
as the instance-identifying index of a PRC, i.e., an attribute
named in a PIB-INDEX clause. The value of an attribute with
this syntax is always greater than zero. PRIs of the same PRC
need not have contiguous values for their instance-identifying
attribute."
SYNTAX Unsigned32 (1..4294967295)
InstanceId:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「PRCのインスタンスを特定するインデックス、すなわち、PIB-INDEX節で指定された属性として使用される属性による使用のための原文のコンベンション。」 いつもこの構文がある属性の値はゼロ以上です。 「PRCが必要とする同じくらいのPRIsには、それらのインスタンスを特定する属性のための隣接の値がありません。」 構文Unsigned32(1..4294967295)
ReferenceId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A textual convention for use by an attribute which is used as
a pointer in order to reference an instance of a particular
ReferenceId:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「事項のインスタンスに参照をつけるのに指針として使用される属性による使用のための原文のコンベンション」です。
McCloghrie, et al. Standards Track [Page 15] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[15ページ]。
PRC. An attribute with this syntax must not be used in a
PIB-INDEX clause , and its description must specify the
particular PRC to which the referenced PRI will belong.
For an attribute of this type, the referenced PRI must exist.
Furthermore, it is an error to try to delete a PRI that is
referenced by another instance without first deleting/modifying
the referencing instance. The definition of an attribute with
this syntax can permit the attribute to have a value of zero to
indicate that it is not currently pointing to a PRI."
SYNTAX Unsigned32
PRC。 PIB-INDEX節でこの構文がある属性を使用してはいけません、そして、記述は参照をつけられたPRIが属する特定のPRCを指定しなければなりません。 このタイプの属性のために、参照をつけられたPRIは存在しなければなりません。 その上、別のインスタンスによって最初に参照箇所インスタンスを削除するか、または変更しないで参照をつけられるのは、PRIを削除しようとする誤りです。 「この構文による属性の定義は、現在PRIを示していないのを示すためにゼロの値が属性にあることを許可できます。」 構文Unsigned32
Prid ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a pointer to a PRI, i.e,. to an instance of a
PRC. The value is the OID name of the PRC's row definition,
appended with one sub-identifier containing the value of the
InstanceId value for the referenced instance. The definition
of an attribute with this syntax can permit the attribute to
have a value of 0.0 to indicate that it is not currently
pointing to a PRI."
SYNTAX OBJECT IDENTIFIER
Prid:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「PRIへの指針、i.eを表す、PRCのインスタンス、」 値は1つのサブ識別子がInstanceId価値の値を含んでいて参照をつけられたインスタンスのために追加されたPRCの行定義のOID名です。 「この構文による属性の定義は、現在PRIを示していないのを示すために0.0の値が属性にあることを許可できます。」 構文オブジェクト識別子
TagId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a tag value, such that all instances of a
particular PRC having the same tag value form a tag list.
A tag list is identified by the tag value shared by all
instances in that tag list."
SYNTAX Unsigned32 (1..4294967295)
TagId:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「タグ値、同じタグ値を持っている特定のPRCのすべてのインスタンスがタグリストを形成するようなものを表します」。 「タグリストはそのタグリストのすべてのインスタンスによって共有されたタグ値によって特定されます。」 構文Unsigned32(1..4294967295)
TagReferenceId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a reference to a tag list of instances of a
particular PRC. The particular PRC must have an attribute
with the syntax of TagId. The tag list consists of
all instances which have the same value of the TagId
attribute. Reference to the tag list is via the attribute
with the syntax of TagReferenceId containing the tag
value which identifies the tag list.
The definition of an attribute with this syntax can permit
the attribute to have a value of 0 to indicate that it is
not currently referencing a tag list."
SYNTAX Unsigned32
END
TagReferenceId:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「特定のPRCのインスタンスのタグリストの参照を表します」。 特定のPRCには、TagIdの構文がある属性がなければなりません。 タグリストはTagId属性の同じ値を持っているすべてのインスタンスから成ります。 タグリストの参照はTagReferenceIdの構文がタグリストを特定するタグ値を含んでいる属性を使用します。 「この構文による属性の定義は示す0の値を持つそれが現在参照をつけていない属性にタグリストを可能にすることができます。」 構文Unsigned32エンド
McCloghrie, et al. Standards Track [Page 16] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[16ページ]。
4. PIB Modules
4. PIBモジュール
The names of all standard PIB modules must be unique (but different versions of the same module should have the same name). Developers of enterprise PIB modules are encouraged to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules.
すべての標準のPIBモジュールの名前はユニークであるに違いありません(同じモジュールの異なった見解には、同じ名前があるべきです)。 企業PIBモジュールの開発者が標準の、または、他の企業モジュールと衝突するという低い確率を持っているそれらのモジュールのための名前を選ぶよう奨励されます。
The first line of a PIB module is:
PIBモジュールの最初の系列は以下の通りです。
PIB-MODULE-NAME PIB-DEFINITIONS ::= BEGIN
PIBモジュール名のPIB-定義:、:= 始まってください。
where PIB-MODULE-NAME is the module name.
PIB-MODULE-NAMEがモジュール名であるところ。
Like the SMI, additional ASN.1 macros must not be defined in PIB modules.
SMIのように、PIBモジュールで追加ASN.1マクロを定義してはいけません。
4.1. Importing Definitions
4.1. 定義をインポートします。
Like the SMI, a PIB module which needs to reference an external definition, must use the IMPORTS statement to identify both the descriptor and the module in which the descriptor is defined, where a module is identified by its ASN.1 module name.
SMI、参照に外部定義を必要とするPIBモジュールがそうしなければならないようにIMPORTS声明を使用して、記述子が定義される記述子とモジュールの両方を特定してください、モジュールがASN.1モジュール名によって特定されるところで。
In particular, a PIB module imports each of the base data types that it uses from COPS-PR-SPPI (defined in this document), and may import as required from other PIB modules. A PIB module may import, from the SMI, (subtree) OIDs for the purpose of defining new OIDs. A PIB module may also import, from MIB modules, OID assignments as well as textual convention definitions providing that their underlying syntax is supported by the SPPI. However, the following must not be included in an IMPORTS statement:
PIBモジュールは、特に、それがCOPS PR SPPI(本書では定義される)から使用するそれぞれに関するベースデータ型を意味して、必要に応じて他のPIBモジュールから輸入するかもしれません。 PIBモジュールは、新しいOIDsを定義する目的のためにSMIから(下位木)がOIDsであることを意味するかもしれません。 また、それらの基本的な構文がSPPIによってサポートされるなら、PIBモジュールはMIBモジュールからの原文のコンベンション定義と同様にOID課題を意味するかもしれません。 しかしながら、IMPORTS声明に以下を含んではいけません:
- named types defined by ASN.1 itself, specifically: INTEGER, OCTET
STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type,
- ASN.1自身によって明確に定義された命名されたタイプ: INTEGER、OCTET STRING、OBJECT IDENTIFIER、SEQUENCE、SEQUENCE OFはタイプします。
- the BITS construct.
- BITS構造物。
For each ASN.1 macro that a PIB uses, it must import that macro's definition from the COPS-PR-SPPI.
PIBが使用するそれぞれのASN.1マクロのために、それはCOPS PR SPPIからそのマクロの定義をインポートしなければなりません。
McCloghrie, et al. Standards Track [Page 17] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[17ページ]。
4.2. Reserved Keywords
4.2. 予約されたキーワード
In addition to the reserved keywords listed in the SMI, the following must not be used as descriptors or module names:
SMIにリストアップされた予約されたキーワードに加えて、記述子かモジュール名として以下を使用してはいけません:
EXTENDS INSTALL-ERRORS Integer64 PIB-MIN-ACCESS PIB-ACCESS PIB-
INDEX PIB-REFERENCES PIB-TAG SUBJECT-CATEGORIES UNIQUENESS
Unsigned64
誤りをインストールする状態で広がっている、Integer64 PIB分がアクセスする、PIB-アクセスPIBはPIB-参照PIB-タグ受けることがあるカテゴリユニークさのUnsigned64に索引をつけます。
5. Naming Hierarchy
5. 階層構造を命名します。
The SPPI uses the same OBJECT IDENTIFIER naming hierarchy as the SMI. That is, OIDs are typically assigned to PIB modules from the subtree administered by the Internet Assigned Numbers Authority (IANA). However, like the SMI, the SPPI does not prohibit the definition of PRCs in other portions of the OID tree.
SPPIはSMIと同じOBJECT IDENTIFIER命名階層構造を使用します。 すなわち、OIDsはインターネットAssigned民数記Authority(IANA)によって管理された下位木からPIBモジュールに通常割り当てられます。 しかしながら、SMIのように、SPPIはOID木の他の一部とのPRCsの定義を禁止しません。
6. Mapping of the MODULE-IDENTITY macro
6. MODULE-IDENTITYマクロに関するマッピング
6.1. Mapping of the SUBJECT-CATEGORIES clause
6.1. SUBJECT-CATEGORIES節に関するマッピング
The SUBJECT-CATEGORIES clause, which must be present, identifies one or more categories of provisioning data for which this PIB module defines provisioning information. For use with the COPS-PR protocol, the individual subject categories are mapped to COPS Client Types [COPS-PR]. IANA Considerations for SPPI SUBJECT-CATEGORIES follow the same requirements as specified in [COPS] IANA Considerations for COPS Client Types. The subject categories are identified either:
SUBJECT-CATEGORIES節(存在していなければならない)はこのPIBモジュールが食糧を供給する情報を定義する食糧を供給するデータの1つ以上のカテゴリを特定します。 COPS-PRプロトコルによる使用において、個々の対象のカテゴリはCOPS Client Types[COPS-PR]に写像されます。 SPPI SUBJECT-CATEGORIESのためのIANA ConsiderationsはCOPS Client Typesのための[COPS]IANA Considerationsの指定されるのと同じ要件に続きます。 対象のカテゴリは特定されます:
- via the keyword "all", indicating the PIB module defines
provisioning information relevant for all subject categories (and
thus, all COPS Client Types), or
- またはPIBモジュールを示すと「すべて」というキーワードで、すべての対象のカテゴリにおいて、関連している食糧を供給する情報が定義される、(そして、その結果、すべてのCOPS Client Types)。
- a list of named-number enumerations, where each number which must
be greater than zero, identifies a subject category, and is mapped
to the Client Type which is identified by that same number in the
COPS protocol. The namespace for these named numbers is global
and therefore the labels should be assigned consistently across
PIB modules. At present time, no more than one named-number
enumeration should be specified.
- 命名された数の列挙のリスト。((そこでは、議定書を作ります)ゼロ以上でなければならなく、対象のカテゴリを特定して、COPSのその同数によって特定されるClient Typeに写像される各数)。 数というこれらのための名前空間はグローバルです、そして、したがって、ラベルはPIBモジュールの向こう側に一貫して割り当てられるべきです。 現時点に、1つ未満の命名された数の列挙が指定されるべきです。
Note that the list of categories specified in a PIB module's SUBJECT- CATEGORIES clause is not exclusive. That is, some other specification might (e.g., at a future date) specify additional COPS Client Types to which the module is relevant.
PIBモジュールのSUBJECT- CATEGORIES節で指定されたカテゴリのリストが排他的でないことに注意してください。 すなわち、ある他の仕様はモジュールが関連している追加COPS Client Typesを指定するかもしれません(例えば、将来の期日に)。
McCloghrie, et al. Standards Track [Page 18] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[18ページ]。
When a PIB module applies to multiple subject categories, that PIB module exists in multiple virtual information stores, one for each Client-Type. A PIB module with SUBJECT-CATEGORIES "all" uses the named- number specified in the SUBJECT-CATEGORIES of the PIB it is associated with, as the COPS Client-Type when it is sent over COPS.
PIBモジュールが複数の対象のカテゴリに適用されるとき、そのPIBモジュールは複数の仮想情報店(各Client-タイプあたり1つ)に存在しています。 SUBJECT-CATEGORIES「すべて」があるPIBモジュールはCOPSの上にそれを送るときそれがCOPS Client-タイプとして関連しているPIBのSUBJECT-CATEGORIESで指定する命名された数を使用します。
7. Mapping of the OBJECT-TYPE macro
7. OBJECT-TYPEマクロに関するマッピング
The SPPI requires that all attribute definitions be contained within a PRC, i.e., within a table definition.
SPPIは、すべての属性定義がすなわち、PRC、テーブル定義の中に含まれているのを必要とします。
7.1. Mapping of the SYNTAX clause
7.1. SYNTAX節に関するマッピング
The SYNTAX clause, which must be present within the definition of an attribute, defines the abstract data structure of that attribute. The data structure must be one of the following: a base type, the BITS construct, or a textual convention.
SYNTAX節(属性の定義の中に存在していなければならない)はその属性の抽象的なデータ構造を定義します。 データ構造は以下の1つであるに違いありません: ベースタイプ、BITS構造物、または原文のコンベンション。
The SYNTAX clause must also be present for the table and row definitions of a PRC, and in this case must be a SEQUENCE OF or SEQUENCE (see section 8.1.7 below).
この場合、SYNTAX節は、また、PRCのテーブルと行定義のために存在していなければならなくて、SEQUENCE OFかSEQUENCEであるに違いありません(セクション8.1.7未満を見てください)。
The base types are an extended subset of the SMI's base types:
ベースタイプはSMIのベースタイプの拡張部分集合です:
- built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER,
- 内蔵のASN.1はタイプします: 整数、八重奏ストリング、オブジェクト識別子
- application-defined types: Integer32, Unsigned32, TimeTicks,
Integer64 and Unsigned64.
- アプリケーションで定義されたタイプ: Integer32、Unsigned32、TimeTicks、Integer64、およびUnsigned64。
A textual convention is a newly-defined type defined as a sub-type of a base type [TC]. The value of an attribute whose syntax is defined using a textual convention is encoded "on-the-wire" according to the textual convention's underlying base type.
原文のコンベンションはベースタイプ[TC]のサブタイプと定義された新たに定義されたタイプです。 構文が原文のコンベンションを使用することで定義される属性の値はコード化された原文のコンベンションの基本的なベースに従った「ワイヤ」のタイプです。
Note that the set of base types has been chosen so as to provide sufficient variety of on-the-wire encodings for attribute values; base types should contain a minimum of semantics. Semantics should, to the extent possible, be incorporated into a data type through the use of a textual convention.
ベースタイプのセットがワイヤの上のencodingsの十分なバラエティーを属性値に提供するために選ばれたことに注意してください。 ベースタイプは最小意味論を含むべきです。 意味論は原文のコンベンションの使用で可能な範囲内でデータ型に組み入れられるべきです。
The differences from the SMI in the semantics of ObjectSyntax are now described.
ObjectSyntaxの意味論におけるSMIからの違いは現在、説明されます。
7.1.1. Counter32
7.1.1. Counter32
The Counter32 type is not supported by the SPPI.
Counter32タイプはSPPIによってサポートされません。
McCloghrie, et al. Standards Track [Page 19] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[19ページ]。
7.1.2. Gauge32
7.1.2. Gauge32
The Gauge32 type is not supported by the SPPI.
Gauge32タイプはSPPIによってサポートされません。
7.1.3. Opaque
7.1.3. 不透明なもの
The Opaque type is provided solely for backward-compatibility, and shall not be used for newly-defined object types. The Opaque type supports the capability to pass arbitrary ASN.1 syntax. A value is encoded using the ASN.1 Basic Encoding Rules [ASN1] into a string of octets. This, in turn, is encoded as an OCTET STRING, in effect "double-wrapping" the original ASN.1 value. Note that a conforming implementation need only be able to accept and recognize opaquely- encoded data. It need not be able to unwrap the data and then interpret its contents. A requirement on "standard" PIB modules is that no object may have a SYNTAX clause value of Opaque.
Opaqueタイプを唯一後方の互換性に提供されて、新たに定義されたオブジェクト・タイプに使用しないものとします。 Opaqueタイプは任意のASN.1構文を通過する能力をサポートします。 値は、ASN.1Basic Encoding Rules[ASN1]を一連の八重奏に使用することでコード化されます。 事実上、元のASN.1価値を「ダブルで包装し」て、これはOCTET STRINGとして順番にコード化されます。 従う実装が不透明にコード化されたデータを受け入れて、認識できるだけでよいことに注意してください。 それは、データを開けて、次に、コンテンツを解釈できる必要はありません。 「標準」のPIBモジュールに関する要件はどんなオブジェクトにもOpaqueのSYNTAX節価値がないかもしれないということです。
7.1.4. IpAddress
7.1.4. IpAddress
The IpAddress type is provided solely for backward-compatibility, and shall not be used for newly-defined object types. Instead, It is recommended to use the InetAddressType/InetAddress pair TCs as defined in RFC2851 [INETADDR].
IpAddressタイプを唯一後方の互換性に提供されて、新たに定義されたオブジェクト・タイプに使用しないものとします。 代わりに、ItがRFC2851[INETADDR]で定義されるようにInetAddressType/InetAddress組TCsを使用することが勧められます。
7.1.5. Counter64
7.1.5. Counter64
The Counter64 type is not supported by the SPPI.
Counter64タイプはSPPIによってサポートされません。
7.1.6. Integer64
7.1.6. Integer64
The Integer64 type represents integer-valued information between -2^63 and 2^63-1 inclusive (-9223372036854775808 to 9223372036854775807 decimal). While Integer64 may be sub-typed to be more constrained, if the constraint results in all possible values being contained in the range (-2147483648..2147483647), then the Integer32 type must be used instead of Integer64.
Integer64タイプは包括的に(-9223372036854775808〜9223372036854775807小数)2^63と2^63-1の間の整数で評価された情報を表します。 Integer64がさらに抑制されるためにサブタイプされているかもしれない間、規制が範囲(-2147483648 .2147483647)に保管されているすべての可能な値をもたらすなら、Integer64の代わりにInteger32タイプを使用しなければなりません。
7.1.7. Unsigned64
7.1.7. Unsigned64
The Unsigned64 type represents integer-valued information between 0 and 2^64-1 inclusive (0 to 18446744073709551615 decimal). While Unsigned64 may be sub-typed to be more constrained, if the constraint results in all possible values being contained in the range (0..4294967295), then the Unsigned32 type must be used instead of Unsigned64.
Unsigned64タイプは包括的に(0〜18446744073709551615小数)0と2^64-1の間の整数で評価された情報を表します。 Unsigned64がさらに抑制されるためにサブタイプされているかもしれない間、規制が範囲(0 .4294967295)に保管されているすべての可能な値をもたらすなら、Unsigned64の代わりにUnsigned32タイプを使用しなければなりません。
McCloghrie, et al. Standards Track [Page 20] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[20ページ]。
7.1.8. Provisioning Classes
7.1.8. クラスに食糧を供給します。
The operations (on PIBs) supported by the SPPI apply exclusively to PRCs. Each PRC is modelled as a tabular structure, i.e., a table. Each instance of a particular PRC has the same set of attributes. The set of attributes which belong to every instance of a particular PRC is modelled as a row in the table. Note that a PRC must have no more than 127 attributes. The usage of subids (for PRC attributes) beyond 127 (that is 128 and above) is reserved for Mapping PIBs to MIBs (see Appendix A). PRCs that require more than 127 attributes must use the AUGMENTS clause to augment the PRC containing the initial 127 attributes to add additional attributes. Definition of Provisioning Classes is formalized by using the OBJECT-TYPE macro to define both:
SPPIによってサポートされた操作(PIBsの)は排他的にPRCsに適用されます。 各PRCはすなわち、表構造、テーブルとしてモデル化されます。 特定のPRCの各インスタンスには、同じセットの属性があります。 特定のPRCのあらゆるインスタンスに属す属性のセットはテーブルの行としてモデル化されます。 PRCには127未満の属性がなければならないことに注意してください。 127(それは128以上である)を超えたsubids(PRC属性のための)の使用法はMapping PIBsのためにMIBsに予約されます(Appendix Aを見てください)。 127以上の属性を必要とするPRCsは、追加属性を加えるために初期の127の属性を含むPRCを増大させるのにAUGMENTS節を使用しなければなりません。 Provisioning Classesの定義は両方を定義するのにOBJECT-TYPEマクロを使用することによって、正式にされます:
- the PRC as a whole, called the table definition, and
- そして全体でテーブル定義と呼ばれるPRC。
- the characteristics of every instance of a particular PRC, called
the row definition.
- 行定義と呼ばれる特定のPRCのあらゆるインスタンスの特性。
In the table definition, the SYNTAX clause has the form:
テーブル定義では、SYNTAX節はフォームを持っています:
SEQUENCE OF <EntryType>
<EntryType>の系列
where <EntryType> refers to the SEQUENCE type of its attribute definitions. In the row definition, the SYNTAX clause has the form:
<EntryType>が属性定義のSEQUENCEタイプを差し向けるところ。 行定義では、SYNTAX節はフォームを持っています:
<EntryType>
<EntryType>。
where <EntryType> is a SEQUENCE type defined as follows:
<EntryType>が以下の通り定義されたSEQUENCEタイプであるところ:
<EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }
<EntryType>:、:= 系列<type1>、…、<typeN>。
where there is one <type> for each attribute, and each <type> is of the form:
1<があるところでは、各属性のために>をタイプしてください。そうすれば、それぞれの<タイプ>はフォームのものです:
<descriptor> <syntax>
<記述子><構文>。
where <descriptor> is the descriptor naming an attribute, and <syntax> has the value of that attribute's SYNTAX clause, except that both sub- typing information and the named values for enumerated integers or the named bits for the BITS construct, are omitted from <syntax>.
<記述子>が属性、および<構文を>と命名する記述子であるところでは、ともにそんなにサブタイプしている情報と列挙された整数のための命名された値かBITS構造物のための命名されたビットを除いて、その属性のSYNTAX節の値が<構文>から省略されましたか?
7.2. Mapping of the MAX-ACCESS clause
7.2. マックス-ACCESS節に関するマッピング
The MAX-ACCESS clause is not supported by the SPPI.
マックス-ACCESS節はSPPIによってサポートされません。
McCloghrie, et al. Standards Track [Page 21] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[21ページ]。
7.3. Mapping of the PIB-ACCESS clause
7.3. PIB-ACCESS節に関するマッピング
The PIB-ACCESS clause must be present for a PRC's table definition, and must not be present for any other OBJECT-TYPE definition. The PIB-ACCESS clause defines what kind of access is appropriate for the PRC.
PIB-ACCESS節は、PRCのテーブル定義のために存在していなければならなくて、いかなる他のOBJECT-TYPE定義のためにも存在しているはずがありません。 PIB-ACCESS節は、PRCに、どういうアクセスが適切であるかを定義します。
- the value "install" is used to indicate a PRC which a PDP can
install in the PEP as provisioning information.
- 値の「インストール」は、PDPが情報に食糧を供給するとしてPEPにインストールできるPRCを示すのに使用されます。
- the value "notify" is used to indicate a PRC for which the PEP
must notify the PDP of all its instances and attribute values of
that PRC.
- 値の「通知」は、PEPがそのPRCのすべてのインスタンスと属性値についてPDPに通知しなければならないPRCを示すのに使用されます。
- the value "install-notify" is used to indicate the uncommon type
of PRC which has both characteristics: "install" and "notify".
- 「インストールで通知してください」が使用されている値は両方の特性を持っているPRCの珍しいタイプを示します: 「インストールしてください」と「通知してください。」
- the value "report-only" is used to indicate a PRC which has
neither the "install" characteristic nor the "notify"
characteristic. However, instances of such a PRC may be included
in synchronous/asynchronous reports generated by the PEP. (Note:
PRCs having the "install" and/or "notify" characteristics may also
be included in reports generated by the PEP.)
- 値の「レポート専用」は、「インストールしてください」という特性も「通知してください」という特性も持っていないPRCを示すのに使用されます。 しかしながら、そのようなPRCのインスタンスはPEPによって作られた同時の、または、非同期なレポートに含まれるかもしれません。 (注意: また、「インストールしてください」、そして/または、「通知してください」特性を持っているPRCsはPEPによって作られたレポートに含まれるかもしれません。)
7.4. Mapping of the INSTALL-ERRORS clause
7.4. INSTALL-ERRORS節に関するマッピング
The INSTALL-ERRORS clause, which may optionally be present for a PRC's table definition, and must be absent otherwise, lists one or more potential reasons for rejecting an install or a removal of an instance of the PRC. Each reason consists of a named-number enumeration, where the number represents a PRC-specific error-code to be used in a COPS protocol message, as the Error Sub-code, with the Error-Code set to priSpecificError (see [COPS-PR]). The semantics of each named-number enumeration should be described in the PRC's DESCRIPTION clause.
INSTALL-ERRORS節(PRCのテーブル定義のために任意に存在しているかもしれなくてそうでなければ欠けているに違いない)はPRCのインスタンスのインストールか取り外しを拒絶する1つ以上の潜在的理由をリストアップします。 各理由は命名された数の列挙から成ります、数がCOPSプロトコルメッセージで使用されるためにPRC特有のエラーコードを表すところで、Error Sub-コードとして、priSpecificErrorへのError-コードセットで([COPS-PR]を見てください)。 それぞれの命名された数の列挙の意味論はPRCの記述節で説明されるべきです。
The numbers listed in an INSTALL-ERRORS must be greater than zero and less than 65536. If this clause is not present, an install/remove can still fail, but no PRC-specific error is available to be reported.
INSTALL-ERRORSに記載された数はゼロと65536未満より大きいに違いありません。 この節がプレゼント、インストール/が取り外されるということでないなら、やり損ないにもかかわらず、PRC特有の誤りがないのが利用可能であるスチール写真を報告できますか?
7.5. Mapping of the PIB-INDEX clause
7.5. PIB-INDEX節に関するマッピング
The PIB-INDEX clause, which must be present for a row definition (unless an AUGMENTS or an EXTENDS clause is present instead), and must be absent otherwise, defines identification information for instances of the PRC.
PIB-INDEX節(行定義(AUGMENTSかEXTENDS節が代わりに存在していない場合)のために存在していなければならなくてそうでなければ欠けているに違いない)はPRCのインスタンスのための識別情報を定義します。
McCloghrie, et al. Standards Track [Page 22] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[22ページ]。
The PIB-INDEX clause includes exactly one descriptor. This descriptor specifies an attribute (typically, but not necessarily of the same PRC) which is used to identify an instance of that PRC. The syntax of this attribute is REQUIRED to be InstanceId (a textual convention with an underlying syntax of Unsigned32), and it has no semantics other than its use in identifying the PRC instance. The OBJECT IDENTIFIER which identifies an instance of a PRC is formed by appending one sub- identifier to the OID which identifies that PRC's row definition. The value of the additional sub-identifier is that instance's value of the attribute specified in the INDEX clause.
PIB-INDEX節はまさに1つの記述子を含んでいます。 この記述子はそのPRCの例を特定するのに使用される属性(必ずないのにもかかわらずの、通常、同じPRCの)を指定します。 この属性の構文はInstanceId(Unsigned32の基本的な構文がある原文のコンベンション)であるREQUIREDです、そして、それには、PRC例を特定することにおける使用以外の意味論が全くありません。 PRCの例を特定するOBJECT IDENTIFIERは、そのPRCの列の定義を特定するOIDに1つのサブ識別子を追加することによって、形成されます。 追加サブ識別子の値はその例のINDEX節で指定された属性の値です。
Note that SPPI does not permit use of the IMPLIED keyword in a PIB- INDEX clause.
SPPIがPIB- INDEX節におけるIMPLIEDキーワードの使用を可能にしないことに注意してください。
7.6. Mapping of the INDEX clause
7.6. INDEX節に関するマッピング
The INDEX clause is optionally present if a PIB-INDEX clause is present, and must be absent otherwise. If present, the INDEX clause can contain any number of attributes, and is used only by the algorithmic conversion of a PIB to a MIB (see Appendix A).
存在していて、そうでなければ、PIB-INDEX節が欠けるに違いないなら、INDEX節は任意に存在しています。 存在しているなら、INDEX節は、いろいろな属性を含むことができて、単にPIBのアルゴリズムの変換でMIBに使用されます(Appendix Aを見てください)。
An IMPLIED keyword can be present in an INDEX clause if so desired.
そう望まれているなら、IMPLIEDキーワードはINDEX節に存在している場合があります。
7.7. Mapping of the AUGMENTS clause
7.7. AUGMENTS節に関するマッピング
The AUGMENTS clause, which must not be present except in row definitions, is an alternative to the PIB-INDEX clause and the EXTENDS clause. Every row definition has exactly one of: a PIB-INDEX clause, an AUGMENTS clause, or an EXTENDS clause.
AUGMENTS節(列の定義を除いて、存在しているはずがない)はPIB-INDEX節とEXTENDS節への代替手段です。 あらゆる列の定義には、ちょうど1つがあります: PIB-INDEX節、AUGMENTS節、またはEXTENDS節。
A row definition which has a PIB-INDEX clause is called a base row definition. A row definition which has an AUGMENTS clause is called a row augmentation, where the AUGMENTS clause names the base row definition which is augmented by this row augmentation. (Thus, a row augmentation cannot itself be augmented.)
PIB-INDEX節を持っている列の定義はベース列の定義と呼ばれます。 AUGMENTS節を持っている列の定義は列の増大と呼ばれます、AUGMENTS節がこの列増大するベース列の定義を増大と命名するところで。 (その結果、列の増大がそうすることができない、それ自体、増大してください、)
A PRC whose row definition is a row augmentation is called an augmenting PRC. Instances of an augmenting PRC are identified according to the PIB-INDEX clause of the base row definition named in the AUGMENTS clause. Further, instances of an augmenting PRC exist according to the same semantics as instances of the PRC which it augments. As such, when an instance of a PRC is installed or removed, an instance of every PRC which augments it is also installed or removed. (for more details, see [COPS-PR]).
列の定義が列の増大であるPRCは増大PRCと呼ばれます。 AUGMENTS節で指定されたベース列の定義のPIB-INDEX節によると、増大PRCの例は特定されます。 さらに、それが増大させるPRCの例と同じ意味論によると、増大PRCの例は存在しています。 PRCの例をインストールするか、または取り除くとき、そういうものとして、それを増大させるあらゆるPRCの例をまた、インストールするか、または取り除きます。 (その他の詳細に関して、[COPS-PR]を見てください。)
McCloghrie, et al. Standards Track [Page 23] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[23ページ]。
7.8. Mapping of the EXTENDS clause
7.8. EXTENDS節に関するマッピング
The EXTENDS clause, which must not be present except in row definitions, is an alternative to the PIB-INDEX clause and the AUGMENTS clause. Every row definition has exactly one of: a PIB- INDEX clause, an AUGMENTS clause, or an EXTENDS clause.
EXTENDS節(列の定義を除いて、存在しているはずがない)はPIB-INDEX節とAUGMENTS節への代替手段です。 あらゆる列の定義には、ちょうど1つがあります: PIB- INDEX節、AUGMENTS節、またはEXTENDS節。
A row definition which has an EXTENDS clause is called a sparse row augmentation, where the EXTENDS clause names the row definition which is sparsely-augmented by this sparse row augmentation. The sparsely- augmented row can be a base row definition, or another sparse row augmentation.
EXTENDS節を持っている列の定義はまばらな列の増大と呼ばれます、EXTENDS節がこのまばらな列によってまばらに増大している列の定義を増大と命名するところで。 まばらに増大している列は、ベース列の定義、または別のまばらな列の増大であるかもしれません。
A PRC whose row definition is a sparse row augmentation is called a sparsely augmenting PRC. Instances of a sparsely augmenting PRC are identified according to the PIB-INDEX clause of the row definition named in the sparsely augmenting PRC's EXTENDS clause.
列の定義がまばらな列の増大であるPRCはまばらに増大しているPRCと呼ばれます。 まばらに増大しているPRCのEXTENDS節で指定された列の定義のPIB-INDEX節によると、まばらに増大しているPRCの例は特定されます。
An instance of a sparsely augmenting PRC can not exist unless a corresponding instance of the PRC which it sparsely augments exists. As such, when an instance of a PRC is removed, an instance of any PRC which sparsely augments it is also removed. However, an instance of a sparsely augmenting PRC need not exist when the corresponding instance of the PRC that it sparsely augments exists. Thus, an instance of a sparsely augmenting PRC can be installed at the same time as or subsequent to the installation of, and can be removed prior to the removal of, the corresponding instance of the PRC that it sparsely augments. So, instances of a sparsely augmenting PRC must be installed explicitly, but are removed either implicitly (via removal of the augmented PRI) or explicitly. When a sparsely augmented PRC is installed, both instances, the instance of the sparsely augmented PRC and the instance of the sparsely augmenting PRC must be sent in one COPS message.
それがまばらに増大させるPRCの対応する例が存在していない場合、まばらに増大しているPRCの例は存在できません。 また、そういうものとして、PRCの例を取り除くとき、それをまばらに増大させるどんなPRCの例も取り除きます。 しかしながら、それがまばらに増大させるPRCの対応する例が存在するとき、まばらに増大しているPRCの例は存在する必要はありません。 その結果、まばらに増大しているPRCの例をインストールにインストールされているか、またはその後である場合があり、取り除くことができる前、取り外し、それがまばらに増大させるPRCの対応する例。 それで、明らかにまばらに増大しているPRCの例を明らかにインストールしなければなりませんが、それとなく取り除きます(増大しているPRIの解任で)。 まばらに増大しているPRCをインストールするとき、1つのCOPSメッセージで両方の例、まばらに増大しているPRCの例、およびまばらに増大しているPRCの例を送らなければなりません。
7.8.1. Relation between PIB-INDEX, AUGMENTS and EXTENDS clauses
7.8.1. PIB-INDEXと、AUGMENTSとEXTENDS節との関係
When defining instance identification information for a PRC:
PRCのための例の識別情報を定義するとき:
- If there is a one-to-one correspondence between instances of this
PRC and instances of an existing PRC, then the AUGMENTS clause
should be used.
- このPRCの例と既存のPRCの例との1〜1つの通信があれば、AUGMENTS節は使用されるべきです。
- Otherwise, if there is a sparse relationship between instances of
this PRC and instances of an existing PRC (that is, there is a one
to zero or one correspondence between instances of a sparsely
augmented PRC and the instances of the PRC that sparsely augments
it.), then an EXTENDS clause should be used.
- さもなければ、このPRCの例と既存のPRCの例とのまばらな関係があれば(すなわち、まばらに増大しているPRCの例とそれをまばらに増大させるPRCの例との1対ゼロか1つの通信があります。)、EXTENDS節は使用されるべきです。
McCloghrie, et al. Standards Track [Page 24] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[24ページ]。
- Otherwise, a PIB-INDEX clause should be used which names its own
InstanceId attribute.
- さもなければ、それ自身のInstanceId属性を命名するPIB-INDEX節は使用されるべきです。
7.9. Mapping of the UNIQUENESS clause
7.9. UNIQUENESS節に関するマッピング
The UNIQUENESS clause, which is optionally present for any row definition, lists a set of zero or more of the PRC's attributes, for which no two instances of the PRC can have the same set of values. The specified set of attributes provide a necessary and sufficient set of values by which to identify an instance of this PRC. The attribute contained in the PIB-INDEX clause may not be present in the UNIQUENESS clause. By definition, an attribute may not appear more than once in a UNIQUENESS clause. A UNIQUENESS clause containing zero attributes indicates that it's possible for two instances of the PRC to have identical values for all attributes except, of course, for the one named in the PIB-INDEX clause.
UNIQUENESS節(どんな列の定義のためにも任意に存在している)は1セットのゼロかPRCの属性の以上を記載します。そのノーのために、PRCの2つの例が同じセットの値を持つことができます。 指定されたセットの属性はこのPRCの例を特定する必要で十分な値を提供します。 PIB-INDEX節に含まれた属性はUNIQUENESS節に存在していないかもしれません。 定義上、属性はUNIQUENESS節で一度より多く見えないかもしれません。 属性を全く含まないUNIQUENESS節は、PRCの2つの例にはもちろん命名されるのを除いたものにちなんでPIB-INDEX節のすべての属性のための同じ値があるのが、可能であることを示します。
If a PRC and its sparsely augmenting PRC both have UNIQUENESS clauses, then the UNIQUENESS constraint for instances of each PRC MUST be applied according to the UNIQUENESS clause in the corresponding PRC definition. Note that a sparsely augmenting PRC thus can override the UNIQUENESS clause of the PRC it sparsely augments.
PRCとPRCのそのまばらに増大している両方であるなら、対応するPRC定義におけるUNIQUENESS節によると、UNIQUENESS節、次にそれぞれのPRC MUSTの例のUNIQUENESS規制は適用されましたか? その結果、まばらに増大しているPRCがそれがまばらに増大させるPRCのUNIQUENESS節に優越できることに注意してください。
Even though the UNIQUENESS clause is optional, its inclusion is recommended wherever it provides useful information.
UNIQUENESS節は任意ですが、役に立つ情報をどこに提供しても、包含はお勧めです。
7.10. Mapping of the PIB-REFERENCES clause
7.10. PIB-REFERENCES節に関するマッピング
The PIB-REFERENCES clause, which must be present for any attribute which has the SYNTAX of ReferenceId, and must be absent otherwise, names the PRC, an instance of which is referenced by the ReferenceId attribute. For example usages of the PIB-REFERENCES clause, see Appendix B.
PIB-REFERENCES節(ReferenceIdのSYNTAXを持っているどんな属性のためにも存在していなければならなくてそうでなければ欠けているに違いない)はPRCを命名します。その例はReferenceId属性によって参照をつけられます。 例えば、用法、PIB-REFERENCES節では、Appendix Bを見てください。
7.11. Mapping of the PIB-TAG clause
7.11. PIB-TAG節に関するマッピング
The PIB-TAG clause, which must be present for an attribute which has the SYNTAX TagReferenceId, and must be absent otherwise, is used to indicate that this attribute references a "tag list" of instances of another PRC. Such a tag list (similar in concept to the usage of the same term in [APPL]) is formed by all instances of the other PRC which have the same (tag) value of a particular attribute of that other PRC. The particular attribute of the other PRC, which must have the SYNTAX TagId, is named in the PIB-TAG clause. For an example usage of the PIB-TAG clause, see Appendix B.
PIB-TAG節(SYNTAX TagReferenceIdを持っている属性のために存在していなければならなくてそうでなければ欠けているに違いない)は、これが「タグリスト」という別のPRCの例の参照を結果と考えるのを示すのに使用されます。 そのようなタグリスト(概念で[APPL]の同じ用語の語法と同様の)はその他のPRCの特定の属性の同じ(タグ)値を持っているもう片方のPRCのすべての例によって形成されます。 もう片方のPRCの特定の属性はPIB-TAG節で命名されます。(PRCはSYNTAX TagIdを持たなければなりません)。 PIB-TAG節の例の用法に関しては、Appendix Bを見てください。
McCloghrie, et al. Standards Track [Page 25] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[25ページ]。
8. Mapping of the OBJECT-IDENTITY macro
8. OBJECT-IDENTITYマクロに関するマッピング
The OBJECT-IDENTITY macro is used in PIB modules to define information about an OBJECT IDENTIFIER assignment.
OBJECT-IDENTITYマクロは、OBJECT IDENTIFIER課題の情報を定義するのにPIBモジュールで使用されます。
9. Mapping of the OBJECT-GROUP macro
9. OBJECT-GROUPマクロに関するマッピング
For conformance purposes, it is useful to define a conformance group as a collection of related PRCs and their attributes. The OBJECT- GROUP macro (directly) defines the collection of attributes which belong to a conformance group. Since each attribute included in the collection belongs to a PRC, the collection of related PRCs which belong to a conformance group is also specified (indirectly) as the set of PRCs to which the included attributes belong.
順応目的に、関連するPRCsと彼らの属性の収集と順応グループを定義するのは役に立ちます。 OBJECT- GROUPマクロは(直接)順応グループに属す属性の収集を定義します。 収集に含まれていた各属性がPRCに属すので、また、順応グループのもの関連するPRCsの収集は(間接的に)含まれている属性が属するPRCsのセットとして指定されます。
9.1. Mapping of the OBJECTS clause
9.1. OBJECTS節に関するマッピング
The OBJECTS clause, which must be present, is used to specify each attribute contained in the conformance group. Each of the specified attributes must be defined in the same PIB module as the OBJECT-GROUP macro appears.
OBJECTS節(存在していなければならない)は、順応グループに含まれた各属性を指定するのに使用されます。 OBJECT-GROUPマクロは同じPIBモジュールで定義されているように見えますが、それぞれの指定された属性はそうであるに違いありません。
It is required that every attribute defined in a PIB module be contained in at least one conformance group. This avoids the common error of adding a new attribute to a module and forgetting to add the new attribute to a group.
PIBモジュールで定義されたあらゆる属性が少なくとも1つの順応グループに含まれているのが必要です。 これは新しい属性をモジュールに追加して、新しい属性をグループに追加するのを忘れる一般的な誤りを避けます。
10. Mapping of the MODULE-COMPLIANCE macro
10. MODULE-COMPLIANCEマクロに関するマッピング
The MODULE-COMPLIANCE macro is used to convey a minimum set of requirements with respect to implementation of one or more PIB modules.
MODULE-COMPLIANCEマクロは、1つ以上のPIBモジュールの実現に関して最小のセットの要件を伝えるのに使用されます。
A requirement on all "standard" PIB modules is that a corresponding MODULE-COMPLIANCE specification is also defined, either in the same module or in a companion module.
すべての「標準」のPIBモジュールに関する要件はまた、対応するMODULE-COMPLIANCE仕様が同じモジュールか仲間モジュールで定義されるということです。
10.1. Mapping of the MODULE clause
10.1. MODULE節に関するマッピング
The MODULE clause, which must be present, is repeatedly used to name each PIB module for which compliance requirements are being specified. Each PIB module is named by its module name, and optionally, by its associated OBJECT IDENTIFIER as well. The module name can be omitted when the MODULE-COMPLIANCE invocation occurs inside a PIB module, to refer to the encompassing PIB module.
MODULE節(存在していなければならない)は、承諾要件が指定されているそれぞれのPIBモジュールを命名するのに繰り返して使用されます。 それぞれのPIBモジュールはモジュール名によってまた、関連OBJECT IDENTIFIERによって任意に命名されます。 MODULE-COMPLIANCE実施が取り囲んでいるPIBモジュールを示すためにPIBモジュールで起こるとき、モジュール名を省略できます。
McCloghrie, et al. Standards Track [Page 26] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[26ページ]。
10.1.1. Mapping of the MANDATORY-GROUPS clause
10.1.1. MANDATORY-GROUPS節に関するマッピング
The MANDATORY-GROUPS clause, which need not be present, names the one or more conformance groups within the correspondent PIB module which are unconditionally mandatory for implementation. If an agent claims compliance to the PIB module, then it must implement each and every attribute (and therefore the PRCs to which they belong) within each conformance group listed.
MANDATORY-GROUPS節(存在している必要はない)は通信員PIBモジュールの中の1つ以上の無条件に実現に義務的な順応グループを命名します。 エージェントがPIBモジュールにコンプライアンスを要求するなら、それぞれを実行しなければなりません、そして、それぞれの順応グループの中のあらゆる属性(そして、したがって、彼らが属するPRCs)が記載しました。
10.1.2. Mapping of the GROUP clause
10.1.2. GROUP節に関するマッピング
The GROUP clause, which need not be present, is repeatedly used to name each conformance group which is conditionally mandatory for compliance to the PIB module. The GROUP clause can also be used to name unconditionally optional groups. A group named in a GROUP clause must be absent from the correspondent MANDATORY-GROUPS clause.
GROUP節(存在している必要はない)は、それぞれの条件付きに承諾に義務的な順応グループをPIBモジュールと命名するのに繰り返して使用されます。 また、無条件に任意のグループを命名するのにGROUP節を使用できます。 GROUP節で指定されたグループは通信員MANDATORY-GROUPS節から欠けているに違いありません。
Conditionally mandatory groups include those which are mandatory only if a particular protocol is implemented, or only if another group is implemented. A GROUP clause's DESCRIPTION specifies the conditions under which the group is conditionally mandatory.
条件付きに義務的なグループは特定のプロトコルが単に実行されるか、または別のグループが実行される場合にだけ義務的なものを含んでいます。 GROUP節の記述はグループが条件付きに義務的である状態を指定します。
A group which is named in neither a MANDATORY-GROUPS clause nor a GROUP clause, is unconditionally optional for compliance to the PIB module.
承諾には、どちらもMANDATORY-GROUPS節かGROUP節で命名されるグループはPIBモジュールに無条件に任意です。
10.1.3. Mapping of the OBJECT clause
10.1.3. OBJECT節に関するマッピング
The OBJECT clause, which need not be present, is repeatedly used to specify each attribute for which compliance has a refined requirement with respect to the PIB module definition. The attribute must be present in one of the conformance groups named in the correspondent MANDATORY-GROUPS clause or GROUP clauses.
OBJECT節(存在している必要はない)は、PIBモジュール定義に関して承諾には洗練された要件がある各属性を指定するのに繰り返して使用されます。 属性は通信員MANDATORY-GROUPS節かGROUP節で指定された順応グループの1つで存在していなければなりません。
By definition, each attribute specified in an OBJECT clause follows a MODULE clause which names the PIB module in which that attribute is defined. Therefore, the use of an IMPORTS statement, to specify from where such attributes are imported, is redundant and is not required in a PIB module.
定義上、OBJECT節で指定された各属性はその属性が定義されるPIBモジュールを命名するMODULE節に従います。 したがって、IMPORTS声明の使用、どこからそのような属性を指定するかは、輸入されていて、余分であり、PIBモジュールで必要ではありません。
10.1.3.1. Mapping of the SYNTAX clause
10.1.3.1. SYNTAX節に関するマッピング
The SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the attribute named in the correspondent OBJECT clause. The refined syntax is the minimum level of support needed for this attribute in order to be compliant.
SYNTAX節(存在している必要はない)は、通信員OBJECT節で指定された属性に洗練されたSYNTAXを提供するのに使用されます。 洗練された構文は言いなりになるのにこの属性に必要である最小のサポート水準です。
McCloghrie, et al. Standards Track [Page 27] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[27ページ]。
10.1.3.2. Mapping of the WRITE-SYNTAX clause
10.1.3.2. WRITE-SYNTAX節に関するマッピング
The WRITE-SYNTAX clause is not supported by the SPPI.
WRITE-SYNTAX節はSPPIによってサポートされません。
10.1.3.3. Mapping of the PIB-MIN-ACCESS clause
10.1.3.3. PIB-MIN-ACCESS節に関するマッピング
The PIB-MIN-ACCESS clause, which need not be present, is used to define the minimal level of access for the attribute named in the correspondent OBJECT clause. If this clause is absent, the minimal level of access is the same as the maximal level specified in the PIB-ACCESS clause of the correspondent invocation of the OBJECT-TYPE macro. If present, this clause must specify a subset of the access specified in the correspondent PIB-ACCESS clause, where: "install" is a subset of "install-notify", "notify" is a subset of "install- notify", and "not- accessible" is a subset of all other values.
PIB-MIN-ACCESS節(存在している必要はない)は、通信員OBJECT節で指定された属性のために最小量のアクセスのレベルを定義するのに使用されます。 この節が欠けるなら、最小量のアクセスのレベルは最大限度のレベルがOBJECT-TYPEマクロの通信員実施のPIB-ACCESS節で指定したのと同じです。 存在しているなら、この節は通信員PIB-ACCESS節で指定されたアクセス、どこに関する部分集合を指定しなければならないか: そして、「インストールしてください」が「インストールで通知してください」の部分集合である、「通知してください」が「インストールに通知する」部分集合である、「-、アクセスしやすさ、」 もう一方が評価するすべてが部分集合がありますか?
An implementation is compliant if the level of access it provides is the same or a superset of the minimal level in the MODULE-COMPLIANCE macro and the same or a subset of the maximal level in the PIB-ACCESS clause.
実現はそれが提供するアクセスのレベルがMODULE-COMPLIANCEマクロと同じくらいの最小量のレベルの同じくらいかスーパーセットかPIB-ACCESS節の最大限度のレベルの部分集合であるなら対応します。
11. Textual Conventions
11. 原文のコンベンション
When designing a PIB module, it is often useful to define new data types similar to those defined in the SPPI. In comparison to a type defined in the SPPI, each of these new types has a different name, a similar syntax, and specific semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading the PIB module.
PIBモジュールを設計するとき、SPPIで定義されたものと同様の新しいデータ型を定義するのはしばしば役に立ちます。 SPPIで定義されたタイプとの比較では、これらの新しいタイプ各人は異なった名前、同様の構文、および特定の意味論を持っています。 これらの新たに定義されたタイプは、原文のコンベンションと呼ばれて、PIBモジュールを読んでいる人間の都合のために使用されます。
Attributes defined using a textual convention are always encoded by means of the rules that define their underlying type.
原文のコンベンションを使用することで定義された属性は彼らの基底型を定義する規則によっていつもコード化されます。
11.1. Mapping of the TEXTUAL-CONVENTION macro
11.1. TEXTUAL-CONVENTIONマクロに関するマッピング
The TEXTUAL-CONVENTION macro is used to convey the syntax and semantics associated with a textual convention. It should be noted that the expansion of the TEXTUAL-CONVENTION macro is something which conceptually happens during implementation and not during run-time.
TEXTUAL-CONVENTIONマクロは、原文のコンベンションに関連している構文と意味論を伝えるのに使用されます。 TEXTUAL-CONVENTIONマクロの拡大がランタイムの間、起こるのではなく、実現の間に概念的に起こる何かであることに注意されるべきです。
The name of a textual convention must consist of one or more letters or digits, with the initial character being an upper case letter. The name must not conflict with any of the reserved words listed in section 5.2, should not consist of all upper case letters, and shall not exceed 64 characters in length. (However, names longer than 32 characters are not recommended.) The hyphen is not allowed in the name of a textual convention (except for use in information modules
原文のコンベンションの名前は1手紙かケタ以上から成らなければなりません、大文字アルファベットである初期のキャラクタで。 名前は、セクション5.2で記載されているリザーブドワードのどれかと闘争してはいけなくて、すべての大文字アルファベットから成るべきでなくて、長さで64のキャラクタを超えていないものとします。 (しかしながら、32のキャラクタより長い名前は推薦されません。) ハイフンが原文のコンベンションの名にかけて許されていない、(情報モジュールにおける使用
McCloghrie, et al. Standards Track [Page 28] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[28ページ]。
converted from SMIv1 which allowed hyphens in ASN.1 type assignments). Further, all names used for the textual conventions defined in all "standard" PIB modules shall be unique.
変換、SMIv1からのASN.1タイプ課題におけるそれの許容ハイフン) さらに、すべての「標準」のPIBモジュールで定義された原文のコンベンションに使用されるすべての名前がユニークになるでしょう。
11.1.1. Mapping of the DISPLAY-HINT clause
11.1.1. DISPLAY-ヒント節に関するマッピング
The DISPLAY-HINT clause, which need not be present, gives a hint as to how the value of an instance of an object with the syntax defined using this textual convention might be displayed. The DISPLAY-HINT clause must not be present if the Textual Convention is defined with a syntax of: OBJECT IDENTIFIER, or any enumerated syntax (BITS or INTEGER). The determination of whether it makes sense for other syntax types is dependent on the specific definition of the Textual Convention.
DISPLAY-ヒント節(存在している必要はない)はどう構文が定義されているこの原文のコンベンションを使用するオブジェクトのインスタンスの値を表示するかもしれないかに関してちょっとほのめかします。 Textual Conventionが以下の構文で定義されるなら、DISPLAY-ヒント節は存在しているはずがありません。 OBJECT IDENTIFIER、またはどんな列挙された構文(BITSかINTEGER)。 他の構文タイプのために理解できるかどうかに関する決断はTextual Conventionの特定の定義に依存しています。
The rules for the format specification of the hint are the same as specified in Section 3.1 of [TC].
ヒントの書式仕様のための規則は[TC]のセクション3.1で指定されるのと同じです。
11.1.2. Mapping of the SYNTAX clause
11.1.2. SYNTAX節に関するマッピング
The SYNTAX clause, which must be present, defines abstract data structure corresponding to the textual convention. The data structure must be one of the following: a base type (see the SYNTAX clause of an OBJECT-TYPE macro), or the BITS construct. Note that this means that the SYNTAX clause of a Textual Convention can not refer to a previously defined Textual Convention.
SYNTAX節(存在していなければならない)は原文のコンベンションに対応する抽象的なデータ構造を定義します。 データ構造は以下の1つであるに違いありません: ベースタイプ(OBJECT-TYPEマクロのSYNTAX節を見る)、またはBITS構造物。 これが、Textual ConventionのSYNTAX節が以前に定義されたTextual Conventionについて言及できないことを意味することに注意してください。
11.1.2.1. Sub-typing of Textual Conventions
11.1.2.1. 原文のコンベンションのサブタイプ
The SYNTAX clause of a TEXTUAL CONVENTION macro may be sub-typed in the same way as the SYNTAX clause of an OBJECT-TYPE macro.
OBJECT-TYPEマクロのSYNTAX節と同様に、TEXTUAL CONVENTIONマクロのSYNTAX節はサブタイプされているかもしれません。
12. Extending a PIB Module
12. PIBモジュールを広げています。
PIBs may be revised as implementation experience is gained. However, changes with potential to cause disruption to interoperability between the previous PIB and the revised PIB are not allowed.
実装経験をするのに従って、PIBsは改訂されるかもしれません。 しかしながら、前のPIBと改訂されたPIBの間の相互運用性の分裂を引き起こす可能性がある変化は許容されていません。
12.1. PIB Modules
12.1. PIBモジュール
For any change, the invocation of the MODULE-IDENTITY macro must be updated to include information about the revision: specifically, updating the LAST-UPDATED clause, adding a pair of REVISION and DESCRIPTION clauses, and making any necessary changes to existing clauses, including the ORGANIZATION and CONTACT-INFO clauses.
どんな変化に関してはも、改正の情報を含むようにMODULE-IDENTITYマクロの実施をアップデートしなければなりません: 明確に、LAST-UPDATED節をアップデートして、1組のREVISIONと記述節を加えて、いずれも必要にするのは既存の節に変化します、ORGANIZATIONとCONTACT-INFO節を含んでいて。
McCloghrie, et al. Standards Track [Page 29] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[29ページ]。
Note that any definition contained in an existing PIB is available to be IMPORT-ed by any other PIB, and is referenced in an IMPORTS clause via the PIB module name. Thus, a PIB module name should not be changed. Definitions should not be moved from one PIB to another.
既存のPIBに含まれたどんな定義もいかなる他のPIBによるIMPORT-教育にもなるように利用可能であり、PIBモジュール名でIMPORTS節で参照をつけられることに注意してください。 したがって、PIBモジュール名を変えるべきではありません。 1PIBから別のPIBまで定義を動かすべきではありません。
Also note that obsolete definitions must not be removed from PIB modules since their descriptors may still be referenced by other PIB modules, and the OBJECT IDENTIFIERs used to name them must never be re-assigned. The EXTENDS/AUGMENTS clause should be used to extend previous definitions depending on the information to be represented.
また、他のPIBモジュールでそれらの記述子がまだ参照をつけられているかもしれないのでPIBモジュールから時代遅れの定義を取り除いてはいけなくて、彼らを命名するのに使用されるOBJECT IDENTIFIERsを決して再選任してはいけないことに注意してください。 EXTENDS/AUGMENTS節は、表現する情報による前の定義を広げるのに使用されるべきです。
Changes to an existing PIB can be made in several ways:
いくつかの方法で既存のPIBへの変更を行うことができます:
- Additional PRCs can be added to a PIB or an existing one
deprecated.
- PIBか既存のものに推奨しない状態で追加PRCsを加えることができます。
- Attributes can be added to, or deprecated from, an existing PRC.
Note that an ASN.1 value of the correct type or an ASN.1 NULL
value must be sent even for deprecated attributes to maintain
interoperability. New attributes must be added in sequence after
the existing ones.
- 属性に加えることができる、または、推奨しない、既存のPRC。 推奨しない属性が相互運用性を維持するのさえ正しいタイプのASN.1値かASN.1NULL価値を送らなければならないことに注意してください。 既存のものの連続して後に新しい属性を加えなければなりません。
- An existing PRC can be extended or augmented with a new PRC
defined in another (perhaps enterprise specific) PIB.
- 既存のPRCを広げているか、または新しいPRCが別の(恐らく企業特有)のPIBで定義されている状態で、増大させることができます。
Additional named-number enumerations may be added to a SUBJECT- CATEGORIES clause.
追加命名された数の列挙はSUBJECT- CATEGORIES節に追加されるかもしれません。
12.2. Object Assignments
12.2. オブジェクト課題
If any non-editorial change is made to any clause of a object assignment, then the OBJECT IDENTIFIER value associated with that object assignment must also be changed, along with its associated descriptor. Note that the max subid for PRC attributes is 127 (See Section 7.1.8)
また、何か非社説変更をオブジェクト課題のどんな節にもするなら、そのオブジェクト課題に関連しているOBJECT IDENTIFIER値を変えなければなりません、関連記述子と共に。 PRC属性のための最大subidが127であることに注意してください。(セクション7.1.8を見ます)
12.3. Object Definitions
12.3. オブジェクト定義
An object definition may be revised in any of the following ways:
オブジェクト定義は以下の方法のどれかに改訂されるかもしれません:
- A SYNTAX clause containing an enumerated INTEGER may have new
enumerations added or existing labels changed. Similarly, named
bits may be added or existing labels changed for the BITS
construct.
- 列挙されたINTEGERを含むSYNTAX節で新しい列挙を加えるかもしれませんか、または既存のラベルは変化しました。 同様に、ビットと命名されているのは、BITS構造物のために変えられた加えられたか既存のラベルであるかもしれません。
McCloghrie, et al. Standards Track [Page 30] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[30ページ]。
- The value of a SYNTAX clause may be replaced by a textual
convention, providing the textual convention is defined to use the
same primitive ASN.1 type, has the same set of values, and has
identical semantics.
- SYNTAX節の値を原文のコンベンションに取り替えるかもしれません、原文のコンベンションが同じ原始のASN.1タイプを使用するために定義されて、同じセットの値を持っていて、同じ意味論を持っているなら。
- A UNITS clause may be added.
- UNITS節は加えられるかもしれません。
- A STATUS clause value of "current" may be revised as "deprecated"
or "obsolete". Similarly, a STATUS clause value of "deprecated"
may be revised as "obsolete". When making such a change, the
DESCRIPTION clause should be updated to explain the rationale.
- 「電流」のSTATUS節価値は「推奨しない」か「時代遅れ」として改訂されるかもしれません。 同様に、「推奨しないこと」のSTATUS節価値は「時代遅れ」として改訂されるかもしれません。 そのような変更を行うとき、原理について説明するために記述節をアップデートするべきです。
- Clarifications and additional information may be included in the
DESCRIPTION clause.
- 明確化と追加情報は記述節に含まれるかもしれません。
- An INSTALL-ERRORS clause may be added or an existing INSTALL-
ERRORS clause have additional errors defined.
- INSTALL-ERRORS節が加えられるかもしれませんか、または既存のINSTALL- ERRORS節には定義された追加誤りがあります。
- A REFERENCE clause may be added or updated.
- REFERENCE節を加えるか、またはアップデートするかもしれません。
- A DEFVAL clause may be added or updated.
- DEFVAL節を加えるか、またはアップデートするかもしれません。
- A PRC may be augmented by adding new objects at the end of the
row, and making the corresponding update to the SEQUENCE
definition.
- PRCは、行の終わりで新しいオブジェクトを加えて、対応するアップデートをSEQUENCE定義にすることによって、増大するかもしれません。
- Entirely new objects may be defined, named with previously
unassigned OBJECT IDENTIFIER values.
- 完全に新しいオブジェクトは、以前に割り当てられなかったOBJECT IDENTIFIER値で、定義されて、命名されているかもしれません。
Otherwise, if the semantics of any previously defined object are changed (i.e., if a non-editorial change is made to any clause other than those specifically allowed above), then the OBJECT IDENTIFIER value associated with that object must also be changed. Note that changing the descriptor associated with an existing object is considered a semantic change, as these strings may be used in an IMPORTS statement.
さもなければ、また、どんな以前に定義されたオブジェクトの意味論も変えるなら(すなわち、非社説変更を上に明確に許容されたもの以外のどんな節にもするなら)、そのオブジェクトに関連しているOBJECT IDENTIFIER値を変えなければなりません。 既存のオブジェクトに関連している記述子を変えるのが意味変化であると考えられることに注意してください、これらのストリングがIMPORTS声明で使用されるとき。
McCloghrie, et al. Standards Track [Page 31] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[31ページ]。
Appendix A: Mapping a PIB to a MIB
付録A: PIBをMIBに写像します。
Since the SPPI is modelled on the SMI, a PIB can be potentially algorithmically mapped into a MIB. This mapping is achieved by means of the following rules:
SMIがSPPIに似せられるので、潜在的にalgorithmicallyにPIBをMIBに写像できます。 このマッピングは以下の規則によって達成されます:
- Modify the module's module name by appending "-MIB" to the name.
- "-MIB"を名前に追加することによって、モジュールのモジュール名を変更してください。
- Change the OID assigned to the MODULE-IDENTITY to be different
value.
- 異価になるようにMODULE-IDENTITYに割り当てられたOIDを変えてください。
- Replace the keyword PIB-DEFINITIONS with the keyword DEFINITIONS.
- キーワードPIB-DEFINITIONSをキーワードDEFINITIONSに取り替えてください。
- Modify the module names of all external references to PIB modules
by appending "-MIB" to each such module name.
- そのようなそれぞれのモジュール名に"-MIB"を追加することによって、すべての外部参照のモジュール名をPIBモジュールに変更してください。
- For each PRC definition, if an INDEX clause is absent, change the
"PIB-INDEX" keyword to "INDEX"; otherwise, delete the PIB-INDEX
clause.
- それぞれのPRC定義単位で、INDEX節が欠けるなら、「索引をつける」ために「PIB-インデックス」キーワードを変えてください。 さもなければ、PIB-INDEX節を削除してください。
- Delete all of the following clauses: PIB-ACCESS, PIB-REFERENCES,
PIB-TAG, UNIQUENESS, INSTALL-ERRORS, and SUBJECT-CATEGORIES.
- 以下の節のすべてを削除してください: PIB-アクセス、PIB-参照、PIB-タグ、誤りをインストールしていて、受けることがあるカテゴリのユニークさ。
- Change all PIB-MIN-ACCESS clauses to MIN-ACCESS clauses, modifying
"install" and "install-notify" to "read-create", and "notify" to
"read-only".
- 「インストールしてください」と「書き込み禁止」に「読書して作成し」て、「通知する」「インストールで通知してください」を変更して、すべてのPIB-MIN-ACCESS節をMIN-ACCESS節に変えてください。
- Add a MAX-ACCESS clause for each OBJECT-TYPE. For each table
definition and row definition, the MAX-ACCESS is "not-accessible".
For each attribute that is in the INDEX clause, the MAX-ACCESS is
"not-accessible". For the remaining attributes, the MAX-ACCESS is
"read-create".
- 各OBJECT-TYPEのためのマックス-ACCESS節を加えてください。 それぞれのテーブル定義と行定義において、マックス-ACCESSは「アクセスしやすくはありません」。 INDEX節にある各属性において、マックス-ACCESSは「アクセスしやすくはありません」。 マックス-ACCESSは残っている属性のための、そうです。「読書して作成します」。
- Add a columnar attribute of type RowStatus with a descriptor and
appropriate DESCRIPTION. The descriptor can be formed by
appending the nine characters "RowStatus" to the end of the PRC's
descriptor (truncated if necessary to avoid the resulting
descriptor being too long). A Subid beyond 127 (i.e., 128 and
above) can be used as the OID for this columnar attribute.
- 記述子と適切な記述でタイプRowStatusの円柱状の属性を加えてください。 PRCの記述子(必要なら、長過ぎる結果として起こる記述子を避けるために、先端を切られる)の終わりに9キャラクタ「RowStatus」を追加することによって、記述子を形成できます。 この円柱状の属性にOIDとして127(すなわち、128以上)を超えたSubidを使用できます。
- Modify any SYNTAX clause which has a base data type which is not
allowed in the SMI, either to be a valid SMI data type or to omit
the OBJECT-TYPE or TEXTUAL-CONVENTION definition and all
references to it. Since it is not clear (at this time) which is
the best SMI data type to use, the conversion SHOULD provide a
configurable option allowing a choice from at least the following:
- それのSMIに許容されていないベースデータ型を持っているどんなSYNTAX節か有効なSMIデータ型であるかOBJECT-TYPEを省略するどちらかかTEXTUAL-CONVENTION定義とすべての参照も変更してください。 どれが使用する中で最も良いSMIデータ型であるかが(このとき)明確でないので、変換SHOULDは少なくとも以下から選択を許す構成可能なオプションを提供します:
McCloghrie, et al. Standards Track [Page 32] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[32ページ]。
- convert to an OCTET STRING of the relevant size. Specifically,
this option would map both Integer64 and Unsigned64 to OCTET
STRING (SIZE(8)), or
- 関連サイズのOCTET STRINGに変えてください。 または明確に、このオプションがInteger64とUnsigned64の両方をOCTET STRINGに写像するだろう、(SIZE(8))。
- omit them from the conversion, or
- または変換からそれらを省略してください。
- map Integer64 and Unsigned64 to Counter64 (even though this has
problems representing negative numbers, and unwanted counter
semantics.)
- Counter64への地図Integer64とUnsigned64(これには、負数、および求められていないカウンタ意味論を表すことにおける問題がありますが。)
Appendix B: Example usage of PIB-REFERENCES and PIB-TAG clauses
付録B: PIB-REFERENCESとPIB-TAG節の例の用法
The following example demonstrates the use of the PIB-REFERENCES and PIB-TAG clauses.
以下の例はPIB-REFERENCESとPIB-TAG節の使用を示します。
In this example, the PIB-REFERENCES clause is used by the qosIfDscpMapQueue attribute to indicate the PRC of which it references an instance, and similarly, by the qosIfDscpMapThresh attribute.
この例では、PIB-REFERENCES節はqosIfDscpMapQueue属性によって使用されて、それが同様にインスタンスに参照をつけるPRCを示します、qosIfDscpMapThresh属性で。
The qosIfDscpMapTable PRC has an instance for each DSCP of a particular "map", but there is no PRC defined for a map itself; rather, a map consists of all instances of qosIfDscpMapTable which have the same value of qosIfDscpMapMapId. That is, a tag list is formed by all instances of qosIfDscpMapTable which have the same value of qosIfDscpMapMapId. This tag list is referenced by the attribute qosIfDscpAssignDscpMap, and its use of the PIB-TAG clause indicates this.
qosIfDscpMapTable PRCには、特定の「地図」の各DSCPのためのインスタンスがありますが、地図自体のために定義されたPRCが全くありません。 むしろ、地図はqosIfDscpMapMapIdの同じ値を持っているqosIfDscpMapTableのすべてのインスタンスから成ります。 すなわち、タグリストはqosIfDscpMapMapIdの同じ値を持っているqosIfDscpMapTableのすべてのインスタンスによって形成されます。 このタグリストは属性qosIfDscpAssignDscpMapによって参照をつけられます、そして、PIB-TAG節の使用はこれを示します。
qosIfDscpAssignTable OBJECT-TYPE
SYNTAX SEQUENCE OF QosIfDscpAssignEntry
PIB-ACCESS install
STATUS current
DESCRIPTION " "
::= { qosIfParameters 9 }
qosIfDscpAssignTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfDscpAssignEntry PIB-ACCESSがSTATUSの現在の記述をインストールする、「「:、:、」= qosIfParameters9
qosIfDscpAssignEntry OBJECT-TYPE
SYNTAX QosIfDscpAssignEntry
STATUS current
DESCRIPTION
"An instance of the qosIfDscpAssign class."
PIB-INDEX { qosIfDscpAssignPrid }
UNIQUENESS { qosIfDscpAssignName, qosIfDscpAssignRoles }
::= { qosIfDscpAssignTable 1 }
「qosIfDscpAssignのインスタンスは分類する」qosIfDscpAssignEntry OBJECT-TYPE SYNTAX QosIfDscpAssignEntry STATUSの現在の記述。 PIB-インデックスqosIfDscpAssignPrid、ユニークさ、qosIfDscpAssignName、qosIfDscpAssignRoles:、:= qosIfDscpAssignTable1
QosIfDscpAssignEntry ::= SEQUENCE {
qosIfDscpAssignPrid InstanceId,
qosIfDscpAssignName SnmpAdminString,
QosIfDscpAssignEntry:、:= 系列、qosIfDscpAssignPrid InstanceId、qosIfDscpAssignName SnmpAdminString
McCloghrie, et al. Standards Track [Page 33] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[33ページ]。
qosIfDscpAssignRoles RoleCombination,
qosIfDscpAssignDscpMap TagReferenceId
}
qosIfDscpAssignRoles RoleCombination、qosIfDscpAssignDscpMap TagReferenceId
qosIfDscpAssignDscpMap OBJECT-TYPE
SYNTAX TagReferenceId
PIB-TAG { qosIfDscpMapMapId } -- attribute defined below
STATUS current
DESCRIPTION
"The DSCP map which is applied to interfaces of type
qosIfDscpAssignName which have a role combination of
qosIfDscpAssignRoles."
::= { qosIfDscpAssignEntry 3 }
qosIfDscpAssignDscpMap OBJECT-TYPE SYNTAX TagReferenceId PIB-TAG qosIfDscpMapMapId--属性はSTATUSの現在の記述の下で「qosIfDscpAssignRolesの役割の組み合わせを持っているタイプqosIfDscpAssignNameのインタフェースに付けられるDSCP地図」を定義しました。 ::= qosIfDscpAssignEntry3
-- -- DSCP to Queue and Threshold Mapping Table --
-- -- 列を作るDSCPと敷居マッピングテーブル--
qosIfDscpMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF QosIfDscpMapEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"Assigns DSCP values to queues and thresholds for an arbitrary
DSCP map. This map can then be assigned to various interface
and role combination pairs."
::= { qosIfParameters 10 }
qosIfDscpMapTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfDscpMapEntry PIB-ACCESSは「任意のDSCPのためのDSCPが待ち行列に評価する案配と敷居は写像する」STATUSの現在の記述をインストールします。 「そして、様々なインタフェースと役割の組み合わせ組にこの地図を配属できます。」 ::= qosIfParameters10
qosIfDscpMapEntry OBJECT-TYPE
SYNTAX QosIfDscpMapEntry
STATUS current
DESCRIPTION
"An instance of the qosIfDscpMap class."
PIB-INDEX { qosIfDscpMapPrid }
UNIQUENESS { qosIfDscpMapMapId, qosIfDscpMapDscp }
::= { qosIfDscpMapTable 1 }
「qosIfDscpMapのインスタンスは分類する」qosIfDscpMapEntry OBJECT-TYPE SYNTAX QosIfDscpMapEntry STATUSの現在の記述。 PIB-インデックスqosIfDscpMapPrid、ユニークさ、qosIfDscpMapMapId、qosIfDscpMapDscp:、:= qosIfDscpMapTable1
QosIfDscpMapEntry ::= SEQUENCE {
qosIfDscpMapPrid InstanceId,
qosIfDscpMapMapId TagId,
qosIfDscpMapDscp Dscp,
qosIfDscpMapQueue ReferenceId,
qosIfDscpMapThresh ReferenceId
}
QosIfDscpMapEntry:、:= 系列qosIfDscpMapPrid InstanceId、qosIfDscpMapMapId TagId、qosIfDscpMapDscp Dscp、qosIfDscpMapQueue ReferenceId、qosIfDscpMapThresh ReferenceId
qosIfDscpMapMapId OBJECT-TYPE
SYNTAX TagId
STATUS current
qosIfDscpMapMapId OBJECT-TYPE SYNTAX TagId STATUS海流
McCloghrie, et al. Standards Track [Page 34] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[34ページ]。
DESCRIPTION
"An integer that identifies the DSCP map to which this PRI
belongs."
::= { qosIfDscpMapEntry 2 }
記述、「このPRIが属するDSCP地図を特定する整数。」 ::= qosIfDscpMapEntry2
qosIfDscpMapQueue OBJECT-TYPE
SYNTAX ReferenceId
PIB-REFERENCES { qosIfQueueEntry }
STATUS current
DESCRIPTION
"This attribute maps the DSCP specified by qosIfDscpMapDscp to
the queue identified by qosIfQueuePrid in qosIfQueueTable.
For a given DSCP map, all the queues must belong to a single
queue set."
::= { qosIfDscpMapEntry 4 }
qosIfDscpMapQueue OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES qosIfQueueEntry、STATUSの現在の記述、「この属性はqosIfDscpMapDscpによってqosIfQueueTableでqosIfQueuePridによって特定された待ち行列に指定されたDSCPを写像します」。 「与えられたDSCP地図のために、すべての待ち行列がただ一つの待ち行列セットに属さなければなりません。」 ::= qosIfDscpMapEntry4
qosIfDscpMapThresh OBJECT-TYPE
SYNTAX ReferenceId
PIB-REFERENCES { qosIfThresholdEntry }
STATUS current
DESCRIPTION
"This attribute maps the DSCP specified by qosIfDscpMapDscp to
the threshold identified by qosIfThresholdId in
qosIfThresholdTable. The threshold set to which this
threshold belongs must be assigned to the queue specified by
qosIfDscpMapQueue."
::= { qosIfDscpMapEntry 5 }
qosIfDscpMapThresh OBJECT-TYPE SYNTAX ReferenceId PIB-REFERENCES qosIfThresholdEntry、STATUSの現在の記述、「この属性はqosIfDscpMapDscpによってqosIfThresholdTableでqosIfThresholdIdによって特定された敷居に指定されたDSCPを写像します」。 「この敷居が属する敷居セットをqosIfDscpMapQueueによって指定された待ち行列に割り当てなければなりません。」 ::= qosIfDscpMapEntry5
Security Considerations
セキュリティ問題
This document defines a language with which to define provisioning information. The language itself has no security impact on the Internet.
このドキュメントは食糧を供給する情報を定義する言語を定義します。 言語自体はインターネットにセキュリティ影響力を全く持っていません。
IANA Considerations
IANA問題
The root of the subtree administered by the Internet Assigned Numbers Authority (IANA) for the Internet is:
インターネットAssigned民数記Authority(IANA)によってインターネットに管理された下位木の根本は以下の通りです。
internet OBJECT IDENTIFIER ::= { iso 3 6 1 }
インターネットOBJECT IDENTIFIER:、:= iso3 6 1
That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix:
すなわち、OBJECT IDENTIFIERsのインターネット下位木は接頭語から始まります:
1.3.6.1.
1.3.6.1.
Several branches underneath this subtree are used for network management:
この下位木の下におけるいくつかのブランチがネットワークマネージメントに使用されます:
McCloghrie, et al. Standards Track [Page 35] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[35ページ]。
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
管理OBJECT IDENTIFIER:、:= インターネット2の実験的なOBJECT IDENTIFIER:、:= インターネット3の個人的なOBJECT IDENTIFIER:、:= インターネット4企業OBJECT IDENTIFIER:、:= 個人的な1
The mgmt(2) subtree is used to identify "standard" objects.
管理(2)下位木は、「標準」のオブジェクトを特定するのに使用されます。
This document defines
このドキュメントは定義します。
pib OBJECT IDENTIFIER ::= { mgmt 2 }
pib OBJECT IDENTIFIER:、:= 管理2
as the root for PIBs defined to be carried over [COPS-PR]. This Object Identifier is a high level assignment that needs to be registered with [IANA]. Root Object Identifiers for future "standards track" PIBs will also need to be registered and MUST use Object Identifiers below this oid. A standards track PIB can only be assigned an OID by IANA if the PIB is approved by the IESG as a "standards track" document. Experimental and enterprise PIBs MUST be defined under the "experimental" and "enterprises" Object Identifiers respectively.
持ち越されるために定義されたPIBs[COPS-PR]のための根として。 このObject Identifierはともに記名される必要がある高い平らな課題[IANA]です。 将来の「標準化過程」PIBsのための根のObject Identifiersはまた、登録されるのが必要であり、このoidの下のObject Identifiersを使用しなければなりません。 「規格道」が記録するようにPIBがIESGによって承認される場合にだけ、IANAは標準化過程PIBにOIDを割り当てることができます。 「実験的」、そして、「企業」Object Identifiersの下でそれぞれ実験的、そして、企業PIBsを定義しなければなりません。
The PIB module "copsPrSppiTc" is defined in this document as a standard module and hence, needs a subid assignment under the "pib" oid from IANA.
PIBモジュール"copsPrSppiTc"は本書では標準のモジュールと定義されます、そして、したがって、必要性aは"pib"oidの下でIANAから課題をsubidします。
SPPI SUBJECT-CATEGORIES are mapped to COPS Client Types. IANA Considerations for SUBJECT-CATEGORIES follow the same requirements as specified in [COPS] IANA Considerations for COPS Client Types. Thus, a new PIB can define a new COPS Client Type in the "standards", "experimental" or "enterprise" space, and when approved that would mean that a new COPS Client Type gets assigned. IANA must update the registry for COPS Client Types (where applicable as described in [COPS] IANA Considerations) as a result.
SPPI SUBJECT-CATEGORIESはCOPS Client Typesに写像されます。 SUBJECT-CATEGORIESのためのIANA ConsiderationsはCOPS Client Typesのための[COPS]IANA Considerationsの指定されるのと同じ要件に続きます。 したがって、新しいPIBは「規格」における新しいCOPS Client Type、「実験的」か「企業」スペースを定義できます、そして、承認されると、それは新しいCOPS Client Typeが割り当てられることを意味するでしょう。 IANAはその結果、COPS Client Types([COPS]IANA Considerationsの説明されるとして適切などこ)のために登録をアップデートしなければならないか。
McCloghrie, et al. Standards Track [Page 36] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[36ページ]。
Authors' Addresses
作者のアドレス
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
Michael Fine Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
マイケルFine Inc.170の西タスマン・Driveシスコシステムズカリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 527 8218 EMail: mfine@cisco.com
以下に電話をしてください。 +1 8218年の408 527メール: mfine@cisco.com
John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054 USA
ジョンSeligsonノーテルはInc.4401グレート・アメリカParkwayカリフォルニア95054サンタクララ(米国)をネットワークでつなぎます。
Phone: +1 408 495 2992 EMail: jseligso@nortelnetworks.com
以下に電話をしてください。 +1 2992年の408 495メール: jseligso@nortelnetworks.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
Scott Hahn Intel 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
McCloghrie, et al. Standards Track [Page 37] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[37ページ]。
Ravi Sahita Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
ラービーSahitaインテル2111NE第25Avenueヒースボロー、または97124米国
Phone: +1 503 712 1554 EMail: ravi.sahita@intel.com
以下に電話をしてください。 +1 1554年の503 712メール: ravi.sahita@intel.com
Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119 USA
アンドリュー・スミスAllegroは6399サンイグナシオAveをネットワークでつなぎます。 サンノゼ、カリフォルニア95119米国
Fax: +1 415 345 1827 EMail: andrew@allegronetworks.com
Fax: +1 1827年の415 345メール: andrew@allegronetworks.com
Francis Reichmeyer PFN Inc. University Park at MIT 26 Landsdowne Street Cambridge, MA 02139 USA
MIT26Landsdowne通りMA02139ケンブリッジ(米国)のフランシスReichmeyer PFN株式会社ユニヴァーシティー・パーク
Phone: +1 617 494 9980 EMail: franr@pfn.com
以下に電話をしてください。 +1 9980年の617 494メール: franr@pfn.com
References
参照
[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-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S.,
Rajan, R. and A. Sastry, " COPS usage for
RSVP", RFC 2749, January 2000.
[COPS-RSVP]ボイルとJ.、コーエンとR.とダラムとD.とハーツォグとS.とRajanとR.とA.Sastry、「RSVPのためのCOPS用法」RFC2749(2000年1月)。
[COPS-PR] Reichmeyer, F., Herzog, S., Chan, K., Durham,
D., Yavatkar, R., Gai, S., McCloghrie, K. and
A. Smith, "COPS Usage for Policy Provisioning",
RFC 3084, March 2001.
[PRを獲得します]のReichmeyer(F.、ハーツォグ、S.、チェン、K.、ダラム、D.、Yavatkar、R.、ガイ、S.、McCloghrie、K.、およびA.スミス)は「方針の食糧を供給する用法を獲得します」、RFC3084、2001年3月。
[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.
[SMI]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
McCloghrie, et al. Standards Track [Page 38] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[38ページ]。
[TC] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[Tc]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[CONF] McCloghrie, K., Perkins, D., Schoenwaelder, J.,
Case, J., Rose, M. and S. Waldbusser,
"Conformance Statements for SMIv2", STD 58, RFC
2580, April 1999.
[CONF] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP
Applications", RFC 2573, April 1999.
[APPL] レビとD.とマイヤーとP.とB.スチュワート、「SNMPアプリケーション」、RFC2573、1999年4月。
[ASN1] Information processing systems -- Open Systems
Interconnection -- Specification of Abstract
Syntax Notation One (ASN.1), International
Organization for Standardization.
International Standard 8824, December 1987.
[ASN1]情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 1987年12月の国際規格8824。
[INETADDR] Daniele, M., Haberman, B., Routhier, S. and J.
Schoenwaelder "Textual Conventions for Internet
Network Addresses", RFC 2851, June 2000.
[INETADDR]ダニエル、M.、ハーバーマン、B.、Routhier、S.、およびJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」、RFC2851、6月2000日
[IANA] http://www.isi.edu/in-notes/iana/assignments/smi-numbers
[IANA] http://www.isi.edu/in-notes/iana/assignments/smi-numbers
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998.
[IANA-問題]Alvestrand、H.、およびT.Narten、「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
McCloghrie, et al. Standards Track [Page 39] RFC 3159 SPPI August 2001
McCloghrie、他 規格はSPPI2001年8月にRFC3159を追跡します[39ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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機能のための基金は現在、インターネット協会によって提供されます。
McCloghrie, et al. Standards Track [Page 40]
McCloghrie、他 標準化過程[40ページ]
一覧
スポンサーリンク
