Subject: [Isms] Request to publish draft-ietf-isms-secshell-15.txt as Proposed Standard RFC

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Mar 2009 14:09:30 +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-secshell-15.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. The document, however, still needs a MIB doctor
review. Since the document is edited by MIB doctors, I do not expect
major problems here.

(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. The trust text in the MIB module
needs to be updated, pending the general resolution of this issue.

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

(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 contained in the document compiles cleanly with smilint
0.4.5.

(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 defines a Transport Model for the Simple Network
        Management Protocol (SNMP), using the Secure Shell protocol
        (SSH).  The document also defines a portion of the Management
        Information Base (MIB) for monitoring and managing the Secure
        Shell Transport Model for SNMP.

      Working Group Summary

        The document has mainly been updated recently to track
	clarifications and to improve the readability. There has been
	WG consensus on revision 15 of this document and there are no
	controversies on the technical solution.

      Document Quality

        There are two known implementations in progress of the Secure
        Shell Transport Model. There are no further vendor commitments
        at the moment to implement this specification.

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