Subject: [Isms] Request to publish draft-ietf-isms-radius-usage-05.txt as Proposed Standard RFC

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Mar 2009 14:09:48 +0100

Pasi, please take this document to the next step. The WG has consensus
to request publication as a Proposed Standard RFC.

Document Shepherd Write-Up for <draft-ietf-isms-radius-usage-05.txt>.
Template used was dated September 17, 2008.

(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 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 gone through multiple WG last calls and has had over
time significant review by subject matter experts. I do not have any
concerns regarding the level of review for this document.

(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 believe any extra special review (other than normal IETF Last
Call) is needed.

(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 
      http://www.ietf.org/ID-Checklist.html 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 passes ID-nits 2.10.03. It contains one unused reference
(RFC3415) and some have been updated since the ID was posted, which
can be resolved easily during the IETF last call process. There are no
formal reviews needed for this document.

(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
references have been published, are currently processed by the IESG,
or are submitted together with this document to the IESG.

(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 IANA section exists and seems to be complete. There are
essentially just RFC editor instructions since this document depends
on allocations of a document processed by the IESG.

(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 document does not contain any formal notations that can be checked
for 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 the use of a Remote Authentication
        Dial-In User Service (RADIUS) authentication and authorization
        service with Simple Network Management Protocol (SNMP) secure
        Transport Models to authenticate users and authorize creation
        of secure transport sessions.

      Working Group Summary

        The document has been stable for several revisions. Most
	updates reflected changes in the companion document produced
	by the Radius Extensions working group and clarifications to
	adapt the SNMP terminology. There has been WG consensus on
	revision 05 of this document.

      Document Quality

        There are no known implementations in progress nor are there
        any known vendor commitments at the moment to implement this
        specification. Note that this document defines how Radius
        attributes are to be used in the context of secure SNMP
        Transport Models and bridges between two worlds. The WG last
        call has been posted to the Radius Extensions working group
        and Radius experts have been involved as document editors.

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