Re: registration OIDs: standardization

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Harrington, David" <dbh@enterasys.com>
> To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; "Andy Bierman" <abierman@cisco.com>
> Cc: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>; "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Tuesday, February 25, 2003 8:53 AM
> Subject: RE: registration OIDs: standardization
...
> 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?
...

One of the difficulties discussed at the workshop was that not all read-write objects
are appropriate for retrieval / playback as configuration information.  Consider
objects with "action" semantics as one example.  Having some kind of machine-
readable marker that would identify object definitions that should be considered
"configuration", "action", or whatever would be helpful, in my opinion.  Putting
them into separate OBJECT-GROUPs with "recognizable" names might provide
a convention that would assist tools, and might also be helpful in figuring out
some of the security considerations issues if there is an operational need to
separate provisioning from "live" control of resources.

The read-write/read-create/read-only distinction is not particularly helpful in
constructing a VACM view.  I think there's really no benefit to telling VACM
to block write access to an object whose MIB definition says it's read-only.
What would help, I think, would be having some way to know which objects
are needed for operational control, and which objects are needed for
provisioning / configuration management, because that distinction is useful
in constructing an access control policy.

Randy