Subject: [IETFMIBS] Proposed resolution of comments on draft-ietf-isms-radius-vacm-09.txt

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 24 Aug 2010 21:12:25 -0700

Hi -

Since the comments have been arriving for over three weeks,
here's a summary of where I think we stand with the comments on
draft-ietf-isms-radius-vacm-09.txt  Please note that in a few cases
there are potential conflicts / interactions between the comments.
Due to the extensive nature of the changes needed to accommodate the
MIB review, in my personal opinion this document should go back to
the working group for another last call to make sure these changes
haven't broken something.

Comment from Amanda Baber, July 30, 2010:
IANA has reviewed draft-ietf-isms-radius-vacm-09.txt, which is
currently in Last Call, and has the following comments:

We understand that, upon publication of this document, IANA will be
expected to register the following MIB-2 number at
http://www.iana.org/assignments/smi-numbers

Decimal   Name          Description                      References
-------   ----          -----------                      ----------
[TBD]  snmpVacmAaaMIB    SNMP-VACM-AAA-MIB               [RFC-ietf-isms-radius-vacm-09.txt]

Action: None
Notes: This interacts with the MIB review comment on naming

Comment from Joel Jaeggli, August 8, 2010:
...
The security considerations section (9) goes far beyond the ordinary
enumeration of limitations and recommendations in order proscribe
procedural behaviors that should be in force in an implementation of
VACM. I'm of two minds on the contnent of the security considerations
section. Either it should be sub-divided to seperately deal with the
identity/access control considerations and the sensitivity of exposure
of various mib elements or the access control considerations should be
moved to the procedural section (7) since the following section of (9)
is essentially an implementation detail.
...

Action: security considerations section split accordingly, with
new subsection headings "Principal Identity Naming" and
"Management Information Considerations".
Notes:  No substantive changes here.

Comment from Magnus Nyström, August 16, 2010:
1. (Editorial:) Suggest letting the first paragraph form a new
   sub-subsection 7.2.1: "Required Information". Easier to reference.
Action: done

Comment from Magnus Nyström, August 16, 2010:
2. In the current subsection 7.2, please clarify if all items are
   required for "further processing" or not. The current text just
   states that User-Name and Management-Policy-ID are.
Action: done.  Added "All four of these pieces of information are REQUIRED"
after the list.

Comment from Magnus Nyström, August 16, 2010:
3. Current sub-subsection 7.2.1 seems to indicate that neither the
   User-Name nor the Management-Policy-ID are required (says "or equivalent").
   Please clarify if this is inconsistent with the text in 7.2 or not (maybe
   I'm missing something here).
Action: none
Notes: Dave Nelson sent Magnus a detailed explanation on the future-
proofing rationale behind the language.  My understanding is that no
specific change has been requested here.

Comment from Magnus Nyström, August 16, 2010:
4. In Section 7.2.3, how many groups can a user be a member of for
   a given securityModel in this design? Only one?
Action: clarify by adding this sentence at the end of 7.2.3:
      The structure of the vacmSecurityToGroupTable makes it
      impossible for a vacmSecurityModel, vacmSecurityName tuple to
      map to more than one group.

Comment from Francis Dupont, August 17, 2010:
 - 1 page 3: perhaps (because it is in the 'well known' list) you should
 put again the definition of the "MIB" abbrev?
 - 4.1 page 4: the user-to-role (group) mapping -> mappings?
 - 4.1 page 4 (last word): behaviour -> behavior
 - 7.1 page 6: They rely critically -> They critically rely?
 - 7.2.1 page 7: in use -> in use; and identifier -> identifier;
  (the ; at the end of list items is the French typo rule, I don't
   know the English one, nor the RFC one if there is one :-)
 - 7.2.3 page 8 (last line): supercede -> supersede
 - 8 page 9: LAST-UPDATED "201007150000Z"          -- 14 July, 2010
  -> 15 July
 - 8 page 10 vacmAaaSecurityToGroupTable: used for  the -> used for the
 - 8 page 10 vacmAaaSecurityToGroupEntry: e.g. -> e.g.,
 - 9 page 13: dangling ')'? in 'RADIUS User-Name).'
Action: all comments accommodated, except the change from "mapping" to
"mappings" which could be potentially misleading.

Comment from Glenn M. Keeni, August 23, 2010:
1. I-D Boilerplate -- OK.
Action: none needed

Comment from Glenn M. Keeni, August 23, 2010:
2. Abstract        -- OK.
   Please move the "Comments are solicited ... org" part to
   Status of this Memo section or any other more appropriate
   place.
Action: offending text deleted

Comment from Glenn M. Keeni, August 23, 2010:
3. MIB Boilerplate -- OK.
   Body of the boilerplate is verbatim.
   References are not not exact copies.
   For RFC2578, RFC2579, there is an additional "Ed.," for
   each author which is not there in the boilerplate. But
   this is not a problem. It accurately reflects the actual
   RFCs.
Action: none

Comment from Glenn M. Keeni, August 23, 2010:
4. Security Considerations Section -- OK.
   The Sensitive objects are listed but the risk/vulnerability
   is not mentioned.
   I would recommend adding something like
     These objects may reveal that User X has logged on with
        Security privileges Y in session Z .
        This raises atleast two issues.
        o Revealing the information may amount to breaching the
          privacy of the User.
        o The information may be misused by an attacker. E.g.
          he/she may focus/narrow down his/her attack by making
          informed guesses about the target system.
Action: none
Notes: comment discussed, consensus that sufficient information
is already present

Comment from Glenn M. Keeni, August 23, 2010:
5. IANA Considerations Section     -- OK.
Action: none
Notes:  This section may need to change, depending on how
the comments on naming are resolved.

Comment from Glenn M. Keeni, August 23, 2010:
6. References                      -- NOK.
6.1 RFC 5590 to be added
|      vacmAaaSessionID OBJECT-TYPE
|          SYNTAX       Unsigned32
|          MAX-ACCESS   not-accessible
|          STATUS       current
|          DESCRIPTION "A specific identifier of the session.
|
|                       This value MUST be unique among all currently open
|                       sessions of all of this SNMP engine's transport
models.
|                       The value has no particular significance other
than to
|                       distinguish sessions.  Implementations in which
|                       tmSessionID is unique across all transport
models MAY
|                       use the tmSessionID value."
|          ::= { vacmAaaSecurityToGroupEntry 3 }

   A reference to RFC 5590 where the object "tmSessionID" is
   probably defined, is required.
   [I note that the reference was there in the earlier versions
    of this memo but then it got removed along with "tmStateReference"
       http://www.ietf.org/mail-archive/web/isms/current/msg04177.html]
   Please put it back. Also, please note that this will be a
   normative reference.
Action: Add a REFERENCE clause to this OBJECT-TYPE, pointing to RFC 5590
Add RFC 5590 to the list of normative references.
Notes:  I believe we'll also need to cite this reference somewhere outside
the MIB module to satisfy idnits.  We need proposed text.  Note well that
the WG consensus was to DELETE the only bit of text referring to RFC 5590.
As a technical contributor, I'm not sure this is really a normative reference,
since it's really only an example of what may be done - it's not really
"OPTIONAL" in the normal sense of MAY.

Comment from Glenn M. Keeni, August 23, 2010:
6.2 A reference to AAA service architecture/Framework will be
    in order if this document does target generic AAA services
   (as the title suggests).
Action: add citations suggested by reviewer in followup message
OLD:
|  Model (VACM) [RFC3415] MIB objects, based on information received
|  from an Authentication, Authorization, and Accounting (AAA) service,
|  such as RADIUS [RFC2865].
NEW:
|  Model (VACM) [RFC3415] MIB objects, based on information received
|  from an Authentication, Authorization, and Accounting (AAA) service
|  [RFC2903, RFC2904], such as RADIUS [RFC2865].

Comment from Glenn M. Keeni, August 23, 2010:
7. Copyright notices -- OK.
   Not in accordance with rfc3978 as reqd by rfc4181 but follows
   the latest requirements as in
   http://www.ietf.org/ietf-ftp/1id-guidelines.txt.
Action: none

Comment from Glenn M. Keeni, August 23, 2010:
8. IPR notices -- OK.
   Not in accordance with rfc3978 as reqd by rfc4181 but follows
   the latest requirements as in
   http://www.ietf.org/ietf-ftp/1id-guidelines.txt.
Action: none

Comment from Glenn M. Keeni, August 23, 2010:
9. Other Issues:
  a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to
     the list of imperatives (although the standard boilerplate in
     RFC 2119 does not include it, it is used in the Security
     Considerations section and it is defined in RFC 2119).
Action: none
Notes: this is a long-standing RFC 2119 problem to be sorted out
by the IESG.  This document uses the standard boilerplate.

Comment from Glenn M. Keeni, August 23, 2010:
10.Technical content -- review of actual technical content for
   compliance with rfc4181
10.1  MIB compilation using smilint -- OK.
Action: none
Notes: due to other extensive changes recommended by this reviewer, the
MIB will need to be re-checked

Comment from Glenn M. Keeni, August 23, 2010:
10.2  MIB issues
10.2.1 In the MODULE-IDENTITY
|         REVISION "201007150000Z"
|         DESCRIPTION "Initial version, published as RFC XXXX."
|          ::= { mib-2 XXX }
      the note to the RFC-Editor to handle the literal XXX is
      missing. I suggest-
OLD:
|         REVISION "201007150000Z"
|         DESCRIPTION "Initial version, published as RFC XXXX."
|          ::= { mib-2 XXX }
NEW:
|         REVISION "201007150000Z"
|         DESCRIPTION "Initial version, published as RFC XXXX."
|          ::= { mib-2 XXX }
|         -- RFC Ed.: replace XXX with IANA-assigned number & remove
this note
Action:  add the RFC editor note
Notes: this new text is redundant with the RFC editor note already present
in the IANA considerations section

Comment from Glenn M. Keeni, August 23, 2010:
10.2.2 the naming of the objects:
       In the MIB module the naming hierarchy uses the following
       prefixes
       snmpVacmAaaMIB
       |
       +-- vacmAaaMIBObjects
       |
       +-- vacmAaaMIBCompliance

       This does not follow the recommended naming conventions
       given in Appendix C of RFC 4181 which urges the pattern

       snmpVacmAaaMIB
       |
       +-- snmpVacmAaaMIBObjects
       |
       +-- snmpVacmAaaMIBCompliance

       Please note, I have not found any opinions strong or weak
       about the naming in the ISMS-WG mailing list archives.
       [I have not looked at the archives in detail]
       If the naming in the document is the result of deliberations
       in the WG, please ignore this comment. Otherwise, please
       consider the usage of the naming convention recommended in
       RFC 4181.
Action: currently "c"
Notes: three proposals discussed as a result of this comment:
    (a) do nothing (i.e., be consistent with VACM)
    (b) the changes suggested by Glenn (which would arguably
        ripple to all the MIB objects)
    (c) the counter-proposal suggested by Randy (changing just
        the module and module-identity)

Comment from Glenn M. Keeni, August 23, 2010:
10.2.3 In the DESCRIPTION vacmAaaSecurityToGroupEntry row object.
|     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 a
GroupName for
|                      a particular session.
|
|                      Each entry corresponds to a session.
|
|                      Entries do not persist across reboots.
|
|                      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."

      There is a need to mention the conditions under which the row is
      created.
      According to RFC 4181
       "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."

      The details are present in Section 7.2.1. Please add the relevant
      part to the DESCRIPTION clause of this object. (That includes the
      row update protocol.)
Action: since reviewer is adamant on this point, clone section 7.2.1
into the DESCRIPTION
Notes: this will be a headache if the document is ever revised.

Comment from Glenn M. Keeni, August 23, 2010:
      It will be useful to have the term "AAA binding" mentioned here
      (see 10.2.4, 10.2.5 below).  E.g.
OLD:
|         DESCRIPTION "An entry in this table maps the combination of a
NEW:
|         DESCRIPTION "An entry in this table represents a AAA binding
|                      which maps the combination of a
Action: accommodated, in conjunction with other "AAA binding" comments

Comment from Glenn M. Keeni, August 23, 2010:
      The terms "SnmpSecurityModel" and "SecurityName" are confusing as
      they represent TEXTUAL CONVENTIONS which in turn represent the
      SYNTAX and to some extent the semantics of objects. These are not
      objects.
      I recommend using "Security Model" and "Security Name". These terms
      are used (not defined) in subsequent object DESCRIPTIONS.
Action:

Comment from Glenn M. Keeni, August 23, 2010:
10.2.4
|     vacmAaaSecurityModel OBJECT-TYPE
|         SYNTAX       SnmpSecurityModel(1..2147483647)
|         MAX-ACCESS   not-accessible
|         STATUS       current
|         DESCRIPTION "The Security Model associated with the AAA binding
|                      represented by this entry.
|
|                      This object cannot take the 'any' (0) value."
|         ::= { vacmAaaSecurityToGroupEntry 1 }

     The term "AAA binding" appears for the first time here.
     (And in subsequent Object DESCRIPTIONs.). This term needs
     to be defined.
     [This will be remedied if the recommendation in 10.2.3 is
      implemented.]
Action: Accommodated as part of "AAA binding" comment bundle

Comment from Glenn M. Keeni, August 23, 2010:
     The term "Security Model" appears for the first time here.
     Presumably it is the term defined in RFC3411.
     A REFERENCE clause would be appropriate here. E.g.
OLD:
|     vacmAaaSecurityModel OBJECT-TYPE
|         SYNTAX       SnmpSecurityModel(1..2147483647)
|         MAX-ACCESS   not-accessible
|         STATUS       current
|         DESCRIPTION "The Security Model associated with the AAA binding
|                      represented by this entry.
|
|                      This object cannot take the 'any' (0) value."
|         ::= { vacmAaaSecurityToGroupEntry 1 }
NEW:
|     vacmAaaSecurityModel OBJECT-TYPE
|         SYNTAX       SnmpSecurityModel(1..2147483647)
|         MAX-ACCESS   not-accessible
|         STATUS       current
|         DESCRIPTION "The Security Model associated with the AAA binding
|                      represented by this entry.
|
|                      This object cannot take the 'any' (0) value."
|         REFERENCE   "RFC 3411; Section 3.1.1.4.1"
|         ::= { vacmAaaSecurityToGroupEntry 1 }
Action: done

Comment from Glenn M. Keeni, August 23, 2010:
10.2.5
|         vacmAaaSecurityName OBJECT-TYPE
|         SYNTAX       SnmpAdminString (SIZE(1..32))
|         MAX-ACCESS   not-accessible
|         STATUS       current
|         DESCRIPTION "The Security Name of the principal associated
with the
|                      AAA binding represented by this entry.  In RADIUS
|                      environments, this corresponds to the User-Name
|                      Attribute."
|         ::= { vacmAaaSecurityToGroupEntry 2 }

     The term "AAA binding" appears for the first time here.
     A clear description of this term should be given.
     [This will be remedied if the recommendation in 10.2.3 is
      implemented.]

     The term "Security Name" is used here. It is first used in
     Section 7.1 in the context "SNMP Security Name [RFC3411]".
     RFC 3411 does NOT have the term Security Name. It has a
     "securityName" object, though. In this memo there is no
     other reference to "Security Name".

     The DESCRIPTION says "In RADIUS environments, this corresponds
     to the User-Name Attribute."
     To me it appears that in the AAA/RADIUS context this is the
     "User-Name" (RFC 2865 section 5.1) and in VACM context it is
     "securityName" (RFC 3411 section 3.2.2).

     Please
          o fix the DESCRIPTION;
          o add a REFERENCE clause citing the appropriate
            document(s).
Action: "AAA binding" handled with that comment bundle
"Security Name" and "SNMP Security Name" to be replaced
with securityName throughout.  REFERENCE clause to be added.

Comment from Glenn M. Keeni, August 23, 2010:
10.2.6
|      vacmAaaSessionID OBJECT-TYPE
|          SYNTAX       Unsigned32
|          MAX-ACCESS   not-accessible
|          STATUS       current
|          DESCRIPTION "A specific identifier of the session.
|
|                       This value MUST be unique among all currently open
|                       sessions of all of this SNMP engine's transport
models.
|                       The value has no particular significance other
than to
|                       distinguish sessions.  Implementations in which
|                       tmSessionID is unique across all transport
models MAY
|                       use the tmSessionID value."
|          ::= { vacmAaaSecurityToGroupEntry 3 }
     the object tmSessionID appears in this DESCRIPTION clause for
     the first time in this memo. Presumably this refers to the
     tmSessionID object in RFC 5590.
     Please add a REFERENCE clause citing the appropriate section
     in RFC 5590. E.g.
OLD:
|     vacmAaaSessionID OBJECT-TYPE
|         SYNTAX       Unsigned32
|         MAX-ACCESS   not-accessible
|         STATUS       current
|         DESCRIPTION "A specific identifier of the session.
|
|                      This value MUST be unique among all currently open
|                      sessions of all of this SNMP engine's transport
models.
|                      The value has no particular significance other
than to
|                      distinguish sessions.  Implementations in which
|                      tmSessionID is unique across all transport models MAY
|                      use the tmSessionID value."
|         ::= { vacmAaaSecurityToGroupEntry 3 }
NEW:
|     vacmAaaSessionID OBJECT-TYPE
|         SYNTAX       Unsigned32
|         MAX-ACCESS   not-accessible
|         STATUS       current
|         DESCRIPTION "A specific identifier of the session.
|
|                      This value MUST be unique among all currently open
|                      sessions of all of this SNMP engine's transport
models.
|                      The value has no particular significance other
than to
|                      distinguish sessions.  Implementations in which
|                      tmSessionID is unique across all transport models MAY
|                      use the tmSessionID value."
|         REFERENCE   "RFC 5590: Section 4.1.2"
|         ::= { vacmAaaSecurityToGroupEntry 3 }
Action: accepted
Notes: if RFC 5590 is added to the normative references section, we
will need to cite it in the text of the document somewhere.  No text
has been suggested.

Comment from Jari Arkko, August 23, 2010:
I had a question about the scope of the document. The document
says:

   It describes the use of
   information provided by Authentication, Authorization, and Accounting
   (AAA) services, such as the Remote Authentication Dial-In User
   Service (RADIUS), to dynamically update user-to-group mappings in the
   View-Based Access Control Model (VACM).
   ...
   This memo specifies a way to simplify the administration of the
   access rights granted to users of network management data.

I'm certainly not at all an expert on VACM but I thought that RFC 5607
already enabled dynamic updates of user-to-group mappings.

As far as I can determine, *this* document only creates a MIB
view of those mappings, so that they can be monitored or debugged
externally. Or at least there are no new rules regarding Management-
Policy-Id attribute treatment beyond RFC 5607 that would have
an effect beyond a change in the new MIB.

As a result, I do not understand how the document enables "dynamic
updates of user-to-group mappings" or "simplify administration".
What am I missing?

If I have understood the scope correctly, then perhaps the two
sentences that I quoted should be toned down.

Action:  elide first and second sentences, removing offending material
OLD:  This memo specifies a way to simplify the administration of the access
rights granted to users of network management data. It functions to dynamically
provision

NEW:
This memo specifies a way
to dynamically provision

Comment from Glenn M. Keeni, August 24, 2010:
10.3  Document issues

a.  Terminology:
    I suggest that a Terminology section be added. Several terms used
    in this document are open to mis-interpretation.  E.g.
    "group":
    This is a generic term. But, in this document it probably, without
    exception, refers to a group as in the VACM document[RFC 3415; Sec 2.1].
    I would recommend
      stating early in the document that the term "group" refers to the
      term defined in [RFC 3415; Sec 2.1] or,
      defining a "VACM-group" and replacing all occurrences of "group" by
      "VACM-group"

    "authenticated user":
    This is a generic term. It would be good to make it clear in the
      document that the term "authenticated user" refers to a user
      authenticated by the AAA services. Or,
      define a "AAA-authenticated user" and use that term consistently for
      the rest of the document.
    [The terms "AAA-authenticated" and "AAA-authorized" are used in the
    document but sporadically.]

    The terms "Security Name", "Security Model", "Group Name" should be
    defined/referred and used consistently in the document. Else,
    the terms securityName, securityModel, groupName should be used
    with appropriate pointers [RFC 3415].

Action: add new terminology section, reference citations to other uses

Comment from Glenn M. Keeni, August 24, 2010:
b.  Page 4. Sec 4.1
|   The use case assumption here is that roles within an organization,
|   which are reflected in VACM as groups and rules, change infrequently,
    I presume "rules" refer to the "access control policy" defined in the
    VACM ? If that is the case I would suggest
OLD:
|   The use case assumption here is that roles within an organization,
|   which are reflected in VACM as groups and rules, change infrequently,
NEW:
|   The use case assumption here is that roles within an organization,
|   which are reflected in VACM as groups and associated access control
|   policies", change infrequently,
Action: accepted

Comment from Glenn M. Keeni, August 24, 2010:
c.  Page 5. Sec 5.2
    Suggested change-
OLD:
    This table is indexed by the integer assigned to each security model
NEW:
    This table is indexed by the identifier assigned to the Security Model

    [Note: Security Model needs to have a pointer/definition early in the
     document.]
Action: no change from "integer" to "identifier", "term" added to Terminology
section.

Comment from Glenn M. Keeni, August 24, 2010:
d. Page 6. Sec 7.1
|  They also assume that the User-Name [RFC2865] from the RADIUS Access-
|  Request message (or equivalent) corresponds to an SNMP Security Name
|  [RFC3411].
    The term "SNMP Security Name" does not appear in RFC 3411.
    securityName is defined in RFC 3411 section 3.2.2.
    Suggested change-
OLD:
|  They also assume that the User-Name [RFC2865] from the RADIUS Access-
|  Request message (or equivalent) corresponds to an SNMP Security Name
|  [RFC3411].
NEW:
|  They also assume that the User-Name [RFC2865] from the RADIUS Access-
|  Request message (or equivalent) corresponds to an SNMP securityName
|  [RFC3411].
Action: accomodated with Terminology changes

Comment from Glenn M. Keeni, August 24, 2010:
e. Page 7. Sec 7.2
   SnmpSecurityModel is not defined in RFC 3411
   I suggest
OLD:
|  o  the SnmpSecurityModel [RFC3411] needed as an index into the
|     vacmSecurityToGroupTable;
NEW:
|  o  the SNMP Security Model, vacmSecurityModel [RFC3411], needed as an
|     index into the vacmSecurityToGroupTable;
    [Note: Security Model needs to have a pointer/definition early in the
     document.]
Action: accommodated with Terminology changes

Comment from Glenn M. Keeni, August 24, 2010:
f. Page 7. Sec 7.2
   the RADIUS User-Name Attribute or equivalent is also needed as an index
   into the vacmSecurityToGroupTable.
   I suggest
OLD:
|  o  the RADIUS User-Name Attribute or equivalent;
NEW:
|  o  the RADIUS User-Name Attribute or equivalent which will be used as
|     the index, vacmSecurityName, into the vacmSecurityToGroupTable;
Action: done

Comment from Glenn M. Keeni, August 24, 2010:
g. Page 7. Sec 7.2
|  In particular, if either the User-Name or Management-Policy-Id is
|  absent, invalid, or a zero-length string, no further processing of
|  the session establishment indication is undertaken.
   If the SNMP Security Model has value 'any' (0) then no further
   processing will be undertaken; is that correct? If that is that is
   the case I suggest
OLD:
|  In particular, if either the User-Name or Management-Policy-Id is
|  absent, invalid, or a zero-length string, no further processing of
|  the session establishment indication is undertaken.
NEW:
|  In particular, if either the User-Name or Management-Policy-Id is
|  absent, invalid, or a zero-length string, or, if the SNMP Security Model
|  has value 'any' (0), no further processing of
|  the session establishment indication is undertaken.
Action: none

Comment from Glenn M. Keeni, August 24, 2010:
h. Page 7. Sec 7.2.1
   Along the lines of the change in (e)
OLD:
|  o  vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to
|     the security model in use
NEW:
|  o  vacmAaaSecurityModel = value of SNMP Security Model corresponding to
|     the security model in use
Action: accommodated with terminology section

Comment from Glenn M. Keeni, August 24, 2010:
i. Page 7. Sec 7.2.1
|  o  vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent,
|     the securityName that will be used in invocations of the
|     isAccessAllowed() abstract service interface;
     "isAccessAllowed() abstract service interface" appears for the first
      time. Please provide a pointer/reference.
Action: reference added

Comment from Glenn M. Keeni, August 24, 2010:
j. Page 7. Sec 7.2.1
   The requirements for the vacmAaaSessionID are not explicit. I suggest
   using text from the DESCRIPTION of vacmAaaSessionID in the MIB module.
OLD:
|  o  vacmAaaSessionID = unique session identifier
NEW:
|  o  vacmAaaSessionID = session identifier. This value MUST be unique
|     among all currently open sessions of all of this SNMP engine's
|     transport models.
Action: done

Comment from Glenn M. Keeni, August 24, 2010:
k. Page 7. Sec 7.2.1
|  Otherwise, if the row already exists, update the vacmAaaGroupName
|  with the value supplied.
   It will be helpful to be explicit about "value supplied". I would
   suggest
OLD:
|  Otherwise, if the row already exists, update the vacmAaaGroupName
|  with the value supplied.
NEW:
|  Otherwise, if the row already exists, update the vacmAaaGroupName
|  with the RADIUS Management-Policy-Id Attribute or equivalent.
Action: done

Comment from Glenn M. Keeni, August 24, 2010:
l. Page 7. Sec 7.2.2
   Suggested change-
OLD:
|  If a corresponding entry already exists in the
|  vacmSecurityToGroupTable, and the row's StorageType is anything other
|  than "volatile", or the RowStatus is anything other than "active",
NEW:
|  If a corresponding entry already exists in the
|  vacmSecurityToGroupTable, and the row's vacmSecurityToGroupStorageType
|  is anything other than "volatile", or the vacmSecurityToGroupStatus is
|  anything other than "active",
Action: done

Comment from Glenn M. Keeni, August 24, 2010:
m. Page 7. Sec 7.2.2
   The second paragraph does not belong to this subsection.
   After making the change suggested in (l) move the paragraph (para-2)
   to section 7.2.3 after the 1st paragraph.
Action: None

Comment from Glenn M. Keeni, August 24, 2010:
n. Page 7. Sec 7.2.3
   Suggested change:
OLD:
|  The operational assumption here is that if the row's StorageType is
|  "volatile", then this entry was probably dynamically created; an
|  entry created by a security administrator would not normally be given
|  a StorageType of "volatile".  If value being provided by RADIUS (or
NEW:
|  The operational assumption here is that if the row's
|  vacmSecurityToGroupStorageType is "volatile", then this entry was
|  probably dynamically created; an entry created by a security
|  administrator would not normally be given a
|  vacmSecurityToGroupStorageType of "volatile". If the value being
|  provided by RADIUS (or
Action: done

Comment from Glenn M. Keeni, August 24, 2010:
o. Page 7. Sec 7.3.2
   s/StorageType/vacmSecurityToGroupStorageType/g;
Action: done

Comment from Glenn M. Keeni, August 24, 2010:
p. An  overview describing the relevant parts of the AAA service and the
   VACM may  be helpful to make the memo more easily understandable. The
   other option which I will not recommend will be to include a statement
   as terse as "the reader of this memo is expected to have read and
   understood the AAA service document RFC XXX1, the RADIUS document RFC
   XXX2 and the View-Based Access Control Model document RFC XXX3."
Action: latter sentence added to introduction

Comment from Glenn M. Keeni, August 24, 2010:
q.  AAA and RADIUS.
    I see that this has been discussed in the mailing list before. But I
    am afraid that the problem persists.
Action: included with "AAA binding" bundle.

Comment from Glenn M. Keeni, August 24, 2010:
Editorial nits.
a. Page 12 Sec 9
OLD:
|  could also occur if the SNMP security administrator had mistakenly
|  created these non-volatile entries in error.
NEW:
|  could also occur if the SNMP security administrator had mistakenly
|  created these non-volatile entries.
Action: done

Comment from Glenn M.  Keeni, August 24, 2010:
you must add the specifications given in  of 7.2.1, 7.2.2, 7.2.3,
7.3.1, 7.3.2 to the DESCRIPTION of the Table. The present DESCRIPTION
does not capture the specifications.
Action: clone text from 7.2.1, 7.2.2, 7.2.3, 7.3.1, and 7.3.2 to the
table description

The "AAA Binding" bundle: Many comments
Action: add "AAA Binding" to the terminology section, using
extracted text from David Harrington's post of August 24th.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Aug 2010 13:02:22 +0200

On Wed, Aug 25, 2010 at 12:49:05PM +0200, Dave Nelson wrote:
> I object to this issue resolution.  With all due respect to the reviewer,
> RFC 2903 and RFC 2904 are the work product of the IRTF AAA Architecture
> Research Group (AAAarch RG).  As far as I know, these documents have not
> formed the basis of any AAA protocols or systems in current deployment.  I
> believe that adding these references may in fact confuse the reader.

I agree (speaking as technical contributor). No change needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 25 Aug 2010 06:49:05 -0400

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 26 Aug 2010 12:55:18 +0900

Hi,
  If RFC 2903 and RFC 2904 are unacceptable as pointers to the
"Authentication, Authorization, and Accounting services" that
we are referring to in this document I am afraid the issue of a
definition/pointer to the phrase remains open.

  I will seek the AD's guidance on this issue.
Glenn