[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Comments on BCP-09



Hi -

> Message-Id: <5.1.0.14.2.20020805130325.03525ba0@127.0.0.1>
> Date: Mon, 05 Aug 2002 17:43:47 -0700
> To: snmpconf@snmp.com, snmpconf@snmp.com
> From: "David T. Perkins" <dperkins@dsperkins.com>
> Subject: Re: snmpconf Comments on BCP-09
> In-Reply-To: <5.1.0.14.0.20020805144345.02b19e98@mail.goldwiretech.com>
> References: <5.1.0.14.2.20020805103913.0350fcc0@127.0.0.1>
>  <5.1.0.14.2.20020805093606.035106b0@127.0.0.1>
>  <5.1.0.14.0.20020628165708.02d37818@mail.goldwiretech.com>
>  <5.1.0.14.2.20020626215950.03476a20@127.0.0.1>
...
>    due to a flapping situation (a hysterics mechanism such as
>    that found in RMON). Instead, a side trip is made into the
...

Uh... working group dynamics aside, I think you mean hysteresis.  :-)

...
> 6) Fine grained access control assignment - a desirable property
>    is to allow management apps to create resource instances
>    via an SNMP set, and to gain "exclusive" or "owner" access
>    as found in file creation operations found in many operating
>    systems, such as the Unix variants. However, the VACM-based
>    access control is VERY different than Unix-like file access
>    control. 

This is by design.  VACM's requirements are quite different
from those for a file system.  For example, VACM needs to
be able to represent an access control policy for things
independent of whether the specific instance exists at the
moment.

>             A design pattern was introduced in the MIB modules
>    from the DISMAN WG which attempted to mimic the Unix-like
>    access control behavior on creation. 

No.  As much as I dislike the implicit delegation approach
that shows up in several disman MIBs (inherited with mutations
from RMON) I must say that it was *not* intended to mimic
Unix semantics.  The Unix concept of "setuid" was used to
illustrate one of the things that one might want to support,
but the extent of the relationship was that existing practice
for scripts and scheduling in Unix was used to help understand
what the requirements and use cases might be.

...
>                                         This design pattern
>    is flawed (and many have not yet realized it). Please
>    describe the objective, show the MIB design pattern and
>    describe how it is flawed. 

If you have a proposal to fix the currently deployed
specifications, please take it to the disman WG.  Until those
specifications are fixed, they remain, for better or worse,
the "best current practice."

>                               (Note that another design pattern
>    to give fined grained access control is found in table
>    usmUserTable in RFC 2574.) The pluses and minuses of
>    the design pattern used there should be pointed out.
...

The kludgy *OwnKeyChange objects have a very special purpose,
and the kludginess was deemed acceptable in the interest of
keeping VACM reasonably scalable.  Using that approach would
be really bad news in other MIBs, since none of the published
subagent protocols would support it, as far as I know, and there
was not sufficient interest in the AgentX WG to do anything
about it.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San Josť, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------