Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

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

IP.com Disclosure Number: IPCOM000026529D
Original Publication Date: 2004-Apr-01
Included in the Prior Art Database: 2004-Apr-06
Document File: 8 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

B. Wijnen: AUTHOR [+2]

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 26% of the total text.

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'

nod...