RE: registration OIDs: standardization

[Andy Bierman <abierman@cisco.com>]

At 10:20 AM 2/25/2003 -0500, Harrington, David wrote:
>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.

I think it should be pointed out that splitting status and config objects
into separate sub-trees is not a widely followed practice.  I don't
know of any MIBs (std or enterprise) that actually do this.  I think
this will make MIBs even harder to read and implement than they are
already.  This idea is well-intentioned, but needs some careful thought.

> 
>dbh

Andy

>-----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