Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.txt

From: [email-masked]
Date: Wed, 2 Dec 2009 00:15:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF.

	Title           : Extensions to View-based Access Control Model for use with RADIUS
	Author(s)       : K. Narayan, et al.
	Filename        : draft-ietf-isms-radius-vacm-00.txt
	Pages           : 18
	Date            : 2009-12-01

This memo describes a backward-compatible extension to the View-based
Access Control Model for SNMPv3 for use with RADIUS and other AAA
services to provide authorization of MIB database access.  This
extension is intended to be used in conjunction with secure SNMP
Transport Models that facilitate RADIUS authentication, such as the
Secure Shell Transport Model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Dec 2009 08:42:45 -0500

Hi,

I took a quick look at the document.

Most of my comments are editorial and could have been done by David
and Kaushik had I pointed these out earlier. I apologize for not
providing this guidance earlier.

Open Issue #7: Generally make the document look like an SNMP document.

The MIB Doctors have described certain sections they like to have in a
MIB module in keeping with RFC4181.
The templates at
http://tools.ietf.org/tools/templates/mib-doc-template-xml.txt
(annotated xml2rfc template) and
http://tools.ietf.org/tools/templates/mib-doc-template-advice.txt
(annotated plain text) describe this recommended layout:

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
4
   2.  The Internet-Standard Management Framework . . . . . . . . . .
4
   3.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .
4
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
   5.  Structure of the MIB Module  . . . . . . . . . . . . . . . . .
5
     5.1.  Textual Conventions  . . . . . . . . . . . . . . . . . . .
5
     5.2.  The [TEMPLATE TODO] Subtree  . . . . . . . . . . . . . . .
5
     5.3.  The Notifications Subtree  . . . . . . . . . . . . . . . .
5
     5.4.  The Table Structures . . . . . . . . . . . . . . . . . . .
5
   6.  Relationship to Other MIB Modules  . . . . . . . . . . . . . .
5
     6.1.  Relationship to the [TEMPLATE TODO] MIB  . . . . . . . . .
6
     6.2.  MIB modules required for IMPORTS . . . . . . . . . . . . .
6
   7.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .
6
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .
7
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .
8
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . .
9
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . .
9
     11.1. Normative References . . . . . . . . . . . . . . . . . . .
9
     11.2. Informative References . . . . . . . . . . . . . . . . . .
10
     11.3. URL References . . . . . . . . . . . . . . . . . . . . . .
10

Organizing the information in this manner makes it easier for expert
review since the discussion of topics that MIB Doctors typically check
for are clearly identified.

The current document does not provide sections 2,3,4,5,6, or 8.

Section 2 is boilerplate. The latest version can be cut and pasted
from ops.ietf.org.
Section 3 usually just contains the RFC2119 boilerplate, plus any new
terminology.

Section 1 and section 4 are usually used to deacribe the general
problem statement and a design overview of how the technology being
modeled in the MIB module works. The current sections 1-3 could be
split into a section 1 Introduction, and a section 4 Overview.

Portions of the current section 3 discuss some table-specific
handling. These discussions could be split out into a recommended
section 5 Structure of the MIB Module.

The first paragraph in section 5 could be moved and expanded to become
the recommended section 6.
Section 8 is boilerplate, also available from ops.ietf.org, to be
filled in with lists of sensitive objects.
Section 9 is mostly boilerplate, to be filled in with the requested
OID (once open issue #3 is decided)

I think this would help to make the current document look more like
other MIB module documents, and make it easier to determine if all the
"normal" requirements of MIB module documents have been addressed.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, December 02, 2009 3:15 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.txt
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 2 Dec 2009 08:35:41 -0800

Hi -

As an editor...
If there are no objections, I will make these changes.

Randy

> From: "David Harrington" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, December 02, 2009 5:42 AM
> Subject: Re: [Isms] I-D Action:draft-ietf-isms-radius-vacm-00.txt
>
> Hi,
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 2 Dec 2009 12:10:40 -0500

> If there are no objections, I will make these changes.

I think following the document organizational structure that Dave  
Harrington suggests may be useful.  After all, there are really only  
two major items of content, the EOP and the MIB module.  Having said  
that, this document is not *just* a MIB module definition.  As long as  
the other (important) elements can be located in logical and  
appropriately titled sections within this organizational template, and  
not be tucked away under a non-obvious section heading, I'm supportive  
of Dave's suggestion.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Dec 2009 16:31:09 -0500

Hi,

I also noticed the need to have sections that describe the underlying
functionality. 
There is some in-depth stuff about RADIUS and VACM in the current
document.
That can be done either as clearly marked subsections of the Overview,
or in a separate section.
The editors can make that call as far as I'm concerned.

The important point about the template was to make sure all the i's
were dotted and t's were crossed for a MIB module document, to make it
easy for subsequent review, not to constrain the section numbers to
match the template ;-)

dbh

> Behalf Of David B. Nelson
> Sent: Wednesday, December 02, 2009 12:11 PM
> To: Randy Presuhn
> Cc: [email-masked]