Re: [Isms] Next steps for Extended VACM?

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

David Harrington writes...

> We do not want to see how.
> We might want to specify what it must heed, and what behavior
> SHOULD be followed. I think this might be addressed in some
> EOP that precede the VACM EOP.

SHOULD or MUST?

Since is this is an SNMP document, I think that specifying Elements of
Procedure, and generally structuring is as much like other SNMP documents as
the authors may be capable of is a reasonable suggestion. 

> It would seem appropriate to store the RADIUS attributes in the local
> datastore associated with a session.

And exactly how does the "local data-store associated with the session"
differ from "tmStateReference"?  A rose by any other name...

> The RADIUS-handling EOP will need access to RADIUS attributes at a
> point where it has no access to tmStateReference.

Unless, of course, the implementation-dependent information passing method
is simply to pass a pointer to the tmStateReference.  :-)

> We are developing RADIUS-aware VACM; I will refer to this extension in
> my email as RACM.

Hmmm.  I'm not too fond of that nomenclature, so I won't adopt it.

> The RACM doc should specify the EOP for creating a row. If a row
> exists for the user that was not created by the RACM, then RACM cannot
> create it, and should increment an error counter. This will probably
> be a RACM-specific error, and should be defined in the RACM-MIB. I
> believe the creation process should create the row in the same table
> that VACM currently uses. After RACM creates the row, normal VACM EOP
> processing is done, with no required changes.

Right.

> The RACM doc should specifiy the EOP for deleting a row. It does not
> try to restore previous row contents; it just deletes the row it
> created earlier. The rows should be deleted under certain conditions:
> 1) A SET changes RowStatus to delete
> 2) the session expires
> 3) a re-auth occurs occurs, forcing the deletion of the current row
> with the same index, and replacement by creation of a new row with the
> same index.

Sounds like a good start.

> All of this EOP happens outside the scope of VACM.

It happens in what I've been calling the VACM Extension or Extended VACM
"manager" (in reference to its role in "managing" the VACM MIB table(s).  I
think we agree on where all this happens, but perhaps not yet on the best
name for it.

> I didn't check whether there are any conditions in which VACM EOP adds
> or deletes a row dynamically. I don't think there is. But if there is,
> then RACM may need to delete the corresponding extra columns.

OK.