RE: registration OIDs: standardization

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

Title: RE: registration OIDs: standardization

Hi Dan,

 

I didn't intend that it be decreed that mibs be structured this way, merely recommended. I also made no suggestion that objects should be duplicated.

 

During the IAB workshop, identifying configuration objects was raised as an issue. Is it really a non-issue? Any operators out there care to comment?

 

Identifying what objects are writable might serve just as well. What mechanisms do you recommend to do this to simplify capturing configurations? Do you know any tools that use the read-write syntax of a mib to determine which objects are used for configuration, and thus should be included in configuration snapshots?

 

I also don't care much for imposing a new tree structure. Enterasys doesn't use the proposed structure, and it would be a real pain to have to reorganize our structure to accommodate such an approach. But the current IETF standard calls for VACM views based on subtrees, and the interleaving of configuration and status objects makes it harder to separate out read-views and write-views efficiently. Of course the proposed approach might make it harder to identify families of functionally-related objects.

 

Should we be working on alternate mib structures that work better with VACM? alternates to VACM that work better with existing mib structure? alternate mib syntax (e.g. a compliance-statement like approach) to address the issue without changing either mib structures of VACM views?

 

I think we have some serious problems that need to be addressed to make SNMPv3 deployable, and they are not being addressed. I don't think they will be easy problems to solve, but I think we need to identify where problems exist, and consider changing the way we do things to better accommodate our "customers" requirements.

 

dbh

 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Tuesday, February 25, 2003 11:14 AM
To: Andy Bierman; Harrington, David
Cc: Wijnen, Bert (Bert); Mreview (E-mail)
Subject: RE: registration OIDs: standardization

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