Subject: [rbridge] draft-ietf-trill-prob-05.txt Publication Request

From: "Donald Eastlake" <[email-masked]>
Date: Thu, 9 Oct 2008 00:04:49 -0400

Hi,

We have requested publication of draft-ietf-trill-prob-05.txt as an
Informational RFC. The PROTO statement is below.

Thanks,
Donald and Erik
=============================
Donald E. Eastlake 3rd
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

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

    Donald E. Eastlake 3rd <[email-masked]>

    Yes

(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 had adequate review. In its early days, when it
    was incomplete and it appear to be difficult to get comments, a
    first WGLC was done which succeeded in eliciting comments. A
    complete revised document was WGLCed here
    http://www.postel.org/pipermail/rbridge/2008-July/003059.html
    producing comments the resolutions of which are here
    http://www.postel.org/pipermail/rbridge/2008-August/003083.html
    resulting is a revised draft notice of posting of which is here
    http://www.postel.org/pipermail/rbridge/2008-September/003110.html

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

    No.

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

    No specific concerns.

    No IPR disclosure specific to this document has been filed but see
    http://www.ietf.org/ietf/IPR/sun-ipr-draft-perlman-rbridge.txt
    for the Sun Microsystems RBridge disclosure.

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

    This document represents the opinion of the working group as
    discerned by the co-chairs. There has been discussion of how
    the document should "describe" IEEE 802 spanning tree protocol
    but that does not affect the techncial content of this document.
    In this the document represents something reasonably close to
    the center of working group opinion.

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

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

    Yes.

(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 but there are no normative references.

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

    None of the above is applicable to this document. That IANA
    section correctly states that no IANA actions are required and
    that the section should be removed on publication.

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

  There are no such sections in this document.

(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 document discusses the avoidance of some problems in
             Layer 2 forwarding with the spanning tree protocol
             through the use of link state routing techniques,
             possibly with a hop count limit. Desired properties and
             the applicability of such improved forwarding are also
             given.

      Working Group Summary

     This document was Working Group Last Called twice. There
     were informal complaints that the first WGLC was improper
     because the document was not complete at that time.

      Document Quality

             This is an informational document intended to describe
             the problem to which the TRILL working group is addressed
              and the applicability of solutions. Document quality is
             good.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge