summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6174.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6174.txt')
-rw-r--r--doc/rfc/rfc6174.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc6174.txt b/doc/rfc/rfc6174.txt
new file mode 100644
index 0000000..8ae652b
--- /dev/null
+++ b/doc/rfc/rfc6174.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Juskevicius
+Request for Comments: 6174 TrekAhead
+Category: Informational March 2011
+ISSN: 2070-1721
+
+
+ Definition of IETF Working Group Document States
+
+Abstract
+
+ The IETF Datatracker tool needs to be enhanced to make it possible
+ for Working Group (WG) Chairs to provide IETF participants with more
+ information about the status and progression of WG documents than is
+ currently possible.
+
+ This document defines new states and status annotation tags that need
+ to be added to the Datatracker to enable WG Chairs and their
+ Delegates to track the status of Internet-Drafts (I-Ds) that are
+ associated with their WGs. This document also describes the meaning
+ of all previously implemented I-D states and substate annotation tags
+ currently used by IETF Area Directors to indicate the status of I-Ds
+ that have been sent to the IESG for evaluation and publication.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6174.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Juskevicius Informational [Page 1]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 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.
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Conventions Used in This Document ...............................4
+ 3. I-D States Already Implemented by the Datatracker ...............5
+ 3.1. I-D Availability States ....................................5
+ 3.1.1. Expired .............................................6
+ 3.1.2. Active ..............................................6
+ 3.1.3. Replaces and Replaced By ............................6
+ 3.2. IESG Document States .......................................7
+ 3.2.1. Publication Requested ...............................7
+ 3.2.2. AD Evaluation .......................................8
+ 3.2.3. IESG Evaluation .....................................8
+ 4. New States and Status Annotation Tags for WG I-Ds ...............9
+ 4.1. Working Group I-D State Diagram ............................9
+ 4.2. Working Group I-D States ..................................11
+ 4.2.1. Call for Adoption by WG Issued .....................12
+ 4.2.2. Adopted by a WG ....................................12
+ 4.2.3. Adopted for WG Info Only ...........................13
+ 4.2.4. WG Document ........................................13
+ 4.2.5. Parked WG Document .................................13
+ 4.2.6. Dead WG Document ...................................14
+ 4.2.7. In WG Last Call ....................................14
+ 4.2.8. Waiting for WG Chair Go-Ahead ......................15
+ 4.2.9. WG Consensus: Waiting for Writeup ..................15
+ 4.2.10. Submitted to IESG for Publication .................15
+ 4.3. Working Group I-D Status Annotation Tags ..................16
+ 4.3.1. Awaiting Expert Review/Resolution of Issues Raised .16
+ 4.3.2. Awaiting External Review/Resolution of
+ Issues Raised ......................................16
+ 4.3.3. Awaiting Merge with Other Document .................16
+ 4.3.4. Author or Editor Needed ............................17
+ 4.3.5. Waiting for Referenced Document ....................17
+
+
+
+Juskevicius Informational [Page 2]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ 4.3.6. Waiting for Referencing Document ...................17
+ 4.3.7. Revised I-D Needed - Issue raised by WGLC ..........18
+ 4.3.8. Revised I-D Needed - Issue raised by AD ............18
+ 4.3.9. Revised I-D Needed - Issue raised by IESG ..........18
+ 4.3.10. Doc Shepherd Followup Underway ....................18
+ 4.3.11. Other - see Comment Log ...........................19
+ 5. Intended Maturity Level of WG Drafts ...........................19
+ 6. Security Considerations ........................................19
+ 7. References .....................................................19
+ 7.1. Normative References ......................................19
+ 7.2. Informative References ....................................20
+ 8. Acknowledgments ................................................20
+ Appendix A: "IESG Document" States ................................21
+ A.1. Definition of "IESG Document" States ......................21
+ A.1.1. Publication Requested ................................21
+ A.1.2. AD Evaluation ........................................21
+ A.1.3. Expert Review ........................................21
+ A.1.4. Last Call Requested ..................................22
+ A.1.5. In Last Call .........................................22
+ A.1.6. Waiting for Writeup ..................................22
+ A.1.7. Waiting for AD Go-Ahead ..............................22
+ A.1.8. IESG Evaluation ......................................22
+ A.1.9. IESG Evaluation - Defer ..............................23
+ A.1.10. Approved - Announcement to be sent ..................23
+ A.1.11. Approved - Announcement sent ........................23
+ A.1.12. RFC Ed Queue ........................................23
+ A.1.13. RFC Published .......................................23
+ A.1.14. DNP - Waiting for AD note ...........................23
+ A.1.15. DNP - Announcement to be sent .......................23
+ A.1.16. AD is Watching ......................................23
+ A.1.17. Dead ................................................24
+ A.2. IESG Document Substates ...................................24
+ A.2.1. Point Raised - writeup needed ........................24
+ A.2.2. AD Followup ..........................................24
+ A.2.3. External Party .......................................25
+ A.2.4. Revised ID Needed ....................................25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Juskevicius Informational [Page 3]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+1. Introduction
+
+ The IETF Datatracker is a web-based system for managing information
+ about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison
+ statements, and several other important aspects of the IETF process
+ [IDTRACKER].
+
+ The Datatracker is currently able to track and report on the status
+ of I-Ds that have been submitted to the IESG for evaluation and
+ publication. Appendix A of this document describes all of the
+ document states and substate annotation tags used by IETF Area
+ Directors (ADs) to indicate the status of I-Ds that have been sent to
+ the IESG.
+
+ In contrast, the Datatracker has almost no ability to indicate the
+ status and progression of I-Ds before they are sent to the IESG. The
+ Datatracker can only track the availability status of I-Ds today
+ (e.g., "Active", Expired", "Withdrawn", "Replaced by") and in some
+ cases indicate which IETF Working Group (WG) an I-D is associated
+ with (if any).
+
+ Section 3 of this document contains a summary of the Datatracker's
+ current ability to track and report on the status of I-Ds in the IETF
+ document stream. The IETF document stream is defined in Section
+ 5.1.1 of RFC 4844 [RFC4844].
+
+ Section 4 of this document defines several new I-D states and I-D
+ status annotation tags that need to be added to the Datatracker to
+ enable status tracking and reporting for WG I-Ds.
+
+2. Conventions Used in This Document
+
+ A "working group I-D" (WG I-D) is an Internet-Draft that has achieved
+ consensus for adoption as a work item by a WG (compared to an
+ individual submission I-D that has not, or has not yet, achieved
+ consensus).
+
+ The terms "WG I-D", "WG document", and "WG draft" are used
+ synonymously throughout this document. The same is true for the
+ plural case of each term.
+
+ The terms "WG document" and "WG draft" are not intended to apply to
+ any other document that may be reviewed, discussed, or produced by an
+ IETF working group. Working group meeting materials such as Blue
+ Sheets, agendas, jabber logs, scribe's notes, minutes, and
+ presentation slides are not to be considered "WG documents" or "WG
+ drafts" in the context of this document.
+
+
+
+
+Juskevicius Informational [Page 4]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ The phrase "WG status of an I-D" is to be interpreted as referring to
+ the state that an I-D is in, as defined in Section 4.2 of this
+ document. This phrase does not refer to an I-D's availability status
+ (e.g., "Expired", "Active", "Replaced by") as described in Section
+ 3.1, or to any of the IESG states used by Area Directors to describe
+ the status of I-Ds they may be evaluating.
+
+3. I-D States Already Implemented by the Datatracker
+
+ This section describes capabilities that are currently implemented in
+ the Datatracker to track the status of I-Ds in the IETF document
+ stream.
+
+ The document availability states described in Section 3.1 are
+ applicable to every I-D submitted to the IETF.
+
+ The IESG document states and substate annotation tags described in
+ Section 3.2 and Appendix A are only applicable to I-Ds that have been
+ submitted to the IESG for evaluation and publication.
+
+ The Datatracker currently has no I-D states or I-D status annotation
+ tags to describe the WG status of any I-D.
+
+3.1. I-D Availability States
+
+ The Datatracker currently maintains availability status information
+ for every I-D submitted to the IETF. The I-D availability states are
+ as follows:
+
+ - Expired
+ - Active
+ - Replaces
+ - Replaced by
+ - Withdrawn by Submitter
+ - Withdrawn by IETF
+ - RFC
+
+ The first four I-D availability states are explained in the following
+ subsections. The other states are self-explanatory.
+
+ Note that the Datatracker describes the status of some I-Ds with the
+ phrase "I-D Exists". "I-D Exists" is the state that is manufactured
+ by the Datatracker to describe I-Ds for which it has no other status
+ information. For example, the tool currently uses "I-D Exists" to
+ describe I-Ds that are not expired and that have not been sent to the
+ IESG.
+
+
+
+
+
+Juskevicius Informational [Page 5]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+3.1.1. Expired
+
+ An "Expired" I-D is a document that is more than six months old and
+ that has not been updated or replaced by a newer I-D or an RFC.
+
+ Every I-D has a normal lifespan of 185 days. An I-D will expire and
+ be deleted from the I-D repository after six months unless it is
+ updated or replaced by a newer version. One exception is that an I-D
+ undergoing official evaluation by the IESG will not be expired before
+ its status is resolved (e.g., the I-D is published as an RFC). IESG
+ states that do not relate to a formal request to publish a document
+ (e.g., "AD is Watching") do not prevent an I-D from expiring.
+ [AUTHGUIDE]
+
+3.1.2. Active
+
+ An "Active" I-D is a document that is less than six months old and
+ has not been updated or replaced by a newer I-D or an RFC.
+
+ The "Active" availability state is applicable to individual I-Ds and
+ WG I-Ds. The Datatracker may also use "Active" to describe the
+ status of I-Ds under formal evaluation by the IESG and I-Ds in the
+ RFC Editor Queue. As a result, the "Active" I-D availability state
+ cannot be used to determine if an I-D is actively being developed by
+ a WG. [WGDTSPEC]
+
+3.1.3. Replaces and Replaced By
+
+ The Datatracker uses "Replaces" and "Replaced by" to describe I-Ds
+ that have been renamed and subsequently resubmitted to the I-D
+ repository for some reason.
+
+ Two common uses of "Replaced by" are as follows:
+
+ - The filename of an individual I-D that is being considered for
+ adoption by a WG typically includes the name of its author (e.g.,
+ 'draft-author-wgname-topic-nn'). If the individual I-D is adopted
+ by a WG it will be "Replaced by" a newer draft having a filename
+ that includes the string 'ietf-' (e.g., 'draft-ietf-wgname-
+ topic-00'); when the newer WG I-D is submitted to the I-D
+ repository, it "Replaces" the older individual submission I-D.
+
+ - The Datatracker also uses "Replaced by" to describe the final
+ state of an I-D that has been published as an RFC; the I-D was
+ "Replaced By" the RFC.
+
+ Note that getting correct "Replaces" and "Replaced by" data into the
+ Datatracker currently requires an explicit request by a WG Chair.
+
+
+
+Juskevicius Informational [Page 6]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ Without such a request, an individual submission I-D will co-exist
+ with the newer WG I-D that replaces it until the individual
+ submission I-D eventually expires.
+
+ The Datatracker's ability to track "Replaces" and "Replaced by"
+ information may need to be extended in the future to handle more
+ complex cases such as the following:
+
+ - Two or more I-Ds are merged into (i.e., "Replaced by") a single
+ I-D; in such cases, the availability status of the (one) new I-D
+ should indicate that the draft "Replaces" two or more older and
+ previously separate I-Ds; and
+
+ - One I-D is split or divided into two or more new I-Ds; in this
+ case the availability status should indicate that one (older) I-D
+ was "Replaced by" two or more newer I-Ds.
+
+3.2. IESG Document States
+
+ In addition to tracking the availability status of every I-D, the
+ Datatracker also maintains detailed information about the status and
+ progression of I-Ds that have been sent to the IESG for evaluation
+ and publication.
+
+ All of the states used by Area Directors to indicate the status of
+ I-Ds under evaluation by the IESG are defined in [IESGSTAT] and are
+ reproduced for convenience in Appendix A.
+
+ The following subsections describe some common interactions between
+ three of the IESG I-D states and normal IETF WG processes. These
+ interactions are relevant to several of the new WG I-D states defined
+ in Section 4.
+
+3.2.1. Publication Requested
+
+ When a WG has determined that at least rough consensus exists within
+ the WG to advance an I-D, progressing the document is then the
+ responsibility of the IESG (unless the IESG returns the I-D to the WG
+ for further development). [RFC2418]
+
+ The "Publication Requested" state describes an I-D for which a formal
+ request has been sent to the IESG to advance/publish the I-D as an
+ RFC, following the procedures specified in Section 7.5 of RFC 2418
+ [RFC2418]. This state does not mean that an Area Director has
+ reviewed the I-D or that any official action has been taken on the
+ I-D other than to note that its publication has been requested.
+
+
+
+
+
+Juskevicius Informational [Page 7]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ Many WG drafts enter the IESG state machine for the first time via
+ the "Publication Requested" state. When an I-D advances through the
+ IESG process, its IESG state will change to reflect its progress.
+ This said, the WG status of the I-D should not change unless an AD or
+ the IESG sends the I-D back to the WG for further development. The
+ WG state of an I-D that is being progressed by the IESG is "Submitted
+ to IESG for Publication", as defined in Section 4.2.10.
+
+3.2.2. AD Evaluation
+
+ The "AD Evaluation" state describes an I-D that the responsible Area
+ Director has begun to review. The purpose of the AD's review is to
+ verify that the I-D is ready for advancement before an IETF Last Call
+ is started or before the document is progressed to the IESG as a
+ whole.
+
+ After evaluating an I-D, the responsible AD may decide that the
+ document needs to be revised before it can be progressed further.
+ The AD may send a working group I-D back to the WG that created it
+ for revision.
+
+ When an AD sends an I-D back to a WG for revision, the Datatracker
+ will report the IESG state and substate status of the document as "AD
+ Evaluation: Revised I-D Needed". If the required revisions are
+ extensive, a WG Chair may decide to change the WG state of the I-D
+ from "Submitted to IESG for Publication" to another WG state (e.g.,
+ "Waiting for WG Chair Go-Ahead" or "WG Document") for as long as it
+ takes the revised I-D to be developed. The IESG status of the I-D
+ will continue to be "AD Evaluation: Revised I-D Needed" until the
+ revised I-D becomes available.
+
+3.2.3. IESG Evaluation
+
+ The "IESG Evaluation" state describes an I-D that is being formally
+ evaluated by the entire IESG. Every AD is able to raise any content
+ or process issues he/she may have with the document. Issues that are
+ blocking approval of the document are called "DISCUSS" comments. A
+ "DISCUSS" with serious issues may cause a WG I-D to be returned to
+ the WG for revision.
+
+ If the IESG sends an I-D back to a WG for more development, the
+ Datatracker will report the IESG state and substate of the I-D as
+ "IESG Evaluation: Revised I-D Needed" until a revised version of the
+ I-D becomes available. During the time that the I-D is being
+ revised, the WG Chair may decide to transition the I-D from the
+ "Submitted to IESG for Publication" state into one of the earlier WG
+ states (e.g., "Waiting for WG Chair Go-Ahead" or "WG Document").
+
+
+
+
+Juskevicius Informational [Page 8]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+4. New States and Status Annotation Tags for WG I-Ds
+
+ The status-tracking states described in Section 3 are currently
+ implemented in the Datatracker; however, their scope is not broad
+ enough to provide good visibility into the WG status of any I-D.
+
+ This section describes new I-D states and I-D status annotation tags
+ that need to be added to the Datatracker to make it possible for WG
+ Chairs and/or their Delegates (e.g., WG Secretaries) to indicate the
+ status and progression of the I-Ds associated with their WGs.
+
+ The WG I-D states defined in this section are a superset of the I-D
+ states currently used across all IETF WGs. This is not to suggest or
+ imply that all of the WG I-D states must be used by all WG Chairs to
+ describe the status and progression of the I-Ds associated with their
+ WGs. Chairs may use all or just some of the document states
+ illustrated in Figure 1 to describe the WG status of their I-Ds as
+ appropriate.
+
+4.1. Working Group I-D State Diagram
+
+ Figure 1 is a state machine diagram that illustrates all of the WG
+ I-D states defined in Section 4.2 of this document. The names of the
+ WG I-D states are capitalized for clarity, and common state
+ transitions are indicated via the solid, dashed, and dotted lines.
+
+ The WG I-D state machine illustrated in Figure 1 is intended to be a
+ new front-end to the IESG I-D state machine [IESGIDSM] that is
+ currently implemented in Datatracker.
+
+ Note that Figure 1 does not show every possible state transition. WG
+ Chairs may move an I-D from any WG state to any other WG state as
+ appropriate to describe the WG status of the document. The lack of
+ an explicit path between two states does not mean that such a state
+ transition is precluded.
+
+ The first WG I-D state is "Call for Adoption by WG Issued" and its
+ meaning and usage are defined in Section 4.2.1.
+
+ One of several possible last states for a WG I-D is "Submitted to
+ IESG for Publication". This state is defined in Section 4.2.10.
+
+
+
+
+
+
+
+
+
+
+Juskevicius Informational [Page 9]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ "I-D EXISTS": 'draft-author-wgname-topic-nn' < - - .
+ : .
+ +---------------------------------------------------------------------+
+ | WG I-D State Machine | . |
+ | v (not adopted) |
+ | . |
+ | CALL FOR ADOPTION BY WG ISSUED . . . . . |
+ | . : |
+ | . v |
+ | v |
+ | ADOPTED FOR ADOPTED BY WG |
+ | WG INFO ONLY . |
+ | : |
+ | : |
+ | (individual I-D "Replaced by" 'draft-ietf-wgname-topic-00') |
+ | : |
+ | v |
+ | |
+ | DEAD WG <--------> WG DOCUMENT <--------> PARKED WG |
+ | DOCUMENT ("Replaces" individual I-D) DOCUMENT |
+ | . |
+ | . ^ \ |
+ | . / \ |
+ | . / \ |
+ | . v \ |
+ | . \ |
+ | . IN WG ---+ v |
+ | LAST CALL | |
+ | ' ^ +--> WG CONSENSUS: |
+ | ^ : WAITING FOR |
+ | ' v +--> WRITEUP |
+ | ' | |
+ | ^ WAITING FOR | | |
+ | ' WG CHAIR ---+ | |
+ | ' GO-AHEAD v |
+ | . |
+ | . SUBMITTED TO IESG |
+ | ("Revised ID Needed") - - < - FOR PUBLICATION |
+ | |
+ | |
+ +---------------------------------------------------------------------+
+ |
+ v
+ IESG Document States
+ (see Appendix A)
+
+ Figure 1: WG I-D States and Common State Transitions
+
+
+
+
+Juskevicius Informational [Page 10]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ The Datatracker will be enhanced to automatically generate the
+ following two state transitions for all WG drafts:
+
+ - A version-00 I-D that conforms to the 'draft-ietf-wgname-topic-00'
+ file naming convention will be moved into the "WG Document" state
+ automatically by the Datatracker when the WG Chair approves the
+ posting of an I-D; and
+
+ - A WG draft that is moved into the IESG state called "Publication
+ Requested" will automatically be moved by the Datatracker into the
+ WG state called "Submitted to IESG for Publication".
+
+ All other WG I-D state transitions will require the WG Chairs or
+ their Delegates to log in to the Datatracker to manually input the
+ appropriate WG state to describe the WG status of an I-D.
+
+ Note that Figure 1 includes an arc from the "Submitted to IESG for
+ Publication" state back to the "WG Document" state. This is one
+ example of what may happen after an AD or the IESG as a whole sends
+ an I-D back to a WG for revision. The WG chair may decide that the
+ I-D needs further development and that it needs to return to the "WG
+ Document" state for a while.
+
+4.2. Working Group I-D States
+
+ The WG I-D states defined in this section are a superset of the I-D
+ states currently used across all IETF WGs.
+
+ All of the states described herein need to be added to the front-end
+ of IESG state machine [IESGIDSM] that has already been implemented in
+ the IETF Datatracker.
+
+ WG Chairs and their Delegates will be given the flexibility to use
+ whichever of the WG I-D states they feel to be appropriate to
+ describe the WG status of the I-Ds associated with their WG.
+
+ It is not suggested or implied that Chairs must use all of the I-D
+ states defined herein to describe the status and progression of all
+ I-Ds associated with their WGs; Chairs may use all of the WG I-D
+ states, or just some of the states.
+
+ Note that an I-D that is not associated with a WG will be in a 'Null'
+ state with respect to the WG state machine in Figure 1.
+
+
+
+
+
+
+
+
+Juskevicius Informational [Page 11]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+4.2.1. Call for Adoption by WG Issued
+
+ The "Call for Adoption by WG Issued" state should be used to indicate
+ when an I-D is being considered for adoption by an IETF WG. An I-D
+ that is in this state is actively being considered for adoption and
+ has not yet achieved consensus, preference, or selection in the WG.
+
+ This state may be used to describe an I-D that someone has asked a WG
+ to consider for adoption, if the WG Chair has agreed with the
+ request. This state may also be used to identify an I-D that a WG
+ Chair asked an author to write specifically for consideration as a
+ candidate WG item [WGDTSPEC], and/or an I-D that is listed as a
+ 'candidate draft' in the WG's charter.
+
+ Under normal conditions, it should not be possible for an I-D to be
+ in the "Call for Adoption by WG Issued" state in more than one
+ working group at the same time. This said, it is not uncommon for
+ authors to "shop" their I-Ds to more than one WG at a time, with the
+ hope of getting their documents adopted somewhere.
+
+ After this state is implemented in the Datatracker, an I-D that is in
+ the "Call for Adoption by WG Issued" state will not be able to be
+ "shopped" to any other WG without the consent of the WG Chairs and
+ the responsible ADs impacted by the shopping.
+
+ Note that Figure 1 includes an arc leading from this state to outside
+ of the WG state machine. This illustrates that some I-Ds that are
+ considered do not get adopted as WG drafts. An I-D that is not
+ adopted as a WG draft will transition out of the WG state machine and
+ revert back to having no stream-specific state; however, the status
+ change history log of the I-D will record that the I-D was previously
+ in the "Call for Adoption by WG Issued" state.
+
+4.2.2. Adopted by a WG
+
+ The "Adopted by a WG" state describes an individual submission I-D
+ that an IETF WG has agreed to adopt as one of its WG drafts.
+
+ WG Chairs who use this state will be able to clearly indicate when
+ their WGs adopt individual submission I-Ds. This will facilitate the
+ Datatracker's ability to correctly capture "Replaces" information for
+ WG drafts and correct "Replaced by" information for individual
+ submission I-Ds that have been replaced by WG drafts.
+
+ This state is needed because the Datatracker uses the filename of an
+ I-D as a key to search its database for status information about the
+ I-D, and because the filename of a WG I-D is supposed to be different
+ from the filename of an individual submission I-D.
+
+
+
+Juskevicius Informational [Page 12]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ The filename of an individual submission I-D will typically be
+ formatted as 'draft-author-wgname-topic-nn'.
+
+ The filename of a WG document is supposed to be formatted as 'draft-
+ ietf-wgname-topic-nn'.
+
+ An individual I-D that is adopted by a WG may take weeks or months to
+ be resubmitted by the author as a new (version-00) WG draft. If the
+ "Adopted by a WG" state is not used, the Datatracker has no way to
+ determine that an I-D has been adopted until a new version of the I-D
+ is submitted to the WG by the author and until the I-D is approved
+ for posting by a WG Chair.
+
+4.2.3. Adopted for WG Info Only
+
+ The "Adopted for WG Info Only" state describes a document that
+ contains useful information for the WG that adopted it, but the
+ document is not intended to be published as an RFC. The WG will not
+ actively develop the contents of the I-D or progress it for
+ publication as an RFC. The only purpose of the I-D is to provide
+ information for internal use by the WG.
+
+4.2.4. WG Document
+
+ The "WG Document" state describes an I-D that has been adopted by an
+ IETF WG and is being actively developed.
+
+ A WG Chair may transition an I-D into the "WG Document" state at any
+ time as long as the I-D is not being considered or developed in any
+ other WG.
+
+ Alternatively, WG Chairs may rely upon new functionality to be added
+ to the Datatracker to automatically move version-00 drafts into the
+ "WG Document" state as described in Section 4.1.
+
+ Under normal conditions, it should not be possible for an I-D to be
+ in the "WG Document" state in more than one WG at a time. This said,
+ I-Ds may be transferred from one WG to another with the consent of
+ the WG Chairs and the responsible ADs.
+
+4.2.5. Parked WG Document
+
+ A "Parked WG Document" is an I-D that has lost its author or editor,
+ is waiting for another document to be written or for a review to be
+ completed, or cannot be progressed by the working group for some
+ other reason.
+
+
+
+
+
+Juskevicius Informational [Page 13]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ Some of the annotation tags described in Section 4.3 may be used in
+ conjunction with this state to indicate why an I-D has been parked,
+ and/or what may need to happen for the I-D to be un-parked.
+
+ Parking a WG draft will not prevent it from expiring; however, this
+ state can be used to indicate why the I-D has stopped progressing in
+ the WG.
+
+ A "Parked WG Document" that is not expired may be transferred from
+ one WG to another with the consent of the WG Chairs and the
+ responsible ADs.
+
+4.2.6. Dead WG Document
+
+ A "Dead WG Document" is an I-D that has been abandoned. Note that
+ 'Dead' is not always a final state for a WG I-D. If consensus is
+ subsequently achieved, a "Dead WG Document" may be resurrected. A
+ "Dead WG Document" that is not resurrected will eventually expire.
+
+ Note that an I-D that is declared to be "Dead" in one WG and that is
+ not expired may be transferred to a non-dead state in another WG with
+ the consent of the WG Chairs and the responsible ADs.
+
+4.2.7. In WG Last Call
+
+ A document "In WG Last Call" is an I-D for which a WG Last Call
+ (WGLC) has been issued and is in progress.
+
+ Note that conducting a WGLC is an optional part of the IETF WG
+ process, per Section 7.4 of RFC 2418 [RFC2418].
+
+ If a WG Chair decides to conduct a WGLC on an I-D, the "In WG Last
+ Call" state can be used to track the progress of the WGLC. The Chair
+ may configure the Datatracker to send a WGLC message to one or more
+ mailing lists when the Chair moves the I-D into this state. The WG
+ Chair may also be able to select a different set of mailing lists for
+ a different document undergoing a WGLC; some documents may deserve
+ coordination with other WGs.
+
+ A WG I-D in this state should remain "In WG Last Call" until the WG
+ Chair moves it to another state. The WG Chair may configure the
+ Datatracker to send an e-mail after a specified period of time to
+ remind or 'nudge' the Chair to conclude the WGLC and to determine the
+ next state for the document.
+
+
+
+
+
+
+
+Juskevicius Informational [Page 14]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ It is possible for one WGLC to lead into another WGLC for the same
+ document. For example, an I-D that completed a WGLC as an
+ "Informational" document may need another WGLC if a decision is taken
+ to convert the I-D into a Standards Track document.
+
+4.2.8. Waiting for WG Chair Go-Ahead
+
+ A WG Chair may wish to place an I-D that receives a lot of comments
+ during a WGLC into the "Waiting for WG Chair Go-Ahead" state. This
+ state describes an I-D that has undergone a WGLC; however, the Chair
+ is not yet ready to call consensus on the document.
+
+ If comments from the WGLC need to be responded to, or a revision to
+ the I-D is needed, the Chair may place an I-D into this state until
+ all of the WGLC comments are adequately addressed and the (possibly
+ revised) document is in the I-D repository.
+
+4.2.9. WG Consensus: Waiting for Writeup
+
+ A document in the "WG Consensus: Waiting for Writeup" state has
+ essentially completed its development within the working group, and
+ is nearly ready to be sent to the IESG for publication. The last
+ thing to be done is the preparation of a protocol writeup by a
+ Document Shepherd. The IESG requires that a document shepherd
+ writeup be completed before publication of the I-D is requested. The
+ IETF document shepherding process and the role of a WG Document
+ Shepherd is described in RFC 4858 [RFC4858]
+
+ A WG Chair may call consensus on an I-D without a formal WGLC and
+ transition an I-D that was in the "WG Document" state directly into
+ this state.
+
+ The name of this state includes the words "Waiting for Writeup"
+ because a good document shepherd writeup takes time to prepare.
+
+4.2.10. Submitted to IESG for Publication
+
+ This state describes a WG document that has been submitted to the
+ IESG for publication and that has not been sent back to the working
+ group for revision.
+
+ An I-D in this state may be under review 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. Other possibilities exist too. The document
+ may be "Dead" (in the IESG state machine) or in a "Do Not Publish"
+ state.
+
+
+
+
+
+Juskevicius Informational [Page 15]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+4.3. Working Group I-D Status Annotation Tags
+
+ In addition to indicating which state a working group draft is in,
+ the Datatracker will allow several substate conditions to be
+ identified and tracked. This section defines annotation tags that
+ may be used to describe a condition that is affecting a WG I-D (e.g.,
+ why a document is in the state it is in) or to indicate an action
+ needed to progress the document.
+
+ Annotation tags do not change the WG I-D state of WG drafts.
+
+ Each of the annotation tags defined herein may be used to provide
+ more information about the status of any WG draft in any state, if it
+ makes sense to do so. Each annotation tag may be used by itself, or
+ in combination with other tags.
+
+4.3.1. Awaiting Expert Review/Resolution of Issues Raised
+
+ This tag means that someone (e.g., an author or editor of the WG
+ draft, or a WG Chair) has initiated an expert review of the document
+ and the review has not yet been completed and/or the resolution of
+ issues raised by the review has not yet been completed. Examples of
+ expert reviews include cross-area reviews, MIB Doctor reviews,
+ security expert reviews, and IANA reviews.
+
+ WG drafts tagged with this annotation should retain the tag until the
+ review is complete and possibly until any issues raised in the review
+ are addressed.
+
+4.3.2. Awaiting External Review/Resolution of Issues Raised
+
+ This tag means that someone (e.g., an author or editor of the WG
+ draft, 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), and the
+ review has not yet been completed and/or the resolution of issues
+ raised by the review has not yet been completed.
+
+ WG drafts tagged with this annotation should retain the tag until the
+ review is complete and possibly until any issues raised in the review
+ are addressed.
+
+4.3.3. Awaiting Merge with Other Document
+
+ This tag means a decision has been made by someone (e.g., the
+ document author, editor, or the WG Chair) to merge the I-D with one
+ or more other I-Ds from the same (or another) working group.
+
+
+
+
+Juskevicius Informational [Page 16]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ If the result of the merge is a new I-D having a different title,
+ then the old I-D may be declared as being a "Dead WG Document". In
+ such a case, the annotation tag should be changed from "Awaiting
+ Merge with Other Document" to "Other - see Comment Log" and a
+ description of the merge should be entered into the log for
+ posterity.
+
+ The Datatracker's regular 'Replaced by' information should also be
+ set for the old I-Ds to make it easier to find the new merged
+ document from the old documents.
+
+ If the result of the merge operation is a revision to the old I-D,
+ this annotation tag should be cleared when the revised (merged) I-D
+ is submitted to the WG.
+
+4.3.4. Author or Editor Needed
+
+ This tag means an I-D has lost a primary author or editor, and that
+ further work on the I-D cannot continue in an effective or efficient
+ manner until a new author or editor is found.
+
+ This tag should be removed after a new primary author or editor is
+ found.
+
+4.3.5. Waiting for Referenced Document
+
+ This tag means that completion of the I-D is on-hold because the
+ draft has a dependency on one or more other documents. A typical
+ example is where an I-D depends on another IETF document that has not
+ yet progressed to a point where it may be referenced; the dependency
+ may be on one or more documents in other IETF Working Groups or on
+ work in progress documents in other SDOs.
+
+ This tag should be removed after the dependency is cleared.
+
+4.3.6. Waiting for Referencing Document
+
+ This tag means that completion of the I-D is on-hold because one or
+ more other documents are dependent on it, and the WG Chair wants to
+ submit all of the documents to the IESG (for publication)
+ simultaneously. This tag is the inverse of 4.3.5.
+
+ This tag should be removed after the dependency is cleared.
+
+
+
+
+
+
+
+
+Juskevicius Informational [Page 17]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+4.3.7. Revised I-D Needed - Issue raised by WGLC
+
+ This annotation may be used to flag an I-D that needs to be revised
+ to address issues raised during a Working Group Last Call. This
+ annotation may also be used to indicate when the I-D is in the
+ process of being revised.
+
+ This tag should be removed after a revised version of the I-D is
+ submitted to the WG.
+
+4.3.8. Revised I-D Needed - Issue raised by AD
+
+ This annotation means the responsible AD raised one or more issues
+ with the I-D during "AD Evaluation" and that the AD has sent the
+ document back to the working group for revision. This annotation may
+ also be used to indicate when the I-D is in the process of being
+ revised.
+
+ This tag should be removed after the revised version of the I-D is
+ submitted to the WG.
+
+4.3.9. Revised I-D Needed - Issue raised by IESG
+
+ This annotation means that one or more IESG members had issues with
+ the I-D during "IESG Evaluation" and the document has been sent back
+ to the working group for revision. This annotation may also be used
+ to indicate that the revision to the I-D is in process.
+
+ This tag should be removed after the revised version of the I-D is
+ submitted to the WG.
+
+4.3.10. Doc Shepherd Followup Underway
+
+ This annotation tag may be used to indicate that the Document
+ Shepherd for the WG document has begun working on the writeup
+ required to submit the document (to the IESG) for publication.
+
+ It is possible that too many I-Ds may arrive in a shepherd's queue in
+ too short a time, and the shepherd cannot create satisfactory
+ writeups for all of the documents simultaneously.
+
+ When this annotation tag is set, it means the Document Shepherd has
+ started work on the writeup for the I-D. The absence or resetting of
+ this annotation tag for an I-D in the "WG Consensus: Waiting for
+ Writeup" state indicates the writeup has not yet been started, or has
+ been put on-hold for some reason.
+
+
+
+
+
+Juskevicius Informational [Page 18]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+4.3.11. 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, the Document
+ Shepherd) has entered one or more comments about the current status
+ of the I-D into the IETF Datatracker.
+
+5. Intended Maturity Level of WG Drafts
+
+ The IESG requires a WG I-D to have an "intended maturity level"
+ associated with it (e.g., Informational, Proposed Standard,
+ Experimental) before the I-D is submitted to the IESG for evaluation
+ and publication. This information is also often requested by IETF
+ participants.
+
+ I-D maturity levels were first defined in Sections 4 and 5 of RFC
+ 2026 [RFC2026]. The names of the maturity levels in use today are:
+
+ * "Experimental"
+ * "Informational"
+ * "Best Current Practice"
+ * "Proposed Standard"
+ * "Draft Standard"
+ * "Standard"
+ * "Historic"
+
+ The Datatracker may need to be enhanced to enable WG Chairs to input
+ and/or change the intended maturity level of a WG draft before the
+ I-D is sent to the IESG.
+
+6. Security Considerations
+
+ This document does not propose any new Internet mechanisms and has no
+ security implications for the Internet.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2418] Bradner, S., "IETF Working Group Guidelines and
+ Procedures", BCP 25, RFC 2418, September 1998.
+
+ [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The
+ RFC Series and RFC Editor", RFC 4844, July 2007.
+
+
+
+
+Juskevicius Informational [Page 19]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+7.2. Informative References
+
+ [AUTHGUIDE] Housley, R., Ed. (for the IESG), "Guidelines to Authors
+ of Internet-Drafts", December 7, 2010,
+ http://www.ietf.org/ietf/1id-guidelines.txt.
+
+ [IDTRACKER] "The IETF Datatracker tool", Web Application:
+ https://datatracker.ietf.org/, Version 3.12, February 2,
+ 2011.
+
+ [IESGIDSM] "Diagram of Main I-D States", Web Application:
+ https://datatracker.ietf.org/images/state_diagram.gif,
+ October 21, 2002.
+
+ [IESGSTAT] "Main I-D States", Web Application:
+ https://datatracker.ietf.org/idtracker/help/state/,
+ Version 3.12, February 2, 2011.
+
+ [PROTO] Levkowetz, H. and Mankin, A., "Requirements on I-D
+ Tracker Extensions for Working Group Chairs", Work in
+ Progress, February 2007.
+
+ [WGDTSPEC] Juskevicius, E., "Minutes of wgdtspec BOF", Proceedings
+ of IETF 77, March 26, 2010,
+ http://www.ietf.org/proceedings/10mar/minutes/wgdtspec
+
+8. Acknowledgments
+
+ The author would like to thank Henrik Levkowetz and Allison Mankin
+ for developing the original I-D [PROTO] that served as the starting
+ point for this document, and Alfred Hoenes for his many comments and
+ suggestions and for articulating the need for the "Adopted by a WG"
+ state.
+
+ The author would also like to thank Henrik Levkowetz, Russ Housley,
+ Paul Hoffman, John Klensin, Pasi Eronen, Robert Sparks, Spencer
+ Dawkins, Mary Barnes, Glenn Parsons, Marc Blanchet, Andy Malis, and
+ Joel Halpern for their comments and feedback along the way.
+
+ Finally, the author also wishes to thank the IETF WG Chairs, ADs and
+ other people who contributed their insights and suggestions in real-
+ time during the wgdtspec BOF at IETF 77, and Lars Eggert, Tim Polk,
+ Robert Sparks, Adrian Farrel and Alexey Melnikov for their comments,
+ suggestions and DISCUSS points on the penultimate draft version of
+ this document.
+
+ This document was initially prepared using 2-Word-v2.0.template.dot.
+
+
+
+
+Juskevicius Informational [Page 20]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+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. All of the terms and definitions in Sections A.1 and
+ A.2 are copied from [IESGSTAT].
+
+ It must be noted that I-Ds sent to the IESG for publication (termed
+ "IESG Documents" in this Appendix) do not stay with the IESG until
+ the day they are published as RFCs. After evaluation, the IESG may
+ declare that some I-Ds deserve a "Do Not Publish" label. Other I-Ds
+ may become "Dead". Some I-Ds may get sent back to their originators
+ (WGs or otherwise), and the rest may go into the RFC Editor queue.
+
+ Note that documents that are not tracked by the IESG (e.g., I-Ds for
+ which no request has been made of the IESG) are in a null state with
+ respect to the IESG state machine. The IESG state of an I-D that has
+ no value assigned to the IESG state variable in the Datatracker's
+ database is 'NULL'.
+
+A.1. Definition of "IESG Document" States
+
+A.1.1. 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, or from an individual. Note: the
+ Secretariat (iesg-secretary@ietf.org) is typically 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 nor has any official action been taken yet, other than to
+ note that its publication has been requested.
+
+A.1.2. AD Evaluation
+
+ A specific AD (e.g., the "Area Advisor" for the WG) has begun their
+ 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.3. 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 "MIB doctors". Other types of
+ reviews may also be requested (e.g., security, operations impacts,
+
+
+
+
+Juskevicius Informational [Page 21]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ etc.) Documents stay in this state until the review is complete 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.4. 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.5. 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.6. 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.7. 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
+ ready for consideration by the IESG as a whole.
+
+A.1.8. 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
+ content or process issues they may have. Unresolvable issues are
+ documented as "DISCUSS" comments that can be forwarded to the
+ authors/WG. See the description of IESG substates in Section A.2 for
+ additional details about the current state of the IESG discussion.
+
+
+
+
+
+
+
+
+Juskevicius Informational [Page 22]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+A.1.9. IESG Evaluation - Defer
+
+ During a telechat, one or more ADs requested an additional two 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.10. Approved - announcement to be sent
+
+ The IESG has approved the document for publication, but the
+ Secretariat has not (yet) sent an official approval message.
+
+A.1.11. 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.12. RFC Ed Queue
+
+ The document is in the RFC editor Queue (as confirmed by
+ http://www.rfc-editor.org/queue2.html)
+
+A.1.13. RFC Published
+
+ The I-D has been published as an RFC.
+
+A.1.14. DNP - waiting for AD note
+
+ Do Not Publish (DNP): 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. See the "note" field for more details on who
+ has the action item.
+
+A.1.15. DNP - announcement to be sent
+
+ The IESG recommends against publishing the document. The 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.16. AD is watching
+
+ An AD is aware of the document and has chosen to place the document
+ in a separate state in order to monitor it (for whatever reason).
+ Documents in this state are not actively tracked by the IESG in the
+ sense that no formal request has been made to publish or advance the
+
+
+
+Juskevicius Informational [Page 23]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ document. The AD has chosen to put the I-D into this state, to make
+ it easier to keep track of (for his or her own reasons).
+
+A.1.17. 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
+
+ Note that the annotation tags described in this section were defined
+ circa 2002. If these conditions were modelled today, they would most
+ likely be modelled as annotation tags rather than as 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" substate
+ until *ALL* IESG blocking 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 the 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 it to bring to the attention of the
+ authors/WG.
+
+
+
+
+
+
+Juskevicius Informational [Page 24]
+
+RFC 6174 IETF Working Group Document States March 2011
+
+
+ - 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.
+
+ - 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 ID 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 Informational [Page 25]
+