[要約] 要約: RFC 3737は、リモートモニタリング(RMON)MIBモジュールのレジストリのためのIANAガイドラインを提供しています。 目的: このRFCの目的は、RMON MIBモジュールのレジストリを効果的に管理し、ネットワーク管理者が必要な情報を容易に見つけることを支援することです。

Network Working Group                                          B. Wijnen
Request for Comments: 3737                           Lucent Technologies
Category: Standards Track                                     A. Bierman
                                                     Cisco Systems, Inc.
                                                              April 2004
        

IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules

リモート監視レジストリ(RMON)MIBモジュールのIANAガイドライン

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.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の現在のエディションを参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2004). All Rights Reserved.

Copyright(c)The Internet Society(2004)。無断転載を禁じます。

Abstract

概要

This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring (rmon) root. This memo also documents the currently assigned values.

このドキュメントでは、IANAがリモート監視(RMON)ルートの下でオブジェクト識別子(OID)ツリーを管理および維持する手順を定義します。このメモには、現在割り当てられている値も文書化されています。

1. Introduction
1. はじめに

The RMONMIB Working Group so far has maintained its own registry for OID assignments for new MIB modules under the root OID for rmon [RFC2819]. This has worked reasonably well, although errors had to be corrected at a late stage one or two times, and a few now defunct assignments have been made as well.

これまでのところ、Rmonmibワーキンググループは、RMON [RFC2819]のルートOIDの下で、新しいMIBモジュールのOID割り当ての独自のレジストリを維持しています。これはかなりうまく機能しましたが、エラーは後期段階で1〜2回修正する必要があり、いくつかの現在の廃止された割り当ても行われています。

It is also a somewhat non-standard way of doing things, because normally a new standards track MIB module will get a MIB root assigned at the time that the module is being published as part of an RFC.

通常、新しい標準はMIBモジュールを追跡すると、モジュールがRFCの一部として公開されている時点でMIBルートが割り当てられるため、物事を行う標準以外の方法でもあります。

This document lists the currently assigned rmon OIDs. It also describes the procedures and rules for new assignments and asks IANA to take over the responsibility for existing and future assignments.

このドキュメントには、現在割り当てられているRMON OIDSがリストされています。また、新しい課題の手順と規則についても説明し、IANAに既存および将来の課題に対する責任を引き継ぐよう求めます。

The current assignments are not all too logical. Initially normal MIB OIDs were assigned under rmon, but at a later time the WG used the rmon root OID to create new MIB modules underneath it. Some people will claim 'an OID is just an OID', and while this is true, it does not make things easier if the organisation of OIDs is not logical. However, we cannot change what has been assigned in the past. From now on, only MODULE-IDENTITY macro (MIB root) assignments will be made (by IANA) under the 'rmon' node. Within a MIB module, the working group authors/editors can then assign their own OIDs according to normal procedures.

現在の割り当ては、それほど論理的ではありません。当初は通常のMIB OIDがRMONの下で割り当てられていましたが、後でWGはRMONルートOIDを使用して、その下に新しいMIBモジュールを作成しました。一部の人々は「OIDは単なるOID」と主張しますが、これは真実ですが、OIDの組織が論理的でない場合、物事を容易にしません。ただし、過去に割り当てられたものを変更することはできません。これからは、「RMON」ノードの下で(IANAによって)モジュールアイデンティティマクロ(MIBルート)のみのみが行われます。MIBモジュール内で、ワーキンググループの著者/編集者は、通常の手順に従って独自のOIDを割り当てることができます。

2. Currently assigned OIDs under the rmon root
2. 現在、RMONルートの下にOIDが割り当てられています

At the time of this writing, the following OIDs have been assigned and IANA has picked up this information in their public registry of assigned values. They are listed as part of the already existing smi-numbers registry at:

この執筆時点で、次のOIDが割り当てられており、IANAは割り当てられた値の公開レジストリでこの情報を受け取りました。それらは、既存のSMI番号レジストリの一部として:

http://www.iana.org/assignments/smi-numbers

http://www.iana.org/assignments/smi-numbers

...mib-2.rmon (1.3.6.1.2.1.16)

... MIB-2.RMON(1.3.6.1.2.1.16)

The assignments under ...mib-2.rmon were maintained by the RMONMIB Working Group until publication of RFC 3737. Some (early) assignments may not look all too logical. That is true, but that is history and cannot be changed. From now on, only MODULE-IDENTITY macro (MIB root) assignments will be made (by IANA) under the 'rmon' node.

MIB-2.RMONの下の割り当ては、RFC 3737の公開までRmonmibワーキンググループによって維持されていました。それは本当ですが、それは歴史であり、変更することはできません。これからは、「RMON」ノードの下で(IANAによって)モジュールアイデンティティマクロ(MIBルート)のみのみが行われます。

   Key: nnn == { rmon nnn }
        
      nnn   descriptor            OID Type                 Document
        
        0   rmonEventsV2          Notifications root       [RFC2819]
        1   statistics            OID                      [RFC2819]
        2   history               OID                      [RFC2819]
        3   alarm                 OID                      [RFC2819]
        4   hosts                 OID                      [RFC2819]
        5   hostTopN              OID                      [RFC2819]
        6   matrix                OID                      [RFC2819]
        7   filter                OID                      [RFC2819]
        8   capture               OID                      [RFC2819]
        9   event                 OID                      [RFC2819]
       10   tokenRing             OID                      [RFC1513]
       11   protocolDir           OID                      [RFC2021]
       12   protocolDist          OID                      [RFC2021]
       13   addressMap            OID                      [RFC2021]
       14   nlHost                OID                      [RFC2021]
       15   nlMatrix              OID                      [RFC2021]
       16   alHost                OID                      [RFC2021]
       17   alMatrix              OID                      [RFC2021]
       18   usrHistory            OID                      [RFC2021]
       19   probeConfig           OID                      [RFC2021]
       20   rmonConformance       OID                      [RFC2021]
       21   mediaIndependentStats OID                      [RFC3273]
       22   switchRMON            M-I                      [RFC2613]
       23   apm                   M-I                      [RFC3729]
       24   available
       25   pmCapsMIB             M-I (defunct)
       26   dsmonMIB              M-I                      [RFC3287]
       27   interfaceTopNMIB      M-I                      [RFC3144]
       28   reserved for sspmMIB  M-I    [..rmonmib-sspm-mib-nn.txt]
       29   hcAlarmMIB            M-I                      [RFC3434]
       30   reserved for tpmMIB   M-I     [..rmonmib-tpm-mib-nn.txt]
       31   reserved for raqmon   M-I  [..rmonmib-raqmon-mib-nn.txt]
       32   reserved for raqmonDs M-I  [..rmonmib-raqmon-pdu-nn.txt]
        
    Key: xxx == { rmon.rmonConformance xxx }
        

...mib-2.rmon.conformance (1.3.6.1.2.1.16.20)

... mib-2.rmon.conformance(1.3.6.1.2.1.16.20)

      xxx   descriptor            OID Type                 Document
        
        1   rmon2MIBCompliances   OID                      [RFC2021]
        2   rmon2MIBGroups        OID                      [RFC2021]
        3   smonMIBCompliances    OID                      [RFC2613]
        4   smonMIBGroups         OID                      [RFC2613]
        5   hcRMON                M-I                      [RFC3273]
        6   hcRmonMIBCompliances  OID                      [RFC3273]
        7   hcRmonMIBGroups       OID                      [RFC3273]
        8   rmonMibModule         M-I                      [RFC2819]
        9   rmonCompliances       OID                      [RFC2819]
       10   rmonGroups            OID                      [RFC2819]
        
3. How to request a new assignment for a MIB module
3. MIBモジュールの新しい割り当てをリクエストする方法

When anyone is writing a internet-draft for which a new assignment is needed/wanted under the rmon OID, then the proper way to do so is as follows:

RMON OIDの下で新しい割り当てが必要/指名されているインターネットドラフトを書いている場合、そのための適切な方法は次のとおりです。

      EXAMPLE-MIB DEFINITIONS ::= BEGIN
        

IMPORTS rmon FROM RMON-MIB

RMON-MIBからRMONをインポートします

.. other imports ..

..その他の輸入。

exampleMIB MODULE-IDENTITY

Examplemibモジュール同一性

... other normal MODULE-IDENTITY stuff ...

...その他の通常のモジュール同一性...

      ::= { rmon nnn }  -- IANA: please assign nnn
                        -- RFC-Editor: replace nnn with IANA-assigned
                        --             number and remove this note
        

IANA will assign the number as part of the RFC publication process.

IANAは、RFC出版プロセスの一部として番号を割り当てます。

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

This memo describes procedures for IANA assignment of OBJECT IDENTIFIER values, and has no impact on the security of the Internet.

このメモは、オブジェクト識別子値のIANA割り当ての手順について説明しており、インターネットのセキュリティに影響を与えません。

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

IANA has picked up the initial set of assignments and integrated them into the existing registry for smi-numbers at:

IANAは、割り当ての最初のセットを取り上げ、smi数の既存のレジストリに統合しました。

http://www.iana.org/assignments/smi-numbers

http://www.iana.org/assignments/smi-numbers

The list is presented in Section 2.

リストはセクション2に示されています。

IANA is requested to maintain this registry for future assignments. New assignments can only be made via Standards Action as described in [RFC2434].

IANAは、将来の割り当てのためにこのレジストリを維持するように要求されています。[RFC2434]に記載されているように、新しい割り当ては標準アクションによってのみ行うことができます。

IANA will assign the number as part of the RFC publication process.

IANAは、RFC出版プロセスの一部として番号を割り当てます。

6. Acknowledgments
6. 謝辞

This document was produced as a result of discussion between the Operations and Management AD responsible for Network Management and the WG chair for the RMONMIB Working Group. Thanks to Andy Bierman for keeping and administering the registry up to this point in time.

このドキュメントは、ネットワーク管理を担当するオペレーションと管理広告とRmonmibワーキンググループのWG議長の間の議論の結果として作成されました。この時点までレジストリを維持および管理してくれたアンディビアマンに感謝します。

The document has been reviewed by the RMONMIB Working Group.

このドキュメントは、Rmonmibワーキンググループによってレビューされています。

7. Normative References
7. 引用文献

[RFC1513] Waldbusser, S., "Token Ring Extensions to the Remote Network Monitoring MIB", RFC 1513, September 1993.

[RFC1513] Waldbusser、S。、「トークンリングリモートネットワーク監視MIBへの拡張リング」、RFC 1513、1993年9月。

[RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.

[RFC2021] Waldbusser、S。、「リモートネットワーク監視管理情報ベース2バージョン2」、RFC 2021、1997年1月。

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。

[RFC2613] Waterman, R., Lahaye, B., Romascanu, D. and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999.

[RFC2613] Waterman、R.、Lahaye、B.、Romascanu、D。、およびS. Waldbusser、「スイッチ型ネットワークのMIB拡張機能のリモートネットワーク監視バージョン1.0」、RFC 2613、1999年6月。

[RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000.

[RFC2819] Waldbusser、S。、「リモートネットワーク監視管理情報ベース」、STD 59、RFC 2819、2000年5月。

[RFC3144] Romascanu, D., "Remote Monitoring MIB Extensions for Interface Parameters Monitoring", RFC 3144, August 2001.

[RFC3144]ロマスカヌ、D。、「インターフェイスパラメーター監視用のリモートモニタリングMIB拡張機能」、RFC 3144、2001年8月。

[RFC3273] Waldbusser, S., "Remote Network Monitoring Management Information Base for High Capacity Networks", RFC 3273, July 2002.

[RFC3273] Waldbusser、S。、「リモートネットワーク監視管理情報ベースの大容量ネットワークの基盤」、RFC 3273、2002年7月。

[RFC3287] Bierman, A., "Remote Monitoring MIB Extensions for Differentiated Services", RFC 3287, July 2002.

[RFC3287] Bierman、A。、「差別化されたサービスのリモート監視MIB拡張機能」、RFC 3287、2002年7月。

[RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring MIB Extensions for High Capacity Alarms", RFC 3434, December 2002.

[RFC3434] Bierman、A。およびK. McCloghrie、「高容量アラームのリモート監視MIB拡張機能」、RFC 3434、2002年12月。

[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.

[RFC3729] Waldbusser、S。、「アプリケーションパフォーマンス測定MIB」、RFC 3729、2004年3月。

8. Authors' Addresses
8. 著者のアドレス

Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands

Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschotenオランダ

   Phone: +31-348-407-775
   EMail: bwijnen@lucent.com
        

Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA

Andy Bierman Cisco Systems、Inc。170 West Tasman Drive San Jose、CA米国

   Phone: +1-408-527-3711
   EMail: abierman@cisco.com
        
9. 完全な著作権声明

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

Copyright(c)The Internet Society(2004)。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となりますが、著者はすべての権利を保持しています。

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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

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エディター機能の資金は現在、インターネット協会によって提供されています。