Internet Engineering Task Force (IETF) M. Ellison
Request for Comments: 5935 Ellison Software Consulting
Category: Standards Track B. Natale
ISSN: 2070-1721 MITRE
August 2010
Expressing SNMP SMI Datatypes in XML Schema Definition Language
Abstract
抽象
This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in XML Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism.
このメモは、XMLスキーマ定義（XSD）言語で管理情報（SMI）基本データ型の構造のIETF標準の表現を定義します。このメモの主な目的は、検証メカニズムとしてXSDを使用して、可能な限りSMIに忠実とされているXML文書の生産を可能にするためです。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5935.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5935で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................4
3. Requirements ....................................................4
4. XSD for SMI Base Datatypes ......................................5
5. Rationale .......................................................8
5.1. Numeric Datatypes ..........................................8
5.2. OctetString ................................................9
5.3. Opaque ....................................................10
5.4. IpAddress .................................................10
5.5. ObjectIdentifier ..........................................10
6. Security Considerations ........................................11
7. IANA Considerations ............................................11
7.1. SMI Base Datatypes Namespace Registration .................12
7.2. SMI Base Datatypes Schema Registration ....................12
8. Acknowledgements ...............................................12
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
Numerous use cases exist for expressing the management information described by SMI Management Information Base (MIB) modules in XML [XML]. Potential use cases reside both outside and within the traditional IETF network management community. For example, developers of some XML-based management applications may want to incorporate the rich set of data models provided by MIB modules. Developers of other XML-based management applications may want to access MIB module instrumentation via gateways to SNMP agents. Such applications benefit from the IETF standard mapping of SMI datatypes to XML datatypes via XSD [XMLSchema], [XSDDatatypes].
多数のユースケースは、SMI管理情報ベース（MIB）XMLのモジュール[XML]によって記載された管理情報を表現するために存在します。潜在的なユースケースは外、伝統的なIETFネットワーク管理コミュニティ内の両方に存在します。例えば、いくつかのXMLベースの管理アプリケーションの開発者は、MIBモジュールによって提供されたデータモデルの豊富なセットを組み込みたいことがあります。他のXMLベースの管理アプリケーションの開発者は、SNMPエージェントへのゲートウェイを経由してMIBモジュールインストルメンテーションにアクセスすることもできます。そのようなアプリケーションは、[XSDDatatypes]、XSD [XMLスキーマ]を介して、XMLデータ型にSMIデータ型のIETF標準マッピングの恩恵を受ける。
MIB modules use SMIv2 [RFC2578] to describe data models. For legacy MIB modules, SMIv1 [RFC1155] was used. MIB data conveyed in variable bindings ("varbinds") within protocol data units (PDUs) of SNMP messages use the primitive, base datatypes defined by the SMI.
MIBモジュールは、データモデルを記述するためのSMIv2 [RFC2578]を使用します。従来のMIBモジュールの場合、でSMIv1 [RFC1155]は使用されました。 SNMPメッセージのプロトコルデータユニット内の変数バインディング（「変数バインド」）に搬送MIBデータ（PDUが）SMIによって定義されたプリミティブ、ベースデータ型を使用します。
The SMI allows for the creation of derivative datatypes, "textual conventions" ("TCs") [RFC2579]. A TC has a unique name, has a syntax that either refines or is a base SMI datatype, and has relatively precise application-level semantics. TCs facilitate correct application-level handling of MIB data, improve readability of MIB modules by humans, and support appropriate renderings of MIB data.
SMIは、デリバティブデータ型の作成、「テキストの表記法」（「のTC」）[RFC2579]を可能にします。 TCは、固有の名前を持っているいずれかのリファインやベースSMIデータ型で、かつ比較的正確なアプリケーションレベルのセマンティクスを持つ構文があります。 TCSが、MIBデータの正しいアプリケーションレベルの取り扱いを容易に人間がMIBモジュールの可読性を改善し、MIBデータの適切なレンダリングをサポートします。
Values in varbinds corresponding to MIB objects defined with TC syntax are always encoded as the base SMI datatype underlying the TC syntax. Thus, the XSD mappings defined in this memo provide support for values of MIB objects defined with TC syntax as well as for values of MIB objects defined with base SMI syntax. Using the translation of TC into base SMI datatypes any MIB module that uses TCs can be mapped into XSD using the mappings defined in this memo. For example, for IP addresses (both IPv4 and IPv6), MIB objects defined using the InetAddress TC (as per [RFC4001]) are encoded using the base SMI datatype underlying the InetAddress TC syntax rather than the IpAddress base datatype.
TC構文で定義されたMIBオブジェクトに対応する変数バインドの値は常にTC構文を下地SMIデータ型として符号化されます。したがって、このメモで定義されたXSDマッピングは、TC構文と同様にベースSMI構文で定義されたMIBオブジェクトの値に対して定義されたMIBオブジェクトの値のためのサポートを提供します。ベースSMIにTCの翻訳を使用してのTCを使用する任意のMIBモジュールがこのメモで定義されたマッピングを使用して、XSDにマッピングすることができるデータ型。例えば、IPアドレス（IPv4とIPv6の両方）のために、MIBオブジェクトは、（[RFC4001]の通り）のInetAddress TCを使用して定義のInetAddress TC構文ではなく、IPアドレスの基本データ型の基礎となるベースSMIデータ型を使用して符号化されます。
Various independent schemes have been devised for expressing SMI datatypes in XSD. These schemes exhibit a degree of commonality, especially concerning numeric SMI datatypes, but these schemes also exhibit sufficient differences, especially concerning the non-numeric SMI datatypes, precluding uniformity of expression and general interoperability.
様々な独立したスキームは、XSDにSMIデータ型を表現するために考案されています。これらのスキームは、特に数値SMIデータ型について、共通の度合いを示すが、これらの方式は、特に、非数値SMIデータ型に関する表現し、一般的な相互運用性の均一性を排除し、十分な相違を示します。
Throughout this memo, the term "fidelity" refers to the quality of an accurate, consistent representation of SMI data values and the term "faithful" refers to the quality of reliably reflecting the semantics of SMI data values. Thus defined, the characteristics of fidelity and being faithful are essential to uniformity of expression and general interoperability in the XML representation of SMI data values.
このメモ全体を通して、用語「忠実度」とは、確実にSMIデータ値のセマンティクスを反映の質を指すSMIデータ値の正確で一貫した表現と「忠実」という用語の品質を指します。このように定義され、忠実度と忠実であることの特性が発現し、SMIデータ値のXML表現の一般的な相互運用性の均一性に必須です。
The primary purpose of this memo is to define the standard expression of SMI base datatypes in XML documents that is both uniform and interoperable. This standard expression enables Internet operators, management application developers, and users to benefit from a wider range of management tools and to benefit from a greater degree of unified management. Thus, standard expression enables and facilitates improvements to the timeliness, accuracy, and utility of management information.
このメモの主な目的は、均一性と相互運用性の両方であるXML文書にSMIベースのデータ型の標準式を定義することです。この標準的な発現は、インターネット事業者、管理アプリケーションの開発者、および管理ツールの広い範囲から利益を得ると統一された管理のより大きな程度の恩恵を受けることができます。したがって、標準的な発現を可能にし、管理情報の適時性、正確性、および有用性の改善を促進します。
The overall objective of this memo, and of any related future memos as may be published, is to define the XSD equivalent [XSDDatatypes] of SMIv2 (STD 58) and to encourage XML-based protocols to carry, and XML-based applications to use, the management information defined in SMIv2-compliant MIB modules. The use of a standard mapping from SMIv2 to XML via XSD validation enables and promotes the efficient reuse of existing and future MIB modules and instrumentation by XML-based protocols and management applications.
このメモの全体的な目的、および関連する将来のメモを公表することができるように、SMIv2の（STD 58）の[XSDDatatypes]同等のXSDを定義し、実行するためにXMLベースのプロトコルを促進するため、およびXMLベースのアプリケーションが使用しますSMIv2の準拠MIBモジュールで定義され、管理情報。 XSD検証を介してXMLへのSMIv2から標準マッピングを使用することは、XMLベースのプロトコルおよび管理アプリケーションによって既存および将来のMIBモジュールと計測の効率的な再利用を可能にし、促進します。
Developers of certain XML-based management applications will find this specification sufficient for their purposes. Developers of other XML-based management applications may need to make more complete reuse of existing MIB modules, requiring standard XSD documents for TCs [RFC2579] and MIB structure [RFC2578]. Memos supporting such requirements are planned, but have not been produced at the time of this writing.
特定のXMLベースの管理アプリケーションの開発者は、その目的のために十分なこの仕様があります。他のXMLベースの管理アプリケーションの開発者のTCのための標準的なXSDの文書を必要とする既存のMIBモジュールのより完全な再利用を行うことが必要になることがあり、[RFC2579]とMIB構造[RFC2578]。このような要件をサポートするメモが予定されていますが、この記事の執筆時点で生産されていません。
Finally, it is worthwhile to note that the goal of fidelity to the SMIv2 standard (STD 58), as specified in the "Requirements" section below, is crucial to this effort. Fidelity leverages the established "rough consensus" of the precise SMIv2 data models contained in MIB modules, and leverages existing instrumentation, the "running code" implementing SMIv2 data models. This effort does not include any redesign of SMIv2 datatypes, data structures or textual conventions in order to overcome known limitations. Such work can be pursued by other efforts.
最後に、下の「要件」セクションで指定されているSMIv2の標準（STD 58）への忠実度の目標は、この取り組みに不可欠であることに注意することは価値があります。忠実度は、MIBモジュールに含まれる正確なSMIv2のデータモデルの確立された「ラフコンセンサス」を活用して、既存のインスツルメンテーション、「実行コード」実施SMIv2のデータモデルを活用します。この取り組みは、既知の制限を克服するためのSMIv2データ型、データ構造またはテキストの表記法のいずれかの再設計が含まれていません。このような作業は、他の努力によって追求することができます。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The following set of requirements is intended to produce XML documents that can be validated via the XSD defined in this specification to faithfully represent values carried "on-the-wire" in SNMP PDUs as defined by the SMI:
要件の以下のセットは、SMIによって定義されるような「オン・ザ・ワイヤ」SNMPのPDUに忠実実施の値を表すために本明細書で定義されたXSDを介して検証することができるXML文書を生成することを意図しています。
R1. All SMI base datatypes MUST have a corresponding XSD datatype.
R1。すべてのSMIの基本データ型は、対応するXSDデータ型を持たなければなりません。
R2. SMIv2 is the normative SMI for this document. Prior to mapping datatypes into XSD, legacy SMIv1 modules MUST be converted (at least logically) in accordance with Section 2.1, inclusive, of the "Coexistence" RFC [RFC3584].
R2。 SMIv2のは、この文書の規範的SMIです。 XSDにマッピングするデータ型の前に、レガシーでSMIv1モジュールは、「共存」RFC [RFC3584]のセクション2.1、包括的に応じて（少なくとも論理的に）変換されなければなりません。
R3. The XSD datatype specified for a given SMI datatype MUST be able to represent all valid values for that SMI datatype.
R3。与えられたSMIデータ型に指定したXSDデータ型は、そのSMIデータ型の有効なすべての値を表すことができなければなりません。
R4. The XSD datatype specified for a given SMI datatype MUST represent any special encoding rules associated with that SMI datatype.
R4。所与SMIデータ型に指定されたXSDデータ型は、SMIデータ型に関連付けられている特別な符号化規則を表現しなければなりません。
R5. The XSD datatype specified for a given SMI datatype MUST include any restrictions on values associated with the SMI datatype.
R5。所与SMIデータ型に指定されたXSDデータ型は、SMIデータ型に関連付けられた値に制限を含まなければなりません。
R6. The XSD datatype specified for a given SMI datatype MUST be the most logical XSD datatype, with the fewest necessary restrictions on its set of values, consistent with the foregoing requirements.
R6。所与SMIデータ型に指定されたXSDデータ型は、上記の要件に合致値のセットに最小限必要な制限が、最も論理的なXSDデータ型でなければなりません。
R7. The XML output produced as a result of meeting the foregoing requirements SHOULD be the most coherent and succinct representation (i.e., avoiding superfluous "decoration") from the perspective of readability by humans.
R7。上記の要件を満たすの結果として生じるXML出力は、最もコヒーレントと簡潔な表現であるべきである（即ち、余分な「装飾」を回避する）人間による可読性の観点から。
This document provides XSD datatype mappings for the SMIv2 base datatypes only -- i.e., the eleven "ObjectSyntax" datatypes defined in RFC 2578. These datatypes -- via tag values defined in the SMIv2 to identify them in varbinds -- constrain values carried "on-the-wire" in SNMP PDUs between SNMP management applications and SNMP agents:
制約値は「上の実施 - RFC 2578でこれらのデータ型を定義し、すなわち、11「ObjectSyntax」データ型 - - のvarbindにそれらを識別するためのSMIv2で定義されたタグ値を経由してこの文書では、唯一のSMIv2ベースデータ型のXSDデータ型のマッピングを提供しますSNMP管理アプリケーションとSNMPエージェント間のSNMP PDUの中-the-ワイヤ」：
o INTEGER, Integer32
O INTEGER、構文Integer32
o Unsigned32, Gauge32
OのUnsigned32、Gauge32
o Counter32
お こうんてｒ３２
o TimeTicks
あなたの時間刻み
o Counter64
お こうんてｒ６４
o OCTET STRING
OオクテットSTRING
o Opaque
不透明
o IpAddress
O IPアドレス
o OBJECT IDENTIFIER
Oオブジェクト識別子
The "BITS" pseudo-type (also referred to as a "construct" in RFC 2578) is treated as a Textual Convention, not a base datatype, for the purpose of this document.
（また、RFC 2578で「構築物」と呼ぶ）、「BITS」疑似型は、この文書の目的のために、テキストの表記法ではなく、基本データ型として扱われます。
BEGIN
ベギン
<?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:smi:base:1.0" targetNamespace="urn:ietf:params:xml:ns:smi:base:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en">
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：XSの= "http://www.w3.org/2001/XMLSchema" のxmlns = "URN：IETF：paramsは：XML ：NS：SMI：ベース：1.0" のtargetNamespace = "壷：IETF：のparams：XML：NS：SMI：ベース：1.0" のelementFormDefault = "資格" attributeFormDefault = "修飾されていない" XML：LANG = "EN">
<xs:annotation> <xs:documentation> Mapping of SMIv2 base datatypes from RFC 2578
<XS：注釈> <XS：ドキュメント> RFC 2578からSMIv2のベースデータ型のマッピング
Contact: Mark Ellison
Organization: Ellison Software Consulting
Address: 38 Salem Road
Atkinson, NH 03811
USA
Telephone: +1 603-362-9270
E-Mail: ietf@EllisonSoftware.com
Contact: Bob Natale Organization: MITRE Address: 300 Sentinel Drive 6th Floor Annapolis Junction, MD 20701 USA Telephone: +1 301-617-3008 E-Mail: rnatale@mitre.org
連絡先：ボブ・ナターレ組織：マイター住所：300センチネルドライブ6階アナポリスジャンクション、MD 20701 USA電話：+1 301-617-3008 Eメール：rnatale@mitre.org
Last Updated: 201002260000Z
最終更新日：201002260000Z
Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2010 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
、に基づき許可されており、中に含まれるライセンス条項に従う、簡体BSDライセンスは、IETFドキュメントに関連IETFトラストの法律規定（のセクション4.Cに記載されている変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用http://trustee.ietf.org/license-info）。
This version of this XML Schema Definition (XSD) document is part of RFC 5935; see the RFC itself for full legal notices.
このXMLスキーマ定義（XSD）ドキュメントのこのバージョンはRFC 5935の一部です。完全な適法な通知についてはRFC自体を参照してください。
</xs:documentation>
</ XS：ドキュメント>
</xs:annotation>
</ XS：注釈>
<xs:simpleType name="INTEGER"> <xs:restriction base="xs:int"/> </xs:simpleType>
<XS：単純型名= "INTEGER"> <XS：制限ベース= "XS：int型" /> </ XS：単純>
<xs:simpleType name="Integer32"> <xs:restriction base="xs:int"/> </xs:simpleType>
<XS：単純型名= "構文Integer32"> <XS：制限ベース= "XS：int型" /> </ XS：単純>
<xs:simpleType name="Unsigned32"> <xs:restriction base="xs:unsignedInt"/> </xs:simpleType>
<XS：単純型名= "Unsigned32の"> <XS：制限ベース= "XS：unsignedInt型" /> </ XS：simpleTypeの>
<xs:simpleType name="Gauge32"> <xs:restriction base="xs:unsignedInt"/> </xs:simpleType>
<XS：単純型名= "Gauge32"> <XS：制限ベース= "XS：unsignedInt型" /> </ XS：simpleTypeの>
<xs:simpleType name="Counter32"> <xs:restriction base="xs:unsignedInt"/> </xs:simpleType>
<XS：単純型名= "Counter32の"> <XS：制限ベース= "XS：unsignedInt型" /> </ XS：simpleTypeの>
<xs:simpleType name="TimeTicks"> <xs:restriction base="xs:unsignedInt"/> </xs:simpleType>
<XS：単純型名= "時間刻み"> <XS：制限ベース= "XS：unsignedInt型" /> </ XS：simpleTypeの>
<xs:simpleType name="Counter64"> <xs:restriction base="xs:unsignedLong"/> </xs:simpleType>
<XS：単純型名= "Counter64の"> <XS：制限ベース= "のxsd：符号なしロング" /> </のxsd：simpleTypeの>
<xs:simpleType name="OctetString"> <xs:restriction base="xs:hexBinary"> <xs:maxLength value="65535"/> </xs:restriction> </xs:simpleType>
<XS：単純型名= "OctetStringに"> <XS：制限ベース= "XS：のhexBinary"> <XS：maxLengthの値= "65535" /> </ XS：制限> </ XS：simpleTypeの>
<xs:simpleType name="Opaque"> <xs:restriction base="xs:hexBinary"/> </xs:simpleType>
<XS：単純型名= "不透明"> <XS：制限ベース= "XS：のhexBinary" /> </ XS：simpleTypeの>
<xs:simpleType name="IpAddress"> <xs:restriction base="xs:string"> <xs:pattern value= "(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3} ([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"/> </xs:restriction> </xs:simpleType>
<XS：単純型名= "IPアドレス"> <XS：制限ベース= "XS：文字列"> <XS：パターン値=「（（[0-9] | [1-9] [0-9] | 1 [ 0-9] [0-9] | 2 [0-4] [0-9] | 25 [0-5]）\）{3}（[0-9] | [1-9] [0- 9] | 1 [0-9] [0-9] | 2 [0-4] [0-9] | 25 [0-5]） "/> </ XS：制限> </ XS：simpleTypeの>
<xs:simpleType name="ObjectIdentifier"> <xs:restriction base="xs:string"> <xs:pattern value= "(([0-1](\.[1-3]?[0-9]))| (2\.(0|([1-9]\d*)))) (\.(0|([1-9]\d*))){0,126}"/> </xs:restriction> </xs:simpleType>
<XS：単純型名= "ObjectIdentifier"> <XS：制限ベース= "XS：文字列"> <XS：？パターン値=「（（[0-1]（\ [1-3] [0-9] ））|（2 \（0 |（[1-9] \ D *））））（\（0 |。（[1-9] \ D *）））{0126} "/> </ XS ：制限> </ XS：単純>
</xs:schema> END
</ XS：スキーマ> END
The XSD datatypes, including any specified restrictions, were chosen based on fit with the requirements specified earlier in this document, and with attention to simplicity while maintaining fidelity to the SMI. Also, the "canonical representations" (i.e., refinements of the "lexical representations") documented in the W3C XSD specification [XMLSchema], [XSDDatatypes] are assumed.
SMIへの忠実度を維持しながら、指定した任意の制限を含むXSDデータ型は、このドキュメントの指定要件に適合に基づいて選択、そしてシンプルに注意を払ってました。また、「正規表現は、」（すなわち、「語彙表現」の改良）W3C XSD仕様[XMLスキーマ]に記載され、[XSDDatatypes]が想定されます。
All of the numeric XSD datatypes specified in the previous section -- INTEGER, Integer32, Unsigned32, Gauge32, Counter32, TimeTicks, and Counter64 -- comply with the relevant requirements
INTEGER、構文Integer32、Unsigned32の、Gauge32、Counter32の、時間刻み、およびCounter64の - - 前のセクションで指定された数値XSDデータ型のすべての関連要件に準拠
o They cover all valid values for the corresponding SMI datatypes.
Oこれらは、対応するSMIデータ型のすべての有効値をカバーしています。
o They comply with the standard encoding rules associated with the corresponding SMI datatypes.
Oそれらは、対応するSMIデータ型に関連付けられている標準的な符号化規則に従います。
o They inherently match the range restrictions associated with the corresponding SMI datatypes.
O彼らは本質的に対応するSMIデータ型に関連付けられている範囲の制限と一致します。
o They are the most direct XSD datatypes that exhibit the foregoing characteristics relative to the corresponding SMI datatypes (which is why no "restriction" statements -- other than the "base" XSD type -- are required in the XSD).
Oそれらは（XSDに必要とされている - - 「ベース」XSD型以外の理由ない「制限」文ではない）は、対応するSMIデータ型に対して、上記特性を示す最も直接的なXSDデータ型です。
o The XML output produced from the canonical representation of these XSD datatypes is also the most direct from the perspective of readability by humans (i.e., no leading "+" sign and no leading zeros).
OこれらのXSDデータ型の正規表現から生成されたXML出力は、ヒト（即ち、なし先頭の「+」記号なし先行ゼロ）による可読性の観点から最も直接的でもあります。
Special note to application developers: compliance with this schema in an otherwise correct translation from raw ("on-the-wire" representation) SNMP MIB data produces values that are faithful to the original. However, the Gauge32, Counter32, Counter64, and TimeTicks datatypes have special application semantics that must be considered when using their raw values for anything other than display, printing, storage, or transmission of the literal value. RFC 2578 provides the necessary details.
アプリケーション開発者に特別な注意：生からそうでない場合は、正しい訳でこのスキーマの遵守（「オン・ザ・ワイヤー」の表現）SNMP MIBデータを元に忠実な値を生成します。しかし、Gauge32、Counter32の、Counter64の、およびTimeTicksのデータ型は、ディスプレイ以外の、印刷、保存、またはリテラル値を伝送するための彼らの生の値を使用する際に考慮しなければならない特別なアプリケーションのセマンティクスを持ちます。 RFC 2578には、必要な詳細を提供します。
This XSD datatype corresponds to the SMI "OCTET STRING" datatype.
このXSDデータ型は、SMI「オクテット文字列」データ型に対応しています。
Several independent schemes for mapping SMI datatypes to XSD have used the XSD "string" type to represent "OCTET STRING", but this mapping does not conform to the requirements specified in this document. Most notably, "string" cannot faithfully represent all valid values (0 thru 255) that each octet in an "OCTET STRING" can have -- or at least cannot do so in a way that provides for easy human readability of the resulting XML output.
XSDにSMIデータ型をマッピングするためのいくつかの独立したスキームは、「オクテット文字列」を表現するためにXSD「文字列」タイプを使用しているが、このマッピングは、この文書で指定された要件に準拠していません。あるいは少なくとも結果のXML出力の容易な可読性のために提供した方法でそれを行うことはできません - 最も顕著なのは、「文字列は」忠実「オクテットSTRING」内の各オクテットが持つことができることを、すべての有効な値（255から0）を表すことはできません。
Consequently, the XSD datatype "hexBinary" is specified as the standard mapping of the SMI "OCTET STRING" datatype. In hexBinary, each octet is encoded as two hexadecimal digits; the canonical representation limits the set of allowed hexadecimal digits to 0-9 and uppercase A-F.
したがって、XSDデータ型「のhexBinaryは、」SMI「オクテットSTRING」データ型の標準的なマッピングとして指定されています。 hexBinaryでは、各オクテットは、2桁の16進数として符号化されます。正規表現は、0-9させ16進数字の組を制限し、-Fを大文字。
The hexBinary representation of "OCTET STRING" complies with the relevant requirements:
「オクテットSTRING」のhexBinary型表現は、関連要件に準拠しています。
o It covers all valid values for the corresponding SMI datatype.
Oそれは、対応するSMIデータ型のすべての有効値をカバーしています。
o It complies with the standard encoding rules associated with the corresponding SMI datatype.
Oは、対応するSMIデータ型に関連付けられている標準的な符号化規則に準拠しています。
o With the "maxLength" restriction to 65535 octets, the XSD datatype specification matches the restrictions associated with the corresponding SMI datatype.
65535オクテット「maxLengthの」制限付きO、XSDデータ型仕様は、対応するSMIデータ型に関連付けられた制限に一致します。
o It is the most direct XSD datatype that exhibits the foregoing characteristics relative to the corresponding SMI datatype (which must allow for any valid binary octet value).
Oそれは、（任意の有効なバイナリオクテットの値を許容しなければならない）、対応するSMIデータ型に対して上記特性を示す最も直接的なXSDデータ型です。
o The XML output produced from the canonical representation of this XSD datatype is not optimal with respect to readability by humans; however, that is a consequence of the SMI datatype itself. Where human readability is more of a concern, it is likely that the actual MIB objects in question will be represented by textual conventions that limit the set of values that will be included in the OctetStrings and will, thus, bypass the hexBinary typing.
OこのXSDデータ型の正規表現から生成されたXML出力は、人間による可読性に関して最適ではありません。しかし、それはSMIデータ型自体の結果です。人間の読みやすさが問題の多い場合には、問題の実際のMIBオブジェクトがOctetStringsに含まれますと、このように、hexBinaryでタイピングをバイパスします値のセットを制限するテキストの表記法で表現される可能性があります。
The "hexBinary" XSD datatype is specified as the representation of the SMI "Opaque" datatype generally for the same reasons as "hexBinary" is specified for the "OctetString" datatype:
「hexBinaryで」XSDデータ型は、一般的に「のhexBinary」と同じ理由で「OctetStringに」データ型に指定されたSMI「不透明」データ型の表現として指定されています。
o It covers all valid values for the corresponding SMI datatype.
Oそれは、対応するSMIデータ型のすべての有効値をカバーしています。
o It complies with the standard encoding rules associated with the corresponding SMI datatype.
Oは、対応するSMIデータ型に関連付けられている標準的な符号化規則に準拠しています。
o There are no restriction issues associated with using "hexBinary" for "Opaque".
O「不透明」のために「のhexBinary」を使用して関連付けられた制限の問題はありません。
o It is the most direct XSD datatype that exhibits the foregoing characteristics relative to the corresponding SMI datatype (which must allow for any valid binary octet value).
Oそれは、（任意の有効なバイナリオクテットの値を許容しなければならない）、対応するSMIデータ型に対して上記特性を示す最も直接的なXSDデータ型です。
o The XML output produced from the canonical representation of this XSD datatype is not optimal with respect to readability by humans; however, that is a consequence of the SMI datatype itself. Unmediated "Opaque" data is intended for consumption by applications, not humans.
OこのXSDデータ型の正規表現から生成されたXML出力は、人間による可読性に関して最適ではありません。しかし、それはSMIデータ型自体の結果です。 Unmediated「不透明」のデータはアプリケーションではなく、人間が消費するためのものです。
The XSD "string" datatype is the natural choice to represent an IpAddress as XML output. The "pattern" restriction applied in this case results in a dotted-decimal string of four values between "0" and "255" separated by a period (".") character. This pattern also precludes leading zeros.
XSD「文字列」データ型は、XML出力としてIPアドレスを表現するための自然な選択です。この場合に適用「パターン」制限は「0」と「255」ピリオドで区切られた（「」）の文字との間の4つの値のドット区切り文字列になります。このパターンはまた、先行ゼロを排除します。
Note that the SMI relies upon Textual Conventions (TCs) to specify an IPv6 address. As such, the representation of an IPv6 address as an XSD datatype is beyond the scope of this document.
SMIは、IPv6アドレスを指定するには、テキストの表記法（TCS）に依存していることに注意してください。このように、XSDデータ型としてIPv6アドレスの表現は、この文書の範囲外です。
This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER" datatype.
このXSDデータ型は、SMI「オブジェクト識別子」のデータ型に対応しています。
The XSD "string" datatype is also the natural choice to represent an ObjectIdentifier as XML output, for the same reasons as for the IpAddress choice. The "pattern" restriction applied in this case results in a dotted-decimal string of up to 128 elements (referred to as "sub-ids"), each holding an "Unsigned32" integer value.
XSD「文字列」データ型はまた、IPアドレスの選択の場合と同じ理由で、XML出力としてObjectIdentifierを表現するための自然な選択です。この場合に適用「パターン」制限は、それぞれ「Unsigned32の」整数値を保持して、最大128個の要素（「サブIDS」と呼ぶ）のドット区切り文字列になります。
Note that the first two components of an "OBJECT IDENTIFIER" each have a limited range of values as indicated in the XSD pattern restriction and as described in the ASN1.1/BER standard [ASN.1].
XSDパターン制限に示されたように「オブジェクト識別子」それぞれの最初の2つの成分は値の限られた範囲を持っていることに留意されたいASN1.1 / BER標準[ASN.1]に記載されているように。
There are three values allocated for the root node, and at most 39 values for nodes subordinate to a root node value of 0 or 1.
ルートノードは、0または1のルートノード値の下位ノードに対して最も39個の値に割り当てられた3つの値があります。
The minimum length of an "OBJECT IDENTIFIER" is two sub-ids and the representation of a zero-valued "OBJECT IDENTIFIER" is "0.0".
「オブジェクト識別子」の最小長さは、2つのサブIDとゼロ値「オブジェクト識別子」の表現である「0.0」です。
Note that no explicit "minLength" restriction, which would be "3" to allow for the minimum of two sub-ids and a single separating dot, is required since the pattern itself enforces this restriction.
パターン自体は、この制限を強制するので、二つのサブIDと単一の分離点の最小値を可能にするために、「3」であろう明示的な「はminLength」制限、ことに注意が必要です。
Security considerations for any given SMI MIB module will be relevant to any XSD/XML mapping of that MIB module; however, the mapping defined in this document does not itself introduce any new security considerations.
任意のSMI MIBモジュールのセキュリティの考慮事項は、MIBモジュールのいずれかのXSD / XMLマッピングに関連するだろう。しかし、この文書で定義されたマッピングは、自身が任意の新しいセキュリティの考慮事項を導入しません。
If and when proxies or gateways are developed to convey SNMP management information from SNMP agents to XML-based management applications via XSD/XML mapping of MIB modules based on this specification and its planned siblings, special care will need to be taken to ensure that all applicable SNMP security mechanisms are supported in an appropriate manner yet to be determined.
プロキシやゲートウェイは、本明細書及びその計画の兄弟に基づいてMIBモジュールのXSD / XMLマッピングを介したXMLベースの管理アプリケーションにSNMPエージェントからSNMP管理情報を伝えるために開発されたときにすべてのことを確実にするためと、特別な注意がする必要がある場合該当するSNMPセキュリティメカニズムは、まだ決定されるべき適切な方法で支持されています。
In accordance with RFC 3688 [RFC3688], the IANA XML registry has been updated with the following namespace and schema registrations associated with this document:
RFC 3688 [RFC3688]に従い、IANAのXMLレジストリは、この文書に関連付けられている次の名前空間とスキーマの登録で更新されました：
o urn:ietf:params:xml:ns:smi:base:1.0
O骨壷：IETF：のparams：XML：NS：SMI：ベース：1.0
o urn:ietf:params:xml:schema:base:1.0
O骨壷：IETF：のparams：XML：スキーマ：ベース：1.0
This document registers a URI for the SMI Base Datatypes XML namespace in the IETF XML registry. Following the format in RFC 3688, IANA has made the following registration:
この文書は、IETF XMLレジストリのSMI基本データ型のXML名前空間のURIを登録します。 RFC 3688でのフォーマットに続いて、IANAは、以下の登録をしました。
URI: urn:ietf:params:xml:ns:smi:base:1.0
URI：URN：IETF：のparams：XML：NS：SMI：ベース：1.0
Registration Contact: The IESG.
登録連絡先：IESG。
XML: N/A, the requested URI is an XML namespace.
XML：N / Aは、要求されたURIは、XML名前空間があります。
This document registers a URI for the SMI Base Datatypes XML schema in the IETF XML registry. Following the format in RFC 3688, IANA has made the following registration:
この文書は、IETF XMLレジストリのSMI基本データ型XMLスキーマのURIを登録します。 RFC 3688でのフォーマットに続いて、IANAは、以下の登録をしました。
URI: urn:ietf:params:xml:schema:smi:base:1.0
URI：URN：IETF：のparams：XML：スキーマ：SMI：ベース：1.0
Registration Contact: The IESG.
登録連絡先：IESG。
XML: Section 4 of this document.
XML：このドキュメントのセクション4。
Dave Harrington provided strategic and technical leadership to the team that developed this particular specification. Yan Li did much of the research into existing approaches that was used as a baseline for the recommendations in this particular specification.
デイブ・ハリントンは、この特定の仕様を開発したチームに戦略的・技術的なリーダーシップを提供します。ヤン李は、この特定の仕様の勧告のためのベースラインとして使用された既存のアプローチの研究の多くをしました。
This document owes much to "Datatypes for Netconf Data Models" [NETCONF-DATATYPES] and to many other sources (including libsmi and group discussions on the NETCONF mailing lists) developed by those who have researched and published candidate mappings of SMI datatypes to XSD.
この文書は、「NETCONFデータモデルのデータ型」[NETCONF-DATATYPES]およびXSDにSMIデータ型の候補マッピングを調査し、公開している人たちによって開発された（NETCONFのメーリングリスト上libsmiやグループディスカッションを含む）、他の多くの情報源への多くを負っています。
Individuals who participated in various discussions of this topic at IETF meetings and on IETF mailing lists include: Ray Atarashi, Yoshifumi Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Rob Ennes, Mehmet Ersue, David Harrington, Alfred Hines, Eliot Lear, Chris Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andrea Westerinen, and Bert Wijnen.
IETF会議でとIETFメーリングリストで、このトピックの様々な議論に参加した個人が含まれます：レイAtarashi、義文Atarashi、アンディBierman、シャロン・チザム、Avriドリア、ロブEnnes、メフメットErsue、デヴィッド・ハリントン、アルフレッド・ハインズ、エリオット・リア、クリスをLonvick、フェイLyと、ランディPresuhn、ユルゲンSchoenwaelder、アンドレアWesterinen、およびバートWijnen。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
、STD 16、RFC 1155、1990年5月、 "TCP / IPベースのインターネットの管理情報の構造と識別" [RFC1155]ローズ、M.、およびK. McCloghrie、。
[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月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、 "経営情報バージョン2（SMIv2）の構造"、1999年4月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]フライ、R.、レヴィ、D.、Routhier、S.、およびB. Wijnenの、 "バージョン1、バージョン2、及びインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、BCP 74、RFC 3584 、2003年8月。
[XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[XML]ワールド・ワイド・ウェブ・コンソーシアム、 "拡張マークアップ言語（XML）1.0"、W3C XML、1998年2月、<http://www.w3.org/TR/1998/REC-xml-19980210>。
[XMLSchema] World Wide Web Consortium, "XML Schema Part 1: Structures Second Edition", W3C XML Schema, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[XMLスキーマ]ワールド・ワイド・ウェブ・コンソーシアム、 "XMLスキーマパート1：構造第二版"、W3C XML Schemaの、2004年10月、<http://www.w3.org/TR/xmlschema-1/>。
[XSDDatatypes] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C XML Schema, October 2004, <http://www.w3.org/TR/xmlschema-2/>.
[XSDDatatypes]ワールド・ワイド・ウェブ・コンソーシアム、 "XMLスキーマパート2：データ型第二版"、W3C XML Schemaの、2004年10月、<http://www.w3.org/TR/xmlschema-2/>。
[ASN.1] International Organization for Standardization, "Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", International Standard 8825, December 1987.
[ASN.1]国際標準化機構、「情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（ASN.1）のための基本的な符号化規則の仕様」、国際標準8825、1987年12月。
[NETCONF-DATATYPES] Romascanu, D., "Datatypes for Netconf Data Models", Work in Progress, May 2007.
[NETCONF-DATATYPES] Romascanu、D.、 "NETCONFデータモデルのデータ型"、進歩、2007年5月での作業。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001]ダニエル、M.、ハーバーマン、B.、Routhier、S.、およびJ. Schoenwaelder、 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 4001、2005年2月。
Authors' Addresses
著者のアドレス
Mark Ellison Ellison Software Consulting 38 Salem Road Atkinson, NH 03811 USA
マーク・エリソンエリソンソフトウェアコンサルティング38セーラム道路アトキンソン、NH 03811 USA
Phone: +1 603-362-9270 EMail: ietf@ellisonsoftware.com
電話：+1 603-362-9270電子メール：ietf@ellisonsoftware.com
Bob Natale MITRE 300 Sentinel Drive 6th Floor Annapolis Junction, MD 20701 USA
ボブ・ナターレ、MITRE 300センチネルドライブ6階アナポリスジャンクション、MD 20701 USA
Phone: +1 301-617-3008 EMail: rnatale@mitre.org
電話：+1 301-617-3008電子メール：rnatale@mitre.org