RFC3419 日本語訳
3419 Textual Conventions for Transport Addresses. M. Daniele, J.Schoenwaelder. December 2002. (Format: TXT=37466 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Daniele
Request for Comments: 3419 Consultant
Category: Standards Track J. Schoenwaelder
TU Braunschweig
December 2002
コメントを求めるワーキンググループM.ダニエル要求をネットワークでつないでください: 3419年のコンサルタントカテゴリ: 標準化過程J.Schoenwaelder TUブラウンシュバイク2002年12月
Textual Conventions for Transport Addresses
輸送アドレスのための原文のコンベンション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6.
このドキュメントは一般的に使用されたトランスポート層アドレス指定情報を表すために原文のコンベンションを定義するManagement Information基地(MIB)のモジュールを導入します。 定義は、Management情報バージョン2(SMIv2)のStructureによって紹介されるTAddress/TDomain組の概念と互換性があって、IPv4とIPv6の上でインターネットがトランスポート・プロトコルであるとサポートします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . 2
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Relationship to Other MIBs . . . . . . . . . . . . . . . . . 4
3.1.1 SNMPv2-TC (TAddress, TDomain) . . . . . . . . . . . . . . . 4
3.1.2 SNMPv2-TM . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.3 INET-ADDRESS-MIB (InetAddressType, InetAddress) . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
8. Intellectual Property Notice . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 インターネット標準の管理フレームワーク. . . . . . . . . 2 3。 概要、他のMIBs. . . . . . . . . . . . . . . . . 4 3.1.1SNMPv2-Tc(TAddress、TDomain).43.1.2SNMPv2-Tm.43.1.3INETアドレスMIB(InetAddressType、InetAddress).5 4との.33.1関係 定義. . . . . . . . . . . . . . . . . . . . . . . . 5 5。 例. . . . . . . . . . . . . . . . . . . . . . . . . . 14 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . 15 7。 承認. . . . . . . . . . . . . . . . . . . . . . 15 8。 知的所有権通知. . . . . . . . . . . . . . . . 15標準の参照. . . . . . . . . . . . . . . . . . . . 16の有益な参照. . . . . . . . . . . . . . . . . . . 16作者のアドレス. . . . . . . . . . . . . . . . . . . . . 17の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 18
Daniele & Schoenwaelder Standards Track [Page 1] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[1ページ]。
1. Introduction
1. 序論
Several MIB modules need to represent transport-layer addresses in a generic way. Typical examples are MIBs for application protocols that can operate over several different transports or application management MIBs that need to model generic communication endpoints.
いくつかのMIBモジュールが、ジェネリック方法でトランスポート層アドレスを表す必要があります。 典型的な例は、アプリケーション・プロトコルのためのいくつかの異なった輸送の上で作動できるMIBsかジェネリックコミュニケーション終点をモデル化する必要があるアプリケーション管理MIBsです。
The SMIv2 in STD 58, RFC 2579 [RFC2579] defines the textual conventions TDomain and TAddress to represent generic transport layer endpoints. A generic TAddress value is interpreted in a given transport domain which is identified by a TDomain value. The TDomain is an object identifier which allows MIB authors to extend the set of supported transport domains by providing suitable definitions in standardized or enterprise specific MIB modules.
STD58のSMIv2、RFC2579[RFC2579]はジェネリックトランスポート層終点を表すために原文のコンベンションのTDomainとTAddressを定義します。 ジェネリックTAddress価値はTDomain値によって特定される与えられた輸送ドメインで解釈されます。 TDomainはMIB作者が標準化されるか企業の特定のMIBモジュールとの適当な定義を提供することによってサポートしている輸送ドメインのセットを広げることができるオブジェクト識別子です。
An initial set of TDomain values and concrete TAddress formats has been standardized in STD 62, RFC 3417 [RFC3417]. These definitions are however mixed up with SNMP semantics. Furthermore, definitions for Internet transport protocols over IPv4 and IPv6 are missing.
1人の始発のTDomain値とTAddressがフォーマットするコンクリートはSTD62、RFC3417[RFC3417]で標準化されました。 しかしながら、これらの定義はSNMP意味論に複雑です。 その上、IPv4とIPv6の上のインターネットトランスポート・プロトコルのための定義はなくなっています。
The purpose of this memo is to introduce a set of well-known textual conventions to represent commonly used transport-layer addressing information which is compatible with the original TDomain and TAddress approach and which includes definitions for additional Internet transport protocols over IPv4 and IPv6. This memo also introduces a new textual convention which enumerates the well-known transport domains since such an enumeration provides in many cases sufficient flexibility and is more efficient compared to object identifiers.
このメモの目的はIPv4の上の追加インターネットトランスポート・プロトコルとIPv6のために定義を含んでいるオリジナルのTDomainと互換性がある情報とTAddressがアプローチであると扱う一般的に使用されたトランスポート層を表すために1セットのよく知られる原文のコンベンションを導入することです。 また、このメモはそのような列挙が多くの場合、十分な柔軟性を提供して、オブジェクト識別子と比べて、より効率的であるのでよく知られる輸送ドメインを列挙する新しい原文のコンベンションを導入します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」はBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることになっているべきです。
2. The Internet-Standard Management Framework
2. インターネット標準の管理フレームワーク
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、RFC3410[RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIBオブジェクトはSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBのオブジェクトは、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されるSMIv2に対応であるMIBモジュールを指定します。
Daniele & Schoenwaelder Standards Track [Page 2] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[2ページ]。
3. Overview
3. 概要
This MIB module contains definitions for commonly used transport layer addressing information. In particular, it provides the following definitions:
このMIBモジュールは一般的に使用されたトランスポート層アドレス指定情報のための定義を含んでいます。 特に、以下の定義を提供します:
1. Textual conventions for generic transport addresses
(TransportAddress) and generic transport domains
(TransportDomain).
1. ジェネリックのための原文のコンベンションはアドレス(TransportAddress)とジェネリック輸送ドメイン(TransportDomain)を輸送します。
2. Object identifier registrations for well-known transport domains.
2. よく知られる輸送ドメインのためのオブジェクト識別子登録証明書。
3. An enumeration of the well-known transport domains, called a
transport address type (TransportAddressType).
3. 輸送アドレスタイプ(TransportAddressType)と呼ばれるよく知られる輸送ドメインの列挙。
4. A set of textual conventions for the address formats used by
well-known transport domains. The DISPLAY-HINTs are aligned with
the formats used in URIs [RFC2396], [RFC3291].
4. よく知られる輸送ドメインによって使用されるアドレス形式のための1セットの原文のコンベンション。 [RFC3291]、DISPLAY-HINTsはURI[RFC2396]に使用される形式に並べられます。
The textual conventions for well-known transport domains support scoped Internet addresses. The scope of an Internet address is a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. A scope zone, or simply a zone, is a concrete connected region of topology of a given scope. Note that a zone is a particular instance of a topological region, whereas a scope is the size of a topological region [SCOPED]. Since Internet addresses on devices that connect multiple zones are not necessarily unique, an additional zone index is needed on these devices to select an interface. The textual conventions TransportAddressIPv4z and TransportAddressIPv6z are provided to support Internet transport addresses that include a zone index. In order to support arbitrary combinations of scoped Internet transport addresses, MIB authors SHOULD use a separate TransportDomain or TransportAddressType objects for each TransportAddress object.
よく知られる輸送ドメインサポートのための原文のコンベンションはインターネット・アドレスを見ました。 インターネット・アドレスの範囲はアドレスがインタフェースにユニークな識別子として使用されるか、または設定されるかもしれないインタフェースの位相的な長さです。 範囲ゾーン、または単にゾーンが与えられた範囲のトポロジーの具体的な接続領域です。 ゾーンが位相的な領域の特定のインスタンスですが、範囲が位相的な領域[SCOPED]のサイズであることに注意してください。 複数のゾーンをつなげるデバイスの上のインターネット・アドレスが必ずユニークであるというわけではないので、追加ゾーンインデックスがインタフェースを選択するのにこれらのデバイスで必要です。 インターネット輸送がゾーンインデックスを含んでいるアドレスであるとサポートするために原文のコンベンションのTransportAddressIPv4zとTransportAddressIPv6zを提供します。 見られたインターネット輸送アドレスの任意の組み合わせをサポートするために、MIBは別々のTransportDomainかTransportAddressTypeがそれぞれのTransportAddressオブジェクトのために反対させるSHOULD使用を書きます。
There are two different ways how new transport domains and textual conventions for the address formats used by those new transport domains can be defined.
それらの新しい輸送ドメインによって使用されるアドレス形式のための新しい輸送ドメインと原文のコンベンションを定義できる2つの異なった方法があります。
1. The MIB module contained in this memo can be updated and new
constants for the TransportDomain and the TransportAddressType
enumeration can be assigned.
1. このメモに含まれたMIBモジュールはアップデートできます、そして、TransportDomainのための新しい定数とTransportAddressType列挙を割り当てることができます。
2. Other MIB modules may define additional transport domains and
associated textual conventions. Such an extension can not update
the TransportAddressType enumeration.
2. 他のMIBモジュールは追加輸送ドメインと関連原文のコンベンションを定義するかもしれません。 そのような拡大はTransportAddressType列挙をアップデートできません。
Daniele & Schoenwaelder Standards Track [Page 3] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[3ページ]。
It is therefore a MIB designers choice whether he uses (a) a more compact TransportAddressType object with limited extensibility or (b) a more verbose TransportDomain object which allows arbitrary extensions in other MIB modules.
したがって、彼が(a) 限られた伸展性がある、よりコンパクトなTransportAddressTypeオブジェクトか(b) 他のMIBモジュールで任意の拡大を許すより冗長なTransportDomainオブジェクトを使用するか否かに関係なく、それはMIBデザイナー選択です。
The MIB module contained in this memo does NOT define the transport mappings of any particular protocol. Rather, it defines a set of common identifiers and textual conventions that are intended to be used within various transport mappings documents.
このメモに含まれたMIBモジュールはどんな特定のプロトコルに関する輸送マッピングも定義しません。 むしろ、それは様々な輸送マッピングドキュメントの中に使用されることを意図する1セットの一般的な識別子と原文のコンベンションを定義します。
3.1 Relationship to Other MIBs
3.1 他のMIBsとの関係
This section discusses how the definitions provided by the MIB module contained in this memo relate to definitions in other MIB modules.
このセクションはこのメモに含まれたMIBモジュールで提供された定義がどう他のMIBモジュールとの定義に関連するかを論じます。
3.1.1 SNMPv2-TC (TAddress, TDomain)
3.1.1 SNMPv2-Tc(TAddress、TDomain)
The SNMPv2-TC MIB module [RFC2579] defines the textual conventions TAddress and TDomain to represent generic transport addresses.
SNMPv2-TC MIBモジュール[RFC2579]は、ジェネリック輸送アドレスを表すために原文のコンベンションのTAddressとTDomainを定義します。
A TAddress is an octet string with a size between 1 and 255 octets. Experience has shown that there is sometimes a need to represent unknown transport addresses. The MIB module contained in this memo therefore introduces a new textual convention TransportAddress which is an octet string with a size between 0 and 255 octets and otherwise identical semantics. In other words, the sub-type TransportAddress (SIZE (1..255)) is identical with the TAddress defined in the SNMPv2-TC MIB module [RFC2579].
TAddressは1と255の八重奏の間には、サイズがある八重奏ストリングです。 経験は、未知の輸送アドレスを表す必要が時々あるのを示しました。 したがって、0と、255の八重奏とそうでなければ、同じ意味論の間には、サイズがある状態で、このメモに含まれたMIBモジュールは八重奏ストリングである新しい原文のコンベンションTransportAddressを導入します。 言い換えれば、サブタイプTransportAddress(SIZE(1 .255))はSNMPv2-TC MIBモジュール[RFC2579]で定義されるTAddressと同じです。
This MIB module also introduces a new textual convention TransportDomain which is compatible with the TDomain definition so that a complete set of definitions is contained in a single MIB module. New MIB modules SHOULD use the generic TransportDomain, TransportAddressType and TransportAddress definitions defined in this memo. Existing MIB modules may be updated to use the definitions provided in this memo by replacing TDomain with TransportDomain and TAddress with TransportAddress (SIZE (1..255)).
また、このMIBモジュールがTDomain定義と互換性がある新しい原文のコンベンションTransportDomainを導入するので、完全な定義はただ一つのMIBモジュールで含まれています。 新しいMIBモジュールSHOULDは定義がこのメモで定義したジェネリックのTransportDomain、TransportAddressType、およびTransportAddressを使用します。 TransportAddress(SIZE(1 .255))と共にこのメモにTDomainをTransportDomainとTAddressに取り替えることによって提供された定義を使用するために既存のMIBモジュールをアップデートするかもしれません。
3.1.2 SNMPv2-TM
3.1.2 SNMPv2-TM
The transport domain values defined in the SNMPv2-TM MIB module [RFC3417] all contain "snmp" as the prefix in their name and are registered under `snmpDomains' (from RFC 2578 [RFC2578]). They were originally intended to describe SNMP transport domains only - but they were later also used for non-SNMP transport endpoints. These definitions are also incomplete since new transport address domains are needed to support (at least) SNMP over UDP over IPv6.
SNMPv2-TM MIBモジュール[RFC3417]で定義された輸送ドメイン値は、それらの名前の接頭語として"snmp"をすべて含んでいて、'snmpDomains'(RFC2578[RFC2578]からの)の下に示されます。 元々、彼らがSNMP輸送ドメインだけについて説明することを意図しましたが、また、それらは後で非SNMP輸送終点に使用されました。 また、新しい輸送アドレスドメインがIPv6の上のUDPの上で(少なくとも)SNMPをサポートするのに必要であるので、これらの定義も不完全です。
Daniele & Schoenwaelder Standards Track [Page 4] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[4ページ]。
The transport domain values defined in this memo are independent of the protocol running over the transport-layer and SHOULD be used for all transport endpoints not carrying SNMP traffic. Programs that interpret transport domain values should in addition accept the transport domain values defined in the SNMPv2-TM MIB module in order to provide interoperability with existing implementations that use the SNMP specific transport domain values.
このメモで定義された輸送ドメイン値はそうです。トランスポート層とSHOULDをひくプロトコルの如何にかかわらず、すべての輸送終点にSNMPトラフィックを運ばないことで使用されてください。 輸送ドメイン値を解釈するプログラムはさらに、SNMPの特定の輸送ドメイン値を使用する既存の実装を相互運用性に提供するためにSNMPv2-TM MIBモジュールで定義された輸送ドメイン値を受け入れるはずです。
Transport endpoints which carry SNMP traffic SHOULD continue to use the definitions from the SNMPv2-TM MIB module where applicable. They SHOULD use the transport domain values defined in this memo for SNMP transports not defined in the SNMPv2-TM MIB module, such as SNMP over UDP over IPv6. Programs that interpret transport domain values should in addition accept all the transport domain values defined in this memo in order to provide interoperability in cases where it is not possible or desirable to distinguish the protocols running over a transport endpoint.
SNMPトラフィックSHOULDを運ぶ輸送終点は、適切であるところでSNMPv2-TM MIBモジュールから定義を使用し続けています。 それら、SHOULDはSNMPv2-TM MIBモジュールで定義されなかったSNMP輸送にこのメモで定義された輸送ドメイン値を使用します、IPv6の上のUDPの上のSNMPなどのように。 輸送ドメイン値を解釈するプログラムは、輸送終点中を走らせながら、さらに、プロトコルを区別するのが可能でもなくて、また望ましくもないケースの中に相互運用性を供給するためにこのメモで定義されたすべての輸送ドメイン値を受け入れるはずです。
3.1.3 INET-ADDRESS-MIB (InetAddressType, InetAddress)
3.1.3 INETアドレスMIB(InetAddressType、InetAddress)
The INET-ADDRESS-MIB MIB module [RFC3291] defines the textual conventions InetAddressType and InetAddress to represent Internet network layer endpoints. Some MIB modules use these textual conventions in conjunction with the InetPortNumber textual convention to represent Internet transport-layer endpoints. This approach is fine as long as a MIB models protocols or applications that are specific to the Internet suite of transport protocols. For protocols or applications that can potentially use other transport protocols, the use of the definitions contained in this memo is more appropriate.
INET-ADDRESS-MIB MIBモジュール[RFC3291]は、インターネット網層の終点を表すために原文のコンベンションのInetAddressTypeとInetAddressを定義します。 いくつかのMIBモジュールが、インターネットトランスポート層終点を表すのにInetPortNumberの原文のコンベンションに関連してこれらの原文のコンベンションを使用します。 MIBがトランスポート・プロトコルのインターネットスイートに特定のプロトコルかアプリケーションをモデル化する限り、このアプローチはよいです。 潜在的に他のトランスポート・プロトコルを使用できるプロトコルかアプリケーションにおいて、このメモに含まれた定義の使用は、より適切です。
4. Definitions
4. 定義
TRANSPORT-ADDRESS-MIB DEFINITIONS ::= BEGIN
輸送アドレスMIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
IMPORTS MODULE-IDENTITY、OBJECT-IDENTITY、mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC。
transportAddressMIB MODULE-IDENTITY
LAST-UPDATED "200211010000Z"
ORGANIZATION
"IETF Operations and Management Area"
CONTACT-INFO
"Juergen Schoenwaelder (Editor)
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig, Germany
transportAddressMIBモジュールアイデンティティは「ユルゲンSchoenwaelder(エディタ)TUブラウンシュバイクBueltenweg74/75 38106ブラウンシュバイク(ドイツ)」という"200211010000Z"組織「IETF操作と管理領域」コンタクトインフォメーションをアップデートしました。
Daniele & Schoenwaelder Standards Track [Page 5] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[5ページ]。
Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de
以下に電話をしてください。 +49 531 391-3289 メールしてください: schoenw@ibr.cs.tu-bs.de
Send comments to <mibs@ops.ietf.org>."
DESCRIPTION
"This MIB module provides commonly used transport
address definitions.
「 to <mibs@ops.ietf.org をコメントに送ってください、gt;、」 「このMIBモジュールは一般的に使用された輸送アドレス定義を提供する」記述。
Copyright (C) The Internet Society (2002). This version of
this MIB module is part of RFC 3419; see the RFC itself for
full legal notices."
Copyright(C)インターネット協会(2002)。 このMIBモジュールのこのバージョンはRFC3419の一部です。 「完全な法定の通知に関してRFC自身を見てください。」
-- Revision log
-- 改正ログ
REVISION "200211010000Z"
DESCRIPTION
"Initial version, published as RFC 3419."
::= { mib-2 100 }
「初期のバージョンであって、RFC3419として発行された」REVISION"200211010000Z"記述。 ::= mib-2 100
transportDomains OBJECT IDENTIFIER ::= { transportAddressMIB 1 }
transportDomainsオブジェクト識別子:、:= transportAddressMIB1
transportDomainUdpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 1 }
transportDomainUdpIpv4 OBJECT-IDENTITY STATUSの現在の記述、「IPv4の上のUDPはドメインを輸送します」。 「グローバルなIPv4アドレスのためのタイプTransportAddressIPv4には対応する輸送アドレスがあります。」 ::= transportDomains1
transportDomainUdpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses."
::= { transportDomains 2 }
transportDomainUdpIpv6 OBJECT-IDENTITY STATUSの現在の記述、「IPv6の上のUDPはドメインを輸送します」。 「グローバルなIPv6アドレスのためのタイプTransportAddressIPv6には対応する輸送アドレスがあります。」 ::= transportDomains2
transportDomainUdpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index."
::= { transportDomains 3 }
transportDomainUdpIpv4z OBJECT-IDENTITY STATUSの現在の記述、「IPv4の上のUDPはドメインを輸送します」。 「ゾーンインデックスがある見られたIPv4アドレスのためのタイプTransportAddressIPv4zには対応する輸送アドレスがあります。」 ::= transportDomains3
transportDomainUdpIpv6z OBJECT-IDENTITY
STATUS current
transportDomainUdpIpv6z OBJECT-IDENTITY STATUS海流
Daniele & Schoenwaelder Standards Track [Page 6] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[6ページ]。
DESCRIPTION
"The UDP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index."
::= { transportDomains 4 }
記述、「IPv6の上のUDPはドメインを輸送します」。 「ゾーンインデックスがある見られたIPv6アドレスのためのタイプTransportAddressIPv6zには対応する輸送アドレスがあります。」 ::= transportDomains4
transportDomainTcpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 5 }
transportDomainTcpIpv4 OBJECT-IDENTITY STATUSの現在の記述、「IPv4の上のTCPはドメインを輸送します」。 「グローバルなIPv4アドレスのためのタイプTransportAddressIPv4には対応する輸送アドレスがあります。」 ::= transportDomains5
transportDomainTcpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses."
::= { transportDomains 6 }
transportDomainTcpIpv6 OBJECT-IDENTITY STATUSの現在の記述、「IPv6の上のTCPはドメインを輸送します」。 「グローバルなIPv6アドレスのためのタイプTransportAddressIPv6には対応する輸送アドレスがあります。」 ::= transportDomains6
transportDomainTcpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index."
::= { transportDomains 7 }
transportDomainTcpIpv4z OBJECT-IDENTITY STATUSの現在の記述、「IPv4の上のTCPはドメインを輸送します」。 「ゾーンインデックスがある見られたIPv4アドレスのためのタイプTransportAddressIPv4zには対応する輸送アドレスがあります。」 ::= transportDomains7
transportDomainTcpIpv6z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index."
::= { transportDomains 8 }
transportDomainTcpIpv6z OBJECT-IDENTITY STATUSの現在の記述、「IPv6の上のTCPはドメインを輸送します」。 「ゾーンインデックスがある見られたIPv6アドレスのためのタイプTransportAddressIPv6zには対応する輸送アドレスがあります。」 ::= transportDomains8
transportDomainSctpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses. This transport domain usually
represents the primary address on multihomed SCTP
endpoints."
::= { transportDomains 9 }
transportDomainSctpIpv4 OBJECT-IDENTITY STATUSの現在の記述、「IPv4の上のSCTPはドメインを輸送します」。 グローバルなIPv4アドレスのためのタイプTransportAddressIPv4には対応する輸送アドレスがあります。 「通常、この輸送ドメインはmultihomed SCTP終点に関するプライマリアドレスを表します。」 ::= transportDomains9
Daniele & Schoenwaelder Standards Track [Page 7] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[7ページ]。
transportDomainSctpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses. This transport domain usually
represents the primary address on multihomed SCTP
endpoints."
::= { transportDomains 10 }
transportDomainSctpIpv6 OBJECT-IDENTITY STATUSの現在の記述、「IPv6の上のSCTPはドメインを輸送します」。 グローバルなIPv6アドレスのためのタイプTransportAddressIPv6には対応する輸送アドレスがあります。 「通常、この輸送ドメインはmultihomed SCTP終点に関するプライマリアドレスを表します。」 ::= transportDomains10
transportDomainSctpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index. This transport
domain usually represents the primary address on
multihomed SCTP endpoints."
::= { transportDomains 11 }
transportDomainSctpIpv4z OBJECT-IDENTITY STATUSの現在の記述、「IPv4の上のSCTPはドメインを輸送します」。 ゾーンインデックスがある見られたIPv4アドレスのためのタイプTransportAddressIPv4zには対応する輸送アドレスがあります。 「通常、この輸送ドメインはmultihomed SCTP終点に関するプライマリアドレスを表します。」 ::= transportDomains11
transportDomainSctpIpv6z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index. This transport
domain usually represents the primary address on
multihomed SCTP endpoints."
::= { transportDomains 12 }
transportDomainSctpIpv6z OBJECT-IDENTITY STATUSの現在の記述、「IPv6の上のSCTPはドメインを輸送します」。 ゾーンインデックスがある見られたIPv6アドレスのためのタイプTransportAddressIPv6zには対応する輸送アドレスがあります。 「通常、この輸送ドメインはmultihomed SCTP終点に関するプライマリアドレスを表します。」 ::= transportDomains12
transportDomainLocal OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The Posix Local IPC transport domain. The corresponding
transport address is of type TransportAddressLocal.
transportDomainLocal OBJECT-IDENTITY STATUSの現在の記述、「Posix Local IPCはドメインを輸送します」。 タイプTransportAddressLocalには対応する輸送アドレスがあります。
The Posix Local IPC transport domain incorporates the
well-known UNIX domain sockets."
::= { transportDomains 13 }
「Posix Local IPC輸送ドメインはよく知られるUNIXドメインソケットを組み込みます。」 ::= transportDomains13
transportDomainUdpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 14 }
transportDomainUdpDns OBJECT-IDENTITY STATUSの現在の記述、「UDPは完全修飾ドメイン名を使用することでドメインを輸送します」。 「タイプTransportAddressDnsには対応する輸送アドレスがあります。」 ::= transportDomains14
Daniele & Schoenwaelder Standards Track [Page 8] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[8ページ]。
transportDomainTcpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 15 }
transportDomainTcpDns OBJECT-IDENTITY STATUSの現在の記述、「TCPは完全修飾ドメイン名を使用することでドメインを輸送します」。 「タイプTransportAddressDnsには対応する輸送アドレスがあります。」 ::= transportDomains15
transportDomainSctpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 16 }
transportDomainSctpDns OBJECT-IDENTITY STATUSの現在の記述、「SCTPは完全修飾ドメイン名を使用することでドメインを輸送します」。 「タイプTransportAddressDnsには対応する輸送アドレスがあります。」 ::= transportDomains16
TransportDomain ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a transport domain.
TransportDomain:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「輸送ドメインを表す値。」
Some possible values, such as transportDomainUdpIpv4, are
defined in this module. Other possible values can be
defined in other MIB modules."
SYNTAX OBJECT IDENTIFIER
transportDomainUdpIpv4などの可能ないくつかの値がこのモジュールで定義されます。 「他のMIBモジュールで他の可能な値を定義できます。」 構文オブジェクト識別子
-- -- The enumerated values of the textual convention below should -- be identical to the last sub-identifier of the OID registered -- for the same domain. --
-- -- 以下の原文のコンベンションの列挙された値はそうするべきです--同じドメインへの登録されたOIDに関する最後のサブ識別子と同じにしてください。 --
TransportAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a transport domain. This is the
enumerated version of the transport domain registrations
in this MIB module. The enumerated values have the
following meaning:
TransportAddressType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「輸送ドメインを表す値。」 これはこのMIBモジュールにおける輸送ドメイン登録証明書の列挙されたバージョンです。 列挙された値には、以下の意味があります:
unknown(0) unknown transport address type
udpIpv4(1) transportDomainUdpIpv4
udpIpv6(2) transportDomainUdpIpv6
udpIpv4z(3) transportDomainUdpIpv4z
udpIpv6z(4) transportDomainUdpIpv6z
tcpIpv4(5) transportDomainTcpIpv4
tcpIpv6(6) transportDomainTcpIpv6
tcpIpv4z(7) transportDomainTcpIpv4z
未知の(0)未知の輸送アドレスタイプudpIpv4(1) transportDomainUdpIpv4 udpIpv6(2) transportDomainUdpIpv6 udpIpv4z(3) transportDomainUdpIpv4z udpIpv6z(4) transportDomainUdpIpv6z tcpIpv4(5) transportDomainTcpIpv4 tcpIpv6(6) transportDomainTcpIpv6 tcpIpv4z(7) transportDomainTcpIpv4z
Daniele & Schoenwaelder Standards Track [Page 9] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[9ページ]。
tcpIpv6z(8) transportDomainTcpIpv6z
sctpIpv4(9) transportDomainSctpIpv4
sctpIpv6(10) transportDomainSctpIpv6
sctpIpv4z(11) transportDomainSctpIpv4z
sctpIpv6z(12) transportDomainSctpIpv6z
local(13) transportDomainLocal
udpDns(14) transportDomainUdpDns
tcpDns(15) transportDomainTcpDns
sctpDns(16) transportDomainSctpDns
tcpIpv6z(8) transportDomainTcpIpv6z sctpIpvの4(9) transportDomainSctpIpv4 sctpIpv6(10の) transportDomainSctpIpv6 sctpIpv4z(11) transportDomainSctpIpvの4z sctpIpv6z(12) transportDomainSctpIpv6zの地方の(13)transportDomainLocal udpDns(14) transportDomainUdpDns tcpDns(15) transportDomainTcpDns sctpDns(16) transportDomainSctpDns
This textual convention can be used to represent transport
domains in situations where a syntax of TransportDomain is
unwieldy (for example, when used as an index).
TransportDomainの構文が扱いにくい(例えばインデックスとして使用されると)状況における輸送ドメインを表すのにこの原文のコンベンションを使用できます。
The usage of this textual convention implies that additional
transport domains can only be supported by updating this MIB
module. This extensibility restriction does not apply for the
TransportDomain textual convention which allows MIB authors
to define additional transport domains independently in
other MIB modules."
SYNTAX INTEGER {
unknown(0),
udpIpv4(1),
udpIpv6(2),
udpIpv4z(3),
udpIpv6z(4),
tcpIpv4(5),
tcpIpv6(6),
tcpIpv4z(7),
tcpIpv6z(8),
sctpIpv4(9),
sctpIpv6(10),
sctpIpv4z(11),
sctpIpv6z(12),
local(13),
udpDns(14),
tcpDns(15),
sctpDns(16)
}
この原文のコンベンションの使用法は、このMIBモジュールをアップデートすることによって追加輸送ドメインをサポートすることができるだけであるのを含意します。 「この伸展性制限はMIB作者が他のMIBモジュールで独自に追加輸送ドメインを定義できるTransportDomainの原文のコンベンションに申し込みません。」 構文整数未知(0)、udpIpv4(1)、udpIpv6(2)、udpIpv4z(3)、udpIpv6z(4)、tcpIpv4(5)、tcpIpv6(6)、tcpIpv4z(7)、tcpIpv6z(8)、sctpIpv4(9)、sctpIpv6(10)、sctpIpv4z(11)、sctpIpv6z(12)、地方の(13)、udpDns(14)、tcpDns(15)、sctpDns(16)
TransportAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic transport address.
TransportAddress:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「ジェネリック輸送アドレスを指示します」。
A TransportAddress value is always interpreted within the
context of a TransportAddressType or TransportDomain value.
Every usage of the TransportAddress textual convention MUST
TransportAddress値はTransportAddressTypeかTransportDomain価値の文脈の中でいつも解釈されます。 TransportAddressの原文のコンベンションのあらゆる使用法はそうしなければなりません。
Daniele & Schoenwaelder Standards Track [Page 10] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[10ページ]。
specify the TransportAddressType or TransportDomain object
which provides the context. Furthermore, MIB authors SHOULD
define a separate TransportAddressType or TransportDomain
object for each TransportAddress object. It is suggested that
the TransportAddressType or TransportDomain is logically
registered before the object(s) which use the
TransportAddress textual convention if they appear in the
same logical row.
文脈を提供するTransportAddressTypeかTransportDomainオブジェクトを指定してください。 その上、MIB作者SHOULDはそれぞれのTransportAddressオブジェクトのために別々のTransportAddressTypeかTransportDomainオブジェクトを定義します。 彼らが同じくらいで論理的に見えるならTransportAddressの原文のコンベンションを使用するオブジェクトが船をこぐ前にTransportAddressTypeかTransportDomainが論理的に登録されることが提案されます。
The value of a TransportAddress object must always be
consistent with the value of the associated
TransportAddressType or TransportDomain object. Attempts
to set a TransportAddress object to a value which is
inconsistent with the associated TransportAddressType or
TransportDomain must fail with an inconsistentValue error.
TransportAddressオブジェクトの値はいつも関連TransportAddressTypeかTransportDomainオブジェクトの値と一致しているに違いありません。 inconsistentValue誤りに応じて、関連TransportAddressTypeかTransportDomainに矛盾した値にTransportAddressオブジェクトを設定する試みは失敗しなければなりません。
When this textual convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (0..255))
この原文のコンベンションがインデックスオブジェクトの構文として使用されるとき、SMIv2(STD58)で指定された128のサブ識別子の限界には問題があるかもしれません。 「この場合、OBJECT-TYPE宣言は潜在的インスタンスサブ識別子の数を制限するために'SIZE'節を含まなければなりません。」 構文八重奏ストリング(サイズ(0 .255))
TransportAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address and a port number (as used for example by UDP,
TCP and SCTP):
TransportAddressIPv4:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「1d.1d.1d.1d: 2d」STATUSの現在の記述、「IPv4アドレスとポートナンバー(例えば、UDP、TCP、およびSCTPによって使用されるように)から成る輸送アドレスを表します:、」
octets contents encoding
1-4 IPv4 address network-byte order
5-6 port number network-byte order
1-4 IPv4アドレスネットワークバイトオーダー5-6ポートナンバーネットワークバイトオーダーをコード化する八重奏コンテンツ
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (6))
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 「しかしながら、使用されているなら、それは対にしそれ自身かTransportAddressTypeかTransportDomainに関連して使用されるかもしれません。」 構文八重奏ストリング(サイズ(6))
TransportAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x]0a:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv6
address and a port number (as used for example by UDP,
TransportAddressIPv6:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「0a[2x:2x:2x:2x:2x:2x:2x: 2x]0a: 2d」STATUSの現在の記述、「IPv6アドレスとポートナンバーから成る輸送アドレスが表す、(例えば、UDPによって使用される、」
Daniele & Schoenwaelder Standards Track [Page 11] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[11ページ]。
TCP and SCTP):
TCPとSCTP)、:
octets contents encoding
1-16 IPv6 address network-byte order
17-18 port number network-byte order
1-16 IPv6アドレスネットワークバイトオーダー17-18ポートナンバーネットワークバイトオーダーをコード化する八重奏コンテンツ
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (18))
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 「しかしながら、使用されているなら、それは対にしそれ自身かTransportAddressTypeかTransportDomainに関連して使用されるかもしれません。」 構文八重奏ストリング(サイズ(18))
TransportAddressIPv4z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d%4d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address, a zone index and a port number (as used for
example by UDP, TCP and SCTP):
TransportAddressIPv4z:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「4d: 1d.1d.1d.1d%2d」STATUSの現在の記述、「IPv4アドレス、ゾーンインデックス、およびポートナンバー(例えば、UDP、TCP、およびSCTPによって使用されるように)から成る輸送アドレスを表します:、」
octets contents encoding
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
9-10 port number network-byte order
1-4 IPv4アドレスネットワークバイトオーダー5-8ゾーンインデックスネットワークバイトオーダー9-10ポートナンバーネットワークバイトオーダーをコード化する八重奏コンテンツ
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (10))
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 「しかしながら、使用されているなら、それは対にしそれ自身かTransportAddressTypeかTransportDomainに関連して使用されるかもしれません。」 構文八重奏ストリング(サイズ(10))
TransportAddressIPv6z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x%4d]0a:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv6
address, a zone index and a port number (as used for
example by UDP, TCP and SCTP):
TransportAddressIPv6z:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「0a[2x:2x:2x:2x:2x:2x:2x: 2x%4d]0a: 2d」STATUSの現在の記述、「IPv6アドレス、ゾーンインデックス、およびポートナンバー(例えば、UDP、TCP、およびSCTPによって使用されるように)から成る輸送アドレスを表します:、」
octets contents encoding
1-16 IPv6 address network-byte order
17-20 zone index network-byte order
21-22 port number network-byte order
1-16 IPv6アドレスネットワークバイトオーダー17-20ゾーンインデックスネットワークバイトオーダー21-22ポートナンバーネットワークバイトオーダーをコード化する八重奏コンテンツ
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。
Daniele & Schoenwaelder Standards Track [Page 12] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[12ページ]。
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (22))
「しかしながら、使用されているなら、それは対にしそれ自身かTransportAddressTypeかTransportDomainに関連して使用されるかもしれません。」 構文八重奏ストリング(サイズ(22))
TransportAddressLocal ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents a POSIX Local IPC transport address:
TransportAddressLocal:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"1a"STATUSの現在の記述、「POSIX Local IPC輸送アドレスを表します:、」
octets contents encoding
all POSIX Local IPC address string
すべてのPOSIX Local IPCアドレスストリングをコード化する八重奏コンテンツ
The Posix Local IPC transport domain subsumes UNIX domain
sockets.
Posix Local IPC輸送ドメインはUNIXドメインソケットを包括します。
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 しかしながら、使用されているなら、それは対にしそれ自身かTransportAddressTypeかTransportDomainに関連して使用されるかもしれません。
When this textual convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
REFERENCE
"Protocol Independent Interfaces (IEEE POSIX 1003.1g)"
SYNTAX OCTET STRING (SIZE (1..255))
この原文のコンベンションがインデックスオブジェクトの構文として使用されるとき、SMIv2(STD58)で指定された128のサブ識別子の限界には問題があるかもしれません。 「この場合、OBJECT-TYPE宣言は潜在的インスタンスサブ識別子の数を制限するために'SIZE'節を含まなければなりません。」 参照「プロトコルインディペンデント・インタフェース(IEEE POSIX1003.1g)」構文八重奏ストリング(サイズ(1 .255))
TransportAddressDns ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents a DNS domain name followed by a colon ':'
(ASCII character 0x3A) and a port number in ASCII.
The name SHOULD be fully qualified whenever possible.
TransportAddressDns:、:= 'TEXTUAL-CONVENTION DISPLAY-ヒントの"1a"STATUSの現在の記述が「DNSドメイン名を表して、続いてコロンを表します': '(ASCII文字0x3A)とASCIIにおけるポートナンバー」。 存在という可能であるときはいつも、完全に資格があった名前SHOULD。
Values of this textual convention are not directly useable as
transport-layer addressing information, and require runtime
resolution. As such, applications that write them must be
prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the
time of the management operation).
この原文のコンベンションの値は、トランスポート層アドレス指定情報として直接useableでなく、ランタイム解決を必要とします。 そういうものとして、そのような値をサポートしないことができないか、決議できないなら(解決が管理操作時点で起こるなら)、取り扱い誤りのためにそれらを書くアプリケーションを準備しなければなりません。
The DESCRIPTION clause of TransportAddress objects that may
そうするかもしれないTransportAddressオブジェクトの記述節
Daniele & Schoenwaelder Standards Track [Page 13] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[13ページ]。
have TransportAddressDns values must fully describe how (and
when) such names are to be resolved to IP addresses and vice
versa.
値が完全にそうしなければならないTransportAddressDnsに逆もまた同様にIPアドレスに決議されるそのような(そして、いつ)名がことである方法を説明させてください。
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 しかしながら、使用されているなら、それは対にしそれ自身かTransportAddressTypeかTransportDomainに関連して使用されるかもしれません。
When this textual convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (1..255))
この原文のコンベンションがインデックスオブジェクトの構文として使用されるとき、SMIv2(STD58)で指定された128のサブ識別子の限界には問題があるかもしれません。 「この場合、OBJECT-TYPE宣言は潜在的インスタンスサブ識別子の数を制限するために'SIZE'節を含まなければなりません。」 構文八重奏ストリング(サイズ(1 .255))
END
終わり
5. Examples
5. 例
This section shows some examples how transport addresses are encoded and rendered using some of the transport address definitions.
このセクションは、輸送アドレスが輸送アドレス定義のいくつかを使用することでどのようにコード化されて、表されるかをいくつかの例に示します。
Description: Unspecified IPv4 address on port 80. Encoding (hex): 000000000050 Display: 0.0.0.0:80
記述: ポート80に関する不特定のIPv4アドレス。 以下をコード化します(魔法をかけます)。 000000000050 ディスプレイ: 0.0.0.0:80
Description: Global IPv4 address on port 80. Encoding (hex): 86A922010050 Display: 134.169.34.1:80
記述: ポート80に関するグローバルなIPv4アドレス。 以下をコード化します(魔法をかけます)。 86A922010050は表示します: 134.169.34.1:80
Description: Unspecified IPv6 address on port 80. Encoding (hex): 000000000000000000000000000000000050 Display: [0:0:0:0:0:0:0:0]:80
記述: ポート80に関する不特定のIPv6アドレス。 以下をコード化します(魔法をかけます)。 000000000000000000000000000000000050 ディスプレイ: [0:0:0:0:0:0:0:0]:80
Description: Global IPv6 address on port 80. Encoding (hex): 108000000000000000080800200C417A0050 Display: [1080:0:0:0:8:800:200C:417A]:80
記述: ポート80に関するグローバルなIPv6アドレス。 以下をコード化します(魔法をかけます)。 108000000000000000080800200C417A0050は表示します: [1080: 0:0:0: 8:800:200C: 417A]: 80
Description: Link-local IPv6 address with zone-index 42 on port 80. Encoding (hex): FE8000000000000000010000000002000000002A0050 Display: [FE80:0:0:0:1:0:0:200%42]:80
記述: ポート80の上にゾーンインデックス42があるリンクローカルのIPv6アドレス。 以下をコード化します(魔法をかけます)。 FE8000000000000000010000000002000000002A0050は表示します: [FE80:、0:、0:0:1、:、0:0:200、%42]:、80
Description: Posix Local IPC address (UNIX domain). Encoding (hex): 2F7661722F6167656E74782F6D6173746572 Display: /var/agentx/master
記述: Posix Local IPCは(UNIXドメイン)を扱います。 以下をコード化します(魔法をかけます)。 2F7661722F6167656E74782F6D6173746572は表示します: /var/agentx/master
Daniele & Schoenwaelder Standards Track [Page 14] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[14ページ]。
Description: Fully qualified domain name on port 80. Encoding (hex): 7777772E6578616D706C652E6E65743A3830 Display: www.example.net:80
記述: ポート80に関する完全修飾ドメイン名。 以下をコード化します(魔法をかけます)。 7777772Eの6578616D706C652E6E65743A3830が表示します: www.example.net: 80
6. Security Considerations
6. セキュリティ問題
The MIB module contained in this memo does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects.
このメモに含まれたMIBモジュールはどんな管理オブジェクトも定義しません。 代わりに、それは管理オブジェクトを定義するのに他のMIBモジュールで使用されるかもしれない1セットの原文のコンベンションを定義します。
Meaningful security considerations can only be written for MIB modules that define concrete management objects. This document has therefore no impact on the security of the Internet.
コンクリートの管理オブジェクトを定義するMIBモジュールのために重要なセキュリティ問題を書くことができるだけです。 したがって、このドキュメントはインターネットのセキュリティに影響力を全く持っていません。
7. Acknowledgments
7. 承認
This document was produced by the Operations and Management Area "IPv6MIB" design team. The authors would like to thank Mark Ellison, Brian Haberman, Mike Heard, Glenn Mansfield Keeni, Erik Nordmark, Shawn A. Routhier, Bill Strahm, Dave Thaler and Bert Wijnen for their comments and suggestions.
このドキュメントはOperationsとManagement Area"IPv6MIB"デザインチームによって製作されました。 作者は彼らのコメントと提案についてマーク・エリソン、ブライアン・ハーバーマン、マイクHeard、グレンマンスフィールドKeeni、エリックNordmark、ショーンA.Routhier、ビルStrahm、デーヴThaler、およびバートWijnenに感謝したがっています。
8. Intellectual Property Notice
8. 知的所有権通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Daniele & Schoenwaelder Standards Track [Page 15] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[15ページ]。
Normative References
引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2578] 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.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December
2002.
[RFC3417]Presuhn(R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMP)のためのマッピングを輸送します」、STD62、RFC3417、2002年12月。
Informative References
有益な参照
[SCOPED] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe,
A. and B. Zill, "IPv6 Scoped Address Architecture", Work in
Progress.
[見られます] 「IPv6はアドレス体系を見た」というデアリング、S.、ハーバーマン、B.、Jinmei、T.、Nordmark、E.、尾上、A.、およびB.Zillは進行中で働いています。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732, August 1998.
[RFC2732] HindenとR.と大工とB.とL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、1998年8月。
[RFC3291] Daniele, M., Haberman, B., Routhier, S. and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 3291, December 2001.
[RFC3291] ダニエルとM.とハーバーマンとB.とRouthierとS.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」、RFC3291、2001年12月。
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケースとJ.とマンディとR.とパーテイン、D.とB.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」RFC3410(2002年12月)。
Daniele & Schoenwaelder Standards Track [Page 16] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[16ページ]。
Authors' Addresses
作者のアドレス
Mike Daniele Consultant 19 Pinewood Rd Hudson, NH 03051 USA
マイクダニエルコンサルタント19の松林ニューハンプシャー03051第ハドソン(米国)
Phone: +1 603 883-6365 EMail: md@world.std.com
以下に電話をしてください。 +1 603 883-6365 メールしてください: md@world.std.com
Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany
ユルゲンSchoenwaelder TUブラウンシュバイクBueltenweg74/75 38106ブラウンシュバイクドイツ
Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de
以下に電話をしてください。 +49 531 391-3289 メールしてください: schoenw@ibr.cs.tu-bs.de
Daniele & Schoenwaelder Standards Track [Page 17] RFC 3419 Textual Conventions for Transport Addresses December 2002
ダニエルとSchoenwaelder規格は2002年12月に輸送アドレスのためにRFC3419の原文のコンベンションを追跡します[17ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。
Daniele & Schoenwaelder Standards Track [Page 18]
ダニエルとSchoenwaelder標準化過程[18ページ]
一覧
スポンサーリンク
