Proto                                                       H. Levkowetz
Internet-Draft                                                  Ericsson
Expires: November 11, 2006                                     A. Mankin
                                                            May 10, 2006

    Requirements on I-D Tracker Extensions for Working Group Chairs

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 11, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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 November 11, 2006               [Page 1]

Internet-Draft        WG Chair Tracker Requirements             May 2006

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

   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 sub-states 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.  This is however
   left out of this document at this time.

1.1.  Terminology

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalised.  The key
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

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

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

Levkowetz & Mankin      Expires November 11, 2006               [Page 2]

Internet-Draft        WG Chair Tracker Requirements             May 2006

   *  Identification of the actions and information which may not be
      accessed by all users (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

   *  Addition of checks for appropriate group membership in the tracker
      code before the code provides access to restricted features

   *  Assignment of appropriate group memberships to existing users

   *  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, additional states are needed
   in the tracker.  These are described in the following sections.

3.1.  WG Document States

   The following states and sub-states should be added to the tracker,
   for use when a document has been adopted as a WG document, but not
   yet submitted for publication as an RFC.

   *  Candidate WG Document
      This document is under consideration for becoming a working group

      Possible next states: "Active WG Document", "I-D Exists", "Dead"

      Permitted sub-states:

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

Levkowetz & Mankin      Expires November 11, 2006               [Page 3]

Internet-Draft        WG Chair Tracker Requirements             May 2006

      Possible next states: "Parked WG Document", "WG Document Awaiting
      Reviews", "Dead"

      Permitted sub-states:

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

      Possible next states: "Active WG Document", "Dead"

      Permitted sub-states: "Need Editor", "Held for a Dependency
      Document", "Other Problem - see comment log", "WG Document
      Awaiting Reviews"

   *  WG Document Awaiting Reviews
      This document needs reviews (possibly a certain number of reviews,
      at a minimum) before a WG last call will be done.

      Possible next states: "Active WG Document", "Parked WG Document",
      "Publication Requested", "In WG Last Call", "Dead"

      Permitted sub-states: "0 reviews", "1 reviews", "2 reviews", "3
      reviews", "4 reviews", "5 reviews", "Awaiting MIB Doctor Review",
      *** More special review states ***

   *  In WG Last Call
      A working group last call has been issued for this document.

      Possible next states: "Active WG Document", "Parked WG Document",
      "WG Document Awaiting Reviews", "Revised ID Needed", "Publication
      Requested", "Dead"

      Permitted sub-states: "1st", "2nd", "3rd", "4th", "5th", "6th",
      "7th", "8th", "9th".

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

Levkowetz & Mankin      Expires November 11, 2006               [Page 4]

Internet-Draft        WG Chair Tracker Requirements             May 2006

   when available.  That work is however out of scope for this document,
   but will be considered as part of future tracker enhancements.

4.  Handling of Substates

   Currently, in the I-D tracker, it is possible to combine any defined
   sub-state with any primary state.  This can through user mistakes
   result in very strange combinations of states and sub-states.  For
   this reason, it is RECOMMENDED that the following changes are made to
   the tracker code:

   *  In the user interface, whenever a major state is changed, the sub-
      state form-field should be cleared (R-020).

   *  In the user interface, whenever a primary state is set, the
      selection list of available sub-states should be updated to show
      only the permitted sub-states for the new primary state (R-021).

5.  Modification of Existing States

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

   The 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
   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).

   This new state, "Doc Shepherd Followup" should also be automatically
   assigned by the tracker when a document is updated when it is in the
   state "In WG Last Call - Revised ID Needed" (which the shepherd may
   or may not choose to use in his/her WG) (R-023).

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

   RFC-Editor: Please remove this section before publication.

Levkowetz & Mankin      Expires November 11, 2006               [Page 5]

Internet-Draft        WG Chair Tracker Requirements             May 2006

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

8.  Normative References

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

Levkowetz & Mankin      Expires November 11, 2006               [Page 6]

Internet-Draft        WG Chair Tracker Requirements             May 2006

Authors' Addresses

   Henrik Levkowetz
   Torsgatan 71

   Phone: +46 708 32 16 08

   Allison Mankin

   Phone: +1 301 728 7199

Levkowetz & Mankin      Expires November 11, 2006               [Page 7]

Internet-Draft        WG Chair Tracker Requirements             May 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Levkowetz & Mankin      Expires November 11, 2006               [Page 8]