summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3737.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3737.txt')
-rw-r--r--doc/rfc/rfc3737.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3737.txt b/doc/rfc/rfc3737.txt
new file mode 100644
index 0000000..e2e39d4
--- /dev/null
+++ b/doc/rfc/rfc3737.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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
+
+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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+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.
+
+1. Introduction
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Wijnen & Bierman Standards Track [Page 1]
+
+RFC 3737 IANA Guidelines for the RMON Registry April 2004
+
+
+ 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.
+
+2. Currently assigned OIDs under the rmon root
+
+ 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:
+
+ http://www.iana.org/assignments/smi-numbers
+
+ ...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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnen & Bierman Standards Track [Page 2]
+
+RFC 3737 IANA Guidelines for the RMON Registry April 2004
+
+
+ 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]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnen & Bierman Standards Track [Page 3]
+
+RFC 3737 IANA Guidelines for the RMON Registry April 2004
+
+
+ Key: xxx == { rmon.rmonConformance xxx }
+
+ ...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
+
+ 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:
+
+ EXAMPLE-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ rmon FROM RMON-MIB
+
+ .. other imports ..
+
+ exampleMIB MODULE-IDENTITY
+
+ ... 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.
+
+4. Security Considerations
+
+ This memo describes procedures for IANA assignment of OBJECT
+ IDENTIFIER values, and has no impact on the security of the Internet.
+
+
+
+
+
+
+
+Wijnen & Bierman Standards Track [Page 4]
+
+RFC 3737 IANA Guidelines for the RMON Registry April 2004
+
+
+5. IANA Considerations
+
+ IANA has picked up the initial set of assignments and integrated them
+ into the existing registry for smi-numbers at:
+
+ http://www.iana.org/assignments/smi-numbers
+
+ The list is presented in Section 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 will assign the number as part of the RFC publication process.
+
+6. Acknowledgments
+
+ 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.
+
+ The document has been reviewed by the RMONMIB Working Group.
+
+7. Normative References
+
+ [RFC1513] Waldbusser, S., "Token Ring Extensions to the Remote
+ Network Monitoring MIB", RFC 1513, September 1993.
+
+ [RFC2021] Waldbusser, S., "Remote Network Monitoring Management
+ Information Base Version 2 using SMIv2", RFC 2021, January
+ 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [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.
+
+ [RFC2819] Waldbusser, S., "Remote Network Monitoring Management
+ Information Base", STD 59, RFC 2819, May 2000.
+
+ [RFC3144] Romascanu, D., "Remote Monitoring MIB Extensions for
+ Interface Parameters Monitoring", RFC 3144, August 2001.
+
+
+
+
+
+Wijnen & Bierman Standards Track [Page 5]
+
+RFC 3737 IANA Guidelines for the RMON Registry April 2004
+
+
+ [RFC3273] Waldbusser, S., "Remote Network Monitoring Management
+ Information Base for High Capacity Networks", RFC 3273,
+ July 2002.
+
+ [RFC3287] Bierman, A., "Remote Monitoring MIB Extensions for
+ Differentiated Services", RFC 3287, July 2002.
+
+ [RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring MIB
+ Extensions for High Capacity Alarms", RFC 3434, December
+ 2002.
+
+ [RFC3729] Waldbusser, S., "Application Performance Measurement
+ MIB", RFC 3729, March 2004.
+
+8. Authors' Addresses
+
+ Bert Wijnen
+ Lucent Technologies
+ Schagen 33
+ 3461 GL Linschoten
+ Netherlands
+
+ Phone: +31-348-407-775
+ EMail: bwijnen@lucent.com
+
+
+ Andy Bierman
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA
+ USA
+
+ Phone: +1-408-527-3711
+ EMail: abierman@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijnen & Bierman Standards Track [Page 6]
+
+RFC 3737 IANA Guidelines for the RMON Registry April 2004
+
+
+9. Full Copyright Statement
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Wijnen & Bierman Standards Track [Page 7]
+