RE: registration OIDs: standardization

["Harrington, David" <dbh@enterasys.com>]

Title: RE: registration OIDs: standardization

I recommend putting the writable status objects under configuration, so it is easy to know they should be saved across rebbots, or included in a snapshot of the running config.

 

Some of that will be domain-specific of course. All we can do is use the 80/20 rule to try to improve the current state of affairs.

 

dbh

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Monday, February 24, 2003 10:33 AM
To: Harrington, David; Mreview (E-mail)
Subject: RE: registration OIDs: standardization

> We encourage standardzied subtree structure at Enterasys as well.
>
> I would like to recommend
>
> >xxxNotifications OBJECT IDENTIFIER ::= { xxxMIB 0 }
> >xxxObjects       OBJECT IDENTIFIER ::= { xxxMIB 1 }
> xxxStatusObjects  OBJECT IDENTIFIER ::= { xxxObjects 1 } -- status and statistics
> xxxConfigObjects  OBJECT IDENTIFIER ::= { xxxObjects 2 } -- config and control
> >xxxConformance   OBJECT IDENTIFIER ::= { xxxMIB 2 }
>
I like that. Do you intend monitoring objects to be part of Status?
I know that there are "status" or "Operational State" opbjects
that would still be writable (for example to enable or disable some
iface or function), which is quite different from just objects that
are always read-only (e.g. max-access read-only) for just monitoring.

Bert
>
> This would make it easier to identify configuration objects,
> in response to section 2.1 of
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-iab-nm-workshop-01.txt:

"SNMP does not support easy retrieval and playback of
      configurations.  One part of the problem is that it is not easy to
      identify configuration objects. "

dbh