Subject: [Emu] PROTO write-up for draft-ietf-emu-eaptunnel-req-08.txt

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Oct 2010 10:34:18 +0200

(1.a) Who is the Document Shepherd for this document?

  ==> Alan DeKok.

	 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?

  ==> Yes, and yes.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members?

  ==> Yes

   Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

  ==> No.

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

  ==> It may be useful to have a review from someone in the security
      community who has not been involved in the document development.

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

  ==> No.

   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?

  ==> No.

        If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.
  (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 consensus shows strong consensus from a number of individuals.
      The WG as a whole understands and agrees with the document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?

  ==> No one has threatened an appeal.

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

  ==> Yes.  The ID Nits are:

	1) uses RFC 2119 text without RFC 2119 template.  This is
	   intentional, and explained in the document

	2) Using non-RFC3330 compliant IP addresses.  This appears
	   to be a "false positive", as the document does not use
	   example IP addresses.

	There are no other reviews necessary.

  (1.h) Has the document split its references into normative and
        informative?

  ==> Yes.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?

  ==> Yes.  The document depends on draft-ietf-emu-chbind.

        If such normative references exist, what is the
        strategy for their completion?

  ==> The channel bindings document is expected to to be published
      before any tunnel method document.
      As a result, there appears to be no issue with publishing the
      tunnel requirements document now.

        Are there normative references
        that are downward references, as described in [RFC3967]?

  ==> No.

        If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

  ==> Yes.  There are no IANA considerations.

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

  ==> This is not applicable.

  (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
   This memo defines the requirements for a tunnel-based Extensible
   Authentication Protocol (EAP) Method.  This method will use Transport
   Layer Security (TLS) to establish a secure tunnel.  The tunnel will
   provide support for password authentication, EAP authentication and
   the transport of additional data for other purposes.

     Working Group Summary
   The document has had substantial review from a number of working
   group participants.  The working group is ready to start working on
   protocols.

     Document Quality
   The document is a requirements document that has had contributions
   from Working group participants from different vendors.  Discussion
   in the Working group has resulted in improvements to the document.