RE: registration OIDs: standardization

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

Title: RE: registration OIDs: standardization

I absolutely agree. I think there are upsides and downsides to the approach.

 

Some upsides:

1) separation of config objects helps to identify which objects to include in snapshots and peristent memory, to meet the requests of operators, and

2) separation of writable and readable objects improves ease of defining VACM views, to meet the requests of operators for improved ease of use/deployment.

 

Downsides:

1) We would need to train mib writers to do things differently than they did for SNMPv1 (i.e. we might need to favor ease of use for operators over ease of mib writing for developers), and

2) the recommendation would be inconsistent with the design of most existing IETF standard mibs, and

3) the recommendation would be inconsistent with the design of most existing enterprise-specific mibs.

 

My recommendation is nothing more than a proposal for an incremental improvement that will address some of the issues we face in the SNMP community. It incrementally improves ease of use within the type of management strategy the NANOG/RIPE/LISA and IAB NM workshop identified as most common, and it improves compatibility with the concepts of SNMPv3 - the current IETF standard for NM.

 

dbh

-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: Tuesday, February 25, 2003 10:52 AM
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-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