Re: [Isms] Moving into some design / architecture issuesofExtended VACM

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

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> Cc: <isms at ietf.org>
> Sent: Monday, June 15, 2009 10:07 PM
> Subject: Re: [Isms] Moving into some design / architecture issuesofExtended VACM
...
> I do not think you need to mess around with contexts. If we can make
> multiple ACMs to work, the problem has a solution.
...

Multiple ACMs would be a wonderful theoretical Pandora's box project to give
to some grad student to play with.  Be careful what you wish for, especially when
it comes time to send notifications.  For the implementations with which I am
familiar, having multiple ACMs would be *very* tricky.  Don't forget the
extent to which isAccessAllowed is involved in the conceptual processing
of GetNext, GetBulk, and notifications, and that a real implementation,
rather than relying on the ASI abstraction, may look directly into the
heart of VACM in order to optimize subagent subtree queries during GetNext
and GetBulk.  Having the possibility of a different access control model
could throw a monkey wrench into those algorithms.

Folks think having VACM to deal with is difficult.  Just wait until
folks start putting in ACMs of their own in order to "simplify" things.

But it will give the WG, implementors, and operators a lot more to do,
so I suppose some might consider that a win.

Randy