Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings
draft-ietf-isms-radius-vacm-11

[Ballot comment]
Magnus Nystrom noted some confusion in the current section 7.2.  After reviewing the text, I think he has a point.

I would suggest deleting "or equivalent" from the second and fourth bullets and appending something along the
following lines at the end of the section:

As noted in section 4.2, the above text refers specifically to RADIUS attributes.  Other AAA services can be
substituted, but the requirements imposed on User-Name and Management-Policy-Id-Attribute MUST be
satisfied using the equivalent fields for that service.

[Ballot comment]
Thanks for this I-D. I have no objection to its publication as an RFC.

Section 4.1

I found the following sentence somewhat tricky.

  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.

The problem is around "implementation-specific" which implies that
there is a single identifier for all communication channels from any
Company-X Product-Y device. Not what you mean!

If you have time to tweak this a little, that would be good.

---

Section 4.2

Not sure that the two uses of "MAY" in this section really need to be
upper case, but it is not very important.

---

Section 5.1

Would be nice to give a reference for the TCs mentioned.

[Ballot comment]
Please consider the editorial comments in the Gen-ART Review from
  Francis Dupont.  The review can be found at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-isms-radius-vacm-09-dupont.txt

[Ballot discuss]
This is a very good document and I plan to enter a 'Yes' in the ballot, but there are a number of issues that were raised in the OPS-DIR review by Joel Jaeggli and in the MIB-Doctor review by Glenn Keeni which are under discussion with the authors. I am holding a DISCUSS until these issues are resolved.

[Ballot discuss]
This document is well written, a necessary specification that
should move forward.

However, before recommending the final approval of this document
I had a question about the scope of the document. The document
says:

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

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

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

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

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

IANA comments:

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

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

Document: draft-ietf-isms-radius-vacm-09.txt

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Juergen Schoenwaelder is the document shepherd. I have reviewed the
document several times including the latest version and I believe it
is ready for forwarding it to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has received WG last call reviews and comments from

- Dave Nelson
- David Harrington
- Juergen Schoenwaelder
- Andrew Donati
- Jeffrey Hutzelman

and I do not have any concerns regarding the level of review for this
document, given that the document is also a minor addition to SNMP.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

I do not think the document needs special reviews.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

I do not have any specific concerns.
No IPR disclosure been filed as far as we know.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The document has WG consensus and the WG wants the document to be
published as a Proposed Standard.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No-one has threatened with an appeal or expressed extreme discontent.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The document has been checked with idnits 2.12.00. The document
contains a MIB module and should go through the MIB doctor review
processs.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References are split in Normative and Informative. All normative
documents have been published.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The document requests a number of assignment in an existing registry.
It does not create any new registries. I believe the IANA instructions
are clear.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The MIB module has been checked using smilint for syntactic
correctness.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
    The document describes how to use Authentication,
Authorization, and Accounting (AAA) services, such as the
Remote Authentication Dial-In User Service (RADIUS), for
access control authorization within the Simple Network
Management Protocol (SNMP) framework. A MIB module is provided
to dynamically update user-to-group mappings in the View-Based
Access Control Model (VACM).

    Working Group Summary
        The working group went over several revisions of this document
and the document and all WG last call comments have been
resolved. There has been strong WG consensus to publish this
document as Proposed Standard.

    Document Quality
        The chair is not aware of any implementations at this point in
time. Dave Harrington has provided significant reviews that
helped with the clarity and modularity aspects of the SNMP
specifications.