RE: registration OIDs: standardization

["C. M. Heard" <heard@pobox.com>]

On Tue, 25 Feb 2003, Harrington, David wrote:
> 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.

I understood that efficient use of VACM views was the reason for
the proposal to put configuration and status objects in separate
subtrees.

> Of course the proposed approach might make it harder to identify
> families of functionally-related objects.

Yep.

> 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 [or] VACM views?

There are probably at least three subsets that you want to be
able to cleanly separate:

- Objects with security parameters

- Configuration objects

- Status/monitoring objects

If you segregate security parameters into separate MIB modules
of their own, I'll bet that you can do a very good (although
not perfect) job of separating configuration objects from
monitoring objects just by separating the read-write/read-create
objects from the read-only ones in the non-security-related
modules.  That does not sound like an overwhelmingly difficult
thing to do, and it does not depend on the MIB module having a
well-organized OID tree.

//cmh