RFC4001 日本語訳
4001 Textual Conventions for Internet Network Addresses. M. Daniele,B. Haberman, S. Routhier, J. Schoenwaelder. February 2005. (Format: TXT=45836 bytes) (Obsoletes RFC3291) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Daniele
Request for Comments: 4001 SyAM Software, Inc.
Obsoletes: 3291 B. Haberman
Category: Standards Track Johns Hopkins University
S. Routhier
Wind River Systems, Inc.
J. Schoenwaelder
International University Bremen
February 2005
コメントを求めるワーキンググループM.ダニエル要求をネットワークでつないでください: 4001 SyAMソフトウェアInc.は以下を時代遅れにします。 3291年のB.ハーバーマンカテゴリ: 大学ブレーメン2005年2月の国際の標準化過程のRouthier風の水系Inc.J.ジョーンズ・ホプキンス大学S.Schoenwaelder
Textual Conventions for Internet Network Addresses
インターネットネットワーク・アドレスのための原文のコンベンション
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.
このMIBモジュールは、一般的に使用されたインターネット網層のアドレス指定情報を表すために原文のコンベンションを定義します。 意図はこれらの原文のコンベンションがそうでなければそれら自身の表現を定義するMIBモジュールでインポートされて、使用されるということです。
Daniele, et al. Standards Track [Page 1] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Table Indexing . . . . . . . . . . . . . . . . . . . . . 14
4.2. Uniqueness of Addresses . . . . . . . . . . . . . . . . 14
4.3. Multiple Addresses per Host . . . . . . . . . . . . . . 15
4.4. Resolving DNS Names . . . . . . . . . . . . . . . . . . 15
5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. Changes from RFC 3291 to RFC 4001 . . . . . . . . . . . . . . 18
9. Changes from RFC 2851 to RFC 3291 . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 22
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 インターネット標準の管理フレームワーク. . . . . . . . . . 4 3。 定義. . . . . . . . . . . . . . . . . . . . . . . . . 5 4。 用法は.134.1をほのめかします。 インデックス. . . . . . . . . . . . . . . . . . . . . 14 4.2をテーブルの上に置いてください。 アドレス. . . . . . . . . . . . . . . . 14 4.3のユニークさ。 複数のホスト. . . . . . . . . . . . . . 15 4.4あたりのアドレス。 DNS名. . . . . . . . . . . . . . . . . . 15 5を決議します。 インデックスの例. . . . . . . . . . . . . . . . . . . . 15 6を見送ってください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 18 8。 RFC3291からのRFC4001.189への変化。 RFC2851からのRFC3291.18 10への変化。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1。 引用規格. . . . . . . . . . . . . . . . . . 19 10.2。 有益な参照. . . . . . . . . . . . . . . . . 20作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 21の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
1. 序論
Several standards-track MIB modules use the IpAddress SMIv2 base type. This limits the applicability of these MIB modules to IP Version 4 (IPv4), as the IpAddress SMIv2 base type can only contain 4-byte IPv4 addresses. The IpAddress SMIv2 base type has become problematic with the introduction of IP Version 6 (IPv6) addresses [RFC3513].
いくつかの標準化過程MIBモジュールがIpAddress SMIv2ベースタイプを使用します。 これはこれらのMIBモジュールの適用性をIPバージョン4(IPv4)に制限します、IpAddress SMIv2ベースタイプが4バイトのIPv4アドレスを含むことができるだけであるとき。 IpAddress SMIv2ベースタイプはIPバージョン6(IPv6)アドレス[RFC3513]の導入で問題が多くなりました。
This document defines multiple textual conventions (TCs) as a means to express generic Internet network layer addresses within MIB module specifications. The solution is compatible with SMIv2 (STD 58) and SMIv1 (STD 16). New MIB definitions that have to express network layer Internet addresses SHOULD use the textual conventions defined in this memo. New MIB modules SHOULD NOT use the SMIv2 IpAddress base type anymore.
このドキュメントはMIBモジュール仕様の中にジェネリックインターネット網層のアドレスを表す手段と複数の原文のコンベンション(TCs)を定義します。 ソリューションはSMIv2(STD58)とSMIv1(STD16)と互換性があります。 ネットワーク層インターネット・アドレスSHOULDを急送しなければならない新しいMIB定義がこのメモで定義された原文のコンベンションを使用します。 新しいMIBモジュールSHOULD NOTはそれ以上SMIv2 IpAddressベースタイプを使用します。
A generic Internet address consists of two objects: one whose syntax is InetAddressType, and another whose syntax is InetAddress. The value of the first object determines how the value of the second is encoded. The InetAddress textual convention represents an opaque Internet address value. The InetAddressType enumeration is used to "cast" the InetAddress value into a concrete textual convention for the address type. This usage of multiple textual conventions allows expression of the display characteristics of each address type and makes the set of defined Internet address types extensible.
ジェネリックインターネットアドレスは2個のオブジェクトから成ります: 構文がInetAddressTypeであるもの、および構文がInetAddressである別のもの。 最初のオブジェクトの値は、2番目の値がどのようにコード化されるかを決定します。 InetAddressの原文のコンベンションは不透明なインターネットアドレス値を表します。 InetAddressType列挙は、アドレスタイプのために具体的な原文のコンベンションにInetAddress値を「投げかけること」に使用されます。 複数の原文のコンベンションのこの使用法で、それぞれのアドレスタイプのディスプレイの特性の式を許容して、定義されたインターネット・アドレスタイプのセットは広げることができるようになります。
Daniele, et al. Standards Track [Page 2] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[2ページ]。
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 [RFC4007]. 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 InetAddressIPv4z and InetAddressIPv6z are provided to support Internet addresses that include a zone index. To support arbitrary combinations of scoped Internet addresses, MIB authors SHOULD use a separate InetAddressType object for each InetAddress object.
よく知られる輸送ドメインサポートのための原文のコンベンションはインターネット・アドレスを見ました。 インターネット・アドレスの範囲はアドレスがインタフェースにユニークな識別子として使用されるか、または設定されるかもしれないインタフェースの位相的な長さです。 範囲ゾーン(単にゾーン)は与えられた範囲のトポロジーの具体的な接続領域です。 ゾーンが位相的な領域の特定のインスタンスですが、範囲が位相的な領域[RFC4007]のサイズであることに注意してください。 複数のゾーンをつなげるデバイスの上のインターネット・アドレスが必ずユニークであるというわけではないので、追加ゾーンインデックスがインタフェースを選択するのにこれらのデバイスで必要です。 インターネットがゾーンインデックスを含んでいるアドレスであるとサポートするために原文のコンベンションのInetAddressIPv4zとInetAddressIPv6zを提供します。 見られたインターネット・アドレス、MIB作者の任意の組み合わせをサポートするために、SHOULDはそれぞれのInetAddressオブジェクトに別々のInetAddressTypeオブジェクトを使用します。
The textual conventions defined in this document can also be used to represent generic Internet subnets and Internet address ranges. A generic Internet subnet is represented by three objects: one whose syntax is InetAddressType, a second one whose syntax is InetAddress, and a third one whose syntax is InetAddressPrefixLength. The InetAddressType value again determines the concrete format of the InetAddress value, whereas the InetAddressPrefixLength identifies the Internet network address prefix.
また、ジェネリックインターネットサブネットを表すのに本書では定義された原文のコンベンションは使用できます、そして、インターネット・アドレスは及びます。 ジェネリックインターネットサブネットは3個のオブジェクトによって表されます: 構文がInetAddressTypeであるもの、構文がInetAddressである2番目のもの、および構文がInetAddressPrefixLengthである3番目のもの。 InetAddressType値は再びInetAddress価値の具体的な形式を決定しますが、InetAddressPrefixLengthはインターネット網アドレス接頭語を特定します。
A generic range of consecutive Internet addresses is represented by three objects. The first one has the syntax InetAddressType, and the remaining objects have the syntax InetAddress and specify the start and end of the address range. Again, the InetAddressType value determines the format of the InetAddress values.
連続したインターネット・アドレスのジェネリック範囲は3個のオブジェクトによって表されます。 最初のものには構文InetAddressTypeがあって、残っているオブジェクトは、構文InetAddressを持って、アドレスの範囲の始めと端を指定します。 一方、InetAddressType値はInetAddress値の形式を決定します。
The textual conventions defined in this document can be used to define Internet addresses by using DNS domain names in addition to IPv4 and IPv6 addresses. A MIB designer can write compliance statements to express that only a subset of the possible address types must be supported by a compliant implementation.
IPv4とIPv6アドレスに加えてDNSドメイン名を使用することによってインターネット・アドレスを定義するのに本書では定義された原文のコンベンションは使用できます。 MIBデザイナーは表す可能なアドレスの部分集合だけが対応する実装でサポートしなければならないのをタイプする承諾声明を書くことができます。
MIB developers who need to represent Internet addresses SHOULD use these definitions whenever applicable, as opposed to defining their own constructs. Even MIB modules that only need to represent IPv4 or IPv6 addresses SHOULD use the InetAddressType/InetAddress textual conventions defined in this memo.
適切であるときはいつも、インターネット・アドレスSHOULDを表す必要があるMIB開発者がこれらの定義を使用します、それら自身の構造物を定義することと対照的に。 IPv4を表す必要性だけかIPv6がSHOULDを扱うMIBモジュールさえこのメモで定義されたInetAddressType/InetAddressの原文のコンベンションを使用します。
There are many widely deployed MIB modules that use IPv4 addresses and that have to be revised to support IPv6. These MIB modules can be categorized as follows:
IPv4アドレスを使用して、IPv6をサポートするために改訂されなければならない多くの広く配布しているMIBモジュールがあります。 以下の通りこれらのMIBモジュールを分類できます:
Daniele, et al. Standards Track [Page 3] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[3ページ]。
1. MIB modules that define management information that is, in
principle, IP version neutral, but the MIB currently uses
addressing constructs specific to a certain IP version.
1. 原則としてIPバージョン中立である経営情報を定義するMIBモジュール、MIBだけが現在、あるIPバージョンに特定のアドレシング構造物を使用します。
2. MIB modules that define management information that is specific
to a particular IP version (either IPv4 or IPv6) and that is very
unlikely to ever be applicable to another IP version.
2. 特定のIPバージョン(IPv4かIPv6のどちらか)に特定であり、別のIPバージョンに非常に適切でありそうにない経営情報を定義するMIBモジュール。
MIB modules of the first type SHOULD provide object definitions (e.g., tables) that work with all versions of IP. In particular, when revising a MIB module that contains IPv4 specific tables, it is suggested to define new tables using the textual conventions defined in this memo that support all versions of IP. The status of the new tables SHOULD be "current", whereas the status of the old IP version specific tables SHOULD be changed to "deprecated". The other approach, of having multiple similar tables for different IP versions, is strongly discouraged.
最初のタイプSHOULDのMIBモジュールはIPのすべてのバージョンで働いているオブジェクト定義(例えば、テーブル)を提供します。 IPv4の特定のテーブルを含むMIBモジュールを改訂するとき、特に、それは、IPのすべてのバージョンをサポートするこのメモで定義された原文のコンベンションを使用することで新しいテーブルを定義するために示されます。 新しいテーブルSHOULDには、いてください。状態、「現在であり」、古いIPバージョン詳細の状態はSHOULDをテーブルの上に置きますが、「推奨しなく」変えてください。 もう片方のアプローチは異なったIPバージョンのための複数の同様のテーブルを持つのについて強くお勧めできないです。
MIB modules of the second type, which are inherently IP version specific, do not need to be redefined. Note that even in this case, any additions to these MIB modules or to new IP version specific MIB modules SHOULD use the textual conventions defined in this memo.
2番目のタイプのMIBモジュールは再定義される必要はありません。(本来、タイプはIPバージョン特有です)。 この場合さえそれに注意してください、これらのMIBモジュール、または、原文のコンベンションがこのメモで定義した新しいIPのバージョン特定のMIBモジュールSHOULD使用へのどんな追加。
MIB developers SHOULD NOT use the textual conventions defined in this document to represent generic transport layer addresses. A special set of textual conventions for this purpose is defined in RFC 3419 [RFC3419].
MIB開発者SHOULD NOTはジェネリックトランスポート層アドレスを表すために本書では定義された原文のコンベンションを使用します。 特別な原文のコンベンションはRFC3419[RFC3419]でこのために定義されます。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY", in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」、これが記録するコネはRFC2119[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, et al. Standards Track [Page 4] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[4ページ]。
3. Definitions
3. 定義
INET-ADDRESS-MIB DEFINITIONS ::= BEGIN
INETアドレスMIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
IMPORTS MODULE-IDENTITY、mib-2、Unsigned32 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC。
inetAddressMIB MODULE-IDENTITY
LAST-UPDATED "200502040000Z"
ORGANIZATION
"IETF Operations and Management Area"
CONTACT-INFO
"Juergen Schoenwaelder (Editor)
International University Bremen
P.O. Box 750 561
28725 Bremen, Germany
inetAddressMIBモジュールアイデンティティは「ユルゲンSchoenwaelder(エディタ)国際大学ブレーメンP.O. Box750 561 28725ブレーメン(ドイツ)」という"200502040000Z"組織「IETF操作と管理領域」コンタクトインフォメーションをアップデートしました。
Phone: +49 421 200-3587
EMail: j.schoenwaelder@iu-bremen.de
以下に電話をしてください。 +49 421 200-3587 メールしてください: j.schoenwaelder@iu-bremen.de
Send comments to <ietfmibs@ops.ietf.org>."
DESCRIPTION
"This MIB module defines textual conventions for
representing Internet addresses. An Internet
address can be an IPv4 address, an IPv6 address,
or a DNS domain name. This module also defines
textual conventions for Internet port numbers,
autonomous system numbers, and the length of an
Internet address prefix.
「 to <ietfmibs@ops.ietf.org をコメントに送ってください、gt;、」 「このMIBモジュールはインターネット・アドレスを表しながら、原文のコンベンションを定義する」記述。 インターネット・アドレスは、IPv4アドレス、IPv6アドレス、またはDNSドメイン名であるかもしれません。 また、このモジュールはインターネット・アドレス接頭語のインターネットポートナンバー、自律システム番号、および長さのために原文のコンベンションを定義します。
Copyright (C) The Internet Society (2005). This version
of this MIB module is part of RFC 4001, see the RFC
itself for full legal notices."
REVISION "200502040000Z"
DESCRIPTION
"Third version, published as RFC 4001. This revision
introduces the InetZoneIndex, InetScopeType, and
InetVersion textual conventions."
REVISION "200205090000Z"
DESCRIPTION
"Second version, published as RFC 3291. This
revision contains several clarifications and
introduces several new textual conventions:
InetAddressPrefixLength, InetPortNumber,
InetAutonomousSystemNumber, InetAddressIPv4z,
and InetAddressIPv6z."
REVISION "200006080000Z"
Copyright(C)インターネット協会(2005)。 「RFC自身は、完全な法定の通知に関してこのMIBモジュールのこのバージョンがRFC4001の一部であると考えます。」 「第3バージョンであって、RFC4001として発行された」REVISION"200502040000Z"記述。 「この改正はInetZoneIndex、InetScopeType、およびInetVersionの原文のコンベンションを導入します。」 「第2バージョンであって、RFC3291として発行された」REVISION"200205090000Z"記述。 この改正は、いくつかの明確化を含んでいて、数人の新しい原文のコンベンションを導入します: 「InetAddressPrefixLength、InetPortNumber、InetAutonomousSystemNumber、InetAddressIPv4z、およびInetAddressIPv6z.」 改正"200006080000Z"
Daniele, et al. Standards Track [Page 5] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[5ページ]。
DESCRIPTION
"Initial version, published as RFC 2851."
::= { mib-2 76 }
「初期のバージョンであって、RFC2851として発行された」記述。 ::= mib-2 76
InetAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of Internet address.
InetAddressType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「一種のインターネット・アドレスを表す値。」
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding
InetAddress object is a zero-length string.
It may also be used to indicate an IP address
that is not in one of the formats defined
below.
未知のアドレスがタイプする未知(0)。 対応するInetAddressオブジェクトの値がゼロ長ストリングであるならこの値を使用しなければなりません。 また、それは、以下で定義された書式の1つにはないIPアドレスを示すのに使用されるかもしれません。
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
InetAddressIPv4の原文のコンベンションによって定義されるようにIPv4が扱うipv4(1)。
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
InetAddressIPv6の原文のコンベンションによって定義されるようにIPv6が扱うipv6(2)。
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z
textual convention.
InetAddressIPv4zの原文のコンベンションによって定義されるゾーンインデックスを含む非グローバルなIPv4が扱うipv4z(3)。
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z
textual convention.
InetAddressIPv6zの原文のコンベンションによって定義されるゾーンインデックスを含む非グローバルなIPv6が扱うipv6z(4)。
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
InetAddressDNSの原文のコンベンションによって定義されるdns(16)A DNSドメイン名。
Each definition of a concrete InetAddressType value must be
accompanied by a definition of a textual convention for use
with that InetAddressType.
原文のコンベンションの定義でそのInetAddressTypeとの使用のために具体的なInetAddressType価値の各定義に伴わなければなりません。
To support future extensions, the InetAddressType textual
convention SHOULD NOT be sub-typed in object type definitions.
It MAY be sub-typed in compliance statements in order to
require only a subset of these address types for a compliant
implementation.
今後の拡大、InetAddressTypeが原文のコンベンションSHOULD NOTであるとサポートするためには、オブジェクト・タイプでサブタイプされた定義になってください。 それは、対応する実装のためにこれらのアドレスタイプの部分集合だけを必要とする承諾にサブタイプされた声明であるかもしれません。
Implementations must ensure that InetAddressType objects
and any dependent objects (e.g., InetAddress objects) are
consistent. An inconsistentValue error must be generated
if an attempt to change an InetAddressType object would,
for example, lead to an undefined InetAddress value. In
実装は、InetAddressTypeオブジェクトとどんな依存するオブジェクト(例えば、InetAddressオブジェクト)も一貫しているのを確実にしなければなりません。 例えば、InetAddressTypeオブジェクトを変える試みが未定義のInetAddress値につながるなら、inconsistentValue誤りを生成しなければなりません。 コネ
Daniele, et al. Standards Track [Page 6] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[6ページ]。
particular, InetAddressType/InetAddress pairs must be
changed together if the address type changes (e.g., from
ipv6(2) to ipv4(1))."
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2),
ipv4z(3),
ipv6z(4),
dns(16)
}
「アドレスタイプが変化するなら特定のInetAddressType/InetAddress組を一緒に変えなければならない、(例えば、ipv6(2)からipv4(1))、」 構文整数未知(0)、ipv4(1)、ipv6(2)、ipv4z(3)、ipv6z(4)、dns(16)
InetAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Internet address.
InetAddress:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「ジェネリックインターネットアドレスを指示します」。
An InetAddress value is always interpreted within the context
of an InetAddressType value. Every usage of the InetAddress
textual convention is required to specify the InetAddressType
object that provides the context. It is suggested that the
InetAddressType object be logically registered before the
object(s) that use the InetAddress textual convention, if
they appear in the same logical row.
InetAddress値はInetAddressType価値の文脈の中でいつも解釈されます。 InetAddressの原文のコンベンションのあらゆる使用法が、文脈を提供するInetAddressTypeオブジェクトを指定するのに必要です。 InetAddressTypeオブジェクトがInetAddressの原文のコンベンションを使用するオブジェクトの前に論理的に登録されることが提案されます、彼らが同じ論理的な行に現れるなら。
The value of an InetAddress object must always be
consistent with the value of the associated InetAddressType
object. Attempts to set an InetAddress object to a value
inconsistent with the associated InetAddressType
must fail with an inconsistentValue error.
InetAddressオブジェクトの値はいつも関連InetAddressTypeオブジェクトの値と一致しているに違いありません。 inconsistentValue誤りに応じて、関連InetAddressTypeに矛盾した値にInetAddressオブジェクトを設定する試みは失敗しなければなりません。
When this textual convention is used as the 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 definition MUST include a 'SIZE' clause to
limit the number of potential instance sub-identifiers;
otherwise the applicable constraints MUST be stated in
the appropriate conceptual row DESCRIPTION clauses, or
in the surrounding documentation if there is no single
DESCRIPTION clause that is appropriate."
SYNTAX OCTET STRING (SIZE (0..255))
この原文のコンベンションがインデックスオブジェクトの構文として使用されるとき、SMIv2(STD58)で指定された128のサブ識別子の限界には問題があるかもしれません。 この場合、オブジェクト定義は潜在的インスタンスサブ識別子の数を制限するために'SIZE'節を含まなければなりません。 「適切な概念的な行記述節に適切な規制を述べなければならない、そうでなければ、さもなければ、周囲のドキュメンテーションでは、どんなただ一つの記述節もなければ、それは適切です。」 構文八重奏ストリング(サイズ(0 .255))
InetAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents an IPv4 network address:
InetAddressIPv4:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"1d.1d.1d.1d"STATUSの現在の記述、「IPv4ネットワーク・アドレスを表します:、」
Daniele, et al. Standards Track [Page 7] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[7ページ]。
Octets Contents Encoding
1-4 IPv4 address network-byte order
八重奏Contents Encoding1-4IPv4アドレスネットワークバイトオーダー
The corresponding InetAddressType value is ipv4(1).
対応するInetAddressType値はipv4(1)です。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (4))
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 「しかしながら、使用されているなら、それはそれ自身かInetAddressTypeに関連して使用されるかもしれません、対にし。」 構文八重奏ストリング(サイズ(4))
InetAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
STATUS current
DESCRIPTION
"Represents an IPv6 network address:
InetAddressIPv6:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「2x:2x:2x:2x:2x:2x:2x: 2x」STATUSの現在の記述、「IPv6ネットワーク・アドレスを表します:、」
Octets Contents Encoding
1-16 IPv6 address network-byte order
八重奏Contents Encoding1-16IPv6アドレスネットワークバイトオーダー
The corresponding InetAddressType value is ipv6(2).
対応するInetAddressType値はipv6(2)です。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (16))
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 「しかしながら、使用されているなら、それはそれ自身かInetAddressTypeに関連して使用されるかもしれません、対にし。」 構文八重奏ストリング(サイズ(16))
InetAddressIPv4z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d%4d"
STATUS current
DESCRIPTION
"Represents a non-global IPv4 network address, together
with its zone index:
InetAddressIPv4z:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「1d.1d.1d.1d%4d」STATUSの現在の記述は「非グローバルなIPv4ネットワーク・アドレスを表して、ゾーンと共に以下に索引をつけます」。
Octets Contents Encoding
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
八重奏Contents Encoding1-4IPv4アドレスネットワークバイトオーダー5-8ゾーンインデックスネットワークバイトオーダー
The corresponding InetAddressType value is ipv4z(3).
対応するInetAddressType値はipv4z(3)です。
The zone index (bytes 5-8) is used to disambiguate identical
address values on nodes that have interfaces attached to
different zones of the same scope. The zone index may contain
the special value 0, which refers to the default zone for each
scope.
ゾーンインデックス(バイト5-8)は、同じ範囲の異なったゾーンにインタフェースを付けるノードの同じアドレス値のあいまいさを除くのに使用されます。 ゾーンインデックスは特別な値0を含むかもしれません。(それは、それぞれの範囲についてデフォルトゾーンを示します)。
This textual convention SHOULD NOT be used directly in object
この原文のコンベンションSHOULD NOT、直接オブジェクトで使用されてください。
Daniele, et al. Standards Track [Page 8] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[8ページ]。
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (8))
アドレスを特定の形式に制限するのによる定義。 「しかしながら、使用されているなら、それはそれ自身かInetAddressTypeに関連して使用されるかもしれません、対にし。」 構文八重奏ストリング(サイズ(8))
InetAddressIPv6z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
STATUS current
DESCRIPTION
"Represents a non-global IPv6 network address, together
with its zone index:
InetAddressIPv6z:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「2x:2x:2x:2x:2x:2x:2x: 2x%4d」STATUSの現在の記述は「非グローバルなIPv6ネットワーク・アドレスを表して、ゾーンと共に以下に索引をつけます」。
Octets Contents Encoding
1-16 IPv6 address network-byte order
17-20 zone index network-byte order
八重奏Contents Encoding1-16IPv6アドレスネットワークバイトオーダー17-20ゾーンインデックスネットワークバイトオーダー
The corresponding InetAddressType value is ipv6z(4).
対応するInetAddressType値はipv6z(4)です。
The zone index (bytes 17-20) is used to disambiguate
identical address values on nodes that have interfaces
attached to different zones of the same scope. The zone index
may contain the special value 0, which refers to the default
zone for each scope.
ゾーンインデックス(バイト17-20)は、同じ範囲の異なったゾーンにインタフェースを付けるノードの同じアドレス値のあいまいさを除くのに使用されます。 ゾーンインデックスは特別な値0を含むかもしれません。(それは、それぞれの範囲についてデフォルトゾーンを示します)。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (20))
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 「しかしながら、使用されているなら、それはそれ自身かInetAddressTypeに関連して使用されるかもしれません、対にし。」 構文八重奏ストリング(サイズ(20))
InetAddressDNS ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Represents a DNS domain name. The name SHOULD be fully
qualified whenever possible.
InetAddressDNS:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"255a"STATUSの現在の記述は「DNSドメイン名を表します」。 存在という可能であるときはいつも、完全に資格があった名前SHOULD。
The corresponding InetAddressType is dns(16).
対応するInetAddressTypeはdns(16)です。
The DESCRIPTION clause of InetAddress objects that may have
InetAddressDNS values MUST fully describe how (and when)
these names are to be resolved to IP addresses.
InetAddressDNS値を持っているかもしれないInetAddressオブジェクトの記述節はIPアドレスに決議されるこれらの(そして、いつ)名がことである方法を完全に説明しなければなりません。
The resolution of an InetAddressDNS value may require to
query multiple DNS records (e.g., A for IPv4 and AAAA for
IPv6). The order of the resolution process and which DNS
record takes precedence depends on the configuration of the
resolver.
値が複数のDNSについて質問するのを必要とするかもしれないInetAddressDNSの決議は(例えば、IPv4のためのAとIPv6のためのAAAA)を記録します。 解決の注文は処理されます、そして、どのDNS記録が優先するかはレゾルバの構成に依存します。
Daniele, et al. Standards Track [Page 9] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[9ページ]。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (1..255))
この原文のコンベンションSHOULD NOT、アドレスを特定の形式に制限するので、直接オブジェクト定義では、使用されてください。 「しかしながら、使用されているなら、それはそれ自身かInetAddressTypeに関連して使用されるかもしれません、対にし。」 構文八重奏ストリング(サイズ(1 .255))
InetAddressPrefixLength ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Denotes the length of a generic Internet network address
prefix. A value of n corresponds to an IP address mask
that has n contiguous 1-bits from the most significant
bit (MSB), with all other bits set to 0.
InetAddressPrefixLength:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「d」STATUSの現在の記述は「ジェネリックインターネット網アドレス接頭語の長さを指示します」。 nの値は隣接の大部分から1ビットの重要なnビット(MSB)を持っているIPアドレスマスクに対応しています、0に設定された他のすべてのビットで。
An InetAddressPrefixLength value is always interpreted within
the context of an InetAddressType value. Every usage of the
InetAddressPrefixLength textual convention is required to
specify the InetAddressType object that provides the
context. It is suggested that the InetAddressType object be
logically registered before the object(s) that use the
InetAddressPrefixLength textual convention, if they appear
in the same logical row.
InetAddressPrefixLength値はInetAddressType価値の文脈の中でいつも解釈されます。 InetAddressPrefixLengthの原文のコンベンションのあらゆる使用法が、文脈を提供するInetAddressTypeオブジェクトを指定するのに必要です。 InetAddressTypeオブジェクトがInetAddressPrefixLengthの原文のコンベンションを使用するオブジェクトの前に論理的に登録されることが提案されます、彼らが同じ論理的な行に現れるなら。
InetAddressPrefixLength values larger than
the maximum length of an IP address for a specific
InetAddressType are treated as the maximum significant
value applicable for the InetAddressType. The maximum
significant value is 32 for the InetAddressType
'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
'ipv6(2)' and 'ipv6z(4)'. The maximum significant value
for the InetAddressType 'dns(16)' is 0.
特定のInetAddressTypeのためのIPアドレスの最大の長さより大きいInetAddressPrefixLength値はInetAddressTypeに、適切な最大の重要な値として扱われます。 最大の重要な値は、InetAddressType'ipv4(1)'と'ipv4z(3)'のための32とInetAddressType'ipv6(2)'と'ipv6z(4)'のための128です。 InetAddressType'dns(16)'のための最大の重要な値は0です。
The value zero is object-specific and must be defined as
part of the description of any object that uses this
syntax. Examples of the usage of zero might include
situations where the Internet network address prefix
is unknown or does not apply.
値ゼロをオブジェクト特有であり、この構文を使用するどんなオブジェクトの記述の一部とも定義しなければなりません。 ゼロの用法に関する例は、インターネット網アドレス接頭語が未知である状況を含むかもしれないか、または適用されません。
The upper bound of the prefix length has been chosen to
be consistent with the maximum size of an InetAddress."
SYNTAX Unsigned32 (0..2040)
「接頭語の長さの上限はInetAddressの最大サイズと一致しているように選ばれました。」 構文Unsigned32(0..2040)
InetPortNumber ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Represents a 16 bit port number of an Internet transport
InetPortNumber:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「d」STATUSの現在の記述は「インターネット輸送の16ビットのポートナンバーを表します」。
Daniele, et al. Standards Track [Page 10] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[10ページ]。
layer protocol. Port numbers are assigned by IANA. A
current list of all assignments is available from
<http://www.iana.org/>.
プロトコルを層にしてください。 ポートナンバーはIANAによって割り当てられます。 すべての課題の現在のリストは<http://www.iana.org/>から利用可能です。
The value zero is object-specific and must be defined as
part of the description of any object that uses this
syntax. Examples of the usage of zero might include
situations where a port number is unknown, or when the
value zero is used as a wildcard in a filter."
REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"
SYNTAX Unsigned32 (0..65535)
値ゼロをオブジェクト特有であり、この構文を使用するどんなオブジェクトの記述の一部とも定義しなければなりません。 「ポートナンバーが未知である、または値ゼロがワイルドカードとしてフィルタで使用されるとき、ゼロの用法に関する例は状況を含むかもしれません。」 参照「STD6(RFC768)、STD7(RFC793)、およびRFC2960」構文Unsigned32(0..65535)
InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Represents an autonomous system number that identifies an
Autonomous System (AS). An AS is a set of routers under a
single technical administration, using an interior gateway
protocol and common metrics to route packets within the AS,
and using an exterior gateway protocol to route packets to
other ASes'. IANA maintains the AS number space and has
delegated large parts to the regional registries.
InetAutonomousSystemNumber:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「d」STATUSの現在の記述は「Autonomous System(AS)を特定する自律システム番号を表します」。 'ASはただ一つの技術的な管理の下で、1セットのルータです、ASの中でパケットを発送するのに内部のゲートウェイプロトコルと一般的な測定基準を使用して、他のASesにパケットを発送するのに外のゲートウェイプロトコルを使用して'。 IANAはAS数のスペースを維持して、かなりの部分を地方の登録へ代表として派遣しました。
Autonomous system numbers are currently limited to 16 bits
(0..65535). There is, however, work in progress to enlarge the
autonomous system number space to 32 bits. Therefore, this
textual convention uses an Unsigned32 value without a
range restriction in order to support a larger autonomous
system number space."
REFERENCE "RFC 1771, RFC 1930"
SYNTAX Unsigned32
自律システム番号は現在、16ビット(0 .65535)に制限されます。 しかしながら、自律システム数のスペースを32ビットに拡大するために、処理中の作業があります。 「したがって、この原文のコンベンションは、より大きい自律システム番号がスペースであるとサポートするのに範囲制限なしでUnsigned32値を使用します。」 参照「RFC1771、RFC1930」構文Unsigned32
InetScopeType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a scope type. This textual convention can be used
in cases where a MIB has to represent different scope types
and there is no context information, such as an InetAddress
object, that implicitly defines the scope type.
InetScopeType:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「範囲タイプの代理をします」。 MIBが異なった範囲タイプの代理をしなければならなくて、それとなく範囲タイプを定義するInetAddressオブジェクトの文脈情報が全くない場合にこの原文のコンベンションを使用できます。
Note that not all possible values have been assigned yet, but
they may be assigned in future revisions of this specification.
Applications should therefore be able to deal with values
not yet assigned."
REFERENCE "RFC 3513"
SYNTAX INTEGER {
-- reserved(0),
すべての可能な値がまだ割り当てられるというわけではありませんでしたが、それらがこの仕様の今後の改正で割り当てられるかもしれないことに注意してください。 「したがって、アプリケーションはまだ割り当てられていなかった値に対処できるべきです。」 REFERENCE「RFC3513」構文整数、--予約された(0)
Daniele, et al. Standards Track [Page 11] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[11ページ]。
interfaceLocal(1),
linkLocal(2),
subnetLocal(3),
adminLocal(4),
siteLocal(5), -- site-local unicast addresses
-- have been deprecated by RFC 3879
-- unassigned(6),
-- unassigned(7),
organizationLocal(8),
-- unassigned(9),
-- unassigned(10),
-- unassigned(11),
-- unassigned(12),
-- unassigned(13),
global(14)
-- reserved(15)
}
interfaceLocal(1)、linkLocal(2)、subnetLocal(3)、adminLocal(4)(siteLocal(5)(サイトローカルのユニキャストアドレス))が(7)が割り当てられなかったRFC3879((6)は割り当てられません)で推奨しない、(12)((13)、グローバルな(14)は割り当てられない)が割り当てられなかった(10)((11)は割り当てられない)が割り当てられなかったorganizationLocal(8)((9)は割り当てられない)は(15)を予約しました。
InetZoneIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A zone index identifies an instance of a zone of a
specific scope.
InetZoneIndex:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「d」STATUSの現在の記述、「ゾーンインデックスは特定の範囲のゾーンのインスタンスを特定します」。
The zone index MUST disambiguate identical address
values. For link-local addresses, the zone index will
typically be the interface index (ifIndex as defined in the
IF-MIB) of the interface on which the address is configured.
ゾーンインデックスは同じアドレス値のあいまいさを除かなければなりません。 リンクローカルのアドレスのために、ゾーンインデックスが通常インタフェースインデックスになる、(中で定義されるifIndex、-、MIB、)、アドレスが構成されるインタフェースについて。
The zone index may contain the special value 0, which refers
to the default zone. The default zone may be used in cases
where the valid zone index is not known (e.g., when a
management application has to write a link-local IPv6
address without knowing the interface index value). The
default zone SHOULD NOT be used as an easy way out in
cases where the zone index for a non-global IPv6 address
is known."
REFERENCE "RFC4007"
SYNTAX Unsigned32
ゾーンインデックスは特別な値0を含むかもしれません。(それは、デフォルトゾーンを示します)。 デフォルトゾーンは有効なゾーンインデックスが知られていない(例えば、インタフェースインデックス価値を知らないで、管理アプリケーションはいつリンクローカルのIPv6アドレスを書かなければなりませんか)場合に使用されるかもしれません。 「デフォルトゾーンSHOULD NOT、安易な解決法として非グローバルなIPv6アドレスのためのゾーンインデックスが知られている場合に使用されてください、」 参照"RFC4007"構文Unsigned32
InetVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value representing a version of the IP protocol.
InetVersion:、:= 「AはIPプロトコルのバージョンを表しながら、評価する」TEXTUAL-CONVENTION STATUSの現在の記述。
unknown(0) An unknown or unspecified version of the IP
protocol.
IPの未知の、または、不特定のバージョンが議定書の中で述べる未知(0)。
Daniele, et al. Standards Track [Page 12] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[12ページ]。
ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5).
IPv4が議定書を作るipv4(1)はRFC791で(STD5)を定義しました。
ipv6(2) The IPv6 protocol as defined in RFC 2460.
IPv6がRFC2460で定義されるように議定書の中で述べるipv6(2)。
Note that this textual convention SHOULD NOT be used to
distinguish different address types associated with IP
protocols. The InetAddressType has been designed for this
purpose."
REFERENCE "RFC 791, RFC 2460"
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2)
}
END
この原文のコンベンションSHOULD NOTがIPプロトコルに関連している異なったアドレスタイプを区別するのに使用されることに注意してください。 「InetAddressTypeはこのために設計されています。」 REFERENCE、「RFC791、RFC2460インチ構文整数、未知の(0)、ipv4(1)、ipv6(2)は終わります。
4. Usage Hints
4. 用法は暗示します。
The InetAddressType and InetAddress textual conventions have been introduced to avoid over-constraining an object definition by the use of the IpAddress SMI base type, which is IPv4 specific. An InetAddressType/InetAddress pair can represent IP addresses in various formats.
IpAddress SMIベースタイプの使用でオブジェクト定義を抑制し過ぎるのを避けるためにInetAddressTypeとInetAddressの原文のコンベンションを導入しました。タイプはIPv4特有です。 InetAddressType/InetAddress組は様々な形式でIPアドレスを表すことができます。
The InetAddressType and InetAddress objects SHOULD NOT be sub-typed in object definitions. Sub-typing binds the MIB module to specific address formats, which may cause serious problems if new address formats need to be introduced. Note that it is possible to write compliance statements indicating that only a subset of the defined address types must be implemented to be compliant.
InetAddressTypeとInetAddress、SHOULD NOTはサブタイプされたコネがオブジェクト定義であったなら反対します。 サブタイプは特定のアドレス形式にMIBモジュールを縛ります。(新しいアドレス形式が、導入される必要があるなら、アドレス形式は深刻な問題を引き起こすかもしれません)。 言いなりになると定義されたアドレスタイプの部分集合だけを実装しなければならないのを示す承諾声明を書くのが可能であることに注意してください。
Every usage of the InetAddress or InetAddressPrefixLength textual conventions must specify which InetAddressType object provides the context for the interpretation of the InetAddress or InetAddressPrefixLength textual convention.
InetAddressかInetAddressPrefixLengthの原文のコンベンションのあらゆる使用法が、どのInetAddressTypeオブジェクトがInetAddressかInetAddressPrefixLengthの解釈のための文脈に原文のコンベンションを供給するかを指定しなければなりません。
It is suggested that the InetAddressType object is logically registered before the object(s) that use(s) the InetAddress or InetAddressPrefixLength textual convention. An InetAddressType object is logically registered before an InetAddress or InetAddressPrefixLength object if it appears before the InetAddress or InetAddressPrefixLength object in the conceptual row (which includes any index objects). This rule allows programs such as MIB compilers to identify the InetAddressType of a given InetAddress or InetAddressPrefixLength object by searching for the InetAddressType object, which precedes an InetAddress or InetAddressPrefixLength object.
InetAddressTypeオブジェクトが(s) InetAddressかInetAddressPrefixLengthの原文のコンベンションを使用するオブジェクトの前に論理的に登録されることが提案されます。 InetAddressTypeオブジェクトがInetAddressの前に論理的に登録されるか、または概念的な行(どんなインデックスオブジェクトも含んでいる)でInetAddressかInetAddressPrefixLengthが反対する前に現れるなら、InetAddressPrefixLengthは反対します。 MIBコンパイラなどのプログラムがこの規則で与えられたInetAddressのInetAddressTypeを特定できますか、InetAddressPrefixLengthがInetAddressに先行するInetAddressTypeオブジェクトを捜し求めることによって、反対するか、またはInetAddressPrefixLengthは反対します。
Daniele, et al. Standards Track [Page 13] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[13ページ]。
4.1. Table Indexing
4.1. テーブルインデックス
When a generic Internet address is used as an index, both the InetAddressType and InetAddress objects MUST be used. The InetAddressType object MUST be listed before the InetAddress object in the INDEX clause.
ジェネリックインターネットアドレスがインデックスとして使用されるとき、InetAddressTypeとInetAddressオブジェクトの両方を使用しなければなりません。 InetAddressがINDEX節で反対する前にInetAddressTypeオブジェクトを記載しなければなりません。
The IMPLIED keyword MUST NOT be used for an object of type InetAddress in an INDEX clause. Instance sub-identifiers are then of the form T.N.O1.O2...On, where T is the value of the InetAddressType object, O1...On are the octets in the InetAddress object, and N is the number of those octets.
INDEX節のタイプInetAddressのオブジェクトにIMPLIEDキーワードを使用してはいけません。 インスタンスサブ識別子はそして、フォームT. N. O1.O2のものです…TがInetAddressTypeオブジェクトの値であることのO1に関して…オンであるのが、InetAddressオブジェクトの八重奏であり、Nはそれらの八重奏の数です。
There is a meaningful lexicographical ordering to tables indexed in this fashion. Command generator applications may look up specific addresses of known type and value, issue GetNext requests for addresses of a single type, or issue GetNext requests for a specific type and address prefix.
こんなやり方で索引をつけられたテーブルには重要な辞書編集の注文があります。 コマンドジェネレータアプリケーションは知られているタイプと価値の特定のアドレス、単独のタイプのアドレスを求める問題GetNext要求、または特定のタイプとアドレス接頭語を求める問題GetNext要求を調べるかもしれません。
4.2. Uniqueness of Addresses
4.2. アドレスのユニークさ
IPv4 addresses were intended to be globally unique, current usage notwithstanding. IPv6 addresses were architected to have different scopes and hence uniqueness [RFC3513]. In particular, IPv6 "link- local" unicast addresses are not guaranteed to be unique on any particular node. In such cases, the duplicate addresses must be configured on different interfaces. So the combination of an IPv6 address and a zone index is unique [RFC4007].
グローバルにユニークであって、用法にもかかわらず、IPv4アドレスが現在であることを意図しました。 IPv6アドレスは、異なった範囲としたがって、ユニークさ[RFC3513]を持つためにarchitectedされました。 特に、IPv6の「リンク地方」のユニキャストアドレスは、どんな特定のノードでも特有になるように保証されません。 そのような場合、異なったインタフェースで写しアドレスを構成しなければなりません。 それで、IPv6アドレスとゾーンインデックスの組み合わせはユニークです[RFC4007]。
The InetAddressIPv6 textual convention has been defined to represent global IPv6 addresses and non-global IPv6 addresses in cases where no zone index is needed (e.g., on end hosts with a single interface). The InetAddressIPv6z textual convention has been defined to represent non-global IPv6 addresses in cases where a zone index is needed (e.g., a router connecting multiple zones). Therefore, MIB designers who use InetAddressType/InetAddress pairs do not need to define additional objects in order to support non-global addresses on nodes that connect multiple zones.
InetAddressIPv6の原文のコンベンションは、ゾーンインデックスが全く必要でない(例えば、単一のインタフェースをもっている終わりのホストの上で)場合におけるグローバルなIPv6アドレスと非グローバルなIPv6アドレスを表すために定義されました。 InetAddressIPv6zの原文のコンベンションは、ゾーンインデックスが必要である場合(例えば、複数のゾーンをつなげるルータ)における非グローバルなIPv6アドレスを表すために定義されました。 したがって、InetAddressType/InetAddress組を使用するMIBデザイナーは、複数のゾーンをつなげるノードに関する非グローバルなアドレスをサポートするために追加オブジェクトを定義する必要はありません。
The InetAddressIPv4z is intended for use in MIB modules (such as the TCP-MIB) which report addresses in the address family used on the wire, but where the entity instrumented obtains these addresses from applications or administrators in a form that includes a zone index, such as v4-mapped IPv6 addresses.
InetAddressIPv4zはアドレスファミリーにおけるレポートアドレスがワイヤの上に使用しましたが、器具を取り付けられた実体がゾーンインデックスを含んでいるフォームでアプリケーションか管理者からこれらのアドレスを得るMIBモジュール(TCP-MIBなどの)における使用のために意図します、v4によって写像されたIPv6アドレスなどのように。
Daniele, et al. Standards Track [Page 14] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[14ページ]。
The size of the zone index has been chosen so that it is consistent with (i) the numerical zone index, defined in [RFC4007], and (ii) the sin6_scope_id field of the sockaddr_in6 structure, defined in RFC 2553 [RFC2553].
ゾーンインデックスのサイズが選ばれたので、それは[RFC4007]で定義された数字のゾーンインデックス、およびsockaddr_in6構造の(ii)sin6_範囲_イド分野がRFC2553[RFC2553]で定義した(i)と一致しています。
4.3. Multiple Addresses per Host
4.3. 複数の1ホストあたりのアドレス
A single host system may be configured with multiple addresses (IPv4 or IPv6), and possibly with multiple DNS names. Thus it is possible for a single host system to be accessible by multiple InetAddressType/InetAddress pairs.
ただ一つのホストシステムは複数のアドレス(IPv4かIPv6)、およびことによると複数のDNS名によって構成されるかもしれません。 したがって、ただ一つのホストシステムが複数のInetAddressType/InetAddress組がアクセスしやすいのは、可能です。
If this could be an implementation or usage issue, the DESCRIPTION clause of the relevant objects must fully describe which address is reported in a given InetAddressType/InetAddress pair.
これが実装か用法問題であるかもしれないなら、関連オブジェクトの記述節は、どのアドレスが与えられたInetAddressType/InetAddress組で報告されるかを完全に説明しなければなりません。
4.4. Resolving DNS Names
4.4. DNS名を決議します。
DNS names MUST be resolved to IP addresses when communication with the named host is required. This raises a temporal aspect to defining MIB objects whose value is a DNS name: When is the name translated to an address?
命名されたホストとのコミュニケーションが必要であるときに、IPアドレスにDNS名を決議しなければなりません。 これは値がDNS名であるMIBオブジェクトを定義するのに時の局面を上げます: 名前はいつアドレスに翻訳されますか?
For example, consider an object defined to indicate a forwarding destination, and whose value is a DNS name. When does the forwarding entity resolve the DNS name? Each time forwarding occurs, or just once when the object was instantiated?
例えば、推進の目的地とだれの値がDNS名であるかを示すために定義されたオブジェクトを考えてください。 推進実体はいつDNS名を決議しますか? オブジェクトが例示された推進が一度だけ起こる各回?
The DESCRIPTION clause of these objects SHOULD precisely define how and when any required name to address resolution is done.
SHOULDが、解決を扱うために何かがどのように、いつ名前を必要としたかを正確に定義するこれらのオブジェクトの記述節は完了しています。
Similarly, the DESCRIPTION clause of these objects SHOULD precisely define how and when a reverse lookup is being done, if an agent has accessed instrumentation that knows about an IP address, and if the MIB module or implementation requires it to map the IP address to a DNS name.
同様に、SHOULDが正確に定義するこれらのオブジェクトの記述節が逆のルックアップが存在であるどのように、時に完了していて、エージェントが計装にアクセスしたなら、それはIPアドレスとMIBモジュールか実装がIPアドレスをDNS名に写像するためにそれを必要とするかどうかを知っています。
5. Table Indexing Example
5. テーブルインデックスの例
This example shows a table listing communication peers that are identified by either an IPv4 address, an IPv6 address, or a DNS name. The table definition also prohibits entries with an empty address (whose type would be "unknown"). The size of a DNS name is limited to 64 characters in order to satisfy OID length constraints.
この例は、テーブルがIPv4アドレス、IPv6アドレス、またはDNSが命名するどちらかによって特定されるコミュニケーション同輩を記載するのを示します。 また、テーブル定義は空のアドレス(タイプは「未知である」)でエントリーを禁止します。 DNS名のサイズは、OID長さの規制を満たすために64のキャラクタに制限されます。
Daniele, et al. Standards Track [Page 15] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[15ページ]。
peerTable OBJECT-TYPE
SYNTAX SEQUENCE OF PeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of communication peers."
::= { somewhere 1 }
「Aはコミュニケーション同輩について記載する」peerTable OBJECT-TYPE SYNTAX SEQUENCE OF PeerEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= どこか、1
peerEntry OBJECT-TYPE
SYNTAX PeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing information about a particular peer."
INDEX { peerAddressType, peerAddress }
::= { peerTable 1 }
peerEntry OBJECT-TYPE SYNTAX PeerEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の同輩の情報を含むエントリー。」 peerAddressType、peerAddressに索引をつけてください:、:= peerTable1
PeerEntry ::= SEQUENCE {
peerAddressType InetAddressType,
peerAddress InetAddress,
peerStatus INTEGER
}
PeerEntry:、:= 系列peerAddressType InetAddressType、peerAddress InetAddress、peerStatus整数
peerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of Internet address by which the peer
is reachable."
peerAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「同輩が届いているインターネット・アドレスのタイプ。」
::= { peerEntry 1 }
::= peerEntry1
peerAddress OBJECT-TYPE
SYNTAX InetAddress (SIZE (1..64))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet address for the peer. The type of this
address is determined by the value of the peerAddressType
object. Note that implementations must limit themselves
to a single entry in this table per reachable peer.
The peerAddress may not be empty due to the SIZE
restriction.
peerAddress OBJECT-TYPE SYNTAX InetAddress(SIZE(1 .64))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述「同輩のためのインターネット・アドレス。」 このアドレスのタイプはpeerAddressTypeオブジェクトの値で決定します。 実装がこの届いている同輩あたりのテーブルで自分たちを単一のエントリーに制限しなければならないことに注意してください。 peerAddressはSIZE制限のために空でないかもしれません。
If a row is created administratively by an SNMP
operation and the address type value is dns(16), then
the agent stores the DNS name internally. A DNS name
行がSNMP操作で行政上作成されて、アドレスタイプ価値がdns(16)であるなら、エージェントは内部的にDNS名を保存します。 DNS名
Daniele, et al. Standards Track [Page 16] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[16ページ]。
lookup must be performed on the internally stored DNS
name whenever it is being used to contact the peer.
それが同輩に連絡するのに使用されているときはいつも、内部的に保存されたDNS名にルックアップを実行しなければなりません。
If a row is created by the managed entity itself and
the address type value is dns(16), then the agent
stores the IP address internally. A DNS reverse lookup
must be performed on the internally stored IP address
whenever the value is retrieved via SNMP."
::= { peerEntry 2 }
行が管理された実体自体によって作成されて、アドレスタイプ価値がdns(16)であるなら、エージェントは内部的にIPアドレスを保存します。 「値がSNMPを通して検索されるときはいつも、内部的に保存されたIPアドレスにDNSの逆のルックアップを実行しなければなりません。」 ::= peerEntry2
The following compliance statement specifies that compliant implementations need only support IPv4/IPv6 addresses without zone indices. Support for DNS names or IPv4/IPv6 addresses with zone indices is not required.
以下の承諾声明は、対応する実装がゾーンインデックスリストなしでサポートIPv4/IPv6アドレスだけを必要とすると指定します。 ゾーンインデックスリストがあるDNS名かIPv4/IPv6アドレスのサポートは必要ではありません。
peerCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement of the peer MIB."
peerCompliance MODULE-COMPLIANCE STATUSの現在の記述、「同輩MIBの承諾声明。」
MODULE -- this module
MANDATORY-GROUPS { peerGroup }
MODULE--このモジュールMANDATORY-GROUPSpeerGroup
OBJECT peerAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is only required to support IPv4
and IPv6 addresses without zone indices."
OBJECT peerAddressType SYNTAX InetAddressType、ipv4(1)、ipv6(2)、「実装がIPv4をサポートするのに必要であるだけであり、IPv6はゾーンインデックスリストなしで扱う」記述。
::= { somewhere 2 }
::= どこか、2
Note that the SMIv2 does not permit inclusion of objects that are not accessible in an object group (see section 3.1 in STD 58, RFC 2580 [RFC2580]). It is therefore not possible to refine the syntax of auxiliary objects that are not accessible. It is suggested that the refinement be expressed informally in the DESCRIPTION clause of the MODULE-COMPLIANCE macro invocation.
SMIv2がオブジェクトグループでアクセスしやすくないオブジェクトの包含を可能にしないことに注意してください(STD58のセクション3.1を見てください、RFC2580[RFC2580])。 したがって、アクセスしやすくない補助のオブジェクトの構文を洗練するのは可能ではありません。 気品がMODULE-COMPLIANCEマクロ実施の記述節で非公式に言い表されることが提案されます。
6. Security Considerations
6. セキュリティ問題
This module 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モジュールで使用されるかもしれない1セットの原文のコンベンションを定義します。
Daniele, et al. Standards Track [Page 17] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[17ページ]。
Meaningful security considerations can only be written in the MIB modules that define 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. For their comments and suggestions, the authors would like to thank Fred Baker, Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro Hagino, Mike Heard, Tim Jenkins, Allison Mankin, Glenn Mansfield, Keith McCloghrie, Thomas Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill.
このドキュメントはOperationsとManagement Area"IPv6MIB"デザインチームによって製作されました。 彼らのコメントと提案について、作者はフレッド・ベイカーに感謝したがっています、ランディ・ブッシュ、リチャードDraves、マーク・エリソン、ビル・フェナー、6月-ichiro Hagino、マイクHeard、ティム・ジェンキンス、アリソン・マンキン、グレン・マンスフィールド、キースMcCloghrie、トーマスNarten、エリックNordmark、Peder Chr。 Norgaard、ランディPresuhn、アンドリュー・スミス、デーヴThaler、ケネス・ホワイト、バートWijnen、およびブライアンZill。
8. Changes from RFC 3291 to RFC 4001
8. RFC3291からRFC4001までの変化
The following changes have been made relative to RFC 3291:
以下の変更はRFC3291に比例して行われました:
o Added a range restriction to the InetAddressPrefixLength textual
convention.
o InetAddressPrefixLengthの原文のコンベンションに範囲制限を追加しました。
o Added new textual conventions InetZoneIndex, InetScopeType, and
InetVersion.
o 新しい原文のコンベンションのInetZoneIndex、InetScopeType、およびInetVersionを加えました。
o Added explicit "d" DISPLAY-HINTs for textual conventions that did
not have them.
o それがした原文のコンベンションのための加えられた明白な「d」DISPLAY-HINTsには、それらがありません。
o Updated boilerplate text and references.
o 決まり文句のテキストと参照をアップデートしました。
9. Changes from RFC 2851 to RFC 3291
9. RFC2851からRFC3291までの変化
The following changes have been made relative to RFC 2851:
以下の変更はRFC2851に比例して行われました:
o Added new textual conventions InetAddressPrefixLength,
InetPortNumber, and InetAutonomousSystemNumber.
o 新しい原文のコンベンションのInetAddressPrefixLength、InetPortNumber、およびInetAutonomousSystemNumberを加えました。
o Rewrote the introduction to say clearly that, in general, one
should define MIB tables that work with all versions of IP. The
other approach of multiple tables for different IP versions is
strongly discouraged.
o 一般に、IPのすべてのバージョンで動作するMIBテーブルを定義するべきであると明確に言うために序論を書き直しました。 異なったIPバージョンのための複数のテーブルのもう片方のアプローチは強くお勧めできないです。
o Added text to the InetAddressType and InetAddress descriptions
requiring that implementations must reject set operations with an
inconsistentValue error if they lead to inconsistencies.
o 矛盾に通じるなら実装がinconsistentValue誤りで集合演算を拒絶しなければならないのを必要とするInetAddressTypeとInetAddress記述にテキストを加えました。
o Removed the strict ordering constraints. Description clauses now
must explain which InetAddressType object provides the context for
an InetAddress or InetAddressPrefixLength object.
o 厳しい注文規制を取り除きました。 現在、記述節でどのInetAddressTypeオブジェクトがInetAddressのための文脈を提供するかがわからなければなりませんか、またはInetAddressPrefixLengthは反対します。
Daniele, et al. Standards Track [Page 18] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[18ページ]。
o Aligned wordings with the IPv6 scoping architecture document.
o IPv6の見ているアーキテクチャドキュメントに言葉遣いを一直線にしました。
o Split the InetAddressIPv6 textual convention into the two textual
conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced
a new textual convention InetAddressIPv4z. Added ipv4z(3) and
ipv6z(4) named numbers to the InetAddressType enumeration.
Motivations for this change: (i) to enable the introduction of a
textual conventions for non-global IPv4 addresses, (ii) alignment
with the textual conventions for transport addresses, (iii)
simpler compliance statements in cases where support for IPv6
addresses with zone indices is not required, and (iv) to simplify
implementations for host systems that will never have to report
zone indices.
o InetAddressIPv6の原文のコンベンションを2つの原文のコンベンション(InetAddressIPv6とInetAddressIPv6z)に分割して、新しい原文のコンベンションInetAddressIPv4zを紹介しました。 加えられたipv4z(3)とipv6z(4)はInetAddressTypeへの数を列挙と命名しました。 これに関する動機は変化します: (i) 非グローバルなIPv4アドレス、輸送アドレスのための原文のコンベンションに伴う(ii)整列、ゾーンインデックスリストがあるIPv6アドレスのサポートは必要でない場合における(iii)より簡単な承諾声明、および(iv)のための原文のコンベンションの導入が決してそうする必要はないホストシステムのために実装を簡素化するのを可能にするには、ゾーンインデックスリストを報告してください。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[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"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2580] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
February 2005.
[RFC4007] デアリングとS.とハーバーマンとB.とJinmeiとT.とNordmark、E.とB.Zill、「IPv6はアドレス体系を見た」RFC4007、2005年2月。
Daniele, et al. Standards Track [Page 19] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[19ページ]。
10.2. Informative References
10.2. 有益な参照
[RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2553,
March 1999.
[RFC2553] ギリガンとR.とトムソンとS.とバウンド、J.とW.スティーブンス、「IPv6"、RFC2553、1999年3月のための基本的なソケットインタフェース拡大。」
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[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月)。
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for
Transport Addresses", RFC 3419, December 2002.
[RFC3419] ダニエルとM.とJ.Schoenwaelder、「輸送アドレスのための原文のコンベンション」、RFC3419、2002年12月。
Daniele, et al. Standards Track [Page 20] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[20ページ]。
Authors' Addresses
作者のアドレス
Michael Daniele SyAM Software, Inc. 1 Chestnut St, Suite 3-I Nashua, NH 03060 USA
マイケルダニエルSyAMソフトウェアInc.1の栗の通り、3Iのナッシュア、スイートニューハンプシャー03060米国
Phone: +1 603 598-9575 EMail: michael.daniele@syamsoftware.com
以下に電話をしてください。 +1 603 598-9575 メールしてください: michael.daniele@syamsoftware.com
Brian Haberman Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
ブライアンハーバーマンジョーンズ・ホプキンス大学応用物理研究所11100のジョーンズ・ホプキン・Road MD20723-6099ローレル(米国)
Phone: +1-443-778-1319 EMail: brian@innovationslab.net
以下に電話をしてください。 +1-443-778-1319 メールしてください: brian@innovationslab.net
Shawn A. Routhier Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501 USA
ショーンA.Routhierが500の風の川の方法アラメダ(カリフォルニア)94501で水系Inc.を巻き上げする、米国
Phone: +1 510 749-2095 EMail: shawn.routhier@windriver.com
以下に電話をしてください。 +1 510 749-2095 メールしてください: shawn.routhier@windriver.com
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany
ユルゲンSchoenwaelderの国際大学ブレーメン私書箱750 561 28725・ブレーメンドイツ
Phone: +49 421 200-3587 EMail: j.schoenwaelder@iu-bremen.de
以下に電話をしてください。 +49 421 200-3587 メールしてください: j.schoenwaelder@iu-bremen.de
Daniele, et al. Standards Track [Page 21] RFC 4001 Internet Network Address Conventions February 2005
ダニエル、他 規格はインターネットネットワーク・アドレスコンベンション2005年2月にRFC4001を追跡します[21ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と、www.rfc-editor.orgに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Daniele, et al. Standards Track [Page 22]
ダニエル、他 標準化過程[22ページ]
一覧
スポンサーリンク
