Re: [Isms] Moving into some design /architectureissuesofExtendedVACM

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

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
> To: "David Harrington" <ietfdbh at comcast.net>
> Cc: <isms at ietf.org>
> Sent: Thursday, June 11, 2009 10:14 AM
> Subject: Re: [Isms] Moving into some design /architectureissuesofExtendedVACM
...
> My point is that have to define what the RADIUS client does in case
> the attempt to push something into the vacmSecurityToGroupTable fails
> - and depending on how long we want to work on this, we might go into
> all the details of distinguishing different failure modes. It will
> sure get complicated if we make it complicated.

There are actually relatively few - I spelled them out in an earlier
message.

> But the minimum we have to do is to specify what the RADIUS client
> does if the creation fails.

Yup, and I think the answer is "nothing."  There's no channel for
signalling back the failure.  From an implementation perspective,
if there aren't resources to create/update a vacmSecurityToGroupEntry,
then I'd be wary of trying to do things like queue up special-purpose
notifications for the security administrator, who'd be the one who'd have
to figure out a recovery strategy.

At an operational level, the user might notice that it was granted
different access rights than it expected.  The user might check its
vacmSecurityToGroupEntry (if it has permission to see it), or leave
that job to the security administrator.   (There would either be no entry,
or the group name specified in that entry would be the "old" one.)
In either case, figuring out a recovery strategy would still be up
to the security administrator, and would be no different from dealing
with a system that ran out of resources while a security policy update
was being pushed to it.

But I think we're off in the extreme corner cases here.  A system that
runs out of memory under these circumstances has a more serious
problem on its hands.  :-)

> And I think we should avoid making this
> really more complicated.

Agreed.

Randy