Subject: [MIB-DOCTORS] status of draft-ietf-radius-vacm-10.txt

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Sep 2010 11:31:05 -0700

Hi -

I think all the issues from the MIB doctor review have
been resolved except the request to add more text to
the DESCRIPTION of vacmAaaSecurityToGroupEntry.

As editor, I'm awaiting direction from the working
group on this item.  Below is my summary of where I think
the issue stands.
---------------------------------------

The current editor's copy says:

vacmAaaSecurityToGroupEntry OBJECT-TYPE
    SYNTAX       VacmAaaSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry in this table maps the combination of a
                 SnmpSecurityModel and securityName into the name
                 of a VACM group defining the access control policy
                 which is to govern a particular session.

                 Each entry corresponds to a session.

                 Entries do not persist across reboots.

                 An entry is created whenever an indication occurs
                 that a new session has been established that would
                 not have the same index values as an existing entry.

                 When a session is torn down, disconnected, timed out
                 (e.g., following the RADIUS Session-Timeout Attribute),
                 or otherwise terminated for any reason, the
                 corresponding vacmAaaSecurityToGroupEntry is deleted."
    REFERENCE   "RFC 3411 section 3.2.2 defines securityName"
    INDEX       {
                  vacmAaaSecurityModel,
                  vacmAaaSecurityName,
                  vacmAaaSessionID
                }
    ::= { vacmAaaSecurityToGroupTable 1 }

The requirement from RFC 4181 cited by the reviewer is:

     - If the agent itself may also create and/or delete rows, then the
       conditions under which this can occur MUST be clearly documented
       in the row object DESCRIPTION clause.

If one were in hair-splitting mode, one might argue that the requirement
does not apply in this case for two reasons.  First, it is subordinate
to the condition "[i]f dynamic row creation and/or deletion by management
applications is supported", and this is clearly not the case here.  (I do
agree with the general notion that the DESCRIPTION of a row should
provide the conditions under which those entries come into and go out
of existence, and the current text does so.)  Secondly, the changes requested
by the reviewer are to supply information about *another* table in a
different MIB module.

The issue is that the operation of the specification which happens to
contain this MIB module also entails the creation, modification, and
deletion of entries in the vacmSecurityToGroupTable.  The mechanism
by which these changes happen is not specified, but the conditions
may be described in terms of when certain changes would happen to the
vacmAaaSecurityToGroupTable, and the changes themselves are described
in terms readily translated to a management interface.  The question, as
I see it, is whether the DESCRIPTION of vacmAaaSecurityToGroupTable
is the appropriate place to replicate the description of how the
normal operation of the AAA/VACM spec would update VACM's
vacmSecurityToGroupTable.  My own opinion is that this would be
confusing rather than enlightening, and is not required by the
guidelines.

Opinions, and more importantly, ACTUAL TEXT, would be welcome!
As far as I know, this is the only issue preventing us
from returning the document to the IESG for approval.

Randy