RE: registration OIDs: standardization

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

I would like to echo Andy's opinion. Typically MIB groups are being organized on functional and operational criteria. 'Status' and 'Configuration' are interleaved and organizing the objects 'by decree' in separate subtrees seems to me leading to unnecessary duplication, without visible benefit. 

Maybe I am missing something, but identifying 'configuration objects' in the context described below seems to me just identifying what objects are writebale. This can be done easily without imposing a new subtree structure. 

Dan
 

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Tuesday, February 25, 2003 5:52 PM
> To: Harrington, David
> Cc: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: RE: registration OIDs: standardization
> 
> 
> 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-n
m-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