RFC3216 日本語訳
3216 SMIng Objectives. C. Elliott, D. Harrington, J. Jason, J.Schoenwaelder, F. Strauss, W. Weiss. December 2001. (Format: TXT=58551 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Elliott
Request for Comments: 3216 Cisco Systems
Category: Informational D. Harrington
Enterasys Networks
J. Jason
Intel Corporation
J. Schoenwaelder
F. Strauss
TU Braunschweig
W. Weiss
Ellacoya Networks
December 2001
コメントを求めるワーキンググループC.エリオット要求をネットワークでつないでください: 3216年のシスコシステムズカテゴリ: 情報のD.ハリントンEnterasysは2001年12月にJ.ジェイソンインテル社J.Schoenwaelder F.ストラウスTUブラウンシュバイクW.ワイスEllacoyaネットワークをネットワークでつなぎます。
SMIng Objectives
SMIng目的
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations.
このドキュメントは直接SNMPに写像できる新しいネットワークマネージメント構造物のモデルに適したデータ定義言語とCOPS-PRプロトコル操作のために目的について説明します。
The purpose of this document is to serve as a set of objectives that a subsequent language specification should try to address. It captures the results of the working group discussions towards consensus on the SMIng objectives.
このドキュメントの目的はその後の言語仕様が記述しようとするべきである1セットの目的として機能することです。 それはSMIng目的に関するコンセンサスに向かってワーキンググループ議論の結果を得ます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Specific Objectives for SMIng . . . . . . . . . . . . . . 4 4.1 Accepted Objectives . . . . . . . . . . . . . . . . . . . 5 4.1.1 The Set of Specification Documents . . . . . . . . . . . . 6 4.1.2 Textual Representation . . . . . . . . . . . . . . . . . . 6 4.1.3 Human Readability . . . . . . . . . . . . . . . . . . . . 6
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 3 2。 動機. . . . . . . . . . . . . . . . . . . . . . . . 3 3。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . 4 4。 SMIng. . . . . . . . . . . . . . 4 4.1のための明確な目標が目的を受け入れた、.54.1、.1、仕様ドキュメント. . . . . . . . . . . . 6 4.1.2の原文の表現. . . . . . . . . . . . . . . . . . 6 4.1.3の人間の読み易さ. . . . . . . . . . . . . . . . . . . . 6のセット
Elliott, et al. Informational [Page 1] RFC 3216 SMIng Objectives December 2001
エリオット、他 [1ページ]情報のRFC3216SMIng目的2001年12月
4.1.4 Rigorously Defined Syntax . . . . . . . . . . . . . . . . 6
4.1.5 Accessibility . . . . . . . . . . . . . . . . . . . . . . 7
4.1.6 Language Extensibility . . . . . . . . . . . . . . . . . . 7
4.1.7 Special Characters in Text . . . . . . . . . . . . . . . . 7
4.1.8 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.9 Namespace Control . . . . . . . . . . . . . . . . . . . . 8
4.1.10 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.11 Module Conformance . . . . . . . . . . . . . . . . . . . . 9
4.1.12 Arbitrary Unambiguous Identities . . . . . . . . . . . . . 9
4.1.13 Protocol Independence . . . . . . . . . . . . . . . . . . 9
4.1.14 Protocol Mapping . . . . . . . . . . . . . . . . . . . . . 10
4.1.15 Translation to Other Data Definition Languages . . . . . . 10
4.1.16 Base Data Types . . . . . . . . . . . . . . . . . . . . . 10
4.1.17 Enumerations . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.18 Discriminated Unions . . . . . . . . . . . . . . . . . . . 11
4.1.19 Instance Pointers . . . . . . . . . . . . . . . . . . . . 11
4.1.20 Row Pointers . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.21 Constraints on Pointers . . . . . . . . . . . . . . . . . 12
4.1.22 Base Type Set . . . . . . . . . . . . . . . . . . . . . . 12
4.1.23 Extended Data Types . . . . . . . . . . . . . . . . . . . 12
4.1.24 Units, Formats, and Default Values of Defined Types and
Attributes . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.25 Table Existence Relationships . . . . . . . . . . . . . . 13
4.1.26 Table Existence Relationships (2) . . . . . . . . . . . . 14
4.1.27 Attribute Groups . . . . . . . . . . . . . . . . . . . . . 14
4.1.28 Containment . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.29 Single Inheritance . . . . . . . . . . . . . . . . . . . . 15
4.1.30 Reusable vs. Final Attribute Groups . . . . . . . . . . . 15
4.1.31 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.32 Creation/Deletion . . . . . . . . . . . . . . . . . . . . 16
4.1.33 Range and Size Constraints . . . . . . . . . . . . . . . . 16
4.1.34 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.35 Extension Rules . . . . . . . . . . . . . . . . . . . . . 17
4.1.36 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . . 17
4.1.37 No Redundancy . . . . . . . . . . . . . . . . . . . . . . 17
4.1.38 Compliance and Conformance . . . . . . . . . . . . . . . . 17
4.1.39 Allow Refinement of All Definitions in Conformance
Statements . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.40 Categories . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.41 Core Language Keywords vs. Defined Identifiers . . . . . . 19
4.1.42 Instance Naming . . . . . . . . . . . . . . . . . . . . . 19
4.1.43 Length of Identifiers . . . . . . . . . . . . . . . . . . 19
4.1.44 Assign OIDs in the Protocol Mappings . . . . . . . . . . . 20
4.2 Nice-to-Have Objectives . . . . . . . . . . . . . . . . . 20
4.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Float Data Types . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.4 きびしく定義された構文. . . . . . . . . . . . . . . . 6 4.1.5のアクセシビリティ、.74.1 .6 .84.1.9名前空間コントロール. . . . . . . . . . . . . . . . . . . . 8 4.1.10のモジュール. . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.11モジュールを順応と命名するテキスト. . . . . . . . . . . . . . . . 7 4.1.8のうちの.74.1の言語伸展性.7特殊文字…; . . . . . . . . . . . 9 4.1.12 任意の明白なアイデンティティ. . . . . . . . . . . . . 9 4.1.13は他のデータ定義言語. . . . . . 10 4.1.16の基地のデータ型. . . . . . . . . . . . . . . . . . . . . 10 4.1.17の列挙. . . . . . . . . . . . . . . . . . . . . . . 11 4.1.18の差別された組合. . . . . . . . . . . . . . . . . . . 11 4.1.19に.104.1.15翻訳を写像する独立. . . . . . . . . . . . . . . . . . 9 4.1.14プロトコルについて議定書の中で述べます。例のポインタ. . . . . . . . . . . . . . . . . . . . 11 4.1.20はポインタ. . . . . . . . . . . . . . . . . 12 4.1.22基地のタイプにおける.124.1の.21規制が設定するポインタを船をこいで運びます…; . . . 12 4.1.23 拡張データ型、.124.1、.24ユニット、形式、および定義されたタイプと属性. . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.25テーブル存在関係の………デフォルト値; . . . . . 13 4.1.26 テーブル存在関係(2). . . . . . . . . . . . 14 4.1.27属性が.144.1に.28の封じ込め. . . . . . . . . . . . . . . . . . . . . . . 14 4.1.29のただ一つの遺産を分類する、.154.1、.30、最終的な属性グループ. . . . . . . . . . . 15 4.1に対して再利用できる.31回のイベント. . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.32創造/削除. . . . . . . . . . . . . . . . . . . . 16 4.1.33範囲とSize Constraints. . . . . . . . . . . . . . . . 16 4.1.34ユニークさ. . . . . . . . . . . . . . . . . . . . . . . . 16 4.1の.35拡大Rules、.174.1、.36、IMPLIED Keyword. . . . . . . . . . . . . 17 4.1.37のいいえRedundancy. . . . . . . . . . . . . . . . . . . . . . 17 4.1.38、コンプライアンスとConformanceのUseを非難してください、.174.1、.39、Conformance StatementsにAll DefinitionsのRefinementを許容してください…; .184.1に、.41は言語キーワードの芯を取ります。18 4.1 .40のカテゴリ、定義された識別子. . . . . . 19 4.1.42に対して、識別子の命名.194.1.43の長さを例証してください…; . . . . . . . . . 19 4.1.44 目的. . . . . . . . . . . . . . . . . 20 4.2.1の方法. . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.2の組合を持つために良いプロトコルマッピング. . . . . . . . . . . 20 4.2のOIDsに割り当ててください…. . . . . . . . . . . . . . . 21 4.2に、.3はデータ型. . . . . . . . . . . . . . . . . . . . . 21 4.2.4のコメント. . . . . . . . . . . . . . . . . . . . . . . . . 22を浮かべます。
Elliott, et al. Informational [Page 2] RFC 3216 SMIng Objectives December 2001
エリオット、他 [2ページ]情報のRFC3216SMIng目的2001年12月
4.2.5 Referencing Tagged Rows . . . . . . . . . . . . . . . . . 22 4.2.6 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.7 Internationalization . . . . . . . . . . . . . . . . . . . 23 4.2.8 Separate Data Modelling from Management Protocol Mapping . 23 4.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 24 4.3.1 Incomplete Translations . . . . . . . . . . . . . . . . . 24 4.3.2 Attribute Value Constraints . . . . . . . . . . . . . . . 24 4.3.3 Attribute Transaction Constraints . . . . . . . . . . . . 25 4.3.4 Method Constraints . . . . . . . . . . . . . . . . . . . . 25 4.3.5 Agent Capabilities . . . . . . . . . . . . . . . . . . . . 25 4.3.6 Relationships . . . . . . . . . . . . . . . . . . . . . . 26 4.3.7 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.8 Associations . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.9 Association Cardinalities . . . . . . . . . . . . . . . . 27 4.3.10 Categories of Modules . . . . . . . . . . . . . . . . . . 27 4.3.11 Mapping Modules to Files . . . . . . . . . . . . . . . . . 27 4.3.12 Simple Grammar . . . . . . . . . . . . . . . . . . . . . . 28 4.3.13 Place of Module Information . . . . . . . . . . . . . . . 28 4.3.14 Module Namespace . . . . . . . . . . . . . . . . . . . . . 29 4.3.15 Hyphens in Identifiers . . . . . . . . . . . . . . . . . . 29 5. Security Considerations . . . . . . . . . . . . . . . . . 30 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30 7. References . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31 9. Full Copyright Statement . . . . . . . . . . . . . . . . . 33
4.2.5 タグ付けをされた通り. . . . . . . . . . . . . . . . . 22 4.2に参照をつけて、.6のアレイ.224.2.7国際化. . . . . . . . . . . . . . . . . . . 23 4.2.8が管理プロトコルマッピング. 23 4.3拒絶された目的. . . . . . . . . . . . . . . . . . . 24 4.3.1の不完全な翻訳. . . . . . . . . . . . . . . . . 24 4.3.2の属性値規制. . . . . . . . . . . . . . . 24 4.3.3の属性取引規制からモデル化されるデータを切り離します; . . . . . . . . . . . 25 4.3.4 方法規制. . . . . . . . . . . . . . . . . . . . 25 4.3.5エージェント能力. . . . . . . . . . . . . . . . . . . . 25 4.3.6関係. . . . . . . . . . . . . . . . . . . . . . 26 4.3.7の手順. . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.8の協会. . . . . . . . . . . . . . . . . . . . . . . 26 4.3.9の協会基数、モジュール. . . . . . . . . . . . . . . . . . 27 4.3.11マの.274.3の.10カテゴリIdentifiers. . . . . . . . . . . . . . . . . . 29 5のModule情報. . . . . . . . . . . . . . . 28 4.3.14モジュールNamespace. . . . . . . . . . . . . . . . . . . . . 29 4.3.15のハイフンのFiles. . . . . . . . . . . . . . . . . 27 4.3.12の簡単なGrammar. . . . . . . . . . . . . . . . . . . . . . 28 4.3.13場所へのpping Modules。 セキュリティ問題. . . . . . . . . . . . . . . . . 30 6。 承認. . . . . . . . . . . . . . . . . . . . . 30 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . 30 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 31 9。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 33
1. Introduction
1. 序論
This document describes the objectives for a new data definition language that can be mapped into SNMP [1], [2] and COPS-PR [3] protocol operations. It may also be translated into SMIv2 [4], [5], [6] MIBs and SPPI [7] PIBs. Concepts such as attributes, attribute groups, methods, conventions for organization into reusable data structures, and mechanisms for representing relationships are discussed.
このドキュメントはSNMP[1]([2]とCOPS-PR[3]プロトコル操作)に写像できる新しいデータ定義言語のために目的について説明します。 また、それは[6]のSMIv2[4]、[5]、MIBs、およびSPPI[7]PIBsに翻訳されるかもしれません。 属性や、属性グループや、方法や、再利用できるデータ構造への組織のためのコンベンションや、関係を表すためのメカニズムなどの概念について議論します。
2. Motivation
2. 動機
As networking technology has evolved, a diverse set of technologies has been deployed to manage the resulting products. These vary from Web based products, to standard management protocols and text scripts. The underlying systems to be manipulated are represented in varying ways including implicitly in the system programming, via proprietary data descriptions, or with standardized descriptions using a range of technologies including MIBs, PIBs, or LDAP schemas. The result is that management interfaces for network protocols, services, and applications such as Differentiated Services may be represented in many different, inconsistent fashions.
ネットワーク・テクノロジーが発展したとき、さまざまの技術は、結果として起こる製品を管理するために配備されました。 これらは標準の管理プロトコルとウェブに基づいている製品からテキストスクリプトに異なります。 操られるべき基本的なシステムは独占データ記述でプログラムを作るシステムか標準化された記述でそれとなくMIBsを含むさまざまな技術を使用するか、PIBs、またはLDAP schemasを含む異なった方法で表されます。 結果はDifferentiated Servicesなどのネットワーク・プロトコル、サービス、およびアプリケーションのための管理インタフェースが多くの異なって、矛盾したやり方で表されるかもしれないということです。
Elliott, et al. Informational [Page 3] RFC 3216 SMIng Objectives December 2001
エリオット、他 [3ページ]情報のRFC3216SMIng目的2001年12月
The SMIng working group has been chartered to define a new data definition language that will eliminate the need for a separate SMIv2 and SPPI language. That is, the new language should address the needs for the current SMIv2 and SPPI languages so that over time we can all use the new language instead.
SMIngワーキンググループは、別々のSMIv2とSPPI言語の必要性を排除する新しいデータ定義言語を定義するためにチャーターされました。 すなわち、新しい言語は、私たちが皆、時間がたつにつれて代わりに新しい言語を使用できるように、現在のSMIv2とSPPI言語の必要性を記述するべきです。
Another motivation is to permit a more expressive and complete representation of the modeled information. Examples of additional expressiveness and completeness that are considered are the ability to formally define table existence relationships, the expression of instance creation/deletion capabilities, and the ability to define attribute groups using inheritance. These additional features are discussed in subsequent sections.
別の動機はモデル化された情報の、より表現の、そして、完全な表現を可能にすることです。 追加表情の豊かさと考えられた完全性に関する例は、正式にテーブル存在関係を定義する能力と、例の創造/削除能力の表現と、遺産を使用することで属性グループを定義する能力です。 その後のセクションでこれらの付加的な機能について議論します。
It has been recognized that the two main goals of (a) merging SMIv2/SPPI and (b) enhancing the state of art in network management data modeling can lead to conflicts. In such cases, the SMIng working group's consensus is to focus on enhancing the state of art in network management data modeling.
ネットワークマネージメントデータのモデル化における技術の状態を高めながらSMIv2/SPPIと(b)を合併する(a)の2つの第一目的が闘争に通じることができると認められました。 そのような場合、SMIngワーキンググループのコンセンサスはネットワークマネージメントデータのモデル化における技術の状態を高めるのは焦点を合わせることです。
3. Background
3. バックグラウンド
The Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) has researched the issues of creating a protocol- independent data definition language that could be used by multiple protocols. Because SMIv2 and SPPI are very similar, the NMRG focused on merging these two languages, but also researched ways to abstract the objectives to produce a language that could be used for other protocols, such as LDAP and Diameter. The NMRG has published the results of their work in a meanwhile expired Internet Draft, but has submitted their specification as one proposal to consider in the development of the SMIng language.
インターネットResearch Task Force(IRTF)のNetwork Management Research Group(NMRG)は複数のプロトコルで使用できたプロトコルの独立しているデータ定義言語を作成する問題について研究しました。 SMIv2とSPPIが非常に同様であるので、NMRGは、これらの2つの言語を合併するのは焦点を合わせて、要約へのまた、研究された唯一の方法は他のプロトコルに使用できた言語を作成する目的です、LDAPやDiameterのように。 NMRGは一方、中の彼らの仕事では、aがインターネットDraftを吐き出したという結果を発表しましたが、SMIng言語の開発で考えるというある提案としてそれらの仕様を提出しました。
The SMIng Working Group has accepted their submission for consideration, and to use their proposal to better understand the objectives and possible obstacles to be overcome. Where useful, the NMRG proposal has been referenced in the details below.
SMIng作業部会は、検討、目的をより理解しているという彼らの提案と可能な越えなければならない障害を使用するために彼らの服従を受け入れました。 役に立つところでは、以下の詳細にNMRG提案に参照をつけてあります。
4. Specific Objectives for SMIng
4. SMIngのための明確な目標
The following sections define the objectives for the definition of a new data definition language. The objectives have been organized as follows: accepted objectives (Section 4.1), nice-to-have objectives (Section 4.2), and rejected objectives (Section 4.3). Each objective has the following information:
以下のセクションは新しいデータ定義言語の定義のために目的を定義します。 目的は以下の通り組織化されました: 目的(セクション4.1)、持つために良い目的(セクション4.2)を受け入れて、目的(セクション4.3)を拒絶しました。 各目的には、以下の情報があります:
o Type: a field that identifies the type of objective, using one of
the following values:
o 以下をタイプしてください。 以下の値の1つを使用して、目的のタイプを特定する分野:
Elliott, et al. Informational [Page 4] RFC 3216 SMIng Objectives December 2001
エリオット、他 [4ページ]情報のRFC3216SMIng目的2001年12月
* basic: considered a basic objective for SMIng and is contained
in SMIv2 and/or SPPI.
* 基本的: SMIngのために基本的な目的を考えて、SMIv2、そして/または、SPPIに含まれています。
* align: supported in different ways in SMIv2 and SPPI and they
must be aligned.
* 並べます: 異なるところで支持されて、SMIv2とSPPIの道とそれらを並べなければなりません。
* fix: considered a fix for a known problem in SMIv2 and/or SPPI.
* 以下を修理してください。 SMIv2、そして/または、SPPIの既知の問題のためのフィックスであると考えられます。
* new: considered a new feature.
* 新しい: 新機能であると考えられます。
o From: a field that defines the origin of the objective and that
contains one or more of the following values:
o From: 目的とその起源を定義する分野は以下の値の1つ以上を含んでいます:
* SMI: exists in SMIv2.
* SMI: SMIv2では、存在しています。
* SPPI: exists in SPPI.
* SPPI: SPPIでは、存在しています。
* NMRG: exists in the NMRG proposal, but not in SMIv2 or SPPI.
* NMRG: NMRG提案で存在していますが、SMIv2かSPPIに存在するというわけではありません。
* Charter: exists in working group charter.
* 以下をチャーターしてください。 ワーキンググループ特許では、存在しています。
* WG: proposed during working group discussions.
* WG: ワーキンググループ議論の間、提案されます。
o Description: a quick description of the objective.
o 記述: 目的の迅速な記述。
o Motivation: rationale for the objective.
o 動機: 目的のための原理。
o Notes: optional notes about an objective. For example, for nice-
to-have or rejected this may contain reasoning why this objective
is not required by the SMIng working group, but justification why
it should be considered anyway. Notes may be the opinions of the
participants in the discussion on objectives and as such should
not be taken as consensus of the working group or the
recommendation of the objectives editing team.
o 注意: 目的に関する任意の注。 または、例えば、良い、-、拒絶されて、これはこの目的がSMIngワーキンググループによって必要とされない推理を含むかもしれなくて、唯一の正当化はそれがとにかく考えられるべきである理由です。 ノートを目的についての議論の関係者の意見であるかもしれなく、ワーキンググループのコンセンサスかチームを編集する目的の推薦としてそういうものとしてみなすべきではありません。
4.1 Accepted Objectives
4.1 受け入れられた目的
This section represents the list of objectives that have been accepted by the SMIng working group as worthwhile and therefore deserving of further consideration. Each of these objectives must be evaluated by the working group to determine if the benefit incurs an acceptable level of cost. An accepted objective may subsequently be rejected if the cost/benefit analysis determines that the benefit does not justify the cost or that the objective is in direct conflict with one or more other accepted objectives that are deemed more important.
このセクションは価値があってしたがって、値するとSMIngワーキンググループによって認められたさらなる考慮の目的のリストを表します。 ワーキンググループは、利益が合格水準の費用を被るかどうか決定するためにそれぞれのこれらの目的を評価しなければなりません。 費用/利益分析が、利益が費用を正当化しないか、または目的が、より重要であると考えられる他の1つ以上の受け入れられた目的とのダイレクト闘争中であることを決定するなら、受け入れられた目的は次に、拒絶されるかもしれません。
Elliott, et al. Informational [Page 5] RFC 3216 SMIng Objectives December 2001
エリオット、他 [5ページ]情報のRFC3216SMIng目的2001年12月
4.1.1 The Set of Specification Documents
4.1.1 仕様ドキュメントのセット
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: SMIv2 is defined in three documents, based on an
obsolete ITU ASN.1 specification. SPPI is defined in one
document, based on SMIv2. The core of SMIng must be defined in
one document and must be independent of external specifications.
記述: 時代遅れのITU ASN.1仕様に基づいてSMIv2は3通のドキュメントで定義されます。 SMIv2に基づいてSPPIは1通のドキュメントで定義されます。 SMIngのコアは、1通のドキュメントで定義しなければならなくて、外部仕様から独立しているに違いありません。
Motivation: Self-containment.
動機: 自己封じ込め。
4.1.2 Textual Representation
4.1.2 原文の表現
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI, WG
From: SMI、SPPI、WG
Description: SMIng definitions must be represented in a textual
format.
記述: 原文の形式でSMIng定義を表さなければなりません。
Motivation: General IETF consensus.
動機: 一般IETFコンセンサス。
4.1.3 Human Readability
4.1.3 人間の読み易さ
Type: basic
以下をタイプしてください。 基本的
From: WG
From: WG
Description: The syntax must make it easy for humans to directly read
and write SMIng modules. It must be possible for SMIng module
authors to produce SMIng modules with text editing tools.
記述: 構文で、人間が直接SMIngモジュールを読み書きするのが簡単にならなければなりません。 SMIngモジュール作者がテキスト編集ツールでSMIngモジュールを作成するのは、可能であるに違いありません。
Motivation: The syntax must make it easy for humans to read and write
SMIng modules.
動機: 構文で、人間がSMIngモジュールを読み書きするのが簡単にならなければなりません。
4.1.4 Rigorously Defined Syntax
4.1.4 きびしく定義された構文
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: There must be a rigorously defined syntax for the SMIng
language.
記述: SMIng言語のためのきびしく定義された構文があるに違いありません。
Elliott, et al. Informational [Page 6] RFC 3216 SMIng Objectives December 2001
エリオット、他 [6ページ]情報のRFC3216SMIng目的2001年12月
Motivation: An unambiguous language promotes consistency across
vendors so that different parsers produce the same results. It
also provides authoritative rules to SMIng modules designers.
動機: 明白な言語が業者の向こう側に一貫性を促進するので、異なったパーサは同じ結果を生みます。 また、それはSMIngモジュールデザイナーに正式の規則を提供します。
4.1.5 Accessibility
4.1.5 アクセシビリティ
Type: align
以下をタイプしてください。 並んでください。
From: SMI, SPPI
From: SMI、SPPI
Description: Attribute definitions must indicate whether attributes
can be read, written, created, deleted, and whether they are
accessible for notifications, or are not accessible. Align PIB-
ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
記述: 属性定義は、属性を読むことができるかどうかを示さなければならないか、削除されて、作成されて、通知に、それらがアクセスしやすいか否かに関係なく、書くか、またはアクセスしやすくはありません。 そして、PIBアクセスとマックス-アクセスを並べてください、PIB分がアクセスする、分アクセサリー
Motivation: Alignment of SMIv2 and SPPI.
動機: SMIv2とSPPIの整列。
4.1.6 Language Extensibility
4.1.6 言語伸展性
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: The language must have characteristics, so that future
modules can contain information of future syntax without breaking
original SMIng parsers.
記述: 言語には、特性が、将来のモジュールが壊れているオリジナルのSMIngパーサなしで将来の構文の情報を含むことができるように、なければなりません。
E.g., when SMIv2 introduced REFERENCEs it would have been nice if
it would not have broken SMIv1 parsers.
例えば、SMIv2がREFERENCEsを導入したとき、SMIv1パーサを壊していないなら、良かったでしょう。
Motivation: Achieve language extensibility without breaking core
compatibility.
動機: 壊れているコアの互換性なしで言語伸展性を達成してください。
4.1.7 Special Characters in Text
4.1.7 テキストの特殊文字
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: Allow an escaping mechanism to encode special
characters, e.g. double quotes and new-line characters, in text
such as DESCRIPTIONs or REFERENCEs.
記述: エスケープメカニズムに特殊文字、例えば二重引用符と復帰改行キャラクタをコード化させてください、DESCRIPTIONsかREFERENCEsなどのテキストで。
Motivation: ABNF can contain literal characters enclosed in double
quotes; to provide the ABNF grammar, there must be the ability to
escape special characters.
動機: ABNFは二重引用符に同封された文字通りのキャラクタを含むことができます。 ABNF文法を提供するために、特殊文字から逃げる能力があるに違いありません。
Elliott, et al. Informational [Page 7] RFC 3216 SMIng Objectives December 2001
エリオット、他 [7ページ]情報のRFC3216SMIng目的2001年12月
4.1.8 Naming
4.1.8 命名
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must provide mechanisms to uniquely identify
attributes, groups of attributes, and events. It is necessary to
specify how name collisions are handled.
記述: SMIngは、唯一属性、属性のグループ、および出来事を特定するためにメカニズムを提供しなければなりません。 名前衝突がどう扱われるかを指定するのが必要です。
Motivation: Already in SMIv2 and SPPI.
動機: 既にSMIv2とSPPIで。
4.1.9 Namespace Control
4.1.9 名前空間コントロール
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: There must be a hierarchical, centrally-controlled
namespace for standard named items, and a distributed namespace
must be supported to allow vendor-specific naming and to assure
unique module names across vendors and organizations.
記述: 標準の命名された項目のための階層的で、中心で制御された名前空間があるに違いありません、そして、業者特有の命名を許して、業者と組織の向こう側にユニークなモジュール名を保証するために分配された名前空間を支持しなければなりません。
Motivation: Need to unambiguously identify definitions of various
kinds. Some SMI implementations have problems with different
objects from multiple modules but with the same name.
Furthermore, the probability of module name clashes rises over
time (for example, different vendors defining their own SYSTEM-
MIB).
動機: 明白に様々な種類の定義を特定するのが必要です。 いくつかのSMI実現には、複数のモジュールからの異なった物にもかかわらず、同じ名前に関する問題があります。 その上、モジュール名前衝突の確率は時間がたつにつれて、(例えば、それら自身のSYSTEM- MIBを定義する異なった業者)を上ります。
Notes: An example naming scheme is the one employed by the Java
programming language with a central naming authority assigning the
top-level names.
注意: 例の命名計画はトップレベル名を割り当てる主要な命名権威でJavaプログラミング言語によって使われたものです。
4.1.10 Modules
4.1.10 モジュール
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must provide a mechanism for uniquely identifying
a module, and specifying the status, contact person, revision
information, and the purpose of a module.
記述: SMIngはモジュール、および状態を指定する連絡窓口を唯一特定するためのメカニズム、改正情報、およびモジュールの目的を提供しなければなりません。
SMIng must provide mechanisms to group definitions into modules
and it must provide rules for referencing definitions from other
modules.
SMIngは定義をモジュールに分類するためにメカニズムを提供しなければなりません、そして、それは他のモジュールから定義に参照をつけるための規則を提供しなければなりません。
Elliott, et al. Informational [Page 8] RFC 3216 SMIng Objectives December 2001
エリオット、他 [8ページ]情報のRFC3216SMIng目的2001年12月
Motivation: Modularity and independent advancement of documents.
動機: ドキュメントのモジュール方式と独立している進歩。
Notes: Text about module conformance has been moved to Section
4.1.11.
注意: モジュール順応に関するテキストはセクション4.1.11に動かされました。
4.1.11 Module Conformance
4.1.11 モジュール順応
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must provide mechanisms to detail the minimum
requirements implementers must meet to claim conformance to a
standard based on the module.
記述: SMIngは必要最小限implementersがモジュールに基づく規格に順応を要求するために満たさなければならない詳細にメカニズムを提供しなければなりません。
Motivation: Ability to convey conformance requirements.
動機: 順応要件を伝える能力。
4.1.12 Arbitrary Unambiguous Identities
4.1.12 任意の明白なアイデンティティ
Type: basic
以下をタイプしてください。 基本的
From: SMI
From: SMI
Description: SMI allows the use of OBJECT-IDENTITIES to define
unambiguous identities without the need of a central registry.
SMI uses OIDs to represent values that represent references to
such identities. SMIng needs a similar mechanism (a statement to
register identities, and a base type to represent values).
記述: SMIはOBJECT-IDENTITIESの使用に中央の登録の必要性なしで明白なアイデンティティを定義させます。 SMIは、そのようなアイデンティティの参照を表す値を表すのにOIDsを使用します。 SMIngは同様のメカニズム(アイデンティティを示す声明、および値を表すベースタイプ)を必要とします。
Motivation: SMI Compatibility.
動機: SMIの互換性。
Notes: This is an obvious objective. Additionally, everything not on
the wire, such as modules, will still be assigned OIDs.
注意: これは明白な目的です。 さらに、モジュールなどのように、それでも、OIDsはすべてがワイヤへの割り当てでないののようになるでしょう。
It is yet to be determined whether the assignment of the OID
occurs within the core or within a protocol-specific mapping.
OIDの課題がコア以内かプロトコル特有のマッピングの中に起こるか否かに関係なく、それはまだ断固としていません。
4.1.13 Protocol Independence
4.1.13 プロトコル独立
Type: basic
以下をタイプしてください。 基本的
From: Charter
From: 憲章
Description: SMIng must define data definitions in support of the
SNMP and COPS-PR protocols. SMIng may define data definitions in
support of other protocols.
記述: SMIngはSNMPとCOPS-PRプロトコルを支持してデータ定義を定義しなければなりません。 SMIngは他のプロトコルを支持してデータ定義を定義するかもしれません。
Elliott, et al. Informational [Page 9] RFC 3216 SMIng Objectives December 2001
エリオット、他 [9ページ]情報のRFC3216SMIng目的2001年12月
Motivation: So data definitions may be used with multiple protocols
and multiple versions of those protocols.
動機: それで、データ定義は複数のプロトコルとそれらのプロトコルの複数のバージョンと共に使用されるかもしれません。
4.1.14 Protocol Mapping
4.1.14 プロトコルマッピング
Type: basic
以下をタイプしてください。 基本的
From: Charter
From: 憲章
Description: The SMIng working group, in accordance with the working
group charter, will define mappings of protocol independent data
definitions to protocols based upon installed implementations.
The SMIng working group can define mappings to other protocols as
long as this does not impede the progress on other objectives.
記述: ワーキンググループ特許に従って、SMIngワーキンググループはプロトコルへの独立しているデータ定義がインストールされた実現に基礎づけたプロトコルに関するマッピングを定義するでしょう。 これが他の目的で進行を妨げない限り、SMIngワーキンググループは他のプロトコルとマッピングを定義できます。
Motivation: SMIng working group charter.
動機: SMIngワーキンググループ特許。
4.1.15 Translation to Other Data Definition Languages
4.1.15 他のデータ定義言語への翻訳
Type: basic
以下をタイプしてください。 基本的
From: Charter
From: 憲章
Description: SMIng language constructs must, wherever possible, be
translatable to SMIv2 and SPPI. At the time of standardization of
a SMIng language, existing SMIv2 MIBs and SPPI PIBs on the
standards track will not be required to be translated to the SMIng
language. New MIBs/PIBs will be defined using the SMIng language.
記述: SMIng言語構築はどこでも、可能であるところでSMIv2とSPPIに翻訳できるに違いありません。 SMIng言語の標準化時点で、標準化過程の上の既存のSMIv2 MIBsとSPPI PIBsによってSMIng言語に翻訳される必要はないでしょう。 新しいMIBs/PIBsは、SMIng言語を使用することで定義されるでしょう。
Motivation: Provide best-effort backwards compatibility for existing
tools while not placing an unnecessary burden on MIBs/PIBs that
are already on the standards track.
動機: 標準化過程の上に既にあるMIBs/PIBsに不必要な負担を置いていない間、ベストエフォート型遅れている互換性を既存のツールに供給してください。
4.1.16 Base Data Types
4.1.16 基地のデータ型
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must support the base data types Integer32,
Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString,
and OID.
記述: SMIngはベースデータ型のInteger32、Unsigned32、Integer64、Unsigned64、Enumeration、Bits、OctetString、およびOIDを支持しなければなりません。
Motivation: Most are already common. Unsigned64 and Integer64 are in
SPPI, must fix in SMI. Note that Counter and Gauge types can be
regarded as derived types instead of base types.
動機: 大部分は既に一般的です。 Unsigned64とInteger64はSPPIにあって、SMIで修理しなければなりません。 CounterとGaugeタイプをベースタイプの代わりに派生型と見なすことができることに注意してください。
Elliott, et al. Informational [Page 10] RFC 3216 SMIng Objectives December 2001
エリオット、他 [10ページ]情報のRFC3216SMIng目的2001年12月
4.1.17 Enumerations
4.1.17 列挙
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must provide support for enumerations. Enumerated
values must be a part of the enumeration definition.
記述: SMIngは列挙のサポートを提供しなければなりません。 列挙された値は列挙定義の一部でなければなりません。
Motivation: SMIv2 already has enumerated numbers.
動機: SMIv2は既に数を列挙しました。
Notes: Enumerations have the implicit constraint that the attribute
is constrained to the values for the enumeration.
注意: 列挙には、属性が列挙のために値に抑制されるという暗黙の規制があります。
4.1.18 Discriminated Unions
4.1.18 差別された組合
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: SMIng must support discriminated unions.
記述: SMIngは差別された組合を支持しなければなりません。
Motivation: Allows to group related attributes together, such as
InetAddressType (discriminator) and InetAddress, InetAddressIPv4,
InetAddressIPv6 (union). The lack of discriminated unions has
also lead to relatively complex sparse table work-around in some
DISMAN mid-level manager MIBs.
動機: InetAddressType(弁別器)やInetAddress、InetAddressIPv4、InetAddressIPv6(組合)などのように関連する属性を分類するのを許容します。 また、差別された組合の不足はいくつかのDISMAN中間レベルのマネージャMIBsに比較的複雑なまばらなテーブル次善策にリードを持っています。
Notes: Discriminated unions have the property that the union
attribute type is constrained by the value of the discriminator
attribute.
注意: 差別された組合には、抑制される組合属性が弁別器属性の値でタイプする特性があります。
4.1.19 Instance Pointers
4.1.19 例のポインタ
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must allow specifying pointers to instances (i.e.,
a pointer to a particular attribute in a row).
記述: SMIngは例(すなわち、並んでいる特定の属性へのポインタ)にポインタを指定させなければなりません。
Motivation: It is common practice in MIBs and PIBs to point to other
instances.
動機: MIBsとPIBsでは、他の例を示すのは、一般的な習慣です。
Elliott, et al. Informational [Page 11] RFC 3216 SMIng Objectives December 2001
エリオット、他 [11ページ]情報のRFC3216SMIng目的2001年12月
4.1.20 Row Pointers
4.1.20 ポインタを船をこいで運んでください。
Type: align
以下をタイプしてください。 並んでください。
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must allow specifying pointers to rows.
記述: SMIngはポインタを列まで指定させなければなりません。
Motivation: It is common practice in MIBs and PIBs to point to other
rows (see RowPointer, PIB-REFERENCES).
動機: MIBsとPIBsでは、他の列を示すのは、一般的な習慣(RowPointer、PIB-REFERENCESを見る)です。
4.1.21 Constraints on Pointers
4.1.21 ポインタにおける規制
Type: align
以下をタイプしてください。 並んでください。
From: SPPI
From: SPPI
Description: SMIng must allow specifying the types of objects to
which a pointer may point.
記述: SMIngはポインタが向けられるかもしれない物のタイプを指定させなければなりません。
Motivation: Allows code generators to detect and reject illegal
pointers automatically. Can also be used to automatically
generate more reasonable implementation-specific data structures.
動機: コード生成プログラムが自動的に不法なポインタを検出して、拒絶するのを許容します。 また、より妥当な実現特有のデータ構造を自動的に発生させるのに使用できます。
Notes: Pointer constraints are a special case of attribute value
constraints (Section 4.3.2) in which the prefix of the OID (row or
instance pointer) value is limited to be only from a particular
table.
注意: ポインタ規制はOID(列か例のポインタ)価値の接頭語が単に特定のテーブルからあるように制限される属性値規制(セクション4.3.2)の特別なケースです。
4.1.22 Base Type Set
4.1.22 基地のタイプはセットしました。
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must support a fixed set of base types of fixed
size and precision. The list of base types must not be extensible
unless the SMI itself changes.
記述: SMIngは固定セットの固定サイズと精度のベースタイプを支持しなければなりません。 SMI自身が変化しない場合、ベースタイプのリストは広げることができるはずがありません。
Motivation: Interoperability.
動機: 相互運用性。
4.1.23 Extended Data Types
4.1.23 拡張データ型
Type: align
以下をタイプしてください。 並んでください。
From: SMI, SPPI
From: SMI、SPPI
Elliott, et al. Informational [Page 12] RFC 3216 SMIng Objectives December 2001
エリオット、他 [12ページ]情報のRFC3216SMIng目的2001年12月
Description: SMIng must support a mechanism to derive new types,
which provide additional semantics (e.g., Counters, Gauges,
Strings, etc.), from base types. It may be desirable to also
allow the derivation of new types from derived types. New types
must be as restrictive or more restrictive than the types that
they are specializing.
記述: SMIngは追加意味論(例えば、Counters、Gauges、Stringsなど)を提供する新しいタイプを引き出すためにメカニズムをサポートしなければなりません、ベースタイプから。 また、派生型から新しいタイプの派生を許容するのは望ましいかもしれません。 新しいタイプは、彼らが専門にしているタイプより制限しているか、または制限しているに違いありません。
Motivation: SMI uses application types and textual conventions. SPPI
uses derived types.
動機: SMIはアプリケーションタイプと原文のコンベンションを使用します。 SPPIは派生型を使用します。
4.1.24 Units, Formats, and Default Values of Defined Types and
Attributes
4.1.24 定義されたタイプと属性のユニット、形式、およびデフォルト値
Type: fix
以下をタイプしてください。 フィックス
From: NMRG
From: NMRG
Description: In SMIv2 OBJECT-TYPE definitions may contain UNITS and
DEFVAL clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-HINTs.
In a similar fashion units and default values must be applicable
to defined types and format information must be applicable to
attributes.
記述: SMIv2 OBJECT-TYPEでは、定義はUNITSを含むかもしれません、そして、DEFVAL節とTEXTUAL-CONVENTIONsはDISPLAY-HINTsを含むかもしれません。 同様にユニットとデフォルト値は定義されたタイプに適切であるに違いありません、そして、形式情報は属性に適切であるに違いありません。
Motivation: Some MIBs introduce TCs such as KBytes and every usage of
the TC then specifies the UNITS "KBytes". It would simplify
things if the UNITS were attached to the type definition itself.
動機: いくつかのMIBsがKBytesなどのTCsを導入します、そして、次に、TCのあらゆる使用法がUNITS「キロバイト」を指定します。 UNITSが型定義自体に取り付けられるなら、それはものを簡素化するでしょうに。
Notes: The SMIng WG must clarify the behavior if an attribute uses a
defined type and both, the attribute and the defined type, have
units/default/format information.
注意: 両方(属性と定義されたタイプ)には、属性が定義されたタイプを使用するなら、SMIng WGは振舞いをはっきりさせなければならなくて、ユニット/デフォルト/形式情報があります。
4.1.25 Table Existence Relationships
4.1.25 テーブル存在関係
Type: align
以下をタイプしてください。 並んでください。
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in the
SNMP/COPS-PR protocol mappings.
記述: SMIngはSNMP/COPS-PRプロトコルマッピングでINDEX、AUGMENTS、およびEXTENDSをサポートしなければなりません。
Motivation: These three table existence relationships exist either in
the SMIv2 or the SPPI.
動機: これらの3つのテーブル存在関係がSMIv2かSPPIに存在しています。
Elliott, et al. Informational [Page 13] RFC 3216 SMIng Objectives December 2001
エリオット、他 [13ページ]情報のRFC3216SMIng目的2001年12月
4.1.26 Table Existence Relationships (2)
4.1.26 テーブル存在関係(2)
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: SMIng must support EXPANDS and REORDERS relationships in
the SNMP/COPS-PR protocol mappings.
記述: SMIngは、EXPANDSとREORDERSがSNMP/COPS-PRプロトコルマッピングでの関係であるとサポートしなければなりません。
Motivation: A REORDERS statement allows indexing orders to be
swapped. An EXPANDS statement formally states that there is a 1:n
existence relationship between table rows.
動機: REORDERS声明で、交換されるために命令に索引をつけます。 EXPANDS声明は、1があると正式に述べます: テーブル行の間のn存在関係。
4.1.27 Attribute Groups
4.1.27 属性グループ
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: An attribute group is a named, reusable set of
attributes that are meaningful together. It can be reused as the
type of attributes in other attribute groups (see also Section
4.1.28). This is similar to `structs' in C.
記述: 属性グループは命名されて、再利用できるセットの一緒に重要な属性です。 他の属性における、属性のタイプが分類するとき(また、セクション4.1.28を見てください)、それを再利用できます。 これはCで'structs'と同様です。
Motivation: Required to map the same grouping of attributes into SNMP
and COPS-PR tables. Allows to do index reordering without having
to redefine the attribute group. Allows to group related
attributes together (e.g. InetAddressType, InetAddress).
動機: SNMPとCOPS-PRテーブルに属性の同じ組分けを写像するのが必要です。 属性グループを再定義する必要はなくてインデックス再命令をするのを許容します。 一緒に関連する属性(例えば、InetAddressType、InetAddress)を分類するのを許容します。
The ability to group attributes provides an indication that the
attributes are meaningful together.
属性を分類する能力は属性が重要であるという指示を一緒に、提供します。
4.1.28 Containment
4.1.28 封じ込め
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: SMIng must provide support for the creation of new
attribute groups from attributes of more basic types and
potentially other attribute groups.
記述: SMIngは、より多くの基本型と潜在的に他の属性グループの属性から新しい属性グループの創設のサポートを提供しなければなりません。
Motivation: Simplifies the reuse of attribute groups such as
InetAddressType and InetAddress pairs.
動機: InetAddressTypeやInetAddress組などの属性グループの再利用を簡素化します。
Elliott, et al. Informational [Page 14] RFC 3216 SMIng Objectives December 2001
エリオット、他 [14ページ]情報のRFC3216SMIng目的2001年12月
Notes: Containment has the implicit existence constraint that if an
instance of a contained attribute group exists, then the
corresponding instance of the containing attribute group must also
exist.
注意: 封じ込めには、また、含まれた属性グループのインスタンスが存在しているなら含んでいる属性グループの対応するインスタンスが存在しなければならないという暗黙の存在規制があります。
4.1.29 Single Inheritance
4.1.29 ただ一つの継承
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: SMIng must provide support for mechanisms to extend
attribute groups through single inheritance.
記述: メカニズムがただ一つの継承を通して属性グループを広げるように、SMIngはサポートを提供しなければなりません。
Motivation: Allows to extend attribute groups, like a generic
DiffServ scheduler, with attributes for a specific scheduler,
without cut&paste.
動機: 特定のスケジューラのために属性でカットとペーストなしでジェネリックDiffServスケジューラのような属性グループを広げるのを許容します。
Notes: Single inheritance with multiple levels (e.g., C derives from
B, and B derives from A) must be allowed.
注意: 複数のレベル(例えば、CがBに由来しています、そして、BがAに由来している)があるただ一つの継承を許容しなければなりません。
Inheritance has the implicit existence constraint that if an
instance of a derived attribute group exists, then the
corresponding instance of the base attribute group must also
exist.
継承には、また、派生している属性グループのインスタンスが存在しているなら基本属性グループの対応するインスタンスが存在しなければならないという暗黙の存在規制があります。
Inheritance could help to add attributes to an attribute group
that are specific to a certain protocol mapping and do not appear
in the protocol-neutral attribute group.
継承は、あるプロトコルマッピングに特定であり、プロトコル中立の属性に現れない属性グループへの属性が分類されると言い足すのを助けるかもしれません。
4.1.30 Reusable vs. Final Attribute Groups
4.1.30 最終的な属性グループに対して再利用できます。
Type: new
以下をタイプしてください。 新しい
From: NMRG, WG
From: NMRG、WG
Description: SMIng must differentiate between "final" and reusable
attribute groups, where the reuse of attribute groups covers
inheritance and containment.
記述: SMIngは「最終的で」再利用できる属性グループを区別しなければなりません。そこでは、属性グループの再利用が継承と封じ込めをカバーします。
Motivation: This information gives people more information how
attribute groups can and should be used. It hinders them from
misusing them.
動機: この情報は属性グループがどのように使用できて、使用されるべきであるかというより多くの情報を人々に教えます。 それは、彼らがそれらを誤用するのを妨げます。
Notes: This objective attempts to convey the idea that some attribute
groups are not meant to stand on their own and instead only make
sense if contained within another attribute group.
注意: この目的は、一人で立って、別の属性グループの中に含まれているならいくつかの属性グループが代わりに理解できることになっているだけではないという考えを伝えるのを試みます。
Elliott, et al. Informational [Page 15] RFC 3216 SMIng Objectives December 2001
エリオット、他 [15ページ]情報のRFC3216SMIng目的2001年12月
4.1.31 Events
4.1.31 イベント
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must provide mechanisms to define events which
identify significant state changes.
記述: SMIngは、重要な州の変化を特定するイベントを定義するためにメカニズムを提供しなければなりません。
Motivation: These represent the protocol-independent events that lead
to SMI notifications or SPPI reports.
動機: これらはSMI通知かSPPIレポートにつながるプロトコルから独立しているイベントを表します。
4.1.32 Creation/Deletion
4.1.32 作成/削除
Type: align
以下をタイプしてください。 並んでください。
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must support a mechanism to define
creation/deletion operations for instances. Specific
creation/deletion errors, such as INSTALL-ERRORS, must be
supported.
記述: SMIngは、インスタンスのための作成/削除操作を定義するためにメカニズムをサポートしなければなりません。 INSTALL-ERRORSなどの特定の作成/削除誤りをサポートしなければなりません。
Motivation: Available for row creation in SMI, and available in SPPI.
動機: SMIで行作成に利用可能であって、SPPIで利用可能です。
4.1.33 Range and Size Constraints
4.1.33 範囲とサイズ規制
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must allow specifying range and size constraints
where applicable.
記述: SMIngは適切であるところで範囲とサイズ規制を指定させなければなりません。
Motivation: The SMI and SPPI both support range and size constraints.
動機: SMIとSPPIは、範囲とサイズが規制であるとともにサポートします。
4.1.34 Uniqueness
4.1.34 ユニークさ
Type: basic
以下をタイプしてください。 基本的
From: SPPI
From: SPPI
Description: SMIng must allow the specification of uniqueness
constraints on attributes. SMIng must allow the specification of
multiple independent uniqueness constraints.
記述: SMIngは属性に一意性制約の仕様を許容しなければなりません。 SMIngは複数の独立している一意性制約の仕様を許容しなければなりません。
Elliott, et al. Informational [Page 16] RFC 3216 SMIng Objectives December 2001
エリオット、他 [16ページ]情報のRFC3216SMIng目的2001年12月
Motivation: Knowledge of the uniqueness constraints on attributes
allows to verify protocol specific mappings (e.g. INDEX clauses).
The knowledge can also be used by code generators to improve
generated implementation-specific data structures.
動機: 属性における規制で、プロトコルの特定のマッピング(例えば、INDEX節)について確かめるユニークさに関する知識。 また、知識はコード生成プログラムによって使用されて、発生している実装特有のデータ構造を改良できます。
4.1.35 Extension Rules
4.1.35 拡大規則
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Description: SMIng must provide clear rules how one can extend SMIng
modules without causing interoperability problems "over the wire".
記述: SMIngは1つがどう「ワイヤ」で相互運用性問題を引き起こさないでSMIngモジュールを広げることができるかを明確なルールに提供しなければなりません。
Motivation: SMIv2 and SPPI have extension rules.
動機: SMIv2とSPPIには、拡大規則があります。
4.1.36 Deprecate Use of IMPLIED Keyword
4.1.36 暗示しているキーワードの使用を非難してください。
Type: fix
以下をタイプしてください。 フィックス
From: WG
From: WG
Description: The SMIng SNMP mapping must deprecate the use of the
IMPLIED indexing schema.
記述: SMIng SNMPマッピングはIMPLIEDインデックス図式の使用を非難しなければなりません。
Motivation: IMPLIED is confusing and most people don't understand it.
The solution (IMPLIED) is worse than the problem it is trying to
solve and therefore for the sake of simplicity, the use of IMPLIED
should be deprecated.
動機: IMPLIEDは混乱させています、そして、ほとんどの人々はそれを理解していません。 ソリューション(IMPLIED)はそれが解決しようとしている問題より悪いです、そして、簡単にするために、したがって、IMPLIEDの使用は推奨しないはずです。
4.1.37 No Redundancy
4.1.37 冗長がありません。
Type: fix
以下をタイプしてください。 フィックス
From: NMRG
From: NMRG
Description: The SMIng language must avoid redundancy.
記述: SMIng言語は冗長を避けなければなりません。
Motivation: Remove any textual redundancy for things like table
entries and SEQUENCE definitions, which only increase
specifications without providing any value.
動機: テーブル項目とSEQUENCE定義のようなもののためのあらゆる原文の冗長を取り除いてください。(どんな値も提供しないで、ものは仕様を増強するだけです)。
4.1.38 Compliance and Conformance
4.1.38 承諾と順応
Type: basic
以下をタイプしてください。 基本的
From: SMI, SPPI
From: SMI、SPPI
Elliott, et al. Informational [Page 17] RFC 3216 SMIng Objectives December 2001
エリオット、他 [17ページ]情報のRFC3216SMIng目的2001年12月
Description: SMIng must provide a mechanism for compliance and
conformance specifications for protocol-independent definitions as
well as for protocol mappings.
記述: SMIngはプロトコルから独立している定義のためのコンプライアンスと順応仕様とプロトコルマッピングにメカニズムを提供しなければなりません。
Motivation: This capability exists in SMIv2 and SPPI. The NMRG
proposal has the ability to express much of this information at
the protocol-dependent layer. Some compliance or conformance
information may be protocol-independent, therefore there is also a
need to be able to express this information protocol-independent
part.
動機: この能力はSMIv2とSPPIに存在しています。 NMRG提案には、プロトコル依存する層にこの情報の多くを表す能力があります。 何らかのコンプライアンスか順応情報がプロトコルから独立しているかもしれない、したがって、また、この情報のプロトコルから独立している部分を表すことができる必要があります。
4.1.39 Allow Refinement of All Definitions in Conformance Statements
4.1.39 順応声明における、すべての定義の気品を許容してください。
Type: fix
以下をタイプしてください。 フィックス
From: WG
From: WG
Description: SMIv2, RFC 2580, Section 3.1 says:
記述: SMIv2、RFC2580、セクション3.1は言います:
The OBJECTS clause, which must be present, is used to specify
each object contained in the conformance group. Each of the
specified objects must be defined in the same information
module as the OBJECT-GROUP macro appears, and must have a MAX-
ACCESS clause value of "accessible-for-notify", "read-only",
"read-write", or "read-create".
OBJECTS節(存在していなければならない)は、順応グループに含まれた各オブジェクトを指定するのに使用されます。 または、それぞれの指定されたオブジェクトがOBJECT-GROUPマクロと同じ情報モジュールが現れて、マックスACCESS節価値を持たなければならない定義されたコネでなければならない、「アクセスしやすい、通知、」 「読書唯一であっ」て、「読書して書く」、「読書して作成します」。
The last sentence forbids to put a not-accessible INDEX object
into an OBJECT-GROUP. Hence, you can not refine its syntax in a
compliance definition. For more details, see
http://www.ibr.cs.tu-bs.de/ietf/smi-errata/
最後の文は、アクセスしやすくないINDEXを置くために、OBJECT-GROUPに反対するように禁じます。 したがって、あなたは承諾定義における構文を改善できません。 その他の詳細に関しては、 http://www.ibr.cs.tu-bs.de/ietf/smi-errata/ を見てください。
Motivation: This error should not be repeated in SMIng.
動機: SMIngでこの誤りを繰り返すべきではありません。
4.1.40 Categories
4.1.40 カテゴリ
Type: basic
以下をタイプしてください。 基本的
From: SPPI
From: SPPI
Description: SMIng must provide a mechanism to group definitions into
subject categories. Concrete instances may only exist in the
scope of a given subject category or context.
記述: SMIngは、定義を対象のカテゴリに分類するためにメカニズムを提供しなければなりません。 具体的なインスタンスは与えられた対象のカテゴリか文脈の範囲に存在するだけであるかもしれません。
Motivation: To scope the categories to which a module applies. In
SPPI this is used to allow a division of labor between multiple
client types.
動機: 範囲へのモジュールが適用されるカテゴリ。 SPPIでは、これは、複数のクライアントタイプの間の分業を許すのに使用されます。
Elliott, et al. Informational [Page 18] RFC 3216 SMIng Objectives December 2001
エリオット、他 [18ページ]情報のRFC3216SMIng目的2001年12月
4.1.41 Core Language Keywords vs. Defined Identifiers
4.1.41 コア言語キーワード対定義された識別子
Type: fix
以下をタイプしてください。 フィックス
From: NMRG
From: NMRG
Description: In SMI and SPPI modules some language keywords (macros
and a number of basetypes) have to be imported from different SMI
language defining modules, e.g. OBJECT-TYPE, MODULE-IDENTITY,
Integer32 must to be imported from SNMPv2-SMI and TEXTUAL-
CONVENTION must be imported from SNMPv2-TC, if used. MIB authors
are continuously confused about these import rules. In SMIng only
defined identifiers must be imported. All SMIng language keywords
must be implicitly known and there must not be a need to import
them from any module.
記述: SMIとSPPIモジュールで、いくつかの言語キーワード(マクロと多くのbasetypes)がSNMPv2-SMIからインポートされるためにモジュール、例えば、OBJECT-TYPE、Integer32が定義しなければならないMODULE-IDENTITYを定義する異なったSMI言語からインポートされなければなりません、そして、SNMPv2-TCからTEXTUAL- CONVENTIONをインポートしなければなりません、使用されるなら。 MIB作者はこれらの輸入規則に関して絶え間なく混乱します。 定義されただけであるSMIngでは、識別子をインポートしなければなりません。 それとなくすべてのSMIng言語キーワードを知っていなければなりません、そして、どんなモジュールからもそれらをインポートする必要があるはずがありません。
Motivation: Reduce confusion. Clarify the set of language keywords.
動機: 混乱を抑えてください。 言語キーワードのセットをはっきりさせてください。
4.1.42 Instance Naming
4.1.42 インスタンス命名
Type: align
以下をタイプしてください。 並んでください。
From: SMI, SPPI
From: SMI、SPPI
Description: Instance naming in SMIv2 and SPPI is different. SMIng
must align the instance naming (either in the protocol neutral
model or the protocol mappings).
記述: SMIv2とSPPIでのインスタンス命名は異なっています。 SMIngは(どちらかプロトコルにおける中立モデルかプロトコルマッピング)を命名するインスタンスを並べなければなりません。
Motivation: COPS-PR and SNMP have different instance identification
schemes that must be handled.
動機: COPS-PRとSNMPには、扱わなければならない異なったインスタンス識別体系があります。
Notes: A solution requires to investigate how close the naming
schemes dictated by the protocols are. Perhaps it is feasible to
have a single instance naming scheme in both SNMP and COPS-PR,
even though the current SPPI and SMIv2 are different.
注意: ソリューションは、プロトコルによって書き取られた命名体系がどれくらい近いかを調査するのを必要とします。 恐らく、SNMPとCOPS-PRの両方にただ一つのインスタンス命名体系を持っているのは可能です、現在のSPPIとSMIv2は異なっていますが。
4.1.43 Length of Identifiers
4.1.43 識別子の長さ
Type: fix
以下をタイプしてください。 フィックス
From: NMRG
From: NMRG
Description: The allowed length of the various kinds of identifiers
must be extended from the current `should not exceed 32' (maybe
even from the `must not exceed 64') rule.
記述: 電流が'32を超えるべきでない'という(多分'必須からさえ、64を'超えていません)規則から許容長さに関する様々な種類に関する識別子を広げなければなりません。
Motivation: Reflect current practice of definitions.
動機: 定義の現在の習慣を反映してください。
Elliott, et al. Informational [Page 19] RFC 3216 SMIng Objectives December 2001
エリオット、他 [19ページ]情報のRFC3216SMIng目的2001年12月
Notes: The 32-rule was added back in the days where compilers could
not deal with long identifiers. This rule is continuously
violated these days and it does not make sense to keep it.
注意: コンパイラが長い識別子に対処できなかったところで32規則が数日に加えられました。 この規則は最近絶え間なく違反されます、そして、それはそれを保つ意味になりません。
4.1.44 Assign OIDs in the Protocol Mappings
4.1.44 プロトコルマッピングでOIDsを割り当ててください。
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: SMIng must not assign OIDs to reusable definition of
attributes, attribute groups, events, etc. Instead, SNMP and
COPS-PR mappings must assign OIDs to the mapped items.
記述: SMIngは属性、属性グループ、イベントなどの再利用できる定義にOIDsを割り当ててはいけません。 代わりに、SNMPとCOPS-PRマッピングは写像している項目にOIDsを割り当てなければなりません。
Motivation: Assignment of OIDs in protocol neutral definitions can
complicate reuse. OIDs of synonymous attributes are not the same
in SMI and SPPI definitions. MIBs and PIBs are already registered
in different parts of the OID namespace.
動機: プロトコルの中立定義における、OIDsの課題は再利用を複雑にすることができます。 同義の属性のOIDsはSMIとSPPI定義で同じではありません。 MIBsとPIBsはOID名前空間の異なった部品に既に登録されます。
4.2 Nice-to-Have Objectives
4.2 持つために良い目的
This section represents the list of recommended objectives that would be nice to have. However, these are not automatically thought of as accepted objectives as, for example, they may entail a non-trivial amount of work in underlying protocols to support or they may be regarded as less important than other contradicting objectives that are accepted.
このセクションは持つために良いお勧めの目的のリストを表します。 しかしながら、重要な仕事量を伴うかもしれないので目的を受け入れるとき考えられて、これらはサポートする基本的なプロトコルで自動的にそうではありませんそれらが、受け入れられる目的に矛盾しながら、重要であるより他と見なされるかもしれません。
4.2.1 Methods
4.2.1 メソッド
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: SMIng should support a mechanism to define method
signatures (parameters, return values, exception) that are
implemented on agents.
記述: SMIngは、エージェントの上で実装されるメソッド署名(パラメタ、リターン値、例外)を定義するためにメカニズムをサポートするはずです。
Motivation: Methods are needed to support the definition of
operational interfaces such as found in [RFC2925] (ping,
traceroute and lookup operations). Also, the ability to define
constructor/destructor interfaces could address issues such as
encountered with SNMP's RowStatus solution.
動機: メソッドが、[RFC2925](ピング、トレースルート、およびルックアップ操作)で見つけられて、操作上のインタフェースの定義をサポートするのに必要です。 また、建設者/塵芥焼却炉インタフェースを定義する能力はSNMPのRowStatusソリューションで遭遇するように問題を扱うかもしれません。
Notes: Is it possible to do methods without changing the underlying
protocol? There is agreement that methods are useful, but
disagreement upon the impact - one end of the spectrum sees this
as a documentation tool for existing SNMP capabilities, while the
注意: 基本的なプロトコルを変えないでメソッドをするのは可能ですか? メソッドが役に立つという協定、しかし、不一致が影響にあります--スペクトルの片端は既存のSNMP能力のためにドキュメンテーションツールであるとこれをみなします。
Elliott, et al. Informational [Page 20] RFC 3216 SMIng Objectives December 2001
エリオット、他 [20ページ]情報のRFC3216SMIng目的2001年12月
other end sees this as a protocol update, moving forward, to
natively support methods. The proposal is to wait and see if this
is practical to implement as a syntax that is useful and can map
to the protocol.
ネイティブにメソッドをサポートするために前方へ動いて、他の終わりはプロトコルアップデートであるとこれをみなします。 提案はこれが役に立つ構文として実装するために実用的であり、プロトコルに写像されることができるかどうか成り行きを見守ることです。
4.2.2 Unions
4.2.2 組合
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: SMIng should support a standard format for unions.
記述: SMIngは組合のために標準書式をサポートするはずです。
Motivation: Allows an attribute to contain one of many types of
values. The lack of unions has also lead to relatively complex
sparse table work-around in some DISMAN mid-level managers.
Despite from discriminated unions (see Section 4.1.18), this kind
of union has no accompanied explicit discriminator attribute that
selects the union's type of value.
動機: 属性が多くのタイプの値の1つを含むのを許容します。 また、組合の不足は何人かのDISMAN中間レベルのマネージャに比較的複雑なまばらなテーブル回避策にリードを持っています。 差別された組合(セクション4.1.18を見る)から、この種類の組合には、組合の価値のタイプを選ぶどんな伴っている明白な弁別器属性もありません。
Notes: The thought is that SNMP and COPS-PR can already support
unions because they do not care about what data type goes with a
particular OID.
注意: 考えは彼らがどんなデータ型が特定のOIDを伴うか気にかけないのでSNMPとCOPS-PRが既に組合をサポートすることができるということです。
4.2.3 Float Data Types
4.2.3 データ型を広めてください。
Type: new
以下をタイプしてください。 新しい
From: WG, NMRG
From: WG、NMRG
Description: SMIng should support the base data types Float32,
Float64, Float128.
記述: SMIngは、ベースデータ型がFloat32、Float64、Float128であるとサポートするはずです。
Motivation: Missing base types can hurt later on, because they cannot
be added without changing the language, even as an SMIng
extension. Lesson learned from the SMIv1/v2 debate about
Counter64/Integer64/...
動機: 行方不明のベースタイプは後で痛むことができます、言語を変えないで彼らを加えることができないので、SMIng拡張子としてさえ。 レッスンはCounter64/Integer64/のSMIv1/v2討論から学びました…
Notes: There is no mention as to whether or not the underlying
protocols will have to natively support float data types. This is
left to the mapping. However, it seems imperative that the float
data type needs to be added to the set of intrinsic types in the
SMIng language at the creation of the language as it will be
impossible to add them later without changing the language.
注意: 基本的なプロトコルがネイティブに浮遊物のデータ型をサポートしなければならないかどうかに関して言及が全くありません。 これはマッピングに残されます。 しかしながら、浮遊物のデータ型が、後で言語を変えないで彼らを加えるのが不可能であるので、言語の作成で本質的なタイプのセットにSMIng言語で追加される必要であるのは必須に見えます。
Elliott, et al. Informational [Page 21] RFC 3216 SMIng Objectives December 2001
エリオット、他 [21ページ]情報のRFC3216SMIng目的2001年12月
4.2.4 Comments
4.2.4 コメント
Type: fix
以下をタイプしてください。 フィックス
From: NMRG
From: NMRG
Description: The syntax of comments should be well defined,
unambiguous and intuitive to most people, e.g., the C++/Java `//'
syntax.
記述: 'コメントの構文は、ほとんどの人々、例えば、C++/Javaによく定義されていて、明白であって、直感的であるべきである''//構文。
Motivation: ASN.1 Comments (and thus SMI and SPPI comments) have been
a constant source of confusion. People use arbitrary lengthy
strings of dashes (`-----------') in the wrong assumption that
this is always treated as a comment. Some implementations try to
accept these syntactically wrong constructs which even raises
confusion. We should get rid of this problem.
動機: ASN.1Comments(そして、その結果、SMIとSPPIコメント)は混乱の一定の源です。 人々がダッシュの任意の長いストリングを使用する、('、-、-、-、-、-、-、-、-、-、--、'、)、これがいつもコメントとして扱われるという間違った仮定で。 いくつかの実装がこれらのシンタクス上間違った構造物を受け入れようとします(混乱を上げさえします)。 私たちはこの問題を取り除くべきです。
Notes: If the SMIng working group adopts a C-like syntax, then the
C++/Java single-line comment should be adopted as well.
注意: SMIngワーキンググループがCのような構文を採用するなら、また、Java C++/単線コメントは採用されるべきです。
4.2.5 Referencing Tagged Rows
4.2.5 タグ付けをされた通りに参照をつけること。
Type: align
以下をタイプしてください。 並んでください。
From: SPPI
From: SPPI
Description: PIB and MIB row attributes reference a group of entries
in another table. SPPI formalizes this by introducing PIB-TAG and
PIB-REFERENCES clauses. This functionality should be retained in
SMIng.
記述: PIBとMIBは別のもののエントリーのグループが見送る属性参照をこぎます。 SPPIは、PIB-TAGとPIB-REFERENCES節を紹介することによって、これを正式にします。 この機能性はSMIngで保有されるべきです。
Motivation: SPPI formalizes tag references. Some MIBs also use tag
references (see SNMP-TARGET-MIB in RFC2573) even though SMIv2 does
not provide a formal notation.
動機: SPPIはタグ参照を正式にします。 SMIv2は正式な記法を提供しませんが、また、いくつかのMIBsがタグ参照(RFC2573のSNMP-TARGET-MIBを見る)を使用します。
4.2.6 Arrays
4.2.6 配列
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: SMIng should allow the definition of a SEQUENCE OF
attributes or attribute groups (Section 4.1.27).
記述: SMIngはSEQUENCE OFの定義に属性を許容するはずであるか、または(セクション4.1.27)を属性グループに許容するはずです。
Motivation: The desire for the ability to have variable-length,
multi-valued objects.
動機: 可変長で、マルチ評価されるようにする能力に関する願望は反対します。
Elliott, et al. Informational [Page 22] RFC 3216 SMIng Objectives December 2001
エリオット、他 [22ページ]情報のRFC3216SMIng目的2001年12月
Notes: Some issues with arrays are still unclear. As long as there
are no concepts to solve the problems with access semantics (how
to achieve atomic access to arbitrary-sized arrays) and their
mappings to SNMP and COPS-PR protocol operations, arrays cannot be
more than a nice to have objective.
注意: 配列のいくつかの問題がまだ不明瞭です。 アクセス意味論(どう任意サイズの配列への原子アクセスを達成する)に関する問題とそれらのマッピングをSNMPとCOPS-PRプロトコル操作に解決するために概念が全くない限り、1以上が目的を持つために良かったなら、配列は限り。
4.2.7 Internationalization
4.2.7 国際化
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: Informational text (DESCRIPTION, REFERENCE, ...) should
allow i18nized encoding, probably UTF-8.
記述: 情報のテキスト(記述、REFERENCE)はi18nizedコード化、たぶんUTF-8を許容するべきです。
Motivation: There has been some demand for i18n in the past. The BCP
RFC 2277 demands for internationalization.
動機: 過去のi18nの何らかの需要がありました。 国際化のBCP RFC2277要求。
Notes: Although English is the language of IETF documents, SMIng
should allow other languages for private use.
注意: 英語はIETFドキュメントの言語ですが、SMIngは私的使用目的で他の言語を許容するはずです。
4.2.8 Separate Data Modelling from Management Protocol Mapping
4.2.8 管理プロトコルマッピングからモデル化される別々のデータ
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: It should be possible to separate the domain specific
data modelling work from the network management protocol specific
work.
記述: ネットワーク管理プロトコルの特定の仕事とドメインの特定のデータモデル化仕事を切り離すのは可能であるべきです。
Motivation: Today, working groups designing new protocols are forced
to care about the design of SNMP MIBs and maybe COPR-PR PIBs to
manage the new protocol. This means that experts in a specific
domain are faced with details of at least one foreign (network
management) technology. This leads to hard work and long revision
processes. It would be a win to separate the task of pure data
modelling which can be done by the domain experts easily from the
network management protocol specific mappings. The mapping to
SNMP and/or COPS-PR can be done (a) later separately and (b) by
network management experts. This required NM expertise no longer
hinders the progress of the domain specific working groups.
動機: 今日、新しいプロトコルを設計するワーキンググループは、新しいプロトコルを管理するためにやむを得ずSNMP MIBsと多分COPR-PR PIBsのデザインを心配します。 これは、特定のドメインの専門家は少なくとも1つの外国(ネットワークマネージメント)技術の詳細に直面していることを意味します。 これはきつい仕事と長い改正プロセスに通じます。 それは、ドメインの専門家がネットワーク管理プロトコルの特定のマッピングから容易にできる純粋なデータモデル化がタスクを切り離すためには勝利でしょう。 (a) 後で別々にSNMPへのマッピング、そして/または、COPS-PRができます。そして、ネットワークマネージメントの専門家による(b)。 この必要なニューメキシコ専門的技術はもうドメインの特定のワーキンググループの進歩を妨げません。
Elliott, et al. Informational [Page 23] RFC 3216 SMIng Objectives December 2001
エリオット、他 [23ページ]情報のRFC3216SMIng目的2001年12月
4.3 Rejected Objectives
4.3 拒絶された目的
This section represents the list of objectives that were rejected during the discussion on the objectives. Those objectives that have been rejected need not be addressed by SMIng. This does not imply that they must not be addressed.
このセクションは目的についての議論の間に拒絶された目的のリストを表します。 拒絶されたそれらの目的はSMIngによって扱われる必要はありません。 これは、それらを扱ってはいけないのを含意しません。
4.3.1 Incomplete Translations
4.3.1 不完全な翻訳
Type: basic
以下をタイプしてください。 基本的
From: WG
From: WG
Description: Reality sucks. All information expressed in SMIng may
not be directly translatable to a MIB or PIB construct, but all
information should be able to be conveyed in documentation or via
other mechanisms.
記述: 現実はしゃぶられます。 SMIngで言い表されたすべての情報が直接MIBかPIB構造物に翻訳できるかもしれないというわけではありませんが、すべての情報がドキュメンテーションか他のメカニズムで運ぶことができるべきです。
Motivation: SMIng working group requires this to ease transition.
動機: SMIngワーキンググループは、変遷を緩和するためにこれを必要とします。
Notes: The SMIng language itself cannot require what compilers do
that translate SMIng into something else. So this seems to fall
out of the scope of the current working group charter.
注意: SMIng言語自体は前提となることができません。どんなコンパイラがそれをするかがSMIngを他の何かに翻訳します。 それで、これは現在のワーキンググループ特許の範囲から落下するように思えます。
4.3.2 Attribute Value Constraints
4.3.2 属性値規制
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: SMIng should provide mechanisms to formally specify
constraints between values of multiple attributes.
記述: SMIngは、正式に複数の属性の値の間の規制を指定するためにメカニズムを提供するはずです。
Motivation: Constraints on attribute values occur where one or more
attributes may affect the value or range of values for another
attribute. One such relationship exists in IPsec, where the type
of security algorithm determines the range of possible values for
other attributes such as the corresponding key size.
動機: 属性値における規制は1つ以上の属性が別の属性のための値の値か範囲に影響するかもしれないところに起こります。 そのような関係の1つはIPsecに存在しています。そこでは、セキュリティアルゴリズムのタイプが対応する主要なサイズなどの他の属性のために可能な値の範囲を決定します。
Notes: This objective as is has been rejected as too general, and
therefore virtually impossible to implement. However, constraints
that are implicit with discriminated unions (Section 4.1.18),
enumerated types (Section 4.1.17), pointer constraints (Section
4.1.21)), etc., are accepted and these implicit constraints are
mentioned in the respective objectives.
注意: そのままなこの目的は実装することができないくらい一般的であって、したがって、実際には不可能であると拒絶されました。 しかしながら、差別された組合(セクション4.1.18)、列挙型(セクション4.1.17)、指針規制(セクション4.1.21)などに暗黙であることの規制を受け入れます、そして、それぞれの目的でこれらの暗黙の規制について言及します。
Elliott, et al. Informational [Page 24] RFC 3216 SMIng Objectives December 2001
エリオット、他 [24ページ]情報のRFC3216SMIng目的2001年12月
4.3.3 Attribute Transaction Constraints
4.3.3 属性トランザクション規制
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: SMIng should provide a mechanism to formally express
that certain sets of attributes can only be modified in
combination.
記述: SMIngは、組み合わせで、あるセットの属性を変更できるだけであると正式に言い表すためにメカニズムを提供するはずです。
Motivation: COPS-PR always does operations on table rows in a single
transaction. There are SMIv2 attribute combinations that need to
be modified together (such as InetAddressType, InetAddress).
動機: COPS-PRは単一取引におけるテーブル行のときにいつも操作します。 一緒に変更される必要があるSMIv2属性組み合わせ(InetAddressType、InetAddressなどの)があります。
Notes: Alternative is to either use Methods (Section 4.2.1) or assume
that all attributes in an attribute group (Section 4.1.27) are to
be considered atomic.
注意: 選択肢は、Methods(セクション4.2.1)を使用するか、または属性グループ(セクション4.1.27)におけるすべての属性が原子であると考えられることであると仮定することです。
4.3.4 Method Constraints
4.3.4 メソッド規制
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: Method definitions should provide constraints on
parameters.
記述: メソッド定義はパラメタで規制を提供するべきです。
Motivation: None.
動機: なし。
Notes: Unless methods (Section 4.2.1) are done, there is no use for
this. Furthermore, this objective has not been motivated by any
proponent.
注意: メソッド(セクション4.2.1)が完了していない場合、これのための無駄があります。 その上、この目的はどんな提案者によっても動機づけられていません。
4.3.5 Agent Capabilities
4.3.5 エージェント能力
Type: basic
以下をタイプしてください。 基本的
From: SMI
From: SMI
Description: SMIng should provide mechanisms to describe agent
implementations.
記述: SMIngは、エージェント実装について説明するためにメカニズムを提供するはずです。
Motivation: To permit manager to determine variations from the
standard for an implementation.
動機: マネージャが実装の規格からの変化を決定することを許可するために。
Notes: Agent capabilities should not be part of SMIng, but should
instead be a separate capabilities table.
注意: エージェント能力はSMIngの一部であるべきではありませんが、代わりに別々の能力テーブルであるべきです。
Elliott, et al. Informational [Page 25] RFC 3216 SMIng Objectives December 2001
エリオット、他 [25ページ]情報のRFC3216SMIng目的2001年12月
4.3.6 Relationships
4.3.6 関係
Type: new
以下をタイプしてください。 新しい
From: NMRG, WG
From: NMRG、WG
Description: Ability to formally depict existence dependency, value
dependency, aggregation, containment, and other relationships
between attributes or attribute groups.
記述: 正式に属性か属性の間の存在の依存、値の依存、集合、封じ込め、および他の関係について表現する能力は分類されます。
Motivation: Helps humans to understand the conceptual model of a
module. Helps implementers of MIB compilers to generate more
`intelligent' code.
動機: 人間がモジュールの概念モデルを理解しているのを助けます。 MIBコンパイラのimplementersが、より'知的な'コードを生成するのを助けます。
Notes: This objective was deemed too general to be useful and instead
the individual types of relationship objectives (e.g., pointers,
inheritance, containment, etc.) are evaluated on a case-by-case
basis with the specific relationships deemed useful being included
as accepted objectives.
注意: この目的は役に立つように思えないほど一般的であると考えられました、そして、受け入れられた目的として含まれていて、代わりに、ケースバイケースで特定の関係が役に立つと考えられている状態で、独特のタイプの関係目的(例えば、指針、継承、封じ込めなど)は評価されます。
4.3.7 Procedures
4.3.7 手順
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: SMIng should support a mechanism to formally define
procedures that are used by managers when interacting with an
agent.
記述: SMIngは、正式にエージェントと対話するときマネージャによって用いられる手順を定義するためにメカニズムをサポートするはずです。
Motivation: None.
動機: なし。
Notes: This objective has not been motivated by any proponent.
注意: この目的はどんな提案者によっても動機づけられていません。
4.3.8 Associations
4.3.8 協会
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: SMIng should provide mechanisms to explicitly specify
associations.
記述: SMIngは、明らかに協会を指定するためにメカニズムを提供するはずです。
Motivation: None.
動機: なし。
Notes: This objective has not been motivated by any proponent.
注意: この目的はどんな提案者によっても動機づけられていません。
Elliott, et al. Informational [Page 26] RFC 3216 SMIng Objectives December 2001
エリオット、他 [26ページ]情報のRFC3216SMIng目的2001年12月
4.3.9 Association Cardinalities
4.3.9 協会基数
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: Cardinalities between associations should be formally
defined.
記述: 関係の間の基数は正式に定義されるべきです。
Motivation: If you have an association between attribute groups A and
B, the cardinality of A indicates how many instances of A may be
associated with a single instance of B. Our discussions in
Minneapolis indicated that we want to convey "how many" instances
are associated in order to define the best mapping algorithm -
whether a new table, a single pointer, etc. For example, do we
use RowPointer or an integer index into another table? Do we map
to a table that holds instances of the association/relationship
itself?
動機: あなたが間の協会にグループAとBを結果と考えさせるなら、Aの基数は、AのいくつのインスタンスがB.のただ一つのインスタンスに関連しているかもしれないかを示します。「how many」のインスタンスを伝えたいと思う示されたミネアポリスでのOur議論は最も良いマッピングアルゴリズムを定義するために関連しています--、新しいテーブル、ただ一つの指針など 例えば、私たちはRowPointerか整数インデックスを別のテーブルに使用しますか? 私たちは協会/関係自体のその船倉インスタンスをテーブルに写像しますか?
Notes: Without associations (Section 4.3.8), this has no use.
注意: 協会(セクション4.3.8)がなければ、これには、無駄があります。
4.3.10 Categories of Modules
4.3.10 モジュールのカテゴリ
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: The SMIng documents should give clear guidance on which
kind of information (with respect to generality, type/attribute
group/extension/..) should be put in which kind of a module.
記述: どの種類の情報(一般性(タイプ/属性group/extension/)に関する)がモジュールのどの種類に置かれるべきであるかに関してSMIngドキュメントは明確な指導を与えるはずです。
E.g., in SMIv2 we don't like to import Utf8String from SYSAPPL-
MIB, but we also do not like to introduce a redundant definition.
例えば、SMIv2では、SYSAPPL- MIBからUtf8Stringをインポートするのが好きではありませんが、また、私たちは、余分な定義を導入するのが好きではありません。
A module review process should probably be described that ensures
that generally useful definitions do not go into device or service
specific modules.
一般に役に立つ定義がデバイスに入りもしませんし、特定のモジュールを修理もしないのを確実にするモジュール吟味の過程はたぶん説明されるべきです。
Motivation: Bad experience with SMIv2.
動機: SMIv2の悪い経験。
Notes: It is not clear how this can be done with the language to be
created by SMIng WG.
注意: 言語でどのようにこれをするか、そして、SMIng WGが作成できるのは、明確ではありません。
4.3.11 Mapping Modules to Files
4.3.11 モジュールをファイルに写像すること。
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Elliott, et al. Informational [Page 27] RFC 3216 SMIng Objectives December 2001
エリオット、他 [27ページ]情報のRFC3216SMIng目的2001年12月
Description: There should be a clear statement how SMIng modules are
mapped to files (1:1, n:1?) and how files should be named (by
module name in case of 1:1 mapping?).
記述: モジュールがファイル(n: 1:1、1?)に写像されるという明確な声明どのようにSMIngとファイルがどう命名されるべきであるかが(1:1マッピングの場合のモジュール名で?)あるべきです。
Motivation: SMI implementations show up a variety of filename
extensions (.txt, .smi, .my, none). Some expect all modules in a
single file, others don't. This makes it more difficult to
exchange modules.
動機: SMI実現はさまざまなファイル名拡大(.txt、.smi、なにもの.my)に目立っています。 或るものは一列ですべてのモジュールを予想して、他のものはそうしません。 これで、モジュールを交換するのは、より難しくなります。
Notes: This is just an implementation detail and is best left to a
BCP and not made a part of the language definition.
注意: これは、ただ実現の詳細であり、BCPに残したのが最も良く、言語定義の一部になりませんでした。
4.3.12 Simple Grammar
4.3.12 簡単な文法
Type: new
以下をタイプしてください。 新しい
From: NMRG
From: NMRG
Description: The grammar of the language should be as simple as
possible. It should be free of exception rules. A measurement of
simplicity is shortness of the ABNF grammar.
記述: 言語の文法はできるだけ簡単であるべきです。 それには、例外の原則があるべきではありません。 簡単さの測定はABNF文法の短かさです。
Motivation: Ease of implementation. Ease of learning/understanding.
動機: 実現の容易さ。 学習容易性/理解。
Notes: This seems like an obvious objective, however shortness of the
ABNF grammar is not necessarily a reflection of the simplicity of
the grammar.
注意: これは明白な目的のように見えて、しかしながら、ABNF文法の短かさは必ず文法の簡単さの反映であるというわけではありません。
4.3.13 Place of Module Information
4.3.13 モジュール情報の場所
Type: fix
以下をタイプしてください。 フィックス
From: NMRG
From: NMRG
Description: Module specific information (organization, contact,
description, revision information) should be bound to the module
itself and not to an artificial node (like SMIv2 MODULE-IDENTITY).
記述: モジュール特殊情報(組織、接触、記述、改正情報)は人工のノード(SMIv2 MODULE-IDENTITYのような)ではなく、モジュール自体に縛られるべきです。
Motivation: Simplicity and design cleanup.
動機: 簡単さとデザインクリーンアップ。
Notes: This does not seem to be a problem with the current SMI.
Although simplification is a good thing, this detail is not
considered an objective.
注意: これは現在のSMIに関する問題であるように思えません。 簡素化は良いものですが、この詳細は目的であると考えられません。
Elliott, et al. Informational [Page 28] RFC 3216 SMIng Objectives December 2001
エリオット、他 [28ページ]情報のRFC3216SMIng目的2001年12月
4.3.14 Module Namespace
4.3.14 モジュール名前空間
Type: new
以下をタイプしてください。 新しい
From: WG
From: WG
Description: Currently the namespace of modules is flat and there is
no structure in module naming causing the potential risk of name
clashes. Possible solutions:
記述: 現在の、モジュールの名前空間は平坦です、そして、名前衝突の危険人物を引き起こすモジュール命名には構造が全くありません。 可能な解決策:
* Assume module names are globally unique (just as SMIv1/v2),
just give some recommendations on module names.
* モジュール名がグローバルにユニークであると(ちょうどSMIv1/v2としての)仮定してください、そして、まさしくモジュール名におけるいくつかの推薦をお願いします。
* Force all organizations, WGs and vendors to apply a name prefix
(e.g. CISCO-GAGA-MIB, IETF-DISMAN-SCRIPT-MIB?).
* すべての組織、WGs、および業者に名前接頭語(例えば、シスコ-GAGA-MIB、IETF-DISMAN-SCRIPT-MIB?)を適用させてください。
* Force enterprises to apply a prefix based on the enterprise
number (e.g. ENT2021-SOME-MIB).
* 企業に企業番号(例えば、ENT2021-SOME-MIB)に基づく接頭語を適用させてください。
* Put module names in a hierarchical domain based namespace (e.g.
DISMAN-SCRIPT-MIB.ietf.org).
* 階層的なドメインに基づいている名前空間(例えば、DISMAN-SCRIPT-MIB.ietf.org)にモジュール名を入れてください。
Motivation: Reduce risk of module name clashes.
動機: モジュール名前衝突の危険を減少させてください。
Notes: Some aspects of this objective overlap with other objectives
(namespace control (Section 4.1.9)) and other aspects were thought
best left to a BCP.
注意: この目的のいくつかの局面が他の目的(名前空間コントロール(セクション4.1.9))に重なりました、そして、他の局面はBCPに残すのが最も良いと考えられました。
4.3.15 Hyphens in Identifiers
4.3.15 識別子のハイフン
Type: fix
以下をタイプしてください。 フィックス
From: NMRG
From: NMRG
Description: There has been some confusion whether hyphens are
allowed in SMIv2 identifiers: Module names are allowed to contain
hyphens. Node identifiers usually are not. But for example
`mib-2' is a frequently used identifier that contains a hyphen due
to its SMIv1 origin, when hyphen were not disallowed. Similarly,
a number of named numbers of enumeration types contain hyphens
violating an SMIv2 rule.
記述: ハイフンがSMIv2識別子で許されているか否かに関係なく、何らかの混乱がありました: モジュール名はハイフンを含むことができます。 通常、ノード識別子はそうではありません。 しかし、例えば、'mib-2'はSMIv1の起源のためハイフンを含む頻繁に使用された識別子です、ハイフンが禁じられなかったとき。 同様に、多くの命名された数の列挙タイプがSMIv2規則に違反するハイフンを含んでいます。
SMIng should simply allow hyphens in all kinds of identifiers. No
exceptions.
SMIngは単にすべての種類の識別子のハイフンを許すはずです。 例外がありません。
Motivation: Reduce confusion and exceptions. Requires, however, that
implementation mappings properly quote hyphens where appropriate.
動機: 混乱と例外を抑えてください。 しかしながら、実現マッピングが適切であるところで適切にハイフンを引用するのが必要です。
Elliott, et al. Informational [Page 29] RFC 3216 SMIng Objectives December 2001
エリオット、他 [29ページ]情報のRFC3216SMIng目的2001年12月
Notes: This nit-picking is not worth to be subject to the discussion
on objectives. However, SMIng should care about the fact that
compilers have to map SMIng to programming languages where a
hyphen is a minus and thus not allowed in identifiers.
注意: このこまかいことへのこだわり、目的についての議論を受けることがあるように価値がありません。 しかしながら、SMIngはコンパイラがハイフンがマイナスである言語をプログラムして、識別子にこのようにして許容されていないのにSMIngを写像しなければならないという事実を心配するはずです。
5. Security Considerations
5. セキュリティ問題
This document defines objectives for a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet.
このドキュメントは経営情報の記述を書いて、読む言語のために目的を定義します。 言語自体はセキュリティ変化もインターネットに与えません。
6. Acknowledgements
6. 承認
Thanks to Dave Durham, whose work on the original NIM (Network Information Model) draft was used in generating this document.
デーヴ・ダラムおかげでは、(ネットワーク情報Model)がオリジナルのNIMへのだれの作業を作成するかはこのドキュメントを作る際に使用されました。
Thanks to Andrea Westerinen for her contributions on the original NIM requirements and SMIng objectives drafts.
彼女の貢献をオリジナルのNIM要件とSMIng目的草稿のときにアンドレアWesterinenをありがとうございます。
7. References
7. 参照
[1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[1] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル(SNMP)」、STD15、RFC1157)は1990がそうするかもしれません。
[2] McCloghrie, K., Case, J., Rose, M. and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.
McCloghrie(K.)がケースに入れる[2]、J.、ローズ、M.、およびS.Waldbusserは「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[3] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS
Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[3] チェン(K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ハーツォグ、S.、Reichmeyer、F.、Yavatkar、R.、およびA.スミス)は、「方針の食糧を供給する(PRを獲得している)用法を獲得します」、RFC3084、2001年3月。
[4] 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.
[4]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[5]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[6]McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[7] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy
Provisioning Information (SPPI)", RFC 3159, August 2001.
[7] McCloghrie、K.、おかげさまで元気です、M.、Seligson、J.、チェン、K.、ハーン、S.、Sahita、R.、スミス、A.、およびF.Reichmeyer、「方針の構造は情報(SPPI)に食糧を供給し」て、RFC3159、2001年8月。
Elliott, et al. Informational [Page 30] RFC 3216 SMIng Objectives December 2001
エリオット、他 [30ページ]情報のRFC3216SMIng目的2001年12月
8. Authors' Addresses
8. 作者のアドレス
Chris Elliott Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA
7025年のクリス・エリオットシスコシステムズキットクリーク道路リサーチトライアングル公園、NC27709米国
EMail: chelliot@cisco.com
メール: chelliot@cisco.com
David Harrington Enterasys Networks 35 Industrial Way P.O. Box 5005 Rochester, NH 03866-5005 USA
デヴィッドハリントンEnterasysは35の産業道P.O. Box5005ニューハンプシャー03866-5005ロチェスター(米国)をネットワークでつなぎます。
EMail: dbh@enterasys.com
メール: dbh@enterasys.com
Jamie Jason Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro, OR 97124 USA
ジェイミージェイソンインテル社MS JF3-206 2111のNeの第25Ave。 ヒルズバロ、または97124米国
EMail: jamie.jason@intel.com
メール: jamie.jason@intel.com
Juergen Schoenwaelder TU Braunschweig Muehlenpfordtstr. 23 38106 Braunschweig Germany
ユルゲンSchoenwaelder TUブラウンシュバイクMuehlenpfordtstr。 23 38106ブラウンシュバイクドイツ
EMail: schoenw@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/
メール: schoenw@ibr.cs.tu-bs.de ユリ: http://www.ibr.cs.tu-bs.de/
Elliott, et al. Informational [Page 31] RFC 3216 SMIng Objectives December 2001
エリオット、他 [31ページ]情報のRFC3216SMIng目的2001年12月
Frank Strauss TU Braunschweig Muehlenpfordtstr. 23 38106 Braunschweig Germany
フランクストラウスTUブラウンシュバイクMuehlenpfordtstr。 23 38106ブラウンシュバイクドイツ
EMail: strauss@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/
メール: strauss@ibr.cs.tu-bs.de ユリ: http://www.ibr.cs.tu-bs.de/
Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH. 03054 USA
ウォルターワイスEllacoyaはメリマク、7ヘンリー・クレイニューハンプシャー博士をネットワークでつなぎます。 03054 米国
EMail: wweiss@ellacoya.com
メール: wweiss@ellacoya.com
Elliott, et al. Informational [Page 32] RFC 3216 SMIng Objectives December 2001
エリオット、他 [32ページ]情報のRFC3216SMIng目的2001年12月
9. Full Copyright Statement
9. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Elliott, et al. Informational [Page 33]
エリオット、他 情報[33ページ]
一覧
スポンサーリンク
