Proto E. Juskevicius Internet Draft TrekAhead Intended status: Informational March 2, 2010 Expires: September 2, 2010 Definition of Working Group Document States draft-ietf-proto-wgdocument-states-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Juskevicius Expires September 2, 2010 [Page 1] Internet-Draft Working Group Document States March 2010 Abstract This document contains definitions for the different states that documents (viz. Internet-Drafts) may experience while associated with an IETF working group. The first state occurs when an Internet Draft (I-D) is submitted for consideration as a working group item. The last state is either when the I-D is sent to the IESG for publication, or declared as "dead". The purpose of this Internet-Draft is to serve as a basis for the definition of requirements to extend the IETF Datatracker tool so that the community may monitor the status and progression of I-Ds through IETF working groups. For completeness, Appendix A has definitions for all of the I-D states which are already coded into the Datatracker. These states describe the progression and status of I-Ds after they have been submitted to the IESG for publication. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................4 3. Definitions of Possible WG Document States.....................4 3.1. WG Document States........................................4 3.1.1. Candidate WG Document................................5 3.1.2. Active WG Document...................................5 3.1.3. Not a WG Document....................................5 3.1.4. Parked WG Document...................................5 3.1.5. In WG Last Call......................................5 3.1.6. WG Last Call Completed...............................5 3.1.7. Waiting for WG Document Shepherd Write-Up............6 3.1.8. Submitted to IESG for Publication....................6 3.1.9. Dead WG Document.....................................6 3.2. Straw Man WG Document State Diagram.......................6 3.3. WG Document Substates.....................................6 3.3.1. Awaiting Cross-Area Review...........................8 3.3.2. Awaiting MIB Doctor Review...........................8 3.3.3. Awaiting Security Review.............................8 3.3.4. Awaiting Other Review................................8 3.3.5. Awaiting Merge with Other Document...................9 3.3.6. Author or Editor Needed..............................9 3.3.7. Held due to Dependency on other Document.............9 3.3.8. Held due to IESG concerns on this Document...........9 Juskevicius Expires September 2, 2010 [Page 2] Internet-Draft Working Group Document States March 2010 3.3.9. Revised I-D Needed - based on WG consensus..........10 3.3.10. Revised I-D Needed - based on WG last call.........10 3.3.11. Doc Shepherd Follow-up.............................10 3.3.12. Other - see Comment Log............................10 3.4. Intended Maturity Level of WG Documents..................11 4. Security Considerations.......................................11 5. IANA Considerations...........................................11 6. References....................................................11 6.1. Normative References.....................................11 6.2. Informative References...................................12 7. Acknowledgments...............................................12 Appendix A: "IESG Document" States...............................13 A.1. Definition of "IESG Document" States.....................13 A.1.1. I-D Exists..........................................13 A.1.2. Publication Requested...............................13 A.1.3. AD Evaluation.......................................13 A.1.4. Expert Review.......................................13 A.1.5. Last Call Requested.................................14 A.1.6. In Last Call........................................14 A.1.7. Waiting for Writeup.................................14 A.1.8. Waiting for AD Go-Ahead.............................14 A.1.9. IESG Evaluation.....................................14 A.1.10. IESG Evaluation - Defer............................15 A.1.11. Approved-announcement to be sent...................15 A.1.12. Approved-announcement sent.........................15 A.1.13. RFC Ed Queue.......................................15 A.1.14. RFC Published......................................15 A.1.15. DNP-waiting for AD note............................15 A.1.16. DNP-announcement to be sent........................15 A.1.17. AD is Watching.....................................15 A.1.18. Dead...............................................16 A.2. "IESG Document" Substates................................16 A.2.1. Point Raised - writeup needed.......................16 A.2.2. AD Followup.........................................16 A.2.3. External Party......................................17 A.2.4. Revised I-D Needed..................................17 Author's Address................................................ 17 1. Introduction The IETF Datatracker is a web-based system for managing information about Internet-Drafts (I-Ds), RFCs and several other important aspects of the IETF process [IDTRACKER]. A limitation of the Datatracker is that its database contains very little information about the status of Internet Drafts prior to the time they are Juskevicius Expires September 2, 2010 [Page 3] Internet-Draft Working Group Document States March 2010 submitted to the IESG for publication. Only one non-IESG state is currently defined and coded into the tool: "I-D Exists". Section 3 of this I-D proposes definitions for an additional set of document states, namely every state that a document written for consideration by an IETF Working Group (WG) may experience during its progression though a WG. The purpose of defining WG document states is to enable community discussion on them and consensus on a state diagram to illustrate the state transitions preferred by most WGs to progress I-Ds. A desired outcome of this initiative is to reach consensus on a set of requirements to extend the Datatracker so that WG Chairs and other members of the community could monitor the status of I-Ds as they progress through IETF working groups. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Definitions of Possible WG Document States The IETF Datatracker tool has minimal information about the status of I-Ds at the WG level today. Prior to someone asking that an I-SD be published, the only state tracked by the tool is "I-D Exists". The Datatracker has no other status information about any WG document. In order for the Datatracker to be record WG document state, new WG document states and substates need to be defined, agreed and then coded into the front-end of the tool. Section 3.1 defines the possible states that could apply to I-Ds that have been submitted to an IETF working group. Section 3.2 illustrates the relationships between the states in diagram form. Section 3.3 defines additional terms which may be useful to flag various WG document substates. Section 3.4 lists the all of the "intended maturity levels" which could be applied to a WG document. 3.1. WG Document States This subsection defines all of the different states that MAY apply to any I-D written as a contribution into an IETF working group. Juskevicius Expires September 2, 2010 [Page 4] Internet-Draft Working Group Document States March 2010 3.1.1. Candidate WG Document An I-D that is under consideration for becoming a working group document as a "Candidate WG Document". A document being in this state does not imply any consensus, and does not imply any precedence or selection. The purpose of this state is simply to indicate that someone has asked for an existing I-D to be considered for acceptance as a working group document. 3.1.2. Active WG Document An "Active WG Document" is an I-D that has been adopted by a working group, and is being actively developed. 3.1.3. Not a WG Document This document is not a WG Document. An I-D may be in this state for a variety of reasons. Some examples are: - the I-D was a "Candidate WG Document" but was rejected by the WG; or - the I-D is an IAB or IRTF document, an individual submission, or an independent submission not intended to become a WG document. 3.1.4. Parked WG Document A "Parked WG Document" is an I-D which has lost its author or editor, is waiting for another document to be written or for a review to be completed, or cannot currently be progressed by the working group for some other reason. 3.1.5. In WG Last Call A document "In WG Last Call" is an I-D for which a WG last call has been issued, and is in progress. 3.1.6. WG Last Call Completed After a WG last call is completed, any comments received SHOULD be evaluated before the I-D is progressed. During the evaluation period, the I-D is in a "WG Last Call Completed" state. After the evaluation, the document MAY return to being an "Active WG Document" again (i.e. to be refined or rewritten) or be "Parked" for a variety of reasons, or be progressed into "Waiting for Document Shepherd Write-Up". Juskevicius Expires September 2, 2010 [Page 5] Internet-Draft Working Group Document States March 2010 Many members of the community desire additional information when the result of a WG Last Call is "Revised I-D Needed". See section 3.3 for "annotation tags" which may be used to provide such additional information. 3.1.7. Waiting for WG Document Shepherd Write-Up The working group last call has been completed and the document is awaiting the document shepherd to submit his/her write-up. 3.1.8. Submitted to IESG for Publication The document has been submitted to the IESG for publication (and has not returned to the WG for further action). The document may be under consideration by the IESG, it may have been approved and be in the RFC Editor's queue, or it may have been published as an RFC; this state does not distinguish between different states that may occur after the document has left the working group. 3.1.9. Dead WG Document A "Dead WG Document" is an I-D that used to a WG document, but has been abandoned. Note that this is not always a final state. If consensus is subsequently achieved in the working group, a "Dead WG Document" can be resurrected. 3.2. Straw Man WG Document State Diagram Figure 1 illustrates all of the different states defined in section 3.1, and most of the state transitions that an I-D MAY experience during its tenure as a WG Document. State transitions which are rare (e.g. an I-D going from "Parked" to "Dead") are not illustrated in the diagram, however the lack of an explicit path between two states in the diagram does not mean that such a transition is impossible. 3.3. WG Document Substates In addition to identifying the state that every WG Document is in, it would be informative for the Datatrack to record associated substates or conditions which may affect each WG Document at different time. The substates do not change the state of WG documents, but they can be used, for example, to help the community understand why a document is in the state it is in, and/or to indicate the next action needed for the document. Juskevicius Expires September 2, 2010 [Page 6] Internet-Draft Working Group Document States March 2010 +------------------------------------------------------------------+ | | | I-D | | Exists | | | | | | | | v | | | | CANDIDATE WG | | DOCUMENT | | | | | | | | v | | | | DEAD WG <----------> ACTIVE WG <--------> PARKED WG | | DOCUMENT . -> DOCUMENT DOCUMENT | | . | | . | ^ ^ | | . | | | | | . | + - < - - + | | | . | | | | | . v | ^ | | | | | | ' IN WG ^ | | | LAST CALL | | | | ^ | | | | | | ^ | | ' | ^ | | | v | | | | ^ | | | | WG LAST CALL - - - + | | | ' COMPLETED - - - - - - - - - + | | | | ^ | | | +---------------------+ | | ' | | | . v | | . | | . SUBMITTED WAITING FOR | | < - - (to IESG) <------ DOC SHEPHERD | | FOR PUBLICATION WRITE-UP | | | +------------------------------------------------------------------+ Figure 1 - Diagram of I-D states relevant to IETG working groups Juskevicius Expires September 2, 2010 [Page 7] Internet-Draft Working Group Document States March 2010 Each of the substates defined herein may be appropriate to indicate the substate of a WG Document at different times. 3.3.1. Awaiting Cross-Area Review This is a valid substate for "Active" and "Parked" WG Documents. It means that someone (e.g. an author or editor of the document, or a WG Chair) has initiated a cross-area review of the document, and the review has not (yet) been completed. Documents tagged with this annotation SHOULD remain in this substate until the review is complete and possibly until the issues raised in the review are addressed. 3.3.2. Awaiting MIB Doctor Review This is a valid substate for "Active" and "Parked" WG Documents. It means that someone (e.g. an author or editor of the document, or the a WG Chair) has initiated a review of the document by a MIB Doctor, and the review has not (yet) been completed. Documents tagged with this annotation SHOULD remain in this substate until the review is complete and possibly until the issues raised in the review are addressed. 3.3.3. Awaiting Security Review This is a valid substate for "Active" and "Parked" WG Documents. It means that someone (e.g. an author or editor of the document, or a WG Chair) has initiated a review of security considerations in the document, and the review has not (yet) been completed. Documents tagged with this annotation SHOULD remain in this substate until the review is complete and possibly until the issues raised in the review are addressed. 3.3.4. Awaiting Other Review This is a valid substate for "Active" and "Parked" WG Documents. It means that someone (e.g. an author or editor of the document, or a WG Chair) has initiated some other review of the document (e.g. sent it to another Standards Development Organization (SDO) for comments via a formal or informal liaison process [MPLSTPDP]) and the review has not (yet) been completed. Juskevicius Expires September 2, 2010 [Page 8] Internet-Draft Working Group Document States March 2010 Documents tagged with this annotation SHOULD remain in this substate until the review is complete and possibly until the issues raised in the review are addressed. 3.3.5. Awaiting Merge with Other Document This is a valid substate for "Active" and "Parked" WG Documents. It means that a decision has been made by someone (e.g. the document's authors, editors, or the WG Chairs) to have the I-D merged with one or more other I-Ds from the same (or other) WG. If the result of the "merge" operation is a brand new I-D having a different title, then the old I-D may be declared as being "Dead". In this case the substate annotation should be changed from "Awaiting Merge with Other Document" to "Other - see Comment Log" and a description of what happened should be entered in the log for posterity. If the result of the "merge" operation is a revision to the I-D, then this substate should be cleared as soon as the the revised I- D is submitted to the IETF by its authors or editors. 3.3.6. Author or Editor Needed This substate is applicable to "Parked", "Dead" and (sometimes) "Active" WG Documents. It means the I-D has lost a primary author or editor, and that further work on the I-D can not continue in an effective or efficient manner without a new author or editor being found. 3.3.7. Held due to Dependency on other Document This substate is most often associated with "Parked" WG Documents. It means that work to complete the I-D is on-hold because of one or more dependencies on other documents. A typical example is where an I-D includes normative references to other IETF documents, but all of other documents have not (yet) been published as RFCs. 3.3.8. Held due to IESG concerns on this Document This is a valid substate for "Active" and "Parked" WG Documents, and I-Ds which are in the "WG Last Call Completed" state. This annotation is an indicator that one or more IESG members have expressed concerns about the document (e.g. during discussions leading up to a WG Last Call, or during the WG Last Call), and Juskevicius Expires September 2, 2010 [Page 9] Internet-Draft Working Group Document States March 2010 that the document MUST NOT be submitted to the IESG for publication until the concerns are addressed. Once in this substate, WG Documents SHOULD continue to be tagged with this indicator until the IESG concerns are resolved, even if the main state of the I-D changes (e.g. from "Active" to "Parked" (or "Dead") or vice-versa). 3.3.9. Revised I-D Needed - based on WG consensus This is a valid substate for "Active", "Parked", and "Dead" WG Documents. This annotation means that rough consensus was developed in the working group that the I-D needs to be revised if it is to be progressed. This annotation can also indicate when an I-D is already in the process of being revised. This substate SHOULD be reset when the revised version of the I-D is submitted to the WG. 3.3.10. Revised I-D Needed - based on WG last call This is a valid substate for "WG Last Call Completed", "Active", "Parked", and/or "Dead" WG Documents. This annotation means the I-D was sent for WG Last Call and the consensus after the Last Call is that the WG Document MUST be revised before it may progress any further. 3.3.11. Doc Shepherd Follow-up This substate annotation indicates when a shepherd for the WG Document is actually working on the write-up required to submit the document (to the IESG) for publication. It is often the case that too many I-Ds can arrive in a Shepherd's queue in too short a time, and the Shepherd can not create write-ups for all of them simultaneously. This substate tag SHOULD be used to distinguish between I-Ds waiting for write-up (i.e. I-Ds for which the write- ups have not yet been started), and I-Ds for which the write-ups are already underway. 3.3.12. Other - see Comment Log This annotation tag is a catch-all to indicate that someone (e.g. an author or editor of the document, the WG Chair, an AD) has entered one or more comments about the current state of the I-D into the IETF Datatracker. Juskevicius Expires September 2, 2010 [Page 10] Internet-Draft Working Group Document States March 2010 3.4. Intended Maturity Level of WG Documents In addition to the substate annotation tags defined in section 3.3, the intended maturity level of every WG Document SHOULD also be tracked. The definition of the maturity levels are as in sections 4 and 5 of RFC 2026 [RFC2026]. They are: * "Experimental" * "Informational" * "Best Current Practice" * "Proposed Standard" * "Draft Standard" * "Full Standard" * "Historic" 4. Security Considerations This document does not propose any new internet mechanisms, and has no security implications for the internet. 5. IANA Considerations This document does not require any new number assignments from IANA, and does not define any new numbering spaces to be administered by IANA. RFC-Editor: Please remove this section before publication. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2026] Bradner, S., "The Internet Standards Process: Revision 3", BCP 9, RFC 2026, October 1996. Juskevicius Expires September 2, 2010 [Page 11] Internet-Draft Working Group Document States March 2010 6.2. Informative References [IDTRACKER] "The IETF Datatracker tool", Web Application: https://datatracker.ietf.org/, March 1, 2010. [IDSTATES] "Main I-D States", Web Application: https://datatracker.ietf.org/idtracker/help/state/, March 1, 2010. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 2008. [MPLSTPDP] Farrel, A., et al, "IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-tp) Document Process", draft-IETF-MPLS-tp-process-05.txt, Section 2.3, January 24, 2010. [PROTO] Levkowetz, H., and Mankin, A., "Requirements on I-D Tracker Extensions for Working Group Chairs", draft-ietf-proto-wgchair-tracker-ext-03, February 8, 2007. 7. Acknowledgments The author would like to thank Henrik Levkowetz and Allison Mankin for writing the original I-Ds [PROTO] that provided copious amounts of text and the basic structure of this document. The author would also like to thank Henrik Levkowetz, Alfred Hoenes, John Klensin, Pasi Eronen, Mary Barnes, Glenn Parsons, Spencer Dawkins, Russ Housley, Marc Blanchet, Andy Malis and other WG chairs for useful discussions, comments and suggestions. This document was initially prepared using 2-Word-v2.0.template.dot. Juskevicius Expires September 2, 2010 [Page 12] Internet-Draft Working Group Document States March 2010 Appendix A: "IESG Document" States This Appendix describes the status information currently stored in the IETF Datatracker tool for every I-D submitted to the IESG for publication. The terms and definitions herein are as in [IDSTATES]. It must be noted that I-Ds sent to the IESG for publication (termed "IESG Documents" in the Appendix) do not stay with the IESG until they day they are published as RFCs. After evaluation, the IESG may declare that some I-Ds deserve a "Do Not Publish" label, while others should be "Dead". Some I-Ds get sent back to their originators (WGs or otherwise), and the rest go into the RFC Editor queue. A.1. Definition of "IESG Document" States A.1.1. I-D Exists This is the initial (default) state for all Internet-Drafts. Such documents are not tracked by the IESG as no request has been made of the IESG to do anything with an I-D in this state. A.1.2. Publication Requested A formal request has been made to advance/publish the document, following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the request could be from a WG Chair, from an individual through the RFC Editor, etc. Note: the Secretariat (iesg-secretary@ietf.org) is copied on these requests to ensure that the request makes it into the Datatracker. A document in this state has not (yet) been reviewed by an Area Director (AD) nor has any official action been taken on it yet (other than to note that its publication has been requested). A.1.3. AD Evaluation A specific AD (e.g. the "Area Advisor" for the WG) has begun his/her review of the document to verify that it is ready for advancement. The shepherding AD is responsible for doing any necessary review before starting an IETF Last Call or sending the document directly to the IESG as a whole. A.1.4. Expert Review An AD sometimes asks for an external review by an outside party as part of evaluating whether a document is ready for advancement. MIBs, for example, are reviewed by the "MIB doctors". Other types Juskevicius Expires September 2, 2010 [Page 13] Internet-Draft Working Group Document States March 2010 of reviews may also be requested (e.g., security, operations impacts, etc.). Documents remain in this state until the review is completed and possibly until the issues raised in the review are addressed. Specific details on the nature of the review may be found in the "note" field associated with this state (i.e. within the Datatracker). A.1.5. Last Call Requested The AD has requested that the Secretariat start an IETF Last Call, but the actual Last Call message has not been sent yet. A.1.6. In Last Call The document is currently waiting for IETF Last Call to complete. Last Calls for WG documents typically last 2 weeks, and those for individual submissions last 4 weeks. A.1.7. Waiting for Writeup Before a standards-track or BCP document is formally considered by the entire IESG, the AD must write-up a protocol action. The protocol action is included in the approval message that the Secretariat sends out when the document is approved for publication as an RFC. A.1.8. Waiting for AD Go-Ahead As a result of the IETF Last Call, comments may need to be responded to and a revision of the I-D may be needed as well. The AD is responsible for verifying that all Last Call comments have been adequately addressed and that the (possibly revised) document is in the I-D directory and ready for consideration by the IESG as a whole. A.1.9. IESG Evaluation The document is now (finally!) being formally reviewed by the entire IESG. Documents are discussed in email or during a bi-weekly IESG telechat. In this phase, each AD reviews the document and airs any issues she/he may have. Unresolvable issues are documented as "discuss" comments that can be forwarded to the authors/WG. See the description of substates in Section A.2 for additional details about the current state of the IESG discussion. Juskevicius Expires September 2, 2010 [Page 14] Internet-Draft Working Group Document States March 2010 A.1.10. IESG Evaluation - Defer During a telechat, one or more ADs requested an additional 2 weeks to review the document. A defer is designed to be an exception mechanism, and can only be invoked once, the first time the document comes up for discussion during a telechat. A.1.11. Approved-announcement to be sent The IESG has approved the document for publication, but the Secretariat has not yet sent out an official approval message. A.1.12. Approved-announcement sent The IESG has approved the document for publication, and the Secretariat has sent out the official approval message to the RFC editor. A.1.13. RFC Ed Queue The document is in the RFC editor Queue (as confirmed by http://www.rfc-editor.org/queue.html) A.1.14. RFC Published The I-D has been published as an RFC. A.1.15. DNP-waiting for AD note Do Not Publish: The IESG recommends against publishing the document, but the writeup explaining its reasoning has not yet been produced. DNPs apply primarily to individual submissions received through the RFC editor. More information on who has the action item should be recorded in the "note" field associated with this state (i.e. within the Datatracker). A.1.16. DNP-announcement to be sent The IESG recommends against publishing the document. A writeup explaining the IESG's reasoning has been produced, but the Secretariat has not yet sent out the official "do not publish" recommendation message. A.1.17. AD is Watching An AD is aware of the document and has chosen to place the document in a separate state in order to keep a closer eye on it (for Juskevicius Expires September 2, 2010 [Page 15] Internet-Draft Working Group Document States March 2010 whatever reason). Documents in this state are still not being actively tracked in the sense that no formal request has been made to publish or advance the document. The sole difference between this state and "I-D Exists" is that an AD has chosen to put it in a separate state, to make it easier to keep track of (for his or her own reasons). A.1.18. Dead The document is "dead" and is no longer being tracked (e.g., it has been replaced by another document having a different name, it has been withdrawn, etc.). A.2. "IESG Document" Substates A.2.1. Point Raised - writeup needed IESG discussions on the document have raised some issues that need to be brought to the attention of the authors/WG, but those issues have not been written down yet. (It is common for discussions during a telechat to result in such situations. An AD may raise a possible issue during a telechat and only decide as a result of that discussion whether the issue is worth formally writing up and bringing to the attention of the authors/WG). A document stays in the "Point Raised - writeup needed" state until *ALL* IESG comments that have been raised have been documented. A.2.2. AD Followup "AD Followup" is a generic substate indicating that the shepherding AD has the action to determine appropriate next steps. In particular, the appropriate steps (and the corresponding next state or substate) depend entirely on the nature of the issues that were raised and can only be decided with active involvement of the shepherding AD. Examples include: - if another AD raises an issue, the shepherding AD may first iterate with the other AD to get a better understanding of the exact issue. Or, the shepherding AD may attempt to argue that the issue is not serious enough to bring to the attention of the authors/WG. - if a documented issue is forwarded to a WG, some further iteration may be needed before it can be determined whether a new revision is needed or whether the WG response to an issue clarifies the issue sufficiently. Juskevicius Expires September 2, 2010 [Page 16] Internet-Draft Working Group Document States March 2010 - when a new revision appears, the shepherding AD will first look at the changes to determine whether they believe all outstanding issues have been raised satisfactorily, prior to asking the ADs who raised the original issues to verify the changes. A.2.3. External Party The document is awaiting review or input from an external party (i.e, someone other than the shepherding AD, the authors, or the WG). See the "note" field for more details on who has the action. A.2.4. Revised I-D Needed An updated I-D is needed to address the issues that have been raised. Author's Address Ed Juskevicius TrekAhead PO Box 491, Carp, ON CANADA Email: edj.etc@gmail.com Juskevicius Expires September 2, 2010 [Page 17]