Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-10..txt Part-I

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 03 Sep 2010 01:22:12 +0900

Hi,
  The following is a review of the revised document
    draft-ietf-isms-radius-vacm-10.txt.
I am happy to note that the document is looking much better,
most of the concerns raised in the review of -09.txt
have been addressed. Thanks. I will summarize the status below.

Cheers, Glenn

+------------------------------------------------------------+

1. I-D Boilerplate -- OK.
2. Abstract        -- OK.
==> Fixed.
3. MIB Boilerplate -- OK.
4. Security Considerations Section -- OK.
==> The actual vulnerabilities are not spelled out.
5. IANA Considerations Section     -- OK.
6. References                      -- OK.
6.1 RFC 5590 added
==> Fixed.
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).
==> There does not seem to be a  definitive reference which can
    be cited. AAA-DOCTORS advised that this is not an
    "important enough issue that changes to the document are
     required".
7. Copyright notices -- OK.
8. IPR notices -- OK.
9. Other Issues:
  a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to
==> Fixed.
10.Technical content -- review of actual technical content for
   compliance with rfc4181
10.1  MIB compilation using smilint -- NOK.
   The REFERENCE clause for vacmAaaSecurityToGroupEntry should precede
   the INDEX clause. A fix is required on Page 11
==> TBD
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.
==> Fixed.

10.2.2 the naming of the objects:
       consider the usage of the naming convention recommended in
       RFC 4181.
==> Fixed.
10.2.3 In the DESCRIPTION vacmAaaSecurityToGroupEntry row object.
      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. Relevant parts must appear
      in the DESCRIPTION clause of this object.
==> Unresolved.
10.2.4 The term "AAA binding" appears for the first time here.
==> Fixed
10.2.5 The term "Security Name" is used
==> Fixed (securityName is used and Reference is added)
10.2.6  the object tmSessionID appears in this DESCRIPTION clause for
     the first time in this memo.
     Please add a REFERENCE clause citing the appropriate section
     in RFC 5590. E.g.
==> Fixed.
10.3  Document issues
==> The concerns raised on consistent terminology have been addressed.

On 2010/08/23 22:28, Glenn M. Keeni wrote:
> Hi,
> I have volunteered to do a MIB Doctor review of
> <draft-ietf-isms-radius-vacm-09.txt>. I have completed Part-I
> the more-or-less mechanical checklist aspects. I will work on
> and send a Part-II of comments on the remaining aspects of the
> memo.
> 
> The document is well written and has gone through several
> revisions. I appreciate the compactness of the MIB.
> 
> The comments below follow the checklist from Appendix A of
> rfc4181.txt. Please send comments/responses to the isms
> mailing list with cc to me and [email-masked].
> 
> Glenn
> 
> +--------------------------------------------------------------+
> 
> 1. I-D Boilerplate -- OK.
> 2. Abstract        -- OK.
>     Please move the "Comments are solicited ... org" part to
>     Status of this Memo section or any other more appropriate
>     place.
> 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.
> 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.
> 5. IANA Considerations Section     -- OK.
> 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.
> 
> 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).
> 
> 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.
> 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.
> 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).
> 
> 10.Technical content -- review of actual technical content for
>     compliance with rfc4181
> 10.1  MIB compilation using smilint -- OK.
> 
> 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
> 
> 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.
> 
> 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.)
> 
>        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
> 
>        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.
> 
> 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.]
> 
>       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 }
> 
> 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).
> 
> 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 }
> 
> 
> 
> 10.3  Document issues
>        TBD
> 
> 
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 3 Sep 2010 17:10:56 -0700

Hi -

> From: "Glenn M. Keeni" <[email-masked]>
> To: <[email-masked]>; "Glenn Mansfield Keeni" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, September 02, 2010 9:22 AM
> Subject: [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-10..txtPart-I
...
>       in the DESCRIPTION clause of this object.
...

The -10 draft added the following to the DESCRIPTION
of vacmAaaSecurityToGroupEntry:

                 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.

The -09 text already clearly (I thought) described conditions for deletion.
I think the current -10 text provides what is needed, so I'd like to know
precisely what additional text is needed here. 

Randy

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 04 Sep 2010 15:58:05 +0900

Hi,
  I have noted that conditions for creation have been added to the
DESCRIPTION clause in the -10.draft. But, the DESCRIPTION still does
not capture the semantics of the table and the entry as is given in
Sec 7. Particularly what may be called the side-effects. To be specific-
a. When an entry is created in vacmAaaSecurityToGroupTable there are
   side-effects on vacmSecurityToGroupTable. This is specified in
   Sec 7.2.3 but does not appear in the DESCRIPTION and may be lost
   to the MIB reader/user/implementer.
b. When an entry is deleted from vacmAaaSecurityToGroupTable there
   may be side-effects on vacmSecurityToGroupTable. This is specified
   in Sec. 7.3.2 but does not appear anywhere in the DESCRIPTION.

Please add corresponding text to the DESCRIPTION.

Glenn

 2010/09/04 9:10, Randy Presuhn wrote:
> Hi -
> 
>> From: "Glenn M. Keeni"<[email-masked]>
>> To:<[email-masked]>; "Glenn Mansfield Keeni"<[email-masked]>
>> Cc:<[email-masked]>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 04 Sep 2010 17:22:48 +0900

Hi,
  This is the part-II of the review. With the extensive edits done by
the editor in -10.txt most of the concerns raised in the review of
-09.txt have been fixed or become irrelevant.
  There is one comment. In section 7.2.4 second paragraph

|  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",
|  then a role (group) mapping for this user (principal) has already
|  been put in place on this system, and will not be overridden.

Is that what we want to say? E.g. are we saying
   "If a corresponding entry already exists in the
    vacmSecurityToGroupTable and the RowStatus is "notReady"
    [notInService|..], then a role (group) mapping for this user
    (principal) has already been put in place on this system..." ?

To me appears that RowStatus other than active is just plain
unknown territory.
I fail to see how RowStatus other than "active" will imply
that there is a group mapping for this principal on the system.
Have I missed something?

In the subsequent (third) paragraph we have only the rationale
behind StorageType based action. There is no explanation about
the RowStatus based action.

Glenn

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Sep 2010 11:24:19 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Saturday, September 04, 2010 1:22 AM
> Subject: MIB Doctor Review: draft-ietf-isms-radius-vacm-10..txtPart-II
>
> Hi,

The other possible values of the RowStatus (notInService and notReady)
suggest that the row in question is still being manipulated by
(presumably) the security administrator, and we shouldn't modify
it.  This seems obvious from the RowStatus TC, and not in need of
explanation.  If the security administrator has created, or is in the
process of creating, a group mapping, we shouldn't mess with it.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Sep 2010 19:14:44 -0700

Hi -

> To: <[email-masked]>
> Sent: Saturday, September 04, 2010 6:50 PM
> Subject: Re: [IETFMIBS] MIB DoctorReview: draft-ietf-isms-radius-vacm-10..txtPart-II
...
> But the question is
> >>      (principal) has already been put in place on this system..."
> is that an accurate statement?
> How/why does RowStatus other than "active" imply that there IS a group
> mapping for this principal on the system.'?

As I understand VACM, the existence of an entry in the
vacmSecurityToGroupTable is *by* *definition*
a group mapping for a principal on the system.
 
> I understand that
> a. the operator may change his/her mind and send a set RowStatus to
>    "destroy" command for the row that was in notInService and notReady.
>    So in effect the row never sees the light of the day:-)
> b. RowStatus notReady implies that the columns of the row may not
>    have sufficient information (e.g. vacmGroupName ).

Yes, but what difference does either of these points make?  VACM was very
carefully designed so that the semantics of the user/group mapping are still
well-defined even when the vacmGroupName has no referent.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Sep 2010 19:25:33 -0700

Hi -

Perhaps it would be helpful to think through this from a different
perspective: that of avoiding surprises for the security administrator.

Consider a security administrator doing create-and-wait provisioning
of the vacmSecurityToGroupTable.  Rows will exist with various
values for RowStatus and StorageType, until things are finally as
the administrator wants them.  At that point, there will be the
StorageType -> nonVolatile and RowStatus -> active transition.  We
don't want the AAA-supplied group to override whatever the security
administrator is putting in place.

The constraints in the current draft minimize the possibility of surprises.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Sep 2010 22:08:08 -0700

Hi -

> Sent: Saturday, September 04, 2010 9:14 PM
> Subject: Re: [IETFMIBS]MIB DoctorReview: draft-ietf-isms-radius-vacm-10..txtPart-II
...
> The issue is the accuracy of the statement (St-1) that appears in the
> current draft in the above context.
> St-1:
>     'If a corresponding entry already exists in the
>      vacmSecurityToGroupTable and the RowStatus is anything other than
>      "active" [e.g. notReady|notInService|..], then a role (group)
>       mapping for this user (principal) has already been put in place
>       on this system...'
> 
> Q-1. Is this an accurate statement?

yes

> Q-2. Is it possible that there is an entry in vacmSecurityToGroupTable
>       with RowStatus notReady and with no value for the vacmGroupName.
>      If the answer is "no" - my understanding of the table is
>      incomplete.
>      If the answer is yes - then next question is-

yes, though the mapping is from that user to a non-existent group

> Q-3  How do we know, even in the absence of a vacmGroupName value for
>      the corresponding vacmSecurityToGroupEntry that a "role (group)
>      mapping for this user (principal) has already been put in place
>      on this system" ?
>      This is something that I am certainly missing.

RFC 3415's DESCRIPTION clause for vacmSecurityToGroupEntry says
"An entry in this table maps the combination of a securityModel and
securityName into a groupName"  If the entry exists, QED.

> Is there any pointer that will substantiate the statement (St-1)?

I don't know how to make it any clearer.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 4 Sep 2010 22:19:10 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Glenn M. Keeni" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, September 04, 2010 9:52 PM
...
> No.
...

I disagree.  Consider security model X, user Y:

  administrator sends a set request with a single varbind:
        vacmSecurityToGroupStatus.X.Y = createAndWait

if that requests succeeds, then
    vacmSecurityToGroupStatus will be notReady
    vacmGroupName will have no value assigned
    vacmSecurityToGroupStorageType's value is not defined

The DESCRIPTION of vacmSecurityToGroupStatus explicitly says:

                 Until instances of all corresponding columns are
                 appropriately configured, the value of the
                 corresponding instance of the vacmSecurityToGroupStatus
                 column is 'notReady'.

                 In particular, a newly created row cannot be made
                 active until a value has been set for vacmGroupName.

 Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 5 Sep 2010 08:00:11 +0200

>                  active until a value has been set for vacmGroupName.

Sorry, I confused vacmGroupName with vacmSecurityName. You are
absolutely right.

/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: "Glenn M. Keeni" <[email-masked]>
Date: Sun, 05 Sep 2010 16:58:23 +0900

On 2010/09/05 14:08, Randy Presuhn wrote:
>> To:<[email-masked]>
I see your point here. And I disagree.
You are not implying that even if there is no value assigned to
vacmGroupName there is a mapping to some groupName somewhere and
that is implied by the DESCRIPTION in RFC3415. Are you?

The DESCRIPTION in RFC3415 is clear. It maps a securityModel and
securityName into a groupName which will be carried out by the
     vacmGroupName.SecModel.SecName = GroupName
assignment for a securityModel = SecModel and securityName = SecName.
If there is no GroupName assigned then there is no mapping, not yet.
This can happen when the RowStatus is "notReady". So obviously,
the DESCRIPTION of RFC3415 does not apply to such rows. [I guess
the same will apply to all Tables.]

> I don't know how to make it any clearer.
Yes. You have made it clear - but you are stretching the DESCRIPTION
beyond the applicable scope.

Glenn

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Sun, 5 Sep 2010 10:37:52 -0400

>> Q-1. Is this an accurate statement?

Will changing the wording slightly as suggested below be of any help ?  

... then a role (group) mapping for this user (principal) is presumably
already in place
on this system...'

- Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Glenn M. Keeni
Sent: Sunday, September 05, 2010 3:58 AM
To: [email-masked]; [email-masked]
Subject: Re: [Isms][IETFMIBS]MIB DoctorReview:
draft-ietf-isms-radius-vacm-10..txtPart-II

On 2010/09/05 14:08, Randy Presuhn wrote:
> Hi -
> 
>> From: "Glenn M. Keeni"<[email-masked]> To:<[email-masked]>
>> Subject: Re: [IETFMIBS]MIB DoctorReview: 
>> draft-ietf-isms-radius-vacm-10..txtPart-II
> ...

> RFC 3415's DESCRIPTION clause for vacmSecurityToGroupEntry says "An 
> entry in this table maps the combination of a securityModel and 
I see your point here. And I disagree.
You are not implying that even if there is no value assigned to
vacmGroupName there is a mapping to some groupName somewhere and that is
implied by the DESCRIPTION in RFC3415. Are you?

The DESCRIPTION in RFC3415 is clear. It maps a securityModel and
securityName into a groupName which will be carried out by the
     vacmGroupName.SecModel.SecName = GroupName assignment for a
securityModel = SecModel and securityName = SecName.
If there is no GroupName assigned then there is no mapping, not yet.
This can happen when the RowStatus is "notReady". So obviously, the
DESCRIPTION of RFC3415 does not apply to such rows. [I guess the same
will apply to all Tables.]

Glenn
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 06 Sep 2010 07:38:19 +0900

> ... then a role (group) mapping for this user (principal) is presumably
Yes. It does help. Thanks.

Glenn

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 5 Sep 2010 16:25:04 -0700

Hi -

> To: <[email-masked]>; <[email-masked]>
> Sent: Sunday, September 05, 2010 12:58 AM
> Subject: Re: [IETFMIBS][Isms] MIB DoctorReview: draft-ietf-isms-radius-vacm-10..txtPart-II
...
> that is implied by the DESCRIPTION in RFC3415. Are you?

Yes.  The mapping is to null (in the database sense).  That's the only way
I can make sense of the VACM elements of procedure.  The original
proposal for what became VACM was horrifically complicated by inter-table
fate sharing due to over-zealous referential integrity constraints.  We
simplified things considerably by nailing down what it meant to, for example,
reference to a non-existant group.

> If there is no GroupName assigned then there is no mapping, not yet.

No.  The entry represents the mapping.  If there is an entry, there is a mapping.
In this particular case, the value mapped to is (database) null, which is a guaranteed
"no match" in terms of access policy.

> beyond the applicable scope.

What can I say?   This conversation doesn't seem to be going anywhere,
so I think we'll need to leave it to the WG and document shepherd to resolve this.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Sep 2010 10:04:20 +0200

> reference to a non-existant group.

I think step 2) in section 3.2 of RFC 3415 applies in this case. The
procedure stops with a noGroupName errorIndication. My understanding
of RowStatus is that a notReady row is not yet available to be used by
the managed device. But even if an implementation looks at such rows,
as Randy pointed out, you end up with a null group name that won't
provide you meaningful access either. VACM has been designed to handle
this corner case well.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 7 Sep 2010 11:48:59 -0700

Hi -

> From: "Donati Andrew-MGIA0477" <[email-masked]>
> To: "Glenn M. Keeni" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Sunday, September 05, 2010 7:37 AM
> Subject: Re: [IETFMIBS][Isms]MIB DoctorReview: draft-ietf-isms-radius-vacm-10..txtPart-II
>
> >> St-1:

Thanks for the suggestion.  Since the part of the sentence that seems to
be causing difficulty is merely explanation, rather than specification, perhaps
we should just eliminate the explanatory material.  Would this make
everyone happy?

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",
then a role (group) mapping for this user (principal)
has already been 
put in place on this system,
and will not be overridden.

NEW:
If a corresponding entry already exists in the
vacmSecurityToGroupTable,
and that row's StorageType is anything other than "volatile",
or its RowStatus is anything other than "active",
then that instance of vacmGroupName MUST NOT be modified.

Randy

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 08 Sep 2010 19:59:24 +0900

(2010/09/08 3:48), Randy Presuhn wrote:
> Hi -
> 
>> From: "Donati Andrew-MGIA0477"<[email-masked]>
>> To: "Glenn M. Keeni"<[email-masked]>;<[email-masked]>;<[email-masked]>

Yes. This looks/sounds good. Thanks.

Glenn