RE: registration OIDs: standardization

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

> 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