<div dir="ltr">Hi,<br><div class="gmail_quote"><div dir="ltr"><div><br></div><div>We have requested publication of <span style="border-collapse:collapse;white-space:pre">draft-ietf-trill-prob-05.txt</span> as an Informational RFC. The PROTO statement is below.<br>
<div class="gmail_quote"><div dir="ltr">
<div><br></div><div>Thanks,</div><div>Donald and Erik<br>=============================<br> Donald E. Eastlake 3rd<br> 155 Beaver Street<br> Milford, MA 01757 USA<br> <a href="mailto:d3e3e3@gmail.com" target="_blank">d3e3e3@gmail.com</a><br>
</div><div><br></div><div><br></div><div><div>(1.a) Who is the Document Shepherd for this document? Has the</div><div> Document Shepherd personally reviewed this version of the</div><div> document and, in particular, does he or she believe this version</div>
<div> is ready for forwarding to the IESG for publication?</div><div><br></div><div> Donald E. Eastlake 3rd <<a href="mailto:d3e3e3@gmail.com" target="_blank">d3e3e3@gmail.com</a>></div><div><br></div><div>
Yes</div><div>
<br></div><div>(1.b) Has the document had adequate review both from key WG members </div><div> and from key non-WG members? Does the Document Shepherd have </div><div> any concerns about the depth or breadth of the reviews that </div>
<div> have been performed? </div><div><br></div><div> The document has had adequate review. In its early days, when it</div><div> was incomplete and it appear to be difficult to get comments, a</div><div> first WGLC was done which succeeded in eliciting comments. A</div>
<div> complete revised document was WGLCed here</div><div> <a href="http://www.postel.org/pipermail/rbridge/2008-July/003059.html" target="_blank">http://www.postel.org/pipermail/rbridge/2008-July/003059.html</a></div>
<div> producing comments the resolutions of which are here</div><div> <a href="http://www.postel.org/pipermail/rbridge/2008-August/003083.html" target="_blank">http://www.postel.org/pipermail/rbridge/2008-August/003083.html</a></div>
<div> resulting is a revised draft notice of posting of which is here</div><div> <a href="http://www.postel.org/pipermail/rbridge/2008-September/003110.html" target="_blank">http://www.postel.org/pipermail/rbridge/2008-September/003110.html</a></div>
<div><br></div><div>(1.c) Does the Document Shepherd have concerns that the document </div><div> needs more review from a particular or broader perspective, </div><div> e.g., security, operational complexity, someone familiar with </div>
<div> AAA, internationalization or XML?</div><div><br></div><div> No.</div><div><br></div><div>(1.d) Does the Document Shepherd have any specific concerns or issues</div><div> with this document that the Responsible Area Director and/or the</div>
<div> IESG should be aware of? For example, perhaps he or she is</div><div> uncomfortable with certain parts of the document, or has</div><div> concerns whether there really is a need for it. In any event, if</div>
<div> the WG has discussed those issues and has indicated that it</div><div> still wishes to advance the document, detail those concerns</div><div> here. Has an IPR disclosure related to this document been filed?</div>
<div> If so, please include a reference to the disclosure and</div><div> summarize the WG discussion and conclusion on this issue.</div><div><br></div><div> No specific concerns.</div><div><br></div><div> No IPR disclosure specific to this document has been filed but see</div>
<div> <a href="http://www.ietf.org/ietf/IPR/sun-ipr-draft-perlman-rbridge.txt" target="_blank">http://www.ietf.org/ietf/IPR/sun-ipr-draft-perlman-rbridge.txt</a></div><div> for the Sun Microsystems RBridge disclosure.</div>
<div><br>
</div><div>(1.e) How solid is the WG consensus behind this document? Does it</div><div> represent the strong concurrence of a few individuals, with</div><div> others being silent, or does the WG as a whole understand and</div>
<div> agree with it?</div><div><br></div><div> This document represents the opinion of the working group as</div><div> discerned by the co-chairs. There has been discussion of how</div><div> the document should "describe" IEEE 802 spanning tree protocol</div>
<div> but that does not affect the techncial content of this document.</div><div> In this the document represents something reasonably close to</div><div> the center of working group opinion.</div><div><br></div>
<div>(1.f) Has anyone threatened an appeal or otherwise indicated extreme</div><div> discontent? If so, please summarise the areas of conflict in</div>
<div> separate email messages to the Responsible Area Director. (It</div><div> should be in a separate email because this questionnaire is</div><div> entered into the ID Tracker.)</div><div><br></div><div>
No. </div><div><br></div><div>(1.g) Has the Document Shepherd personally verified that the document</div><div> satisfies all ID nits? (See</div><div> <a href="http://www.ietf.org/ID-Checklist.html" target="_blank">http://www.ietf.org/ID-Checklist.html</a> and</div>
<div> <a href="http://tools.ietf.org/tools/idnits/" target="_blank">http://tools.ietf.org/tools/idnits/</a>). Boilerplate checks are not</div><div> enough; this check needs to be thorough. Has the document met</div>
<div> all formal review criteria it needs to, such as the MIB Doctor,</div>
<div> media type and URI type reviews?</div><div><br></div><div> Yes.</div><div><br></div><div>(1.h) Has the document split its references into normative and</div><div> informative? Are there normative references to documents that</div>
<div> are not ready for advancement or are otherwise in an unclear</div><div> state? If such normative references exist, what is the strategy</div><div> for their completion? Are there normative references that are</div>
<div> downward references, as described in [RFC3967]? If so, list</div><div> these downward references to support the Area Director in the</div><div> Last Call procedure for them [RFC3967].</div><div><br></div>
<div> References are split but there are no normative references.</div><div><br></div><div>(1.i) Has the Document Shepherd verified that the document IANA</div><div> consideration section exists and is consistent with the body of</div>
<div> the document? If the document specifies protocol extensions, are</div><div> reservations requested in appropriate IANA registries? Are the</div><div> IANA registries clearly identified? If the document creates a</div>
<div> new registry, does it define the proposed initial contents of</div><div> the registry and an allocation procedure for future</div><div> registrations? Does it suggest a reasonable name for the new</div>
<div> registry? See [RFC5226]. If the document describes an Expert</div><div> Review process has Shepherd conferred with the Responsible Area</div><div> Director so that the IESG can appoint the needed Expert during</div>
<div> the IESG Evaluation?</div><div><br></div><div> None of the above is applicable to this document. That IANA</div><div> section correctly states that no IANA actions are required and</div><div> that the section should be removed on publication.</div>
<div><br></div><div>(1.j) Has the Document Shepherd verified that sections of the document</div><div> that are written in a formal language, such as XML code, BNF</div><div> rules, MIB definitions, etc., validate correctly in an automated</div>
<div> checker?</div><div><br></div><div> There are no such sections in this document.</div><div><br></div><div>(1.k) The IESG approval announcement includes a Document Announcement</div><div> Write-Up. Please provide such a Document Announcement</div>
<div> Write-Up? Recent examples can be found in the "Action"</div><div> announcements for approved documents. The approval</div><div> announcement contains the following sections:</div>
<div><br></div><div><br></div><div> Technical Summary </div><div><br></div><div> This document discusses the avoidance of some problems in</div><div> Layer 2 forwarding with the spanning tree protocol</div>
<div> through the use of link state routing techniques,</div><div> possibly with a hop count limit. Desired properties and</div><div> the applicability of such improved forwarding are also</div>
<div> given.</div><div><br></div><div> Working Group Summary </div><div> </div><div><span style="white-space:pre"> </span> This document was Working Group Last Called twice. There</div>
<div><span style="white-space:pre"> </span> were informal complaints that the first WGLC was improper</div><div><span style="white-space:pre"> </span> because the document was not complete at that time.</div>
<div> </div><div> Document Quality </div><div><br></div><div> This is an informational document intended to describe</div><div> the problem to which the TRILL working group is addressed</div>
<div>
and the applicability of solutions. Document quality is</div><div> good.</div><div><br></div></div></div></div></div></div></div><br>
</div>