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
Structure of Policy Provisioning Information (SPPI)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書は、ポリシープロビジョニング情報の構造（SPPI）は、ポリシー情報ベース（PIB）モジュールを作成するために使用管理情報のSNMPの構造（SMI）の適応サブセットを定義します。
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.
RFC 2748は、COPSプロトコルを定義し、RFC 2749には、COPSプロトコルはRSVPのために政策決定のアウトソーシングを提供するために使用される方法について説明します。ポリシーのプロビジョニングのためのCOPSプロトコルの別の使用は、このプロビジョニングモデルではRFC 3084.に導入され、ポリシー情報は、仮想情報ストアに存在する（のPRI）プロビジョニングクラス（位相応答曲線）とプロビジョニング・インスタンスのコレクションとして見られます、ポリシー情報ベース（PIB）と呼ばれます。関連プロビジョニングクラスのコレクションは、PIBモジュールで定義されています。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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
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
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モジュールはASN.1データ定義言語[ASN1]の適合サブセットを使用するSNMPのSMIとMIBモジュールに基づいています。このフォーマットにPIBモジュールの定義をベースにするという決定は、コミュニティの知識、経験及びSMIとMIBモジュールのツールを活用することができます。
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などの記述子を持つタイプと同様に、スカラーと柱状オブジェクト型の両方を使用しています。 COPSプロトコルオブジェクトとの混同を避けるためにSPPIは、用語「オブジェクト」を使用していません。代わりに、行定義のインスタンス化のため、SPPI（それぞれxxxTableとxxxEntryオブジェクト）テーブルと行定義の用語プロビジョニングクラス（PRC）を使用して、プロビジョニング・インスタンス（PRI）。テーブル定義の円柱状のオブジェクトの場合、SPPIは、プロビジョニングクラスの用語「属性」を使用しています。 （SPPIは、SMIのスカラーオブジェクトと同等のものをサポートしていません。）
SNMP's SMI is divided into five parts: module definitions, object definitions, notification definitions [SMI], textual convention definitions [TC] and conformance definitions [CONF].
モジュール定義、オブジェクト定義、通知定義[SMI]、テキストの表記法の定義[TC]と適合性の定義[CONF]：SNMPのSMIは、5つの部分に分かれています。
- 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で（この時点で）使用されていません。 （キーワードの使用はSMIの通知に関連していないSPPIに「知らせる」ことに注意してください）。
- 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のテキストの表記法マクロは、新しいデータ型を定義することができます。 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.
OBJECT-GROUPマクロ、NOTIFICATION-GROUPマクロ、MODULE-COMPLIANCEマクロとAGENT-CAPABILITIESマクロ： - SMIの適合性の定義には、いくつかのマクロを定義します。 SPPIは位相応答曲線の属性の実装の許容される低境界、およびそれによって間接的、位相応答曲線自体の実装の許容される低境界を指定するオブジェクト・グループとMODULE-COMPLIANCEマクロを使用します。 NOTIFICATION-GROUPマクロはSPPIによって（この時点で）使用されていません。エージェント - CAPABILITIESマクロのSPPIにより、潜在的な使用方法は、今後の検討課題です。
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定義に関して指定されています。この文書では、一緒にSMIのとの違いを持っているSPPIのASN.1定義の中でのみ、これらの要素の説明テキストで、SMIの定義の修正版であるASN.1定義を介してもSPPIを指定します。この仕様には説明文を持っていないASN.1定義の要素について、読者はその要素のSMIの説明テキストと呼ばれます。
COPS-PR-SPPI DEFINITIONS ::= BEGIN
IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, mgmt FROM SNMPv2-SMI;
輸入のObjectName、SNMPv2の-SMI FROM SimpleSyntax、ExtUTCTime、MGMT。
-- the root for PIB definitions
- PIB定義のルート
pib OBJECT IDENTIFIER ::= { mgmt 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
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
RevisionPart ::=
Revisions
| empty
Revisions ::=
Revision
| Revisions Revision
Revision ::=
"REVISION" value(Update ExtUTCTime)
"DESCRIPTION" Text
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
--
--
OBJECT-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- 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を、オブジェクト識別子 - 7アプリケーション定義型：構文Integer32、IPアドレス、Unsigned32の、 - TimeTicksの、不透明、Integer64そして、Unsigned64に
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
-- note that SEQUENCEs for table and row definitions
-- are not mentioned here...
application-wide ApplicationSyntax }
アプリケーション全体ApplicationSyntax}
-- application-wide types
- アプリケーション全体のタイプ
ApplicationSyntax ::=
CHOICE {
ipAddress-value
IpAddress,
timeticks-value
TimeTicks,
arbitrary-value 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)
-- (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].
-- an unsigned 32-bit quantity
Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
-- hundredths of seconds since an epoch
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)
--for backward compatibility only
Opaque ::=
[APPLICATION 4]
IMPLICIT OCTET STRING
-- the following 2 types are not present in the SMI
- 以下の2種類がSMIには存在しません
Integer64 ::=
[APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Unsigned64 ::=
[APPLICATION 11]
IMPLICIT INTEGER (0..18446744073709551615)
-- definition for Provisioning Classes and their attributes -- (differences from the SMI are noted in the ASN.1 comments)
- プロビジョニングクラスとその属性の定義は、 - （SMIとの違いは、ASN.1コメントに記載されています）
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
VALUE NOTATION ::=
value(VALUE 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
type
| "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
UnitsPart ::=
"UNITS" Text
| empty
Access ::= -- modified
"install"
| "notify"
| "install-notify"
| "report-only"
Status ::=
"current"
| "deprecated"
| "obsolete"
ErrorsPart ::= -- new
"INSTALL-ERRORS" "{" Errors "}"
| empty
Errors ::= -- new
Error
| Errors "," Error
Error ::= -- new
identifier "(" number ")" -- number is positive
ReferPart ::=
"REFERENCE" Text
| empty
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
value(ObjectName)
MibIndexPart ::=
"INDEX" "{" IndexTypePart "}"
| empty
IndexTypePart ::=
IndexTypes
| IndexTypes "," ImpliedIndex
| ImpliedIndex
IndexTypes ::=
Index
| IndexTypes "," Index
ImpliedIndex ::=
"IMPLIED" Index
PibReferencesPart ::=
-- for use with ReferenceId TC
"PIB-REFERENCES" "{" Entry "}"
| empty
PibTagPart ::=
-- for use with TagReferenceId TC
"PIB-TAG" "{" Attr "}"
| empty
Attr ::= -- specifies an attribute
value(ObjectName)
UniquePart ::= -- new
"UNIQUENESS" "{" UniqueTypes "}"
| "UNIQUENESS" "{" "}"
| empty
UniqueTypes ::=
UniqueType
| UniqueTypes "," UniqueType
UniqueType ::=
-- the correspondent OBJECT-TYPE invocation
value(ObjectName)
DefValPart ::= "DEFVAL" "{" Defvalue "}"
| empty
Defvalue ::= -- must be valid for the type specified in
-- SYNTAX clause of same OBJECT-TYPE macro
value(ObjectSyntax)
| "{" BitsValue "}"
BitsValue ::= BitNames
| empty
|空の
BitNames ::= BitName
| BitNames "," BitName
BitName ::= identifier
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- definitions for conformance groups
- 適合グループの定義
OBJECT-GROUP MACRO ::=
BEGIN
TYPE NOTATION ::=
ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
ObjectsPart ::=
"OBJECTS" "{" Objects "}"
Objects ::=
Object
| Objects "," Object
Object ::=
value(ObjectName)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- definitions for compliance statements
- コンプライアンスのステートメントの定義
MODULE-COMPLIANCE MACRO ::=
BEGIN
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
ModulePart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
ModulePart ::=
Modules
Modules ::=
Module
| Modules Module
Module ::=
-- name of module --
"MODULE" 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
MandatoryPart ::=
"MANDATORY-GROUPS" "{" Groups "}"
| empty
Groups ::=
Group
| Groups "," Group
Group ::=
value(OBJECT IDENTIFIER)
CompliancePart ::=
Compliances
| empty
Compliances ::=
Compliance
| Compliances Compliance
Compliance ::=
ComplianceGroup
| Object
ComplianceGroup ::=
"GROUP" value(OBJECT IDENTIFIER)
"DESCRIPTION" Text
Object ::=
"OBJECT" value(ObjectName)
InstallSyntaxPart -- modified
AccessPart
"DESCRIPTION" Text
-- must be a refinement for object's SYNTAX clause
InstallSyntaxPart ::= "SYNTAX" Syntax
| empty
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 "}"
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
AccessPart ::=
"PIB-MIN-ACCESS" Access -- modified
| empty
Access ::= -- modified
"not-accessible"
| "install"
| "notify"
| "install-notify"
| "report-only"
| 「レポートのみ」
-- a character string as defined in [SMI]
Text ::= value(IA5String)
END
-- definition of textual conventions
- テキストの表記法の定義
TEXTUAL-CONVENTION MACRO ::=
BEGIN
TYPE NOTATION ::=
DisplayPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
"SYNTAX" Syntax
VALUE NOTATION ::=
value(VALUE Syntax) -- adapted ASN.1
DisplayPart ::=
"DISPLAY-HINT" Text
| empty
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in [SMI]
Text ::= value(IA5String)
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement), or
-- a BITS pseudo-type
type
| "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
END
終わり
END
終わり
COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN
IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION, pib FROM COPS-PR-SPPI;
輸入Unsigned32の、MODULE-IDENTITY、TEXTUAL-CONVENTION、COPS-PR-SPPI FROM PIB。
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-カテゴリー{すべて} LAST-UPDATED "200108160000Z" ORGANIZATION "IETF RAP WG" CONTACT-INFO「キースMcCloghrieシスコシステムズ、株式会社170西タスマン・ドライブ、サンノゼ、CA 95134-1706 USA電話：+1 408 526 5260 Eメール：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 }
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)
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
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
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
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)
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
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
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のように、追加のASN.1マクロは、PIBモジュールで定義されてはなりません。
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モジュールと同様に、モジュールはそのASN.1モジュール名で識別される記述子は、定義されている記述子とモジュールの両方を識別するために、Importsステートメントを使用する必要があります。
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モジュールから必要に応じて、特に、PIBモジュール輸入が（この文書で定義される）COPS-PR-SPPIから使用する基本データ型の各々、およびインポートすることができます。 PIBモジュールは、新しいOIDを定義する目的のためにSMI、（サブツリー）のOIDからインポートすることができます。 PIBモジュールはまた、MIBモジュールから、OIDの割り当てをインポートすることだけでなく、テキストの表記法の定義は、その基礎となる構文はSPPIでサポートされていることを提供します。ただし、以下はImportsステートメントに含まれていない必要があります。
- named types defined by ASN.1 itself, specifically: INTEGER, OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type,
- ASN.1自体、特にによって定義された名前付きの型：INTEGER、OCTET STRINGを、オブジェクト識別子、SEQUENCE、種類のシーケンス、
- 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からそのマクロの定義をインポートする必要があります。
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
INSTALL-エラーInteger64 PIB-MIN-ACCESS PIB-ACCESS PIB-INDEX PIB-REFERENCES PIB-TAGの主題カテゴリーUNIQUENESS Unsigned64にを拡張
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と同じオブジェクト識別子の名前階層を使用しています。すなわち、OIDは、典型的にはInternet Assigned Numbers Authority（IANA）によって投与するサブツリーからPIBモジュールに割り当てられています。しかし、SMIのように、SPPIは、OIDツリーの他の部分でのPRCsの定義を禁止するものではありません。
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:
存在しなければならない主題カテゴリ句は、このPIBモジュールがプロビジョニング情報を定義するためのデータをプロビジョニングの1つまたは複数のカテゴリを特定します。 COPS-PRプロトコルで使用するために、個々の対象のカテゴリは、クライアントタイプ[COPS-PR]をCOPSにマッピングされます。 COPSクライアントタイプのために[COPS] IANAの考慮事項に指定されているSPPIのサブジェクトカテゴリのIANAの考慮事項は、同じ要件に従ってください。対象カテゴリはいずれかの識別されます。
- 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）、または定義します
- 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プロトコルにおいて同じ番号で識別されるクライアントタイプにマッピングされます。これらの名前付きの数値のための名前空間はグローバルであるため、ラベルは、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モジュールのサブジェクトカテゴリ句で指定したカテゴリのリストは排他的ではないことに注意してください。それは他のいくつかの仕様が（例えば、将来の日の）モジュールが関連するために追加のCOPSクライアントの種類を指定することが、あります。
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モジュールは、複数の仮想情報ストア内の各クライアントタイプのための1つが存在します。サブジェクトカテゴリのPIBモジュールは、「すべて」とは、COPSを介して送信されるCOPSクライアントタイプとして、それが関連付けられているPIBの主題カテゴリに指定named-番号を使用します。
The SPPI requires that all attribute definitions be contained within a PRC, i.e., within a table definition.
SPPIは、テーブル定義内に、すなわち、すべての属性定義がPRC内に含まれることを必要とします。
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.
属性の定義の範囲内に存在していなければならない構文句は、その属性の抽象データ構造を定義します。基本型、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のテーブルおよび列の定義のために存在する必要があり、この場合のシーケンスまたは順序（以下のセクション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タイプ：INTEGER、OCTET STRINGを、オブジェクト識別子、
- application-defined types: Integer32, Unsigned32, TimeTicks, Integer64 and Unsigned64.
- アプリケーション定義型：構文Integer32、Unsigned32の、時間刻み、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.
属性値のためのオンワイヤエンコーディングの十分な多様性を提供するように基本型のセットが選択されていることに注意してください。基本型は、セマンティクスの最小値を含める必要があります。セマンティクスは、可能な限り、テキストの表記法を使用することによってデータ型に組み込まれるべきです。
The differences from the SMI in the semantics of ObjectSyntax are now described.
ObjectSyntaxの意味でのSMIとの違いを説明しています。
The Counter32 type is not supported by the SPPI.
Counter32のタイプはSPPIでサポートされていません。
The Gauge32 type is not supported by the SPPI.
Gauge32タイプはSPPIでサポートされていません。
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.
不透明タイプは、下位互換性のためにのみ提供され、新しく定義されたオブジェクト・タイプに使用してはなりません。不透明タイプは、任意のASN.1構文を渡す機能をサポートしています。値は、オクテットストリングにASN.1基本符号化規則[ASN1]を使用して符号化されます。これは、今度は、エフェクト「二重包装」オリジナルASN.1値は、OCTET STRINGとして符号化されます。準拠した実装が唯一受け入れて、不透明でエンコードされたデータを認識することができる必要があることに注意してください。データのラップを解除してから、その内容を解釈することである必要はありません。 「標準」PIBモジュールの要件には、オブジェクトが不透明のSYNTAX節価値を有していなくてもよいということです。
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].
IPアドレスのタイプは、下位互換性のためにのみ提供され、新しく定義されたオブジェクト・タイプに使用してはなりません。その代わりに、RFC2851 [INETADDR]で定義されたInetAddressType / InetAddressの対のTCを使用することが推奨されます。
The Counter64 type is not supported by the SPPI.
Counter64のタイプはSPPIでサポートされていません。
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タイプが間-2 ^ 63と2 ^ 63-1（-9223372036854775808 9223372036854775807に10進数）包括整数値情報を表しています。 Integer64、より拘束されるようにサブタイプされてもよいが制約範囲（-2147483648..2147483647）に含まれているすべての可能な値になる場合は、次にInteger32のタイプではなくInteger64を使用しなければなりません。
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から2 ^ 64-1（0 18446744073709551615の10進数）までの整数値の情報を表します。 Unsigned64には、より拘束されるようにサブタイプされてもよいが制約範囲（0 4294967295）に含まれているすべての可能な値になる場合は、次にUnsigned32のタイプではなくUnsigned64にを使用しなければなりません。
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でサポートされている（PIBの上）の操作はのPRCsのみに適用されます。各PRCは、平板状構造、即ち、テーブルとしてモデル化されます。特定のPRCの各インスタンスは、同じ属性セットを持っています。特定のPRCのすべてのインスタンスに属する属性のセットは、テーブル内の行としてモデル化されます。 PRCはせいぜい127個の属性を持たなければならないことに注意してください。 127を超えて（PRC属性の）subidsの使用（すなわち128以上である）（付録A参照）のMIBへのマッピングのPIBのために予約されています。 127のを超える属性を必要とするのPRCsは、追加の属性を追加するには、最初の127個の属性を含むPRCを強化するためにAUGMENTS句を使用する必要があります。プロビジョニングクラスの定義は、両方を定義するOBJECT-TYPEマクロを使用することによって正式にされています。
- the PRC as a whole, called the table definition, and
- 中国は全体として、テーブル定義と呼ばれ、
- 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>
OF SEQUENCE <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>規定の配列タイプです。
<EntryType> ::= SEQUENCE { <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節の値を持っています<構文>。
The MAX-ACCESS clause is not supported by the SPPI.
MAX-ACCESS句はSPPIでサポートされていません。
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は、そのすべてのインスタンスのPDPを通知し、そのPRCの属性値を必要のある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によって生成された同期/非同期レポートに含めることができます。 （注：「インストール」および/または「通知」特性を有する位相応答曲線はまた、PEPにより生成されたレポートに含まれてもよいです。）
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.
必要に応じてPRCのテーブル定義のために存在してもよく、そうでなければ存在してはならないINSTALL-ERRORSの句は、PRCのインスタンスのインストールまたは削除を拒否するための1つまたは複数の潜在的な理由を示しています。エラーコードがpriSpecificErrorに設定してそれぞれの理由は、エラーサブコードとして、数はCOPSプロトコルメッセージで使用するPRC固有のエラーコードを表す名前の数の列挙、から成る（参照[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-エラーに記載されている数字は、インストール/削除がまだ失敗することができますが、何のPRC固有のエラーが報告されるために利用可能ではない、ゼロより大きく、65536未満でなければなりません。
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のインスタンスの識別情報を定義します。
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の）を指定します。この属性の構文は（Unsigned32のの根本的な構文を使用してテキストの表記法を）INSTANCEIDする必要があり、それがPRCのインスタンスを識別する際のその使用以外の意味を持っていません。 PRCのインスタンスを識別するオブジェクト識別子は、PRCの行定義ことを識別するOID 1つのサブ識別子を付加することによって形成されています。追加のサブ識別子の値は、INDEX句で指定された属性のインスタンスの値です。
Note that SPPI does not permit use of the IMPLIED keyword in a PIB-INDEX clause.
SPPIは、PIB-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).
INDEX句は、PIB-INDEX句が存在し、そうでなければ存在しないなければならない場合に必要に応じて存在しています。存在する場合、INDEX句は、任意の数の属性を含むことができ、及びMIBのPIB（付録A参照）のアルゴリズム変換によってのみ使用されます。
An IMPLIED keyword can be present in an INDEX clause if so desired.
必要に応じて暗黙のキーワードは、INDEX句に存在することができます。
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句に対する代替であり、句を拡張します。すべての行の定義は正確の一つを有する：PIB-INDEX句、AUGMENTS句を、または句を拡張します。
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。増強PRCのインスタンスはAUGMENTS句で指定されたベース行定義のPIB-INDEX節に従って同定されます。さらに、増強PRCのインスタンスは、それが増強PRCのインスタンスと同じセマンティクスに従って存在します。このように、PRCのインスタンスがインストールまたは削除されている場合、それはまた、インストールまたは削除されている増強毎PRCのインスタンス。 （詳細については、[COPS-PR]を参照）。
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.
列の定義を除いて存在してはならない句を拡張し、PIB-INDEX句とAUGMENTS句に対する代替です。すべての行の定義は正確の一つを有する：PIB-INDEX句、AUGMENTS句を、または句を拡張します。
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.
句名このスパース行増強によりまばらに、増強された行の定義を拡張するwhere句を拡張有する行定義は、スパース行増強と呼ばれます。まばら-増強行が基底行定義、または別のスパース行増強することができます。
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のインスタンスは、まばらに増大PRCのは、extends節で指定された行定義のPIB-INDEX句に従って同定されています。
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がインストールされている場合、両方のインスタンスは、まばらに増強PRCおよびまばらに増強PRCのインスタンスのインスタンスは、1つのCOPSメッセージで送信されなければなりません。
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のインスタンス（つまりのインスタンス間のまばらな関係が存在する場合それ以外の場合は、ゼロへの1つまたはまばらに増強PRCのインスタンスとまばらにそれを補強PRCのインスタンスの間に1対1の対応があります。）、次いで句が使用されるべきで延びています。
- Otherwise, a PIB-INDEX clause should be used which names its own InstanceId attribute.
- それ以外の場合は、PUB-INDEX句は、名前、独自のインスタンスId属性を使用する必要があります。
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句は、PRCのない2つのインスタンスが同じ値のセットを持つことはできませんいるPRCの属性のゼロ以上のセットを一覧表示します。属性の指定されたセットは、このPRCのインスタンスを識別するための値の必要かつ十分なセットを提供します。 PIB-INDEX節に含まれる属性一意句に存在しなくてもよいです。定義では、属性一意句で複数回表示されない場合があります。ゼロ属性を含むUNIQUENESS句は、中国の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のインスタンスの一意性制約は、対応するPRC定義のUNIQUENESS条項に従って適用されなければなりません。まばら増強PRCは、このようにPRCそれまばらオーグメントの一意句を上書きできることに注意してください。
Even though the UNIQUENESS clause is optional, its inclusion is recommended wherever it provides useful information.
UNIQUENESS句はオプションですが、それは有用な情報を提供してどこでも、その含めることが推奨されます。
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.
ReferenceIdの構文を持つすべての属性のために存在しなければならない、そうでなければ存在してはならないPIB-REFERENCES句、名前PRC、ReferenceId属性によって参照されたインスタンス。 PIB-REFERENCES句の例の使用法については、付録Bを参照してください。
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.
SYNTAX TagReferenceIdを有する属性に対して存在しなければならない、そうでなければ存在してはならないPIB-TAG句は、この属性は、別のPRCのインスタンスの「タグリスト」を参照していることを示すために使用されます。 （[APPL]における同じ用語の使用と概念が類似している）、このようなタグリストは、その他のPRCの特定の属性の同じ（タグ）値を有する他のPRCのすべてのインスタンスによって形成されます。 SYNTAXタグIDを持っている必要があり、他のPRCの特定の属性は、PIB-TAG句で指定されています。 PIB-TAG句の使用例は、付録Bを参照してください
The OBJECT-IDENTITY macro is used in PIB modules to define information about an OBJECT IDENTIFIER assignment.
OBJECT-IDENTITYマクロは、オブジェクト識別子の割り当てに関する情報を定義するためにPIBモジュールで使用されます。
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とその属性の集合としての適合グループを定義すると便利です。オブジェクト・グループマクロは（直接的に）適合グループに属する属性の集合を定義します。コレクションに含まれる各属性がPRCに属しているので、適合グループに属する関連する位相応答曲線のコレクションも含まれている属性が属する位相応答曲線のセットとして（間接的に）指定されます。
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モジュールで定義されたすべての属性が、少なくとも一つの準拠グループに含まれている必要があります。これは、モジュールに新しい属性を追加し、グループに新しい属性を追加し忘れの一般的なエラーを回避することができます。
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マクロは、一つ以上の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モジュールの要件は、対応するモジュールコンプライアンス仕様も同じモジュールまたはコンパニオン・モジュールのいずれかで定義されていることです。
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モジュールは、同様にそれに関連するオブジェクト識別子によって、必要に応じてそのモジュール名で命名され、。 MODULE-COMPLIANCE呼び出しが包含PIBモジュールを参照するために、PIBモジュールの内部に発生した場合、モジュール名を省略することができます。
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）を実装する必要があります。
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モジュールへの遵守のために無条件で任意です。
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句で指定された適合グループのいずれかに存在している必要があります。
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モジュールで必要とされません。
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を提供するために使用されます。洗練された構文が準拠するために、この属性のために必要なサポートの最低レベルです。
The WRITE-SYNTAX clause is not supported by the SPPI.
WRITE-SYNTAX句はSPPIでサポートされていません。
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句で指定されたアクセスのサブセットを指定する必要があります。「インストール-通知」のサブセットである「インストール」を、「通知」、「インストール・通知」のサブセットであり、 「not-アクセスは、」他のすべての値のサブセットです。
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句の最大レベルのサブセットにおける最小レベルのスーパーセットである場合に実装が準拠しています。
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.
テキストの表記法を使用して定義された属性は、常に彼らの基本となる型を定義する規則によってコードされています。
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 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.
テキストの表記法の名前は、最初の文字が大文字であることと、一の以上の文字または数字で構成しなければなりません。名前は、すべて大文字で構成されてはならない、セクション5.2に記載されている予約語のいずれかと競合してはならず、長さは64文字を超えてはなりません。 （ただし、32文字より長い名前は推奨されません。）ハイフンは（ASN.1タイプの割り当てでハイフン許可でSMIv1から変換された情報モジュールでの使用を除く）テキストの表記法の名前で許可されていません。さらに、すべての「標準」PIBモジュールで定義されたテキストの表記法のために使用されるすべての名前は一意でなければなりません。
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-ヒント句は、このテキストの表記法を使用して定義された構文を持つオブジェクトのインスタンスの値が表示される場合があります方法についてのヒントを提供します。オブジェクト識別子、または任意の列挙構文（BITSまたはINTEGER）：テキスト条約の構文で定義されている場合DISPLAY-HINT句が存在してはなりません。それは他の構文のタイプのために理にかなっているかどうかの決意は、テキストの表記法の具体的な定義に依存しています。
The rules for the format specification of the hint are the same as specified in Section 3.1 of [TC].
[TC]のセクション3.1で指定されるようにヒントの形式仕様の規則は同じです。
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.
存在していなければならない構文句は、テキストの表記法に対応する抽象データ構造を定義します。データ構造は、次のいずれかでなければならない：ベース型（OBJECT-TYPEマクロのSYNTAX節を参照）、またはBITS構築物。これはテキストの表記法のSYNTAX句は、以前に定義されたテキストの表記法を参照することができない、ということを意味します。
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.
テキストの表記マクロのSYNTAX節サブ型付きオブジェクト型マクロのSYNTAX節と同様であってもよいです。
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.
実装経験が得られるようのPIBは改定される場合があります。しかし、前回のPIBと改訂された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更新句の更新、リビジョンとDESCRIPTION節のペアを追加し、既存の節に必要な変更を行うこと、を含みます組織とCONTACT-INFO句。
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によってインポートEDに利用可能であり、そしてPIBモジュール名介しIMPORTS句で参照されていることに留意されたいです。このように、PIBモジュール名は変更しないでください。定義は別の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モジュールから削除されてはならないことに注意し、それらに名前を付けるために使用されるオブジェクト識別子を再割り当てしてはいけません。 /節を表現する情報に応じて、前の定義を拡張するために使用されるべきである増強延びています。
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.
- 追加のPRCsは、PIBまたは廃止予定の既存のものに追加することができます。
- 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のNULL値のASN.1値も相互運用性を維持するために非推奨属性のために送らなければならないことに注意してください。新しい属性は、既存のものの後の順序で追加する必要があります。
- An existing PRC can be extended or augmented with a new PRC defined in another (perhaps enterprise specific) PIB.
- 既存のPRCは、拡張または別の（おそらくエンタープライズ特定）PIBで定義された新しいPRCで拡張することができます。
Additional named-number enumerations may be added to a SUBJECT-CATEGORIES clause.
追加の名前の数の列挙はSUBJECT-カテゴリ句に追加することができます。
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)
任意の非社説変更をオブジェクトの割り当てのいずれかの条項に行われた場合、そのオブジェクトの割り当てに関連付けられているオブジェクト識別子値もそれに関連する記述子と一緒に、変更する必要があります。 PRCの最大のサブIDが127される属性のことに注意してください（セクション7.1.8を参照してください）
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.
- 新しい列挙を有していてもよい列挙された整数を含むSYNTAX句が追加または既存のラベルが変更されました。同様に、名前のビットを追加してもよいか、または既存のラベルは、BITSの構築のために変更されました。
- 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.
- A単位句を添加してもよいです。
- 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節の値が「廃止」と変更することができます。このような変更を行う場合には、DESCRIPTION句は根拠を説明するために更新する必要があります。
- 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は、行の最後に新しいオブジェクトを追加し、シーケンスの定義に対応する更新を行うことによって増強することができます。
- Entirely new objects may be defined, named with previously unassigned OBJECT IDENTIFIER values.
- まったく新しいオブジェクトは、定義された以前に割り当てられていないオブジェクト識別子値で命名することができます。
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.
以前に定義されたオブジェクトのセマンティクスが変更された場合（非編集上の変更は、特に上記許可以外の任意の条項に言及する場合、すなわち、）そうでなければ、そのオブジェクトに関連付けられているオブジェクト識別子の値も変更されなければなりません。これらの文字列は、Importsステートメントで使用することができるよう、既存のオブジェクトに関連付けられた記述子を変更すると、セマンティック変更と見なされることに注意してください。
Appendix A: Mapping a PIB to a MIB
付録A：MIBにPIBのマッピング
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:
SPPIはSMIをモデルにしているので、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-定義を交換してください。
- 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.
- INDEX句が存在しない場合は、各PRC定義については、「インデックス」に「PIB-INDEX」のキーワードを変更します。それ以外の場合は、PIB-INDEX句を削除します。
- Delete all of the following clauses: PIB-ACCESS, PIB-REFERENCES, PIB-TAG, UNIQUENESS, INSTALL-ERRORS, and SUBJECT-CATEGORIES.
PIB-ACCESS、PIB-REFERENCES、PIB-TAG、UNIQUENESS、INSTALL-エラー、およびSUBJECT-カテゴリー： - 次の句のすべてを削除します。
- Change all PIB-MIN-ACCESS clauses to MIN-ACCESS clauses, modifying "install" and "install-notify" to "read-create", and "notify" to "read-only".
- 「インストール」と「リード作成」し、「通知・インストール」、および「読み取り専用」に「通知」の変更、MIN-ACCESS節にすべてのPIB-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のためのMAX-ACCESS句を追加します。各表の定義と行定義については、MAX-ACCESSは「アクセス不可」です。 INDEX句にある各属性について、MAX-ACCESSは、「アクセス不可能」です。残りの属性については、MAX-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の記述の最後に「RowStatus標準」を9つの文字を追加することによって形成することができる（長すぎる結果の記述を避けるために、必要に応じて切り捨て）。 127（即ち、128以上）を超えSUBIDこの柱状属性のOIDとして使用することができます。
- 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またはテキストの表記法の定義とそれへのすべての参照を省略します。それは使用するための最良のSMIデータ型がある（この時点で）明確ではないので、変換は、少なくとも次の中から選択できるよう設定可能なオプションを提供する必要があります。
- convert to an OCTET STRING of the relevant size. Specifically, this option would map both Integer64 and Unsigned64 to OCTET STRING (SIZE(8)), or
- 関連した大きさのオクテット文字列に変換します。具体的には、このオプションは、オクテットSTRING（SIZE（8））にInteger64とUnsigned64に両方をマップする、または
- 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句はqosIfDscpMapThresh属性によって、同様に、それがインスタンスを参照そのPRCを示すためqosIfDscpMapQueue属性で使用され、。
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 }
qosIfDscpAssignEntry OBJECT-TYPE
SYNTAX QosIfDscpAssignEntry
STATUS current
DESCRIPTION
"An instance of the qosIfDscpAssign class."
PIB-INDEX { qosIfDscpAssignPrid }
UNIQUENESS { qosIfDscpAssignName, qosIfDscpAssignRoles }
::= { qosIfDscpAssignTable 1 }
QosIfDscpAssignEntry ::= SEQUENCE {
qosIfDscpAssignPrid InstanceId,
qosIfDscpAssignName SnmpAdminString, 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 }
-- -- 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 }
qosIfDscpMapEntry OBJECT-TYPE
SYNTAX QosIfDscpMapEntry
STATUS current
DESCRIPTION
"An instance of the qosIfDscpMap class."
PIB-INDEX { qosIfDscpMapPrid }
UNIQUENESS { qosIfDscpMapMapId, qosIfDscpMapDscp }
::= { qosIfDscpMapTable 1 }
QosIfDscpMapEntry ::= SEQUENCE {
qosIfDscpMapPrid InstanceId,
qosIfDscpMapMapId TagId,
qosIfDscpMapDscp Dscp,
qosIfDscpMapQueue ReferenceId,
qosIfDscpMapThresh ReferenceId
}
qosIfDscpMapMapId OBJECT-TYPE SYNTAX TagId STATUS current
qosIfDscpMapMapId OBJECT-TYPE SYNTAX TAGIDのSTATUSの現在
DESCRIPTION
"An integer that identifies the DSCP map to which this PRI
belongs."
::= { qosIfDscpMapEntry 2 }
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 }
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 }
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:
インターネットのためInternet Assigned Numbers Authority（IANA）によって投与するサブツリーのルートです。
internet OBJECT IDENTIFIER ::= { iso 3 6 1 }
That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix:
つまり、オブジェクト識別子のインターネットサブツリーが接頭辞で始まる、次のとおりです。
Several branches underneath this subtree are used for network management:
このサブツリーの下にいくつかの支店は、ネットワーク管理のために使用されます。
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
The mgmt(2) subtree is used to identify "standard" objects.
MGMT（2）のサブツリーを「標準」オブジェクトを識別するために使用されます。
This document defines
この文書では、定義します
pib OBJECT IDENTIFIER ::= { mgmt 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.
持ち越されるように定義のPIBのルートとして[COPS-PR]。このオブジェクト識別子は、[IANA]に登録する必要がハイレベルの割り当てです。将来のためのルートオブジェクト識別子のPIBも登録する必要がありますと、このOID下のオブジェクト識別子を使用しなければならない「の基準はトラック」。基準は、PIBは「基準トラック」文書としてIESGによって承認された場合PIBのみIANAによってOIDを割り当てることができます追跡します。実験及び企業のPIBは、それぞれ、「実験的」と「企業」オブジェクト識別子の下で定義されなければなりません。
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」は標準モジュールとして、この文書で定義され、従って、IANAから「PIB」OID下のサブIDの割り当てを必要としています。
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のサブジェクトカテゴリはCOPSクライアントタイプにマッピングされます。 COPSクライアントタイプのために[COPS] IANAの考慮事項に指定されている主題カテゴリのIANAの考慮事項は、同じ要件に従ってください。このように、新しいPIBは「実験的」または「企業」スペース、および承認されたときに、新しいCOPSクライアントタイプが割り当てられますことを意味し、「標準」に新しいCOPSクライアントタイプを定義することができます。 IANAは、結果として、（[COPS] IANAの考慮事項に記載されているように適用可能）COPSクライアントタイプのレジストリを更新しなければなりません。
Authors' Addresses
著者のアドレス
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
キースMcCloghrieシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1 408 526 5260 Email: kzm@cisco.com
電話：+1 408 526 5260 Eメール：kzm@cisco.com
Michael Fine Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
マイケル・ファインシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1 408 527 8218 EMail: mfine@cisco.com
電話：+1 408 527 8218 Eメール：mfine@cisco.com
John Seligson Nortel Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95054 USA
ジョンSeligsonノーテルネットワークス株式会社4401グレートアメリカパークウェイサンタクララ、CA 95054 USA
Phone: +1 408 495 2992 EMail: jseligso@nortelnetworks.com
電話：+1 408 495 2992 Eメール：jseligso@nortelnetworks.com
Kwok Ho Chan Nortel Networks, Inc. 600 Technology Park Drive Billerica, MA 01821 USA
クォックホーチャンノーテルネットワークス株式会社600テクノロジーパークドライブビレリカ、MA 01821 USA
Phone: +1 978 288 8175 EMail: khchan@nortelnetworks.com
電話：+1 978 288 8175 Eメール：khchan@nortelnetworks.com
Scott Hahn Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
スコット・ハーンインテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: +1 503 264 8231 EMail: scott.hahn@intel.com
電話：+1 503 264 8231 Eメール：scott.hahn@intel.com
Ravi Sahita Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA
ラヴィSahitaインテル2111 NE 25日アベニューヒルズボロ、OR 97124 USA
Phone: +1 503 712 1554 EMail: ravi.sahita@intel.com
電話：+1 503 712 1554 Eメール：ravi.sahita@intel.com
Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119 USA
アンドリュー・スミスアレグロ・ネットワーク6399サンイグナチオアベニュー。サンノゼ、CA 95119 USA
Fax: +1 415 345 1827 EMail: andrew@allegronetworks.com
ファックス：+1 415 345 1827 Eメール：andrew@allegronetworks.com
Francis Reichmeyer PFN Inc. University Park at MIT 26 Landsdowne Street Cambridge, MA 02139 USA
MIT 26ランズダウン・ストリート、ケンブリッジ、MA 02139 USAでのフランシス・ライヒマイヤーPFN株式会社ユニバーシティパーク
Phone: +1 617 494 9980 EMail: franr@pfn.com
電話：+1 617 494 9980 Eメール：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.
[COPS]ボイル、J.、コーエン、R.、ダーラム、D.、ヘルツォーク、S.、ラジャン、R.とA. Sastry、 "COPS（コモンオープンポリシーサービス）プロトコル"、RFC 2748、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.、ラジャン、R.およびA. Sastry、 "RSVPの使用をCOPS"、RFC 2749、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.
[COPS-PR] Reichmeyer、F.、ヘルツォーク、S.、チャン、K.、ダラム、D.、Yavatkar、R.、ガイ、S.、McCloghrie、K.とA.スミス、「ポリシーのプロビジョニングの使用をCOPS 」、RFC 3084、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）の構造"、STD 58、RFC 2578は、 1999年4月。
[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のためのテキストの表記法"、STD 58、RFC 2579、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のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[APPL]レビ、D.、マイヤー、P.とB.スチュワート、 "SNMPアプリケーション"、RFC 2573、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]情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（ASN.1）、国際標準化機構の仕様。国際標準8824、1987年12月。
[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 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 2851、2000年6月。
[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問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。