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

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Mar 2009 14:09:08 +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-tmsm-16.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. Some references 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
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 establishes a registry for SNMP transport domains. The
IANA section defines the initial content, an allocation procedure, and
it suggests a reasonable name. An Expert Review process is not
defined.

(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 defines a Transport Subsystem, extending the
        Simple Network Management Protocol (SNMP) architecture defined
        in RFC 3411. The subsystem can contain Transport Models
        comparable to other subsystems in the RFC 3411 architecture.
        The Transport Subsystem can be used to expand the transports
        to include secure transports such as SSH or TLS.

      Working Group Summary

        The working group went over several revisions of this document
	while developing a Transport Model for SSH. The document did
	stabilize several revisions ago and has mainly been kept back
	to track clarifications and to ensure the new subsystem works
	with the SSH transport defined in a companion document. There
	has been strong WG consensus on revision 16 of this document.

      Document Quality

        There are two known implementations in progress of secure
        transport models. A concrete SSH subsystem has been worked out
        by the ISMS working group and a DTLS subsystem is in progress
        as an individual draft and it seems the Transport Subsystem
        defined in this document is capable to supports both secure
        transports.

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