[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-proto-wgdocument-states

Proto                                                       H. Levkowetz
Internet-Draft                                                  Ericsson
Intended status: Informational                                 A. Mankin
Expires: August 12, 2007                                February 8, 2007


    Requirements on I-D Tracker Extensions for Working Group Chairs
                draft-ietf-proto-wgchair-tracker-ext-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 August 12, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes the changes required to make it possible for
   working group chairs to update the I-D tracker during document
   shepherding, after the request for publication.  It also describes
   additional requirements for the chairs to use the I-D tracker for
   managing WG documents from their earliest stages.  Having the tracker
   support the working groups more fully is a primary benefit, but in
   addition, this moves towards the goal of providing an integrated view
   of document states from -00 to RFC publication.



Levkowetz & Mankin       Expires August 12, 2007                [Page 1]

Internet-Draft        WG Chair Tracker Requirements        February 2007


1.  Introduction

   In order to make it possible for working group chairs acting as
   document shepherds to do the full duties of shepherding it is
   necessary for them to be able to enter document state changes and
   issue resolutions into the I-D tracker.  However, at the time of
   writing, only area directors have the necessary write access to the
   tracker.  In order to take over the full duties of shepherding,
   sufficient write access has to be provided also for working group
   chairs.

   Another deficiency of the current I-D tracker is that although it
   accurately reflects document states from the time publication has
   been requested for a document, there is no state information
   available for documents which have been adopted as working group
   documents, but not yet submitted for publication.  In order to make
   it possible for the tracker to reflect this information, new states
   and annotation possibilities are necessary, in addition to the
   ability for working group chairs to change document state in the
   tracker.

   The need for new states also exist for documents which go through a
   different publication process than that used for documents approved
   by the IESG, such as IAB and IRTF documents.  In order to do the
   necessary updates for such documents, write access to the tracker
   also needs to be provided to IAB and IRTF people.  Specification of
   additional states for IAB and IRTF documents is left out of this
   document, and instead specified in
   draft-ietf-proto-iab-irtf-tracker-ext.

   Note that although the proposed changes introduce write access to the
   tracker for groups of IETF participants which does not currently have
   write access, such as working group chairs, they does not introduce
   general write access to the tracker for everybody.

1.1.  Terminology

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalised.  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 [RFC2119].

   The requirements in this document are specified as English phrases
   ending with an "(R-nnn)" indication, where "nnn" is a unique
   requirement number.





Levkowetz & Mankin       Expires August 12, 2007                [Page 2]

Internet-Draft        WG Chair Tracker Requirements        February 2007


2.  I-D Tracker Write Access

   Providing write access for working group chairs and other non-IESG
   people to the tracker requires:

   *  Having a 'groups' attribute associated with each user.  This
      attribute should contain a list of groups of which the user is a
      member (R-001).

   *  For the mentioned group attribute, there should at least be values
      defined corresponding to 'AD', 'Chair', 'Shepherd', 'IAB' and
      'IRTF', permitting per-group access control of actions and
      features with this granularity (R-011).

   *  Identification of the actions and information which may require
      verification of the user's access rights (R-002).  Such actions
      and information will be called 'restricted features' in the
      following.  Some known restricted features are:

      -  Requesting IETF last call
      -  Setting Document Approved states
      -  Access to the tool which places documents on the IESG Agenda

      Access to the document comment log is not a restricted feature.

   *  An additional state table for WG state (Section 3.1), and
      additional tables for WG state annotation tags (Section 3.2),
      planned next state, and date of next state (Section 3.3) (R-010).

   *  Addition of checks for appropriate group membership in the tracker
      code before the code provides access to restricted features
      (R-003).

   *  Assignment of appropriate group memberships to existing users
      (R-004).

   *  Establishment of new users, with appropriate group memberships and
      passwords (R-005).


3.  New Document States

   In order to be able to provide appropriate document state indications
   for documents which are working group documents, and have not yet
   been submitted for publication as RFC, one additional state variable
   (see Section 3.1), and two additional fields (see Section 3.2 and
   Section 3.4) is needed in the tracker.  These are described in the
   following sections.



Levkowetz & Mankin       Expires August 12, 2007                [Page 3]

Internet-Draft        WG Chair Tracker Requirements        February 2007


3.1.  WG Document States

   A new state variable or field to hold WG Document states will be
   added to the tracker.  This field will track the working group state
   of the document, and will be updated by the working group chairs once
   a document has been adopted as a WG document.

   The reason why this is a different field rather than the existing
   IESG state field is that there are cases where a document has been
   passed to the IESG, and has reached a certain point in the IESG's
   handling, but is then sent back to the WG for a brief time.  It is
   beneficial to be able to keep the IESG state visible, rather than
   have it overwritten by the WG state.

   Defined WG States:

   *  Candidate WG Document
      This document is under consideration for becoming a working group
      document.  A document being in this state does not imply any
      consensus, and does not imply any precedence or selection.  It's
      simply a way to indicate that somebody has asked for a document to
      be considered for adoption.
      (R-009)

   *  Active WG Document
      This document has been adopted by a working group, and is being
      actively developed.
      (R-006)

   *  Parked WG Document
      This document has lost its author or editor, is waiting for
      another document to be written, or cannot currently be worked on
      by the working group for some other reason.
      (R-007)

   *  In WG Last Call
      A working group last call has been issued for this document, and
      is in progress.  When the last call has completed, a document
      would normally enter either the "Active WG Document" or the
      "Waiting for Document Shepherd Write-up" state, depending on the
      nature of the WG Last Call comments received.  In both cases, an
      annotation of "Revised ID Needed" might also be appropriate, based
      on the comments received.
      (R-008)







Levkowetz & Mankin       Expires August 12, 2007                [Page 4]

Internet-Draft        WG Chair Tracker Requirements        February 2007


   *  Waiting for Document Shepherd Writeup
      The Working group last call has been completed, and the document
      is waiting for the Document Shepherd to complete his write-up.
      (R-030)

      The naming of this state is very close to one of the current IESG
      states, "Waiting for Document Writeup".  This IESG state should be
      renamed to "Waiting for Area Director Writeup" for clarity
      (R-031).

   *  Submitted WG Document
      The document has been submitted to the IESG for publication (and
      not returned to the WG for further action).  The document may be
      under consideration by the IESG, it may have been approved and in
      the RFC Editor's queue, or it may have been published as an RFC;
      this state doesn't distinguish between different states occurring
      after the document has left the working group.
      (R-008)

   *  Dead WG Document
      This document has been a WG document, but has been killed or
      abandoned.  This does not have to be a final state; if there is
      consensus in the workgroup, a Dead document can be resurrected.
      (R-025)

   *  Not a WG Document
      This document is not a WG document.  This means that the IESG
      state for the document is either "I-D Exists" or "AD is watching".
      The document may have various other states set, such as various
      IAB or IRTF document states; but if so it is not reflected in the
      WG document state which simply will indicate "Not a WG Document".
      (R-014)

3.2.  WG State Annotation Tags

   The use of a separate tagging or annotation field makes it possible
   to capture a number of specific conditions for a draft, where these
   conditions can exist in parallel.  These conditions also does not
   really change the WG state of the document, but are still useful to
   show for instance what action is needed next for the document.  The
   tracker should provide a means to set one or more of these annotation
   tags for a document, for instance by use of a multiple-choice
   selection box in a web interface (R-012).

   These annotation tags are similar to the existing sub-states of the
   IESG state, but may be a more appropriate mechanism to show
   additional information which is not directly related to the document
   state.



Levkowetz & Mankin       Expires August 12, 2007                [Page 5]

Internet-Draft        WG Chair Tracker Requirements        February 2007


   Defined WG state annotation tags (R-013):

   *  "Editor Needed"
   *  "Held for Dependency on other Document"
   *  "Awaiting MIB Doctor Review"
   *  "Awaiting Cross-Area Review"
   *  "Awaiting Security Review"
   *  "Awaiting Other Reviews"
   *  "Revised ID Needed"
   *  "Doc Shepherd Followup"
   *  "Other - see Comment Log"

   When a document is in the WG state "In WG Last Call" with the
   annotation "Revised ID Needed", the WG annotation tag "Doc Shepherd
   Followup" should be automatically assigned by the tracker when the
   document is updated (R-023).  This is analogous to the automatic
   transition described below in Section 4.

   The annotation tag "Revised ID Needed" should be automatically
   cleared when a new revision of a document is made available (R-024).

3.3.  Next WG Document State Field

   As part of the WG status handling, a field should be available to
   indicate the next planned state of a draft, and the planned date for
   that state.  The Next WG Document State field has the same possible
   values as the WG Document State (Section 3.1) field (R-027).

   The Next Doc-State Date field is not a free-text field, but uses a
   well-known date representation form (R-028).  (Example:
   "2007-01-19".)  Any web-page providing input to this field should
   accept input in the form of a number of days and / or a pull-down
   list with a number of choices such as for instance "1 Day", "2 Days",
   ... "1 Week", "2 Weeks", ... "1 Month", "2 Months" etc.  (R-029).
   This information is then converted to the chosen date format and
   stored.  The Next Doc-State Date field may also be left blank.

3.4.  Intended Status Field

   As part of the WG status handling, a field should be available to
   indicate the intended status of a draft, with the possible values
   being (R-026):

   *  "Informational"
   *  "Experimental"
   *  "Best Current Practice"





Levkowetz & Mankin       Expires August 12, 2007                [Page 6]

Internet-Draft        WG Chair Tracker Requirements        February 2007


   *  "Proposed Standard"
   *  "Draft Standard"
   *  "Full Standard"
   *  "Historic"

   When possible (for instance, when a draft is submitted through
   automated mechanisms, and contains a line in the first page document
   header which indicates the intended status, such as for instance
   "Intended status: Informational") this field should be automatically
   set by the submission tool.

3.5.  Document States for External Bodies

   It would be highly desirable to have document states also for RFC
   editor queue states and IANA queue states.  These could be
   automatically set through interaction with RFC Editor and IANA
   support tools, or could be fetched from the RFC Editor state
   information (now available in XML format) and IANA state information
   when available.  That work is however out of scope for this document,
   but will be considered as part of future tracker enhancements.


4.  Modification of Existing Fields

   One existing sub-state in the tracker should be modified to reflect
   the role of the WG document shepherds.

   The IESG sub-state "AD Followup" is defined as generic and may be
   used for many purposes by an Area Director.  However, the tracker
   automatically assigns this sub-state when a document which has been
   in the "Revised ID Needed" sub-state is updated.  The "AD Followup"
   sub-state shall continue to exist for the first purpose, but when a
   working group document is in "IESG Evaluation - Revised ID Needed"
   and an update arrives, it shall receive an automatic state change to
   a new sub-state instead: "Doc Shepherd Followup" (R-022).  Non-WG
   documents continue to change state to "AD Followup" as before.


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.






Levkowetz & Mankin       Expires August 12, 2007                [Page 7]

Internet-Draft        WG Chair Tracker Requirements        February 2007


6.  Security Considerations

   This document does not propose any new internet mechanisms, and has
   no security implications for the internet.

   However, security of tracker access and security of private tracker
   comments need to be safeguarded, which requires care in handling,
   assignment and re-assignment of passwords.  Auto-generated passwords
   MUST be generated with adequate strength, and if it is possible for
   users to change their passwords, strength assessment of the new
   password SHOULD be provided.

   The mechanism to limit access to private comments and restricted
   actions MUST be tested and verified as functional after all the
   changes have been coded which are needed to implement the
   functionality described in this document, and before the changes are
   made available to the new set of users.


7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


Authors' Addresses

   Henrik Levkowetz
   Ericsson
   Torsgatan 71
   Stockholm
   SWEDEN

   Phone: +46 708 32 16 08
   Email: henrik@levkowetz.com


   Allison Mankin

   Phone: +1 301 728 7199
   Email: mankin@psg.com










Levkowetz & Mankin       Expires August 12, 2007                [Page 8]

Internet-Draft        WG Chair Tracker Requirements        February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Levkowetz & Mankin       Expires August 12, 2007                [Page 9]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/