Re: [Isms] Moving into some design/architectureissuesofExtendedVACM

["Dave Nelson" <d.b.nelson at comcast.net>]

David Harrington writes...

> While the SNMPv3 WG punted on designing an ACM selector field
> in the message, or some other mechanism, it was always the consensus
> of the SNMPv3 WG that multiple ACMs could exist and operate 
> simultaneously.

In other words, you're all pretty much in a state of denial. :-)

> COPS-PR was a no-go in the IETF because it demanded that if COPS-PR
> was enabled, then COPS-PR and only COPS-PR, controlled the policy
> decisions for a managed device

An interesting sidelight on IETF network management protocol history, but
not directly relevant to the current debate, I think.

> For me, this argument that when RADIUS is in use, it must
> be the only access control in play follows a similar vein of
> thinking, and I think this is a no-go.

Except that no one has ever said that.  What I have said is that the
"multiple writers" problem for AAA should be solved in an organized way,
following accepted principles of precedence -- primary and fallback -- and
not in the simple "last change takes precedence" fashion traditional to
SNMP.  The use of RADIUS does not preclude the use of statically configured
user-to-group data in the NAS, any more than the use of NIS for UNIX login
precludes the use of the /etc/passwd file.

Sometimes in order to obtain new functionality, you need to be open to
change.

All I'm asking is that the RADIUS provisioning operation model not be
violated, and that RADIUS provisioned access control information has a
lifetime limited to that of the underlying session.