Subject: Re: [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt

From: Sean Turner <[email-masked]>
Date: Fri, 13 Aug 2010 19:17:19 -0400

I've put this one the 8/26 telechat.  Any chance of a review before 
the end of next week?

Thanks!

spt

Romascanu, Dan (Dan) wrote:
> Any volunteers?
> 
> Dan 
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Sean Turner
>> Sent: Friday, July 30, 2010 9:56 AM
>> To: [email-masked]
>> Subject: [IETFMIBS] MIB Doctor Review: 
>> draft-ietf-isms-radius-vacm-09.txt
>>
>> I would like a MIB Doctor review of the following ID (which 
>> is currently in AD review): 
>> draft-ietf-isms-radius-vacm-09.txt.  Can I please note get 
>> Juergen, David H., and Randy as they were involved in the 
>> development of this I-D.
>>
>> Thanks!
>>
>> spt
>> _______________________________________________
>> IETFMIBS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietfmibs
>>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Aug 2010 15:29:04 +0200

Hi,

perhaps it helps to know that this document is 17 pages (including all
the boilerplate stuff) and the MIB module defines a single table with
just four columns. This document should be a relatively easy thing to
review.

/js

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 16 Aug 2010 22:46:06 +0900

Dan,
    I have never done a MIB Doctor review. Even then,
I will volunteer for this one, unless you have a better
candidate.

    Glenn

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Aug 2010 15:47:36 +0200

Thanks, Glenn. 

Can you do it until the end of this week? 

Dan

> [mailto:[email-masked]] On Behalf Of Glenn M. Keeni
> Sent: Monday, August 16, 2010 4:46 PM
> To: Juergen Schoenwaelder
> Cc: Sean Turner; [email-masked]
> Subject: Re: [IETFMIBS] MIB Doctor Review: 
>     I have never done a MIB Doctor review. Even then, I will 
> volunteer for this one, unless you have a better candidate.
> 
>     Glenn
> 
> >>>> I would like a MIB Doctor review of the following ID (which is 
> >>>> currently in AD review):
> >>>> draft-ietf-isms-radius-vacm-09.txt.  Can I please note 
> get Juergen, 
> >>>> David H., and Randy as they were involved in the development of 
> >>>> this I-D.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> spt

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 16 Aug 2010 23:41:32 +0900

Dan,
   I will be doing this mainly over the weekend. I
plan to get the review done by Monday morning JST.
Will that be OK?

   Glenn

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Aug 2010 16:53:16 +0200

This is fine. 

Can you just make sure that your review is forwarded to both mib-doctors
and isms lists? 

Thanks and Regards,

Dan

> From: Glenn M. Keeni [mailto:[email-masked]] 
> Sent: Monday, August 16, 2010 5:42 PM
> To: Romascanu, Dan (Dan)
> Cc: Juergen Schoenwaelder; Sean Turner; [email-masked]
>    I will be doing this mainly over the weekend. I plan to 
> get the review done by Monday morning JST.
> Will that be OK?
> 
>    Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Tue, 17 Aug 2010 00:06:11 +0900

OK.

Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 23 Aug 2010 22:28:19 +0900

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: Mon, 23 Aug 2010 14:12:49 -0700

Hi -

Thanks for the detailed review.
Comments in-line below.

> From: "Glenn M. Keeni" <[email-masked]>
> To: <[email-masked]>; "Glenn Mansfield Keeni" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, August 23, 2010 6:28 AM
> Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-I
>
> Hi,

If this sentence is a problem, then I propose just deleting it.

>    this is not a problem. It accurately reflects the actual

The references are what is generated by the current xml2rfc.
If this is a problem, then I suggest that either the boilerplate
or xml2rfc's citation library should be fixed.

I propose that no changes be made to this document here.

>           informed guesses about the target system.

I'm not sure how useful it is to enumerate specific ways in which
information already identified as potentially sensitive might be misused.
Since the security considerations section was quite contentious during the
development of this document, I'd like to see some indication
from the WG / Chairs whether the proposed text is actually necessary.
I assume you want the suggested text inserted immediately prior to the
paragraph beginning "SNMP versions".

>    Please put it back. Also, please note that this will be a

Given the contentiousness of this item, instead I would propose deleting
the sentence "Implementations in which tmSessionID is unique across
all transport models MAY use the tmSessionID value" and NOT adding
a reference, and NOT adding a REFERENCE.

>     in order if this document does target generic AAA services

Where would we need to reference such a reference?  Text please.

>      Considerations section and it is defined in RFC 2119).

OK.  Should I also remove from the list the ones that are not used?
Will any of these changes cause idnits to freak out?
 
> |         -- RFC Ed.: replace XXX with IANA-assigned number & remove

The complete instructions are already present in the IANA considerations section.
Do we really want the same instructions in multiple locations?

>        consider the usage of the naming convention recommended in

Given the large number of changes to both the MIB module and the
text that this would entail, I'd like to make a counter-proposal:

SNMP-VACM-AAA-MIB -> VACM-AAA-MIB
snmpVacmAaaMIB -> vacmAaaMIB

These two (relatively isolated) changes would satisfy the naming guideline
consistency request, with much lower risk of screwing something up in
the editing process.

>       part to the DESCRIPTION clause of this object. (That includes the

Ok.  My understanding is the proposal is to clone the content of section 7.2.1
within the DESCRIPTION of vacmAaaSecurityToGroupEntry.

> |                      which maps the combination of a

I'm not wild about the way "AAA binding" is turning into a term in this
document. It just crept in in June to address DBH's comments.  I'd rather
find a way to get rid of the phrase, rather than turn it into a technical term.
As a counter-proposal, I suggest eliminating "AAA binding" from the two
places where it appears.

>       objects.  I recommend using "Security Model" and "Security Name". These terms

Just in the MIB module or throughout the document?  In terms of mimizing the number
of changes to the document, I think it might be better to get rid of "Security Model"
(appearing only once) and "Security Name" (appearing only twice).
 
> |         ::= { vacmAaaSecurityToGroupEntry 1 }

Suggest deleting "the AAA binding represented by" to satisty earlier comments.

It's not clear to me how this REFERENCE clause would be helpful,
since the relevant semantics come with the textual convention itself.

>      [This will be remedied if the recommendation in 10.2.3 is

I think it might be simpler to just delete "the AAA binding represented by".

>      other reference to "Security Name".

"securityName" is used fairly consistently in the rest of the document, so
that would be my first choice for a replacement.    "SNMP Security Name"
would be a close second.
 
>           o add a REFERENCE clause citing the appropriate

Ok.  However, as a technical contributor this use of REFERENCE
does not seem terribly helpful to me, and I would like to hear
from others before I go ahead as editor and make this and similar changes.

> |         ::= { vacmAaaSecurityToGroupEntry 3 }

I think it's better to remove all reference to tmSessionID.  Providing any
hints to implementors has been contentious.  REQUIRing this
to be tmSessionID would make this table more useful, but tmSessionID
is so under-specified as to preclude this possibility.  This also avoids
any need to reference RFC 5590.
 
>       TBD

When?

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Aug 2010 09:10:35 +0200

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

[...]

> If this sentence is a problem, then I propose just deleting it.

I suggest we delete this sentence. The WG contact information is in
the MIB module and that should be sufficient.

> I propose that no changes be made to this document here.

I agree that no change is needed.

> paragraph beginning "SNMP versions".

The current text does a good job spelling out which information can
leak and I do not think we need to explain the many possible usages of
this information. I do not think a change is needed here.
 
> a reference, and NOT adding a REFERENCE.

I think the WG settled on the current text so I do not see why we 
now should remove it. Adding a REFERENCE to the document defining
tmSessionID does not seem to hurt, or does it?

> Where would we need to reference such a reference?  Text please.

Since it is unclear to me which document should be referenced, I think
we should not make a change.

> Will any of these changes cause idnits to freak out?

The text is the boilerplate coming from RFC 2119 and RFC 2119 has an
errata pending that indeed NOT RECOMMENDED is missing in the
boilerplate. There are recent RFCs that use NOT RECOMMENDED with the
RFC 2119 boilerplate. Also note that the NOT RECOMMENDED comes from
the SNMP security considerations boilerplate text - so likely every
RFC containing a MIB module published in the last few years has the
problem. In short, there is a general conflict here between
boilerplate texts that the IESG should sort out. Until this has
happened, I suggest we do what we have always done so far, namely
using RFC 2119 boilerplate text literally.
 
> The complete instructions are already present in the IANA
> considerations section.  Do we really want the same instructions in
> multiple locations?

I do not think we need to respin this document for this reason. But if
we do so, adding this hint to IANA also won't hurt.

> consistency request, with much lower risk of screwing something up in

The current naming scheme is consistent with the naming scheme used in
the SNMP-VIEW-BASED-ACM-MIB and thus I think we should not make
changes at this point in time. I also do not like the counter proposal.

> within the DESCRIPTION of vacmAaaSecurityToGroupEntry.

Can we just have a pointer to 7.2.1? Keeping redundant text consistent
is always a pain.

> As a counter-proposal, I suggest eliminating "AAA binding" from the two

I agree with the idea behind the counter proposal, although I have to
see the replacement text...

> Just in the MIB module or throughout the document?  In terms of
> mimizing the number of changes to the document, I think it might be
> better to get rid of "Security Model" (appearing only once) and
> "Security Name" (appearing only twice).

I think Glenn's comment concerns "SnmpSecurityModel" and
"SecurityName", not "Security Model" and "Security Name". In some
places the usage of the TC names seems quite appropriate while in some
other cases this might be less appropriate. That said, I do not see
any confusion that can be caused. Or lets put it different, replacing
"SnmpSecurityModel" generally with "Security Model" and "SecurityName"
"Security Name" will lead to other odd usages of "Security Model" and
"Security Name".

> Ok.  However, as a technical contributor this use of REFERENCE does
> not seem terribly helpful to me, and I would like to hear from
> others before I go ahead as editor and make this and similar
> changes.

I tend to agree that adding REFERENCE clauses to any term that shows
up in a DESCRIPTION clause is likely adding a lot of noise. In this
case, adding a reference to RFC 2865 section 5.1 might be appropriate
since SNMP implementors less likely know RADIUS attributes by heart.
But I assume that securityName is something SNMP access control
implementors will be rather familiar with.

[skipping issues that pop up multiple times]

/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: Tue, 24 Aug 2010 08:04:47 -0400

Juergen Schoenwaelder writes...

> > > 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).
> >
> Since it is unclear to me which document should be referenced,
> I think we should not make a change.

I am equally unaware of anything resembling an "AAA Framework" document.
It's possible that some requirements document written by members of the AAA
WG when they were attempting to find a successor to RADIUS (which became
Diameter) might be characterized as a "framework".  Still, we have nothing
in the AAA space equivalent to RFC 3410 for SNMP.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Aug 2010 14:18:48 +0200

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Nelson
> Sent: Tuesday, August 24, 2010 3:14 PM
> To: 'Randy Presuhn'; 'Glenn M. Keeni'; [email-masked]; 'Glenn 
> Mansfield Keeni'
> Cc: [email-masked]
> Subject: Re: [Isms] MIB Doctor 
> Review:draft-ietf-isms-radius-vacm-09.txtPart-I
> 
> Randy Presuhn writes...
> 
> > > |         DESCRIPTION "An entry in this table maps the 
> combination 
> > > | of a
> > > NEW:
> > I'm not wild about the way "AAA binding" is turning into a term in 
> > this document. It just crept in in June to address DBH's comments.  
> > I'd rather find a way to get rid of the phrase, rather than turn it 
> > into a technical term.
> >
> > As a counter-proposal, I suggest eliminating "AAA binding" from the 
> > two places where it appears.
> 
> Well, "AAA binding" is just short-cut notation for "The SNMP 
> SecurityName that has been authenticated by RADIUS as a 
> RADIUS User-Name Attribute".  It seems we can either have 
> accuracy or conciseness, but not both.  I don't think that 
> coming up with a short-form notational device, for use within 
> the scope of a single document is such a bad idea.  On the 
> other hand, simply deleting text is worse, if we actually 
> lose the fully nuanced meaning of the concept being referenced.
> 

So why not define the usage of the term in this document in the
'Conventions' section? 

Dan

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 24 Aug 2010 08:14:09 -0400

Randy Presuhn writes...

> As a counter-proposal, I suggest eliminating "AAA binding" from the two

Well, "AAA binding" is just short-cut notation for "The SNMP SecurityName
that has been authenticated by RADIUS as a RADIUS User-Name Attribute".  It
seems we can either have accuracy or conciseness, but not both.  I don't
think that coming up with a short-form notational device, for use within the
scope of a single document is such a bad idea.  On the other hand, simply
deleting text is worse, if we actually lose the fully nuanced meaning of the
concept being referenced.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Aug 2010 15:20:48 +0200

> So why not define the usage of the term in this document in the

I would rather expand the term - it only pops up in two places if I
recall correctly.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 24 Aug 2010 15:30:49 +0200

> From: Juergen Schoenwaelder 

> I would rather expand the term - it only pops up in two 
> places if I recall correctly.
> 

Either way is fine with me. 

Dan

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Tue, 24 Aug 2010 23:29:01 +0900

Hi,

Thanks for waiting. This is the Part-II of the MIB Doctor Review
of draft-ietf-isms-radius-vacm-09.txt. It focuses on the Document
issues.

Glenn

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

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].

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,

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.]

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].

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.]

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;

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.

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

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.
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.

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.

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",

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.

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
o. Page 7. Sec 7.3.2
   s/StorageType/vacmSecurityToGroupStorageType/g;

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."

q.  AAA and RADIUS.
    I see that this has been discussed in the mailing list before. But I
    am afraid that the problem persists.

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.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 24 Aug 2010 10:34:07 -0400

Hi,

(as a technical contributor)

I think that's an incomplete description of "AAA binding".

If you go back to my June(?) analysis, I started using that term
because SSH has certain security assumptions, RADIUS has certain
security assumptions, and SNMP has certain security assumptions, and
those assumptions differ and conflict. 

The assumptions ended up being met by following the elements of
procedure in the correct order. Off the top of my head, I don't
remember the specifics. It's in my June(?) email. As I recall,
processing SSH and RADIUS concepts as per the EOP led to a "binding"
that satisfied the SSH security assumptions and the RADIUS security
assumptions, and then additional processing took the result of that
binding and bound it to SNMP elements (modularity and the ASI
parameters I think) that ended up meeting SNMP security assumptions. I
think it is important to explain how the current document's EOP allows
these conflicting assumptions to be satisfied while still maintaining
RFC3411 modularity.

The term "AAA binding" refers to this binding of concepts in a
specific manner to provide the correct security properties. 

Randy, do you have the email where I used that term? Can you post it
or point to it? I can't locate it.

dbh

> Sent: Tuesday, August 24, 2010 8:14 AM

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 24 Aug 2010 11:11:01 -0400

Hi,

The text in the document actually provides details about what gets
bound in the "AAA binding":
   An implementation-specific identifier is needed for each AAA-
   authorized "session", corresponding to a communication channel,
such
   as a transport session, for which a principal has been AAA-
   authenticated and which is authorized to offer SNMP service.  When
a
   RADIUS-Management-Policy-ID Attribute (or equivalent) is bound to
   such a session and principal authentication, this binding provides
   sufficient information to compute dynamic updates to VACM.  How
this
   information is communicated within an implementation is
   implementation-dependent; this memo is only concerned with
   externally-observable behaviour.

A "AAA binding" binds
	1) a communications channel
	2) an authenticated principal
	3) service authorization
	4) an access control policy name

some of the binding is actually done via other standards.
A transport model, such as sshtm, provides a binding between 1) and 2)
and 3) - a securityName et al
AAA provides a binding between (1+2+3) and 4) - MGMT-Policy-ID
This document extends that further, to create a binding between
(1+2+3+4) and the local (VACM MIB) definition of the named policy
(group)

-
The binding between 1+2 satisfies assumptions of SSH or TLS
The SSHTM binding between 1+2+3 satisfies assumptions of SSH
subsystems (I'm not sure how TLSTM does this)
These 1+2+3 bindings also satisfy AAA assumptions about the channel,
the principal and the service authorization being bound together.
By keeping these inside a transport model, the 1+2+3 bindings also
meet SNMP modularity and secruity assumptions.
MGMT-Policy-ID satisfies the AAA assumption that authorization and
authentication are bound together, since the MGMT-Policy-ID is
AAA-bound to (1+2+3). This is the complete "AAA binding" (1+2+3+4)
(channel+authn+service+authz).
By doing it in "implementation-dependent in-the-background" manner, we
cheated to meet SNMP modularity assumptions, but this way allows for
other models to be developed that won't be forced to implement a
one-size-fits-all mechanism for this, and we didn't have to redesign
the ASIs, so we met the objectives of SNMP modularity.

dbh

> Behalf Of David Harrington
> Sent: Tuesday, August 24, 2010 10:34 AM
> To: 'Dave Nelson'; 'Randy Presuhn'; 'Glenn M. Keeni'; 
> [email-masked]; 'Glenn Mansfield Keeni'
> Cc: [email-masked]
> Subject: Re: [Isms] MIB 
> DoctorReview:draft-ietf-isms-radius-vacm-09.txtPart-I
> 
> Hi,
> 
> If you go back to my June(?) analysis, I started using that 
> term because SSH has certain security assumptions, RADIUS has 
> certain security assumptions, and SNMP has certain security 
> assumptions, and those assumptions differ and conflict. 
> 
> The assumptions ended up being met by following the elements 
> of procedure in the correct order. Off the top of my head, I 
> don't remember the specifics. It's in my June(?) email. As I 
> recall, processing SSH and RADIUS concepts as per the EOP led 
> to a "binding"
> that satisfied the SSH security assumptions and the RADIUS 
> security assumptions, and then additional processing took the 
> result of that binding and bound it to SNMP elements 
> (modularity and the ASI parameters I think) that ended up 
> meeting SNMP security assumptions. I think it is important to 
> explain how the current document's EOP allows these 
> conflicting assumptions to be satisfied while still maintaining
> RFC3411 modularity.
> 
> The term "AAA binding" refers to this binding of concepts in 
> a specific manner to provide the correct security properties. 
> 
> Randy, do you have the email where I used that term? Can you 
> post it or point to it? I can't locate it.
> 
> dbh
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Dave Nelson
> > To: 'Randy Presuhn'; 'Glenn M. Keeni'; [email-masked]; 
> 'Glenn Mansfield 
> > Keeni'
> > Cc: [email-masked]
> > SecurityName that has been authenticated by RADIUS as a RADIUS 
> > User-Name Attribute".  It seems we can either have accuracy or 
> > conciseness, but not both.  I don't think that coming up with a 
> > short-form notational device, for use within the scope of a single

> > document is such a bad idea.  On the other hand, simply 
> deleting text 
> > is worse, if we actually lose the fully nuanced meaning of 
> the concept 
> > being referenced.
> > 
> >

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 24 Aug 2010 11:40:46 -0400

> 	4) an access control policy name

+1

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 24 Aug 2010 11:57:17 -0400

> I think that's an incomplete description of "AAA binding".

Agreed.  I like the description in your follow up message.  My primary point was that we should not attempt to remove this term, but rather make sure it's properly defined in the front-matter of the document.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 24 Aug 2010 10:33:36 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Dave Nelson'" <[email-masked]>; "'Randy Presuhn'" <[email-masked]>; "'Glenn M. Keeni'"
<[email-masked]>; <[email-masked]>; "'Glenn Mansfield Keeni'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, August 24, 2010 7:34 AM
> Subject: RE: [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I
...
> or point to it? I can't locate it.

June 8.  Link:
http://www.ietf.org/mail-archive/web/isms/current/msg04321.html

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Aug 2010 23:18:03 +0200

> or point to it? I can't locate it.

I am still trying to understand what is unclear that an implementor
won't do the right thing...

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Aug 2010 23:24:23 +0200

[...]

I am wondering whether we are preparing for a beauty contest here or
whether there is really something so fundamentally unclear that people
can't implement things correctly. Some of the suggested changes IMHO
make the document more difficult to read; while trying to improve
purity of the terminology, we loose clarity of the sentences.

/js (speaking as contributor)

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 25 Aug 2010 11:08:15 +0900

Hi,
OK.
> I propose that no changes be made to this document here.
There is no issue here. It is mentioned above - "this is not a
problem.".
OK.
> paragraph beginning "SNMP versions".
Correct.
> a reference, and NOT adding a REFERENCE.
If the WG agrees with that change - this is acceptable.
> Where would we need to reference such a reference?  Text please.
The right place would be in the Introduction section where
Authorization, and Accounting (AAA) service is mentioned
for the first time.
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].
> Will any of these changes cause idnits to freak out?
No idea.
>> |         -- RFC Ed.: replace XXX with IANA-assigned number&  remove
>> this note
> 
That will make it comply with RFC 4181 section 4.5.
> consistency request, with much lower risk of screwing something up in
No disagreement, if WG agrees with that change - this is acceptable.
> within the DESCRIPTION of vacmAaaSecurityToGroupEntry.
Yes.
I will also go on to add that since the intent given RFC 4181 sec 4.6.2 says
  4.6.2.  DESCRIPTION and REFERENCE Clauses

     It is hard to overemphasize the importance of an accurate and
     unambiguous DESCRIPTION clause for all objects and TCs.  The
     DESCRIPTION clause contains the instructions that implementors will
     use to implement an object, and if they are inadequate or ambiguous,
     then implementation quality will suffer.  Probably the single most
     important job of a MIB reviewer is to ensure that DESCRIPTION clauses
     are sufficiently clear and unambiguous to allow interoperable
     implementations to be created.

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.

> As a counter-proposal, I suggest eliminating "AAA binding" from the two
No disagreement.
> (appearing only once) and "Security Name" (appearing only twice).
For consistency - this needs to be done throughout the document, I am
afraid.
> since the relevant semantics come with the textual convention itself.
The REFERENCE is needed to nail down the term "Security Model" used in
the DESCRIPTION.
> I think it might be simpler to just delete "the AAA binding represented by".
I do not disagree.
> that would be my first choice for a replacement.    "SNMP Security Name"
Sounds reasonable.
> from others before I go ahead as editor and make this and similar changes.
Lets hear. I will respect your opinion that it is not "terribly
helpful". Some may find it useful. I would like to hear the REFERENCE
is a problem- noisy or whatever.

> any need to reference RFC 5590.
No disagreement.
> When?
Done.
Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 25 Aug 2010 11:52:27 +0900

> purity of the terminology, we loose clarity of the sentences.
The present activity is part of the process to bring the quality of the
document to the level of an IETF Standard.
Compliance to processes and guidelines (e.g. RFC 4181) and, unambiguous
and consistent terminology is a requirement.
I agree that there maybe exceptional cases. We have the flexibility
to handle exceptions. Lets discuss the specific issues.
Glenn

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 24 Aug 2010 20:48:32 -0700

Hi -

> Sent: Tuesday, August 24, 2010 7:29 AM
> Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II
>
> Hi,
> 

Ok, I will add a list of tautologies in a new "Terminology" section.
However, as a technical contributor, I think the tendency to elevate
each English word or phrase to the status of "term" is most
unfortunate, and seriously detracts from the clarity of the document.

>     document but sporadically.]

I will add these to the tautology list

>     with appropriate pointers [RFC 3415].

Ok.

> |   policies", change infrequently,

Ok.

>     [Note: Security Model needs to have a pointer/definition early in the

I's like to hear others' opinions on this one.
As a technical contributor, I think the proposed change of "integer" to
"identifier" is misleading and potentially confusing.

I will add "security model" to the list of tautologies.

> |  Request message (or equivalent) corresponds to an SNMP securityName

I'll accomodate this by adding "security name" to the list of tautologies.

>     [Note: Security Model needs to have a pointer/definition early in the

I think dragging in vacmSecurityModel in this way confuses rather than enlightens.
Instead, the TC would make sense here, providing the syntax of the formal parameter.

> |     the index, vacmSecurityName, into the vacmSecurityToGroupTable;

Ok, though I think this is not helpful.

> |  the session establishment indication is undertaken.

As a technical contributor:
The distinction here is between information from sources external
to the implementation, and implementation-internal sources.  Pointing
out bad stuff that might come from an external source is  probably helpful
to an implementor.  Identifying things that might happen if an implementation
is *itself* broken seems like an endless and counter-productive path.

As Editor: no action taken, pending comments from others.

> |     the security model in use

Ok.

>       time. Please provide a pointer/reference.

Ok.

> |     among all currently open sessions of all of this SNMP engine's

Ok.

> |  with the RADIUS Management-Policy-Id Attribute or equivalent.

Ok.

> |  anything other than "active",

Ok, though as a technical contributor I think this change makes the document much
harder to read / understand.

>    to section 7.2.3 after the 1st paragraph.

No.  The paragraph belongs here - it spells out conditions under which
an entry MUST NOT be created.

> |  vacmSecurityToGroupStorageType of "volatile". If the value being

Ok, though I think this is a huge step backwards in terms of readability.

>    s/StorageType/vacmSecurityToGroupStorageType/g;

Ok, though I think this is a huge step backwards in terms of readability.

>    XXX2 and the View-Based Access Control Model document RFC XXX3."

I'll take the latter option.  The document is already far too long as it is,
considering how little it actually does.
 
> |  created these non-volatile entries.

Ok

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 25 Aug 2010 01:41:44 -0400

Hi,

<as technical contributor> 

I welcome Glenn to the MIB Doctors directorate. **welcome, glenn!!**

I think he may have gone overboard on some points, as is common with
new reviewers.
I am concerned that the wordsmithing of this document has been very
difficult, and a reviewer that has not been involved in the
wordsmithing negotiations to this point will not understand some of
the implications involved in changing the wordings.

As the editor of many of the architectural documents in the RFC34xx
and ISMS series, I think that moving from securityModel to Security
Model is not helpful in most cases.
I don't think that moving from securityName to Security Name is
helpful in most cases.

We use securityModel and securityName in the RFC3411 and ISMS
architectural interfaces between models (in the ASIs), so the data
flow is well defined.
If the document is discussing a parameter value being passed between
subsystems of models, then the ASI parameter name is most appropriate
(e.g., securityName).
If the document is discussing a generic model of a particular
subsystem, such as "each security model" that fits into the security
subsystem, then "security model" (not capitalized) is most
appropriate. (In early documents, we capitalized these, but moved away
from that in later docs on advice from the RFC editor.)
We use capitalized Security Model when referring to a specific
security model, such as the Transport Security Model (TSM) or the User
Security Model (USM).

I am fairly sensitive to these conventions, and while I have not done
a new review to check for this usage, this was not something I noticed
as a problem when I did my previous thorough reviews for compliance to
the modularity conventions.

and as juergen points out, this might have little impact on
implementers being able to interpret the text.

> I will add these to the tautology list

"authenticated user" is only used three times, and each time I think
the purpose is clear.
I don't think this needs to be put into a tautology section. Trying to
come up with a clear and unambiguous definition of this would likely
be difficult given that we are mapping multiple security protocols
together that have slightly different concepts for user and for
authentication; and not running into SNMP modularity issues when
defining such a term would likely be difficult.

I only found "AAA-authenticated" once in the text, and its usage was
very specific and appropriate.

My search didn't find any use of "AAA-authorized" or "AAA authorized"
in the document, which I consider very appropriate since there are two
unrelated levels of AAA-authorization - the service authorization and
the management-policy-id authorization - and referring to something as
AAA-authorized would likely be confusing.

> > |   which are reflected in VACM as groups and rules, change 
> > | infrequently,
> > |   which are reflected in VACM as groups and rules, change 
> > | infrequently,
> > NEW:

I think the assignments of users to groups (or management policies)
may change frequently, as the result of adds/drops/changes of an
employee role; that's why centralized mappings for this relation via
AAA is important.

However, I think the access control policy (the MIB configuration)
associated with a specific group is not likely to change frequently.
Which wildcarded MIB info an administrator is allowed to access as
compared to helpdesk personnel or as compared to a general user is not
likely to change often.

So I think the OLD text is more accurate (although I personally would
have preferred roles "are reflected in VACM groups" without the "and
rules"). 

I'm satisfied with the OLD text.

> 
>  
> > 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
> > 
> As a technical contributor, I think the proposed change of 
> "integer" to "identifier" is misleading and potentially confusing.

I prefer integer.
I prefer "each security model" to "the Security Model"

> Instead, the TC would make sense here, providing the syntax 

agreed.

> Ok, though I think this is not helpful.
I agree this is not helpful.

> > | 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.
> 
> The distinction here is between information from sources 
> external to the implementation, and implementation-internal 
> sources.  Pointing out bad stuff that might come from an 
> external source is  probably helpful to an implementor.  
> Identifying things that might happen if an implementation is 
> *itself* broken seems like an endless and counter-productive path.
> 

agreed.

> > |     the security model in use

unnecessary, and I am not sure it is as accurate as the original
statement.

> > | vacmSecurityToGroupTable, and the row's StorageType is anything 
> > | other  than "volatile", or the RowStatus is anything other than 
> > | "active",
> > NEW:
> > | vacmSecurityToGroupTable, and the row's 
> > | vacmSecurityToGroupStorageType  is anything other than 
> "volatile", 
> > | or the vacmSecurityToGroupStatus is  anything other than
"active",
> 
> Ok, though as a technical contributor I think this change 
> makes the document much harder to read / understand.

I agree. I think it is widely understood that StoargeType and RwStatus
refer to the row they are in, so it is not necessary to spell out the
row's fuill object name.

> No.  The paragraph belongs here - it spells out conditions 
> under which an entry MUST NOT be created.

agreed. 
this will likely go through iesg review easier if you changed the
"will not" to "MUST NOT" be overridden.

> StorageType is  

> > | entry created by a security administrator would not normally be 
> > | given  a StorageType of "volatile".  If value being provided by 
> > | RADIUS (or
> > NEW:

> Ok, though I think this is a huge step backwards in terms of 

agreed. I recommend not making this change.

> Ok, though I think this is a huge step backwards in terms of 

agreed. I recommend not making this chnage.

> I'll take the latter option.  The document is already far too 
> long as it is, considering how little it actually does.

As a person who needs to review lots of documents, I understand the
reviewer's desire to have a succinct intro to make things easier to
understand, but implementers will need to understand the RADIUS and
VACM specs, so I think it appropriate to say "the reader is expected
to have read ..."

> > | created these non-volatile entries.

how about "mistakenly created these entries as non-volatile."?
that is the error under consideration here, right?
but it is a nit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Aug 2010 08:17:39 +0200

> unfortunate, and seriously detracts from the clarity of the document.

As a technical contributor, I do not support this change.

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 25 Aug 2010 02:35:38 -0400

as technical contributor, I have not seen solid enough reasons to add
such a section at this late point in the process. If it were really
needed, I think we would have added it long ago.

dbh

> [mailto:[email-masked]] On Behalf Of Juergen
Schoenwaelder
> Sent: Wednesday, August 25, 2010 2:18 AM
> To: Randy Presuhn
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [IETFMIBS] [Isms] MIB Doctor Review: 
> draft-ietf-isms-radius-vacm-09.txt Part-II
>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 25 Aug 2010 21:31:22 +0900

Hi,
> I welcome Glenn to the MIB Doctors directorate. **welcome, glenn!!**
Honored. Thanks.
> I think he may have gone overboard on some points, as is common with
No comments :-)
> the implications involved in changing the wordings.
I admit I was not involved in the WG discussions. I have pored over the
WG-mailing list archives, all of them related to this document to try
to understand the arguments and lines of thought.
> the modularity conventions.
I am sensitive too :-) And that is the issue. The above conventions are
not followed in the document. The usage is inconsistent.
It has
|   DESCRIPTION "The Security Name of the principal associated with the
|                AAA binding represented by this entry.  In RADIUS
which contravenes what you have said above. I will be happy with the
usage of securityName. But I will find  SecurityName unacceptable as in
|   o  provide an indication of the start of a session for a particular
|      authenticated principal, identified using a SecurityName, and
This does not come under any of the allowed usage categories mentioned
above.
> AAA-authorized would likely be confusing.

There is at least one  "AAA authentication and authorization" and
several "AAA authorization" in the document. (Page 6 sec 7.1,
Page 7 sec 7.2, Page 8 sec 7.3).
Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 25 Aug 2010 22:05:14 +0900

Hi,
> an entry MUST NOT be created.
That is interesting. If this 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.
spells out conditions under which an entry MUST NOT be created.

Then you are implying that if the above condition is not met i.e.
   If a corresponding entry already exists in the
   vacmSecurityToGroupTable, and the row's StorageType is
   "volatile", or the RowStatus is "active",
an entry will be/may be/must be created? Am I missing something?

Glenn

On 2010/08/25 12:48, Randy Presuhn wrote:
> Hi -
> 
>> From: "Glenn M. Keeni"<[email-masked]>
>> To:<[email-masked]>; "Glenn Mansfield Keeni"<[email-masked]>
>> Cc:<[email-masked]>

---

From: "t.petch" <[email-masked]>
Date: Wed, 25 Aug 2010 18:15:37 +0200

Just picking up on two technical points ....

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'Randy Presuhn'" <[email-masked]>; "'Glenn M. Keeni'"
<[email-masked]>; <[email-masked]>; "'Glenn Mansfield Keeni'"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 25, 2010 7:41 AM

> I welcome Glenn to the MIB Doctors directorate. **welcome, glenn!!**

Yes, good to see another volunteer

> I am fairly sensitive to these conventions, and while I have not done

Yup, me too.  But this I-D does have securityName, SecurityName and Security
Name which I do not think that the usage justifies.  Rather securityName where
the RFC3415 concept is intended, and security name anywhere else.  I cannot
recall a TC for SecurityName so would say that that is an error

Tom Petch

> I prefer "each security model" to "the Security Model"

Since SnmpSecurityModel has a SYNTAX of INTEGER, I would see integer as right
and anything else as less than right.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Wed, 25 Aug 2010 18:19:18 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'Juergen Schoenwaelder'" <[email-masked]>; "'Randy
Presuhn'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, August 25, 2010 8:35 AM

> needed, I think we would have added it long ago.
Broadly I agree, but would probably have made an exception for securityModel and
securityName briefly referring to the relevant RFC - the definitions can be hard
to find amongst the RFC341x series in  a Definitions section; I would not
include anything else.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Wed, 25 Aug 2010 18:30:53 +0200

Uh huh,

I just got bounce messages for
[email-masked]
and
[email-masked]

Hopefully they will see messages via the list, or via someone's response to
mine:-)

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "David Harrington" <[email-masked]>; "'Randy Presuhn'"
<[email-masked]>; "'Glenn M. Keeni'" <[email-masked]>;
<[email-masked]>; "'Glenn Mansfield Keeni'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 25, 2010 6:15 PM
Subject: Re: [Isms] [IETFMIBS]
MIBDoctorReview:draft-ietf-isms-radius-vacm-09.txt Part-II

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 25 Aug 2010 11:21:33 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, August 25, 2010 6:05 AM
> Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II
>
> Hi,
> >
> >> m. Page 7. Sec 7.2.2

I see your point.  This paragraph is redundant tutorial material
and can safely be deleted. I'm now persuaded that we should just
delete the second paragraph in section 7.2.2, since it doesn't
add anything that doesn't follow from what is specified in the
following section.

Randy

---

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

Hi,
> unfortunate, and seriously detracts from the clarity of the document.
Please use the Conventions section. We can do without a new
"Terminology" section.

Thanks, Glenn

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 25 Aug 2010 21:56:52 -0700

Hi -

> Subject: [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I
...
...

I've verified that idnits rejects this sort of boilerplate change, flagging
it as an error.

Consequently, I will *NOT* add "NOT RECOMMENDED" to the list.

Randy

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 26 Aug 2010 19:04:28 +0900

> Consequently, I will *NOT* add "NOT RECOMMENDED" to the list.
OK. I will leave that as an issue to be handled by the RFC editor.
[Lets hope that someone is watching and will fix this conflict
 of requirements in the IETF documents process.]

Glenn

---

From: "t.petch" <[email-masked]>
Date: Thu, 26 Aug 2010 12:52:42 +0200

----- Original Message -----
From: "Glenn M. Keeni" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 26, 2010 12:04 PM

>  of requirements in the IETF documents process.]

The issue has been around for a long time and I had always taken it as gospel
that RFC2119 meant what it said ie NOT RECOMMENDED must not (MUST NOT?) be used
and I saw I-Ds edited to avoid using it.

Recently there was an exchange along the lines that this was all a mistake and
that NOT RECOMMENDED would be added retrospectively; uh huh, I think Randy has
got it right.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Thu, 26 Aug 2010 08:28:45 -0400

The IESG and RFC Editor are well aware.
Errata exist for this.

dbh

> Behalf Of Glenn M. Keeni
> Sent: Thursday, August 26, 2010 6:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] [IETFMIBS] MIB Doctor 
> To:<[email-masked]>; "Glenn 
> >> Mansfield Keeni"<[email-masked]> Cc:<[email-masked]>
> >> draft-ietf-isms-radius-vacm-09.txtPart-I
> > ...
> >> 9. Other Issues:
> > I've verified that idnits rejects this sort of boilerplate change,

> > flagging it as an error.
> [Lets hope that someone is watching and will fix this 
> conflict  of requirements in the IETF documents process.]
> 
> Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 26 Aug 2010 21:29:03 +0900

On 2010/08/26 20:58, Sean Turner wrote:
> Randy Presuhn wrote:
>> flagging
> I've done it on other IDs, but you have to have it in a specific order:
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
> "OPTIONAL" in this document are to be interpreted as described in 
> [RFC2119].
>
Excellent. Then we can close this issue.

Glenn

---

From: Sean Turner <[email-masked]>
Date: Thu, 26 Aug 2010 07:58:25 -0400

spt

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 29 Aug 2010 09:01:59 -0700 (PDT)

>>>>> On Thu, 26 Aug 2010, Tom Petch wrote:
tp> ----- Original Message -----
tp> From: "Glenn M. Keeni" <[email-masked]>
tp> To: <[email-masked]>
tp> Cc: <[email-masked]>
tp> Sent: Thursday, August 26, 2010 12:04 PM
tp> 
tp> > On 2010/08/26 13:56, Randy Presuhn wrote:
tp> > >> From: "Glenn M. Keeni"<[email-masked]>
tp> > >> To:<[email-masked]>; "Glenn Mansfield Keeni"<[email-masked]>
tp> > >> Cc:<[email-masked]>
tp> > >> Sent: Monday, August 23, 2010 6:28 AM
tp> > > ...
tp> > >> 9. Other Issues:
tp> > >>    a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to
tp> > >>       the list of imperatives (although the standard boilerplate in
tp> > >>       RFC 2119 does not include it, it is used in the Security
tp> > >>       Considerations section and it is defined in RFC 2119).
tp> > > ...
tp> > > I've verified that idnits rejects this sort of boilerplate change, flagging
tp> > > it as an error.
tp> > >
tp> > > Consequently, I will *NOT* add "NOT RECOMMENDED" to the list.
tp> > OK. I will leave that as an issue to be handled by the RFC editor.
tp> > [Lets hope that someone is watching and will fix this conflict
tp> >  of requirements in the IETF documents process.]
tp> 
tp> The issue has been around for a long time and I had always taken it as gospel
tp> that RFC2119 meant what it said ie NOT RECOMMENDED must not (MUST NOT?) be used
tp> and I saw I-Ds edited to avoid using it.
tp> 
tp> Recently there was an exchange along the lines that this was all a mistake and
tp> that NOT RECOMMENDED would be added retrospectively; uh huh, I think Randy has
tp> got it right.

I'm not sure if this is the exchange Tom was thinking of, but I raised the point 
on the OPSAWG list in connection with the 4181bis draft:

http://www.ietf.org/mail-archive/web/opsawg/current/msg00950.html

In that message I pointed out that this term is sanctioned by RFC 2119:

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

and therefore _is_ one of the standard imperatives.  That being the case, it
obviously belongs in the list.

>>>>> On Thu, 26 Aug 2010, David Harrington wrote:
dbh> The IESG and RFC Editor are well aware.
dbh> Errata exist for this.

There is an erratum reported against RFC 2119 for this.  It is #499:

http://www.rfc-editor.org/errata_search.php?eid=499

Note that its status is reported.  It clearly needs to be verified.

>>>>> On Thu, 26 Aug 2010, Sean Turner wrote:
spt> I've done it on other IDs, but you have to have it in a specific order:
spt> 
spt> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
spt> "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
spt> document are to be interpreted as described in [RFC2119].

Apparently idnits has been fixed since Randy's run-in when editing 
4181bis, since this is exactly the order used in RFC 4181.  That is 
also the order shown in erratum #499.

>>>>> On Thu, 26 Aug 2010, Glenn M. Keeni wrote:
gmk> Excellent. Then we can close this issue.

Yes, after erratum #499 is verified and has its status listed as such.

Mike Heard

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 30 Aug 2010 18:07:05 +0900

Mike,
> Yes, after erratum #499 is verified and has its status listed

You are referring to the larger issue of inconsistent/
templates and requirements- is that correct? [The status is
still "reported". Probably unchanged since 2006-01-09.]
As far as this draft is concerned the issue of using "NOT
 RECOMMENDED" without a reference to RFC 2119 will be addressed
by adding "NOT RECOMMENDED" to the draft in the Conventions
section at the appropriate place. Have I missed something?

Glenn

On 2010/08/30 1:01, C. M. Heard wrote:
> tp>  From: "Glenn M. Keeni"<[email-masked]>
> tp>  To:<[email-masked]>
> tp>  Cc:<[email-masked]>

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 30 Aug 2010 08:21:43 -0700 (PDT)

Correct.

> section at the appropriate place.

I agree with that resolution.

> Have I missed something?

No, not at all.  All I wanted to do was to help prevent this issue 
from coming up again, since it's plagued us before.

//cmh

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Tue, 31 Aug 2010 10:21:21 +0900

> from coming up again, since it's plagued us before.
Thanks.

Glenn