draft-ietf-proto-wgchair-tracker-ext-00.txt		draft-ietf-proto-wgchair-tracker-ext-01.txt
	Proto H. Levkowetz		Proto H. Levkowetz
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Expires: November 11, 2006 A. Mankin		Intended status: Standards Track A. Mankin
	May 10, 2006		Expires: July 10, 2007 January 6, 2007
	Requirements on I-D Tracker Extensions for Working Group Chairs		Requirements on I-D Tracker Extensions for Working Group Chairs
	draft-ietf-proto-wgchair-tracker-ext-00		draft-ietf-proto-wgchair-tracker-ext-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 11, 2006.		This Internet-Draft will expire on July 10, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes the changes required to make it possible for		This document describes the changes required to make it possible for
	working group chairs to update the I-D tracker during document		working group chairs to update the I-D tracker during document
	shepherding, after the request for publication. It also describes		shepherding, after the request for publication. It also describes
	additional requirements for the chairs to use the I-D tracker for		additional requirements for the chairs to use the I-D tracker for
	managing WG documents from their earliest stages. Having the tracker		managing WG documents from their earliest stages. Having the tracker
	support the working groups more fully is a primary benefit, but in		support the working groups more fully is a primary benefit, but in
	addition, this moves towards the goal of providing an integrated view		addition, this moves towards the goal of providing an integrated view
	skipping to change at page 2, line 22		skipping to change at page 2, line 22
	tracker. In order to take over the full duties of shepherding,		tracker. In order to take over the full duties of shepherding,
	sufficient write access has to be provided also for working group		sufficient write access has to be provided also for working group
	chairs.		chairs.
	Another deficiency of the current I-D tracker is that although it		Another deficiency of the current I-D tracker is that although it
	accurately reflects document states from the time publication has		accurately reflects document states from the time publication has
	been requested for a document, there is no state information		been requested for a document, there is no state information
	available for documents which have been adopted as working group		available for documents which have been adopted as working group
	documents, but not yet submitted for publication. In order to make		documents, but not yet submitted for publication. In order to make
	it possible for the tracker to reflect this information, new states		it possible for the tracker to reflect this information, new states
	and sub-states are necessary, in addition to the ability for working		and annotation possibilities are necessary, in addition to the
	group chairs to change document state in the tracker.		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		The need for new states also exist for documents which go through a
	different publication process than that used for documents approved		different publication process than that used for documents approved
	by the IESG, such as IAB and IRTF documents. In order to do the		by the IESG, such as IAB and IRTF documents. In order to do the
	necessary updates for such documents, write access to the tracker		necessary updates for such documents, write access to the tracker
	also needs to be provided to IAB and IRTF people. This is however		also needs to be provided to IAB and IRTF people. Specification of
	left out of this document at this time.		additional states for IAB and IRTF documents is left out of this
			document, and instead specified in
			draft-ietf-proto-iab-irtf-tracker-ext.
	1.1. Terminology		1.1. Terminology
	In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
	of the specification. These words are often capitalised. The key		of the specification. These words are often capitalised. The key
	words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
	"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document		"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
	are to be interpreted as described in [RFC2119].		are to be interpreted as described in [RFC2119].
	The requirements in this document are specified using a set of		The requirements in this document are specified using a set of
	requirements. These requirements are English phrases ending with an		requirements. These requirements are English phrases ending with an
	"(R-nnn)" indication, where "nnn" is a unique requirement number.		"(R-nnn)" indication, where "nnn" is a unique requirement number.
	2. I-D Tracker Write Access		2. I-D Tracker Write Access
	Providing write access for working group chairs and other non-IESG		Providing write access for working group chairs and other non-IESG
	people to the tracker requires:		people to the tracker requires:
	* Having a 'groups' attribute associated with each user. This		o Having a 'groups' attribute associated with each user. This
	attribute should contain a list of groups of which the user is a		attribute should contain a list of groups of which the user is a
	member (R-001).		member (R-001).
	* Identification of the actions and information which may not be		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		accessed by all users (R-002). Such actions and information will
	be called 'restricted features' in the following. Some known		be called 'restricted features' in the following. Some known
	restricted features are:		restricted features are:
	- Requesting IETF last call		* Requesting IETF last call
	- Setting Document Approved states		* Setting Document Approved states
	- Access to the tool which places documents on the IESG Agenda		* Access to the tool which places documents on the IESG Agenda
	* Addition of checks for appropriate group membership in the tracker		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		code before the code provides access to restricted features
	(R-003).		(R-003).
	* Assignment of appropriate group memberships to existing users		o Assignment of appropriate group memberships to existing users
	(R-004).		(R-004).
	* Establishment of new users, with appropriate group memberships and		o Establishment of new users, with appropriate group memberships and
	passwords (R-005).		passwords (R-005).
	3. New Document States		3. New Document States
	In order to be able to provide appropriate document state indications		In order to be able to provide appropriate document state indications
	for documents which are working group documents, and have not yet		for documents which are working group documents, and have not yet
	been submitted for publication as RFC, additional states are needed		been submitted for publication as RFC, one additional state variable
	in the tracker. These are described in the following sections.		(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 States		3.1. WG Document States
	The following states and sub-states should be added to the tracker,		A new state variable or field should be added to the tracker. This
	for use when a document has been adopted as a WG document, but not		field will track the working group state of the document, and will be
	yet submitted for publication as an RFC.		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		* Candidate WG Document
	This document is under consideration for becoming a working group		This document is under consideration for becoming a working group
	document.		document.
	Possible next states: "Active WG Document", "I-D Exists", "Dead"
	Permitted sub-states:
	(R-009)		(R-009)
	* Active WG Document		* Active WG Document
	This document has been adopted by a working group, and is being		This document has been adopted by a working group, and is being
	actively developed.		actively developed.
	Possible next states: "Parked WG Document", "WG Document Awaiting
	Reviews", "Dead"
	Permitted sub-states:
	(R-006)		(R-006)
	* Parked WG Document		* Parked WG Document
	This document has lost its author or editor, is waiting for		This document has lost its author or editor, is waiting for
	another document to be written, or cannot currently be worked on		another document to be written, or cannot currently be worked on
	by the working group for some other reason.		by the working group for some other reason.
			(R-007)
	Possible next states: "Active WG Document", "Dead"		* In WG Last Call
			A working group last call has been issued for this document.
			(R-008)
	Permitted sub-states: "Need Editor", "Held for a Dependency		* Not a WG Document
	Document", "Other Problem - see comment log", "WG Document		This document is not a WG document.
	Awaiting Reviews"		(R-014)
	(R-007)
	* WG Document Awaiting Reviews		3.2. WG State Annotation Tags
	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",		The use of a separate tagging or annotation field makes it possible
	"Publication Requested", "In WG Last Call", "Dead"		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).
	Permitted sub-states: "0 reviews", "1 reviews", "2 reviews", "3		These annotation tags are similar to the existing sub-states of the
	reviews", "4 reviews", "5 reviews", "Awaiting MIB Doctor Review",		IESG state, but may be a more appropriate mechanism to show
	*** More special review states ***		additional information which is not directly related to the document
	(R-008)		state.
	* In WG Last Call		Defined WG state annotation tags (R-013):
	A working group last call has been issued for this document.
	Possible next states: "Active WG Document", "Parked WG Document",		o "Editor Needed"
	"WG Document Awaiting Reviews", "Revised ID Needed", "Publication
	Requested", "Dead"
	Permitted sub-states: "1st", "2nd", "3rd", "4th", "5th", "6th",		o "Held for Dependency on other Document"
	"7th", "8th", "9th".
	(R-008)
	3.2. Document States for External Bodies		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		It would be highly desirable to have document states also for RFC
	editor queue states and IANA queue states. These could be		editor queue states and IANA queue states. These could be
	automatically set through interaction with RFC Editor and IANA		automatically set through interaction with RFC Editor and IANA
	support tools, or could be fetched from the RFC Editor state		support tools, or could be fetched from the RFC Editor state
	information (now available in XML format) and IANA state information		information (now available in XML format) and IANA state information
	when available. That work is however out of scope for this document,		when available. That work is however out of scope for this document,
	but will be considered as part of future tracker enhancements.		but will be considered as part of future tracker enhancements.
	4. Handling of Sub-states		4. Modification of Existing 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		One existing sub-state in the tracker should be modified to reflect
	the role of the WG document shepherds.		the role of the WG document shepherds.
	The sub-state "AD Followup" is defined as generic and may be used for		The IESG sub-state "AD Followup" is defined as generic and may be
	many purposes by an Area Director. However, the tracker		used for many purposes by an Area Director. However, the tracker
	automatically assigns this sub-state when a document which has been		automatically assigns this sub-state when a document which has been
	in the "Revised ID Needed" sub-state is updated. The "AD Followup"		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		sub-state shall continue to exist for the first purpose, but when a
	document is in "IESG Evaluation - Revised ID Needed" and an update		working group document is in "IESG Evaluation - Revised ID Needed"
	arrives, it shall receive an automatic state change to a new sub-		and an update arrives, it shall receive an automatic state change to
	state instead: "Doc Shepherd Followup" (R-022).		a new sub-state instead: "Doc Shepherd Followup" (R-022). Non-WG
			documents continue to change state to "AD Followup" as before.
	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		5. IANA Considerations
	This document does not require any new number assignments from IANA,		This document does not require any new number assignments from IANA,
	and does not define any new numbering spaces to be administered by		and does not define any new numbering spaces to be administered by
	IANA.		IANA.
	RFC-Editor: Please remove this section before publication.		RFC-Editor: Please remove this section before publication.
	7. Security Considerations		6. Security Considerations
	This document does not propose any new internet mechanisms, and has		This document does not propose any new internet mechanisms, and has
	no security implications for the internet.		no security implications for the internet.
	However, security of tracker access and security of private tracker		However, security of tracker access and security of private tracker
	comments need to be safeguarded, which requires care in handling,		comments need to be safeguarded, which requires care in handling,
	assignment and re-assignment of passwords. Auto-generated passwords		assignment and re-assignment of passwords. Auto-generated passwords
	MUST be generated with adequate strength, and if it is possible for		MUST be generated with adequate strength, and if it is possible for
	users to change their passwords, strength assessment of the new		users to change their passwords, strength assessment of the new
	password SHOULD be provided.		password SHOULD be provided.
	The mechanism to limit access to private comments and restricted		The mechanism to limit access to private comments and restricted
	actions MUST be tested and verified as functional after all the		actions MUST be tested and verified as functional after all the
	changes have been coded which are needed to implement the		changes have been coded which are needed to implement the
	functionality described in this document, and before the changes are		functionality described in this document, and before the changes are
	made available to the new set of users.		made available to the new set of users.
	8. Normative References		7. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	Authors' Addresses		Authors' Addresses
	Henrik Levkowetz		Henrik Levkowetz
	Ericsson		Ericsson
	Torsgatan 71		Torsgatan 71
	Stockholm		Stockholm
	SWEDEN		SWEDEN
	Phone: +46 708 32 16 08		Phone: +46 708 32 16 08
	Email: henrik@levkowetz.com		Email: henrik@levkowetz.com
	Allison Mankin		Allison Mankin
	Phone: +1 301 728 7199		Phone: +1 301 728 7199
	Email: mankin@psg.com		Email: mankin@psg.com
	Intellectual Property Statement		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		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 8, line 29		skipping to change at page 8, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		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		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 37 change blocks.
	100 lines changed or deleted		119 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/