Proto H. Levkowetz Internet-Draft EricssonExpires: November 11, 2006Intended status: Standards Track A. MankinMayExpires: July 10,20062007 January 6, 2007 Requirements on I-D Tracker Extensions for Working Group Chairsdraft-ietf-proto-wgchair-tracker-ext-00draft-ietf-proto-wgchair-tracker-ext-01 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 onNovember 11, 2006.July 10, 2007. Copyright Notice Copyright (C) TheInternet Society (2006).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. 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 andsub-statesannotation 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.ThisSpecification of additional states for IAB and IRTF documents ishoweverleft out of thisdocument at this time.document, and instead specified in draft-ietf-proto-iab-irtf-tracker-ext. 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 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:*o 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).*o For the mentioned group attribute, there should at least be values defined corresponding to 'ADs', 'Chairs', 'IAB' and 'IRTF', permitting per-group access control of actions and features with this granularity (R-011). o 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*o An additional state table for WG state, and an additional table for WG state annotation tags (R-010). o Addition of checks for appropriate group membership in the tracker code before the code provides access to restricted features (R-003).*o Assignment of appropriate group memberships to existing users (R-004).*o 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 additionalstates arestate variable (see Section 3.1), and one additional tagging field (see Section 3.2 is needed in the tracker. These are described in the following sections. 3.1. WG Document StatesThe following states and sub-statesA new state variable or field should be added to thetracker, for use whentracker. 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 WGdocument,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, butnot yet submittedis then sent back to the WG forpublication as an RFC.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.Possible next states: "Active WG Document", "I-D Exists", "Dead" Permitted sub-states:(R-009) * Active WG Document This document has been adopted by a working group, and is being actively developed.Possible next states: "Parked WG Document", "WG Document Awaiting Reviews", "Dead" Permitted sub-states:(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.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"(R-007) *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 *** (R-008) *In WG Last Call A working group last call has been issued for this document.Possible next states: "Active WG Document", "Parked(R-008) * Not a WGDocument", "WGDocumentAwaiting Reviews", "Revised ID Needed", "Publication Requested", "Dead" Permitted sub-states: "1st", "2nd", "3rd", "4th", "5th", "6th", "7th", "8th", "9th". (R-008)This document is not a WG document. (R-014) 3.2.Document States for External Bodies It would be highly desirableWG State Annotation Tags The use of a separate tagging or annotation field makes it possible tohave document states alsocapture a number of specific conditions forRFC editor queue states and IANA queue states.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. Defined WG state annotation tags (R-013): o "Editor Needed" o "Held for Dependency on other Document" o "Other - see Comment Log" o "Awaiting MIB Doctor Review" o "Awaiting Cross-Area Review" o "Awaiting Security Review" o "Awaiting Other Reviews" o "Revised ID Needed" o "Doc Shepherd Followup" 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. This is analogous to the automatic transition described below in Section 4. (R-023). The annotation tag "Revised ID Needed" should be automatically cleared when a new revision of a document is made available (R-024). 3.3. 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.Handling of Sub-states 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 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). 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 chooseand an update arrives, it shall receive an automatic state change touse in his/her WG) (R-023). 6.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.7.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.8.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 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 PropertyStatementThe 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.Disclaimer of Validity 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 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. 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.Acknowledgement Funding for the RFC Editor function iscurrentlyprovided by theInternet Society.IETF Administrative Support Activity (IASA).