Re: snmpconf Comments on BCP-09

HI,

on the following...
At 06:56 PM 8/5/2002 -0700, Randy Presuhn wrote:
><stuff cut>
>> 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.
Yes, the property of VACM to create "access policys" that refer
to instances that don't yet exist is a good property. The limitation
of VACM to not being able to directly support "set access to x"
on create for creator's group is a problem with VACM.

>>             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."
Sure...

>>    (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.
Again, understanding of both the pluses and minus of an approach
allows us to make better future choices. Maybe some of those
choices with be a better master/sub-agent interface.

Regards,
/david t. perkins