[要約] RFC 5935は、SNMP SMIデータ型をXMLスキーマ定義言語で表現するための仕様です。このRFCの目的は、SNMPデータ型をXML形式で表現するための標準化を提供することです。

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

XMLスキーマ定義言語でSNMP SMIデータ型を表現します

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.

Copyright(c)2010 IETF Trustおよび文書著者として特定された人。全著作権所有。

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
        
1. Introduction
1. はじめに

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].

XML [XML]のSMI管理情報ベース(MIB)モジュールによって説明されている管理情報を表現するための多くのユースケースが存在します。潜在的なユースケースは、従来のIETFネットワーク管理コミュニティの外側と内側と内部にあります。たとえば、一部のXMLベースの管理アプリケーションの開発者は、MIBモジュールが提供するリッチな一連のデータモデルを組み込むことをお勧めします。他のXMLベースの管理アプリケーションの開発者は、SNMPエージェントへのゲートウェイを介してMIBモジュールインストゥルメンテーションにアクセスしたい場合があります。このようなアプリケーションは、XSD [XMLSchema]、[XSDDATATYPES]を介して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]を使用してデータモデルを記述します。Legacy MIBモジュールには、SMIV1 [RFC1155]が使用されました。SNMPメッセージのプロトコルデータユニット(PDU)内の可変バインディング(「varbinds」)で伝えられたMIBデータは、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は、派生データ型「テキストコンベンション」(「TCS」)[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オブジェクトに対応するVARBINDSの値は、常にTC構文の基礎となるベースSMIデータ型としてエンコードされます。したがって、このメモで定義されているXSDマッピングは、TC構文で定義されたMIBオブジェクトの値と、ベースSMI構文で定義されたMIBオブジェクトの値をサポートします。TCのベースSMIデータ型への変換を使用すると、TCSを使用するMIBモジュールは、このメモで定義されているマッピングを使用してXSDにマッピングできます。たとえば、IPアドレス(IPv4とIPv6の両方)の場合、InetAddress TC([RFC4001]に従って)を使用して定義されたMIBオブジェクトは、iPaddressベースデータタイプではなく、InetAddress TC Syntaxの基礎となるベース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)のXSD等価[XSDDATATYPES]を定義し、XMLベースのプロトコルを運ぶことを奨励すること、およびXMLベースのアプリケーションを使用することです。、SMIV2準拠のMIBモジュールで定義されている管理情報。XSD検証を介してSMIV2からXMLへの標準マッピングを使用すると、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ベースの管理アプリケーションの開発者は、既存のMIBモジュールをより完全に再利用する必要がある場合があり、TCS [RFC2579]およびMIB構造[RFC2578]の標準XSDドキュメントが必要です。そのような要件をサポートするメモは計画されていますが、この執筆時点では作成されていません。

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)の忠実度の目標は、この取り組みにとって重要であることに注意する価値があります。Fidelityは、MIBモジュールに含まれる正確なSMIV2データモデルの確立された「大まかなコンセンサス」を活用し、SMIV2データモデルを実装する「実行中のコード」である既存の機器を活用します。この取り組みには、既知の制限を克服するためのSMIV2データ型、データ構造、またはテキストの規則の再設計は含まれません。そのような仕事は、他の努力によって追求されることができます。

2. Conventions
2. 規約

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]で説明されているように解釈されます。

3. Requirements
3. 要件

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:

次の一連の要件は、この仕様で定義された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にマッピングする前に、「共存」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出力は、人間による読みやすさの観点から最も一貫性のある簡潔な表現(つまり、余分な「装飾」を回避する)でなければなりません。

4. XSD for SMI Base Datatypes
4. SMIベースデータ型のXSD

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:

このドキュメントは、SMIV2ベースデータ型のみのXSDデータ型マッピングを提供します。つまり、RFC 2578で定義された11の「ObjectSyntax」データ型を提供します。これらのデータ型 - SMIV2で定義されたタグ値を介して、Varbindsでそれらを識別する - -The-Wire "SNMP管理アプリケーションとSNMPエージェントの間のSNMP PDU:

o INTEGER, Integer32

o 整数、整数32

o Unsigned32, Gauge32

o unsigned32、Gauge32

o Counter32

o カウンター32

o TimeTicks

o タイムテックス

o Counter64

o カウンター64

o OCTET STRING

o オクテット文字列

o Opaque

o 不透明

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.

「BITS」擬似タイプ(RFC 2578の「コンストラクト」とも呼ばれます)は、このドキュメントの目的のために、ベースデータ型ではなくテキスト条約として扱われます。

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">
        
     <xs:annotation>
       <xs:documentation>
           Mapping of SMIv2 base datatypes from RFC 2578
        

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

連絡先:マークエリソン組織:エリソンソフトウェアコンサルティングアドレス:38セーラムロードアトキンソン、ニューハンプシャー州03811米国電話:1 603-362-9270電子メール: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電子メール:rnatale@mitre.org

Last Updated: 201002260000Z

最終更新:201002260000Z

Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved.

Copyright(c)2010 IETF TrustおよびCodeの著者として特定された人。全著作権所有。

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).

変更とバイナリ形式での再配布と使用は、変更の有無にかかわらず、IETF Trustの法的規定(IETFドキュメントに関する法的規定)のセクション4.Cに記載されている簡略化されたBSDライセンスに基づいて許可されており、ライセンス条件に従います。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:annotation>
        
     <xs:simpleType name="INTEGER">
       <xs:restriction base="xs:int"/>
     </xs:simpleType>
        
     <xs:simpleType name="Integer32">
       <xs:restriction base="xs:int"/>
     </xs:simpleType>
        
     <xs:simpleType name="Unsigned32">
       <xs:restriction base="xs:unsignedInt"/>
     </xs:simpleType>
        
     <xs:simpleType name="Gauge32">
       <xs:restriction base="xs:unsignedInt"/>
     </xs:simpleType>
        
     <xs:simpleType name="Counter32">
       <xs:restriction base="xs:unsignedInt"/>
     </xs:simpleType>
        
     <xs:simpleType name="TimeTicks">
       <xs:restriction base="xs:unsignedInt"/>
     </xs:simpleType>
        
     <xs:simpleType name="Counter64">
       <xs:restriction base="xs:unsignedLong"/>
     </xs:simpleType>
        
     <xs:simpleType name="OctetString">
       <xs:restriction base="xs:hexBinary">
         <xs:maxLength value="65535"/>
       </xs:restriction>
     </xs:simpleType>
        
     <xs:simpleType name="Opaque">
       <xs:restriction base="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: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:schema> END

</xs:schema> end

5. Rationale
5. 根拠

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.

指定された制限を含むXSDデータ型は、このドキュメントで前述した要件に適合し、SMIの忠実度を維持しながら単純さに注意を払って選択されました。また、W3C XSD仕様[XMLSchema]、[XSDDATATYPES]に文書化された「標準表現」(つまり、「語彙表現」の改良)が想定されています。

5.1. Numeric Datatypes
5.1. 数値データタイプ

All of the numeric XSD datatypes specified in the previous section -- INTEGER, Integer32, Unsigned32, Gauge32, Counter32, TimeTicks, and Counter64 -- comply with the relevant requirements

前のセクションで指定されたすべての数値XSDデータタイプ - 整数、整数、整数32、ゲージ32、カウンター32、タイムテック、およびカウンター64は、関連要件に準拠しています

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 これらは、対応するSMIデータ型に比べて前述の特性を示す最も直接的なXSDデータ型です(これは、「ベース」XSDタイプ以外の「制限」ステートメントが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.

アプリケーション開発者への特別なメモ:RAW(「オンワイヤ」表現)からの正しい翻訳でこのスキーマのコンプライアンスSNMP MIBデータは、オリジナルに忠実な値を生成します。ただし、Gauge32、Counter32、Counter64、およびTimeticksデータ型には、リテラル値の表示、印刷、保存、または送信以外に生の値を使用する場合に考慮する必要がある特別なアプリケーションセマンティクスがあります。RFC 2578は必要な詳細を提供します。

5.2. OctetString
5.2. オクテットストリング

This XSD datatype corresponds to the SMI "OCTET STRING" datatype.

このXSDデータ型は、SMI「Octet String」データタイプに対応しています。

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.

SMIデータタイプをXSDにマッピングするためのいくつかの独立したスキームは、XSD「文字列」タイプを使用して「Octet String」を表すが、このマッピングはこのドキュメントで指定された要件に準拠していない。最も顕著なのは、「文字列」は、「オクテット文字列」の各オクテットが持つことができるすべての有効な値(0 255)を忠実に表すことはできません。。

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「Octet String」データ型の標準マッピングとして指定されています。六角形では、各オクテットは2つの16進数桁としてエンコードされています。標準表現は、許可された16進数桁のセットを0-9および大文字のA-Fに制限します。

The hexBinary representation of "OCTET STRING" complies with the relevant requirements:

「Octet String」の六角表現は、関連する要件に準拠しています。

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.

o 65535オクテットに対する「最大長」制限により、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オブジェクトは、オクテッツストリングスに含まれる値のセットを制限するテキストの規則で表される可能性があります。

5.3. Opaque
5.3. 不透明

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データ型は、「octetString」データ型で「hexbinary」と同じ理由で、一般に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 「Opaque」に「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データ型自体の結果です。媒介されていない「不透明」データは、人間ではなくアプリケーションによる消費を目的としています。

5.4. IpAddress
5.4. IPアドレス

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 "String" Datatypeは、iPaddressをXML出力として表す自然な選択です。この場合に適用された「パターン」制限は、期間(「」)文字で区切られた「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アドレスの表現は、このドキュメントの範囲を超えています。

5.5. ObjectIdentifier
5.5. ObjectIdentifier

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 "String" Datatypeは、iPaddress選択と同じ理由で、XML出力としてObjectIdentifierを表す自然な選択でもあります。この場合に適用された「パターン」制限は、最大128の要素(「サブID」と呼ばれる)の点線の弦があり、それぞれが「unsigned32」整数値を保持します。

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].

「オブジェクト識別子」の最初の2つのコンポーネントはそれぞれ、XSDパターン制限に示されているように、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.

ルートノードには割り当てられた3つの値があり、最大39の値は、ルートノード値0または1に従属するノードの値に最大39の値があります。

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.

パターン自体がこの制限を強制するため、最低2つのサブIDと単一の分離ドットを可能にする「3」となる明示的な「最小」制限はないことに注意してください。

6. Security Considerations
6. セキュリティに関する考慮事項

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マッピングを介してSNMP管理情報をSNMP管理情報をSNMPエージェントからXMLベースの管理アプリケーションに伝えるためにプロキシまたはゲートウェイが開発された場合、すべてのすべてのことを確実にするために特別な注意を払う必要があります。適用されるSNMPセキュリティメカニズムは、まだ決定されていない適切な方法でサポートされています。

7. IANA Considerations
7. IANAの考慮事項

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 urn:ietf:params:xml:ns:smi:base:1.0

o urn:ietf:params:xml:schema:base:1.0

o urn:ietf:params:xml:schema:base:1.0

7.1. SMI Base Datatypes Namespace Registration
7.1. SMI Base Datatypes NameSpace登録

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
        

Registration Contact: The IESG.

登録連絡先:IESG。

XML: N/A, the requested URI is an XML namespace.

XML:N/A、要求されたURIはXMLネームスペースです。

7.2. SMI Base Datatypes Schema Registration
7.2. SMIベースデータ型スキーマ登録

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
        

Registration Contact: The IESG.

登録連絡先:IESG。

XML: Section 4 of this document.

XML:このドキュメントのセクション4。

8. Acknowledgements
8. 謝辞

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.

デイブ・ハリントンは、この特定の仕様を開発したチームに戦略的および技術的なリーダーシップを提供しました。Yan Liは、この特定の仕様の推奨事項のベースラインとして使用された既存のアプローチの多くの研究を行いました。

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データ型の候補マッピングを調査および公開した人々によって開発された人々によって開発された他の多くのソース(libsmiやnetconfメーリングリストでのグループディスカッションを含む)に大きくあります。

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メーリングリストでこのトピックのさまざまな議論に参加した個人には、レイアタラシ、ヨシフミアタラシ、アンディビアマン、シャロンチショルム、アヴリドリア、ロブエンヌ、メフメットエルス、デビッドハリントン、アルフレッドハインズ、エリオットリア、クリスリアLonvick、Faye LY、Randy Presuhn、Juergen Schoenwaelder、Andrea Westerinen、およびBert Wijnen。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.

[RFC1155] Rose、M。およびK. McCloghrie、「TCP/IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、1990年5月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2(SMIV2)」、STD 58、RFC 2578、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] Frye、R.、Levi、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] World Wide Webコンソーシアム、「拡張可能なマークアップ言語(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/>.

[XMLSchema] World Wide Webコンソーシアム、「XMLスキーマパート1:Structures Second Edition」、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] World Wide Web Consortium、「XML Schema Part 2:Datatypes Second Edition」、W3C XML Schema、2004年10月、<http://www.w3.org/tr/xmlschema-2/>。

9.2. Informative References
9.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]ロマスカヌ、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.、Perkins、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] Daniele、M.、Haberman、B.、Routhier、S。、およびJ. Schoenwaelder、「インターネットネットワークアドレスのテキストコンベンション」、RFC 4001、2005年2月。

Authors' Addresses

著者のアドレス

Mark Ellison Ellison Software Consulting 38 Salem Road Atkinson, NH 03811 USA

マークエリソンエリソンソフトウェアコンサルティング38セーラムロードアトキンソン、ニューハンプシャー03811 USA

   Phone: +1 603-362-9270
   EMail: ietf@ellisonsoftware.com
        

Bob Natale MITRE 300 Sentinel Drive 6th Floor Annapolis Junction, MD 20701 USA

ボブナタールマイター300センチネルドライブ6階アナポリスジャンクション、メリーランド州20701アメリカ

   Phone: +1 301-617-3008
   EMail: rnatale@mitre.org