From proto-team-bounces@ietf.org Wed Jan 03 16:08:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DLE-0001fJ-9J; Wed, 03 Jan 2007 16:08:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2DLC-0001f9-Ci for proto-team@ietf.org; Wed, 03 Jan 2007 16:08:06 -0500 Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2DLB-0008Mz-7H for proto-team@ietf.org; Wed, 03 Jan 2007 16:08:06 -0500 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id C2A573835D; Wed, 3 Jan 2007 22:07:39 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8D11537F46; Wed, 3 Jan 2007 22:07:39 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 9A82837E47; Wed, 3 Jan 2007 22:08:01 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H2DKp-0001uJ-O3; Wed, 03 Jan 2007 22:07:43 +0100 Message-ID: <459C1B21.50207@levkowetz.com> Date: Wed, 03 Jan 2007 22:07:45 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Brian E Carpenter , Margaret Wasserman X-Enigmail-Version: 0.94.1.2 Content-Type: multipart/mixed; boundary="------------000006070501000204020108" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brc@zurich.ibm.com, margaret@thingmagic.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 1.2 (+) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Cc: proto-team@ietf.org Subject: [proto-team] draft-ietf-proto-wgchair-tracker-ext X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org This is a multi-part message in MIME format. --------------000006070501000204020108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Here's an updated version of the wgchair tracker document. I've read through it again, to see if there are things I'd like to tweak, but there are virtually no changes compared with the -01.g version I sent out between Montreal and San Diego. I've added a "Not a WG document" state to the WG states to make the set complete, and the date and boilerplate has been updated. If there are no comments on this, I plan to submit it tomorrow (in about 24 hours, that is). Regards, Henrik --------------000006070501000204020108 Content-Type: text/plain; charset=ISO-8859-1; name*0="shiraz/ietf/draft/proto/wgchair-tracker-ext/draft-ietf-proto-wgc"; name*1="hair-tracker-ext-01.g.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="shiraz/ietf/draft/proto/wgchair-tracker-ext/draft-ietf-proto"; filename*1="-wgchair-tracker-ext-01.g.txt" Proto H. Levkowetz Internet-Draft Ericsson Intended status: Standards Track A. Mankin Expires: July 7, 2007 January 3, 2007 Requirements on I-D Tracker Extensions for Working Group Chairs draft-ietf-proto-wgchair-tracker-ext-01.g 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 July 7, 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 July 7, 2007 [Page 1] =0C Internet-Draft WG Chair Tracker Requirements January 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. 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: Levkowetz & Mankin Expires July 7, 2007 [Page 2] =0C Internet-Draft WG Chair Tracker Requirements January 2007 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 additional state 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 States A new state variable or field should 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 Levkowetz & Mankin Expires July 7, 2007 [Page 3] =0C Internet-Draft WG Chair Tracker Requirements January 2007 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. (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. (R-008) * Not a WG Document This document is 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 Levkowetz & Mankin Expires July 7, 2007 [Page 4] =0C Internet-Draft WG Chair Tracker Requirements January 2007 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" Similarly to the automatic transition described below in Section 4, the WG annotation tag "Doc Shepherd Followup" should be automatically assigned by the tracker when a document is updated when it is in the WG state "In WG Last Call" with the annotation tag "Revised ID Needed" (which the shepherd may or may not choose to use in his/her WG) (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. Modification of Existing States One existing sub-state in the tracker should be modified to reflect the role of the WG document shepherds. Levkowetz & Mankin Expires July 7, 2007 [Page 5] =0C Internet-Draft WG Chair Tracker Requirements January 2007 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. 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. Levkowetz & Mankin Expires July 7, 2007 [Page 6] =0C Internet-Draft WG Chair Tracker Requirements January 2007 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 July 7, 2007 [Page 7] =0C Internet-Draft WG Chair Tracker Requirements January 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Levkowetz & Mankin Expires July 7, 2007 [Page 8] =0C --------------000006070501000204020108 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --------------000006070501000204020108-- From proto-team-bounces@ietf.org Wed Jan 03 16:32:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Dix-0005Jl-6Q; Wed, 03 Jan 2007 16:32:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Diw-0005Jf-IF for proto-team@ietf.org; Wed, 03 Jan 2007 16:32:38 -0500 Received: from aquila.nsf.gov ([198.181.231.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Diu-0004Rr-Ai for proto-team@ietf.org; Wed, 03 Jan 2007 16:32:38 -0500 Received: from nsf-fe-01.nsf.gov (HELO nsf-fe-01.ad.nsf.gov) ([128.150.4.151]) by aquila.nsf.gov with ESMTP; 03 Jan 2007 16:32:34 -0500 X-SBRS: None Received: from NSF-BE-03.ad.nsf.gov ([128.150.130.228]) by nsf-fe-01.ad.nsf.gov with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 16:32:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [proto-team] draft-ietf-proto-wgchair-tracker-ext Date: Wed, 3 Jan 2007 16:32:48 -0500 Message-ID: <3E387C1C64088E499E7BF0E86B0E1BF72E2CE7@NSF-BE-03.ad.nsf.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [proto-team] draft-ietf-proto-wgchair-tracker-ext Thread-Index: Accve1ROQcpL+ovZRc6frdM36BpeDwAAmb4A From: "Mankin, Allison J" To: "Henrik Levkowetz" , "Brian E Carpenter" , "Margaret Wasserman" X-OriginalArrivalTime: 03 Jan 2007 21:32:49.0252 (UTC) FILETIME=[B7640A40:01C72F7E] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Henrik, Very very nice. I find one paragraph is hard to read. Suggested clarification: OLD: Similarly to the automatic transition described below in Section 4, the WG annotation tag "Doc Shepherd Followup" should be automatically assigned by the tracker when a document is updated when it is in the WG state "In WG Last Call" with the annotation tag "Revised ID Needed" (which the shepherd may or may not choose to use in his/her WG) (R-023). NEW: 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. Not all shepherds will choose to annotate documents in WG Last Call this way. Thanks so much for carrying this on!! Happy New Year! Allison -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Wednesday, January 03, 2007 4:08 PM To: Brian E Carpenter; Margaret Wasserman Cc: proto-team@ietf.org Subject: [proto-team] draft-ietf-proto-wgchair-tracker-ext Hi, Here's an updated version of the wgchair tracker document. I've read through it again, to see if there are things I'd like to tweak, but there are virtually no changes compared with the -01.g version I sent out between Montreal and San Diego. I've added a "Not a WG document" state to the WG states to make the set complete, and the date and boilerplate has been updated. If there are no comments on this, I plan to submit it tomorrow (in about 24 hours, that is). Regards, Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jan 03 17:53:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Eyk-0004Vw-Mv; Wed, 03 Jan 2007 17:53:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Eyj-0004St-1d for proto-team@ietf.org; Wed, 03 Jan 2007 17:53:01 -0500 Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Eyh-0005mn-OE for proto-team@ietf.org; Wed, 03 Jan 2007 17:53:01 -0500 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 9E27937FC6; Wed, 3 Jan 2007 23:52:36 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6B72837F49; Wed, 3 Jan 2007 23:52:36 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id C3FF137E42; Wed, 3 Jan 2007 23:52:57 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H2Eyf-0002Kh-0z; Wed, 03 Jan 2007 23:52:57 +0100 Message-ID: <459C33CB.4020608@levkowetz.com> Date: Wed, 03 Jan 2007 23:52:59 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: "Mankin, Allison J" Subject: Re: [proto-team] draft-ietf-proto-wgchair-tracker-ext References: <3E387C1C64088E499E7BF0E86B0E1BF72E2CE7@NSF-BE-03.ad.nsf.gov> In-Reply-To: <3E387C1C64088E499E7BF0E86B0E1BF72E2CE7@NSF-BE-03.ad.nsf.gov> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: amankin@nsf.gov, brc@zurich.ibm.com, margaret@thingmagic.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 1.2 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Margaret Wasserman , Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Allison, on 2007-01-03 22:32 Mankin, Allison J said the following: > Henrik, > > Very very nice. > > I find one paragraph is hard to read. Suggested clarification: > > OLD: > Similarly to the automatic transition described below in Section 4, > the WG annotation tag "Doc Shepherd Followup" should be automatically > assigned by the tracker when a document is updated when it is in the > WG state "In WG Last Call" with the annotation tag "Revised ID > Needed" (which the shepherd may or may not choose to use in his/her > WG) (R-023). > > NEW: > 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. Not all shepherds will choose to annotate > documents in WG Last Call this way. Agreed, this is an easier read. I'll use your text, but skip the last sentence which seems rather superfluous in both the old and new version. Thanks, Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Thu Jan 04 03:24:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ntl-0004LJ-Ix; Thu, 04 Jan 2007 03:24:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ntk-0004KD-UM for proto-team@ietf.org; Thu, 04 Jan 2007 03:24:28 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Nti-0004fP-HH for proto-team@ietf.org; Thu, 04 Jan 2007 03:24:28 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l048OP0L043724 for ; Thu, 4 Jan 2007 08:24:25 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l048OPgd1048764 for ; Thu, 4 Jan 2007 08:24:25 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l048OPur025531 for ; Thu, 4 Jan 2007 08:24:25 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l048OOkP025516; Thu, 4 Jan 2007 08:24:24 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA349820; Thu, 4 Jan 2007 09:24:23 +0100 Message-ID: <459CB9B9.8020508@zurich.ibm.com> Date: Thu, 04 Jan 2007 09:24:25 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [proto-team] draft-ietf-proto-wgchair-tracker-ext References: <3E387C1C64088E499E7BF0E86B0E1BF72E2CE7@NSF-BE-03.ad.nsf.gov> <459C33CB.4020608@levkowetz.com> In-Reply-To: <459C33CB.4020608@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Margaret Wasserman , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Great. And then you need to decide whether it's ready for including in a spec for Neustar or whether it needs further time for comment. Brian On 2007-01-03 23:52, Henrik Levkowetz wrote: > Hi Allison, > > on 2007-01-03 22:32 Mankin, Allison J said the following: >> Henrik, >> >> Very very nice. >> >> I find one paragraph is hard to read. Suggested clarification: >> >> OLD: >> Similarly to the automatic transition described below in Section 4, >> the WG annotation tag "Doc Shepherd Followup" should be automatically >> assigned by the tracker when a document is updated when it is in the >> WG state "In WG Last Call" with the annotation tag "Revised ID >> Needed" (which the shepherd may or may not choose to use in his/her >> WG) (R-023). >> >> NEW: >> 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. Not all shepherds will choose to annotate >> documents in WG Last Call this way. > > Agreed, this is an easier read. I'll use your text, but skip the last > sentence which seems rather superfluous in both the old and new version. > > Thanks, > > > Henrik > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Thu Jan 04 04:39:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2P4M-0003s9-Fj; Thu, 04 Jan 2007 04:39:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2P4K-0003rx-DX for proto-team@ietf.org; Thu, 04 Jan 2007 04:39:28 -0500 Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2P4H-0002fL-VI for proto-team@ietf.org; Thu, 04 Jan 2007 04:39:28 -0500 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 1F1E237FE1; Thu, 4 Jan 2007 10:39:23 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id E199237FC9; Thu, 4 Jan 2007 10:39:22 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 7C8E137E46; Thu, 4 Jan 2007 10:39:21 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H2P4D-0000j7-4s; Thu, 04 Jan 2007 10:39:21 +0100 Message-ID: <459CCB4A.3060702@levkowetz.com> Date: Thu, 04 Jan 2007 10:39:22 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [proto-team] draft-ietf-proto-wgchair-tracker-ext References: <3E387C1C64088E499E7BF0E86B0E1BF72E2CE7@NSF-BE-03.ad.nsf.gov> <459C33CB.4020608@levkowetz.com> <459CB9B9.8020508@zurich.ibm.com> In-Reply-To: <459CB9B9.8020508@zurich.ibm.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brc@zurich.ibm.com, amankin@nsf.gov, margaret@thingmagic.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 1.2 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Margaret Wasserman , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Brian, on 2007-01-04 09:24 Brian E Carpenter said the following: > Great. And then you need to decide whether it's > ready for including in a spec for Neustar or whether > it needs further time for comment. Right. There were a lot of comments from the WG chairs on the previous version; I feel that it would be prudent to announce it there again, explain the changes, and ask for further comments. If there are any minor ones, I should be able to do a fast turn-around for a new version -- I don't expect any major ones which require re-thinking of the approach this time. Henrik > Brian > > On 2007-01-03 23:52, Henrik Levkowetz wrote: >> Hi Allison, >> >> on 2007-01-03 22:32 Mankin, Allison J said the following: >>> Henrik, >>> >>> Very very nice. >>> >>> I find one paragraph is hard to read. Suggested clarification: >>> >>> OLD: >>> Similarly to the automatic transition described below in Section 4, >>> the WG annotation tag "Doc Shepherd Followup" should be automatically >>> assigned by the tracker when a document is updated when it is in the >>> WG state "In WG Last Call" with the annotation tag "Revised ID >>> Needed" (which the shepherd may or may not choose to use in his/her >>> WG) (R-023). >>> >>> NEW: >>> 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. Not all shepherds will choose to annotate >>> documents in WG Last Call this way. >> >> Agreed, this is an easier read. I'll use your text, but skip the last >> sentence which seems rather superfluous in both the old and new version. >> >> Thanks, >> >> >> Henrik >> > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Thu Jan 04 04:55:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PJu-0002dR-CE; Thu, 04 Jan 2007 04:55:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2PJt-0002dG-Lm for proto-team@ietf.org; Thu, 04 Jan 2007 04:55:33 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2PJr-0006cY-6h for proto-team@ietf.org; Thu, 04 Jan 2007 04:55:33 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l049tQnm256048 for ; Thu, 4 Jan 2007 09:55:26 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l049tPHV1441990 for ; Thu, 4 Jan 2007 09:55:25 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l049seRo002287 for ; Thu, 4 Jan 2007 09:54:40 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l049sdkM002279; Thu, 4 Jan 2007 09:54:40 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA128798; Thu, 4 Jan 2007 10:54:37 +0100 Message-ID: <459CCEDE.5020806@zurich.ibm.com> Date: Thu, 04 Jan 2007 10:54:38 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [proto-team] draft-ietf-proto-wgchair-tracker-ext References: <3E387C1C64088E499E7BF0E86B0E1BF72E2CE7@NSF-BE-03.ad.nsf.gov> <459C33CB.4020608@levkowetz.com> <459CB9B9.8020508@zurich.ibm.com> <459CCB4A.3060702@levkowetz.com> In-Reply-To: <459CCB4A.3060702@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Margaret Wasserman , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Agreed On 2007-01-04 10:39, Henrik Levkowetz wrote: > Hi Brian, > > on 2007-01-04 09:24 Brian E Carpenter said the following: >> Great. And then you need to decide whether it's >> ready for including in a spec for Neustar or whether >> it needs further time for comment. > > Right. There were a lot of comments from the WG chairs on > the previous version; I feel that it would be prudent to > announce it there again, explain the changes, and ask for > further comments. If there are any minor ones, I should be > able to do a fast turn-around for a new version -- I don't > expect any major ones which require re-thinking of the approach > this time. > > > Henrik > > >> Brian >> >> On 2007-01-03 23:52, Henrik Levkowetz wrote: >>> Hi Allison, >>> >>> on 2007-01-03 22:32 Mankin, Allison J said the following: >>>> Henrik, >>>> >>>> Very very nice. >>>> >>>> I find one paragraph is hard to read. Suggested clarification: >>>> >>>> OLD: >>>> Similarly to the automatic transition described below in Section 4, >>>> the WG annotation tag "Doc Shepherd Followup" should be automatically >>>> assigned by the tracker when a document is updated when it is in the >>>> WG state "In WG Last Call" with the annotation tag "Revised ID >>>> Needed" (which the shepherd may or may not choose to use in his/her >>>> WG) (R-023). >>>> >>>> NEW: >>>> 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. Not all shepherds will choose to annotate >>>> documents in WG Last Call this way. >>> Agreed, this is an easier read. I'll use your text, but skip the last >>> sentence which seems rather superfluous in both the old and new version. >>> >>> Thanks, >>> >>> >>> Henrik >>> > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 09 05:29:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4EE5-0001Zk-Ip; Tue, 09 Jan 2007 05:29:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4EE5-0001Zf-3z for proto-team@ietf.org; Tue, 09 Jan 2007 05:29:05 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4EE3-0008F2-OL for proto-team@ietf.org; Tue, 09 Jan 2007 05:29:05 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l09ASwjN196446 for ; Tue, 9 Jan 2007 10:29:01 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l09ASvSG1724662 for ; Tue, 9 Jan 2007 10:28:57 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l09ASv3N029925 for ; Tue, 9 Jan 2007 10:28:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l09ASuQ4029910 for ; Tue, 9 Jan 2007 10:28:57 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA234774 for ; Tue, 9 Jan 2007 11:28:56 +0100 Message-ID: <45A36E67.4000101@zurich.ibm.com> Date: Tue, 09 Jan 2007 11:28:55 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: proto-team@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [proto-team] Re: I-D ACTION:draft-ietf-proto-wgchair-tracker-ext-01.txt X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Thanks for this - will the authors launch a discussion on the WG Chairs list? BTW, I'm still in need of the update to draft-ietf-proto-wgchair-doc-shepherding, which is in state "IESG Evaluation :: Revised ID Needed" Brian _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 09 06:46:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4FRM-0008Lh-3O; Tue, 09 Jan 2007 06:46:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4FRK-0008LV-P4 for proto-team@ietf.org; Tue, 09 Jan 2007 06:46:50 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4FRI-0003PY-Pd for proto-team@ietf.org; Tue, 09 Jan 2007 06:46:50 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C620E2596BA; Tue, 9 Jan 2007 12:43:05 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10363-09; Tue, 9 Jan 2007 12:43:00 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 97DE12596B9; Tue, 9 Jan 2007 12:43:00 +0100 (CET) Message-ID: <45A380A2.1040900@alvestrand.no> Date: Tue, 09 Jan 2007 12:46:42 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Brian E Carpenter , proto-team@ietf.org References: <03dc01c73116$33fabb60$6a01a8c0@china.huawei.com> <073d01c731aa$f04e4090$0a23fea9@your029b8cecfe> <87ejq7f8ek.fsf@latte.josefsson.org><2F04242A9E159580681BB631@[192.168.1.108]><45A21835.1080000@zurich.ibm.com><08e201c73314$a4669fe0$0a23fea9@your029b8cecfe> <45A23A14.7040808@zurich.ibm.com> <09cf01c73353$8e3ccd40$0a23fea9@your029b8cecfe> <45A36FCA.2000308@zurich.ibm.com> In-Reply-To: <45A36FCA.2000308@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [proto-team] Re: Tracking resolution of DISCUSSes X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Brian E Carpenter wrote: > Cutting to the chase: > > > How about allowing PROTO shepherds to post to the I-D tracker? > > See whether draft-ietf-proto-wgchair-tracker-ext-01.txt > covers what you want. If not, immediately would be > a very good time to tell the PROTO team. > > Brian > Since Brian asked for it... section 3.1: What is the value of the "WG state" variable when: - the document is an individual contribution - the document is in IESG processing - the document is in the RFC Editor's queue? It is fine if the answer is "WG state irrelevant", but then "WG state irrelevant" needs to be added to the state list. I'm assuming that the document is in state "Exists" or "AD is watching" when it is in one of the states where the WG state is relevant. The document doesn't say that WG chairs are able to add entries to the comment log - was this thought "too obvious to mention"? The document does not say which state transitions a WG chair or document shepherd should be able to trigger, there's just section 2 bullet 3 saying which transitions they should not be able to trigger - is this thought to be "we'll make it up as we go along"? BTW: that sentence uses "not all users" to mean "IESG only", I think. There are lots of users of the tracker who are not WG chairs or proto shepherds. I'm fine with the implied decision in section 2 bullet 2 to treat "chairs" as a group, meaning that any chair can change the state of any document in any WG. I think logging changes and who makes them is enough to deal with the hypothetical possibility of abuse - if abuse ever happens, we'll fire the offending chair/shepherd and change the states back. That's all on a quick scan.... Harald _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 09 09:51:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IK7-0002NB-VC; Tue, 09 Jan 2007 09:51:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IK5-0002MF-AU for proto-team@ietf.org; Tue, 09 Jan 2007 09:51:33 -0500 Received: from av9-1-sn3.vrr.skanova.net ([81.228.9.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4IK3-0003T8-Pp for proto-team@ietf.org; Tue, 09 Jan 2007 09:51:33 -0500 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id EEE3B38071; Tue, 9 Jan 2007 15:51:26 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B34AC37EB4; Tue, 9 Jan 2007 15:51:26 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 21CB337E4B; Tue, 9 Jan 2007 15:51:26 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H4IJu-0006xS-9v; Tue, 09 Jan 2007 15:51:22 +0100 Message-ID: <45A3ABA2.70104@levkowetz.com> Date: Tue, 09 Jan 2007 15:50:10 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [proto-team] Re: Tracking resolution of DISCUSSes References: <03dc01c73116$33fabb60$6a01a8c0@china.huawei.com> <073d01c731aa$f04e4090$0a23fea9@your029b8cecfe> <87ejq7f8ek.fsf@latte.josefsson.org><2F04242A9E159580681BB631@[192.168.1.108]><45A21835.1080000@zurich.ibm.com><08e201c73314$a4669fe0$0a23fea9@your029b8cecfe> <45A23A14.7040808@zurich.ibm.com> <09cf01c73353$8e3ccd40$0a23fea9@your029b8cecfe> <45A36FCA.2000308@zurich.ibm.com> <45A380A2.1040900@alvestrand.no> In-Reply-To: <45A380A2.1040900@alvestrand.no> X-Enigmail-Version: 0.94.1.2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: harald@alvestrand.no, brc@zurich.ibm.com, proto-team@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2010072258==" Errors-To: proto-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2010072258== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF70985705DEED5C6CD5A258" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF70985705DEED5C6CD5A258 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Harald, on 2007-01-09 12:46 Harald Alvestrand said the following: > Brian E Carpenter wrote: >> Cutting to the chase: >> >> > How about allowing PROTO shepherds to post to the I-D tracker? >> >> See whether draft-ietf-proto-wgchair-tracker-ext-01.txt >> covers what you want. If not, immediately would be >> a very good time to tell the PROTO team. >> >> Brian >> > Since Brian asked for it... >=20 > section 3.1: What is the value of the "WG state" variable when: >=20 > - the document is an individual contribution "Not a WG Document" > - the document is in IESG processing Hmm. I was thinking "Active WG Document", but with the explanation of this state currently in the draft, this doesn't fit. I think we should add a state for this. What about "Completed WG Document", or "Submitted WG Document" ? > - the document is in the RFC Editor's queue? As above. I.e., no distinction in the WG state once the document is out of the WG's hands. > It is fine if the answer is "WG state irrelevant", but then "WG state=20 > irrelevant" needs to be added to the state list. Agreed. But as indicated above, I'd like to split this into the two states "Not a WG Document" and "Submitted WG Document" (or whatever they should be called). > I'm assuming that the document is in state "Exists" or "AD is watching"= =20 > when it is in one of the states where the WG state is relevant. That would be the case for "Not a WG Document", but not for "Submitted WG Document", no? > The document doesn't say that WG chairs are able to add entries to the = > comment log - was this thought "too obvious to mention"? No. Good point. Should the WG chairs have this access right? > The document does not say which state transitions a WG chair or documen= t=20 > shepherd should be able to trigger, there's just section 2 bullet 3=20 > saying which transitions they should not be able to trigger - is this=20 > thought to be "we'll make it up as we go along"? Since the tracker in general doesn't verify or control state transitions,= I've seen this as a matter of 'what isn't restricted is possible'. I'm not sure we want to build in more smartness in the tracker for this (at least until we have some experience with the new usage). > BTW: that sentence uses "not all users" to mean "IESG only", I think.=20 > There are lots of users of the tracker who are not WG chairs or proto=20 > shepherds. Good point. What about: OLD: 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: NEW: o 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: > I'm fine with the implied decision in section 2 bullet 2 to treat=20 > "chairs" as a group, meaning that any chair can change the state of any= =20 > document in any WG. I think logging changes and who makes them is enoug= h=20 > to deal with the hypothetical possibility of abuse - if abuse ever=20 > happens, we'll fire the offending chair/shepherd and change the states = back. >=20 > That's all on a quick scan.... Thanks! Henrik --------------enigDF70985705DEED5C6CD5A258 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFFo6upeVhrtTJkXCMRAs04AKCq2rrNTqFiKNfseVLNT2XgN9T0VgCg15N5 b2a7rUlygHBOpT6biz7z8AE= =DRjJ -----END PGP SIGNATURE----- --------------enigDF70985705DEED5C6CD5A258-- --===============2010072258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============2010072258==-- From proto-team-bounces@ietf.org Tue Jan 09 09:52:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IKg-0002gH-57; Tue, 09 Jan 2007 09:52:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IKf-0002g6-1z for proto-team@ietf.org; Tue, 09 Jan 2007 09:52:09 -0500 Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4IKd-0003lk-PU for proto-team@ietf.org; Tue, 09 Jan 2007 09:52:09 -0500 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 89F7538094; Tue, 9 Jan 2007 15:51:43 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4062C38094; Tue, 9 Jan 2007 15:51:43 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 91FCA37E49; Tue, 9 Jan 2007 15:52:06 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H4IKb-000710-UH; Tue, 09 Jan 2007 15:52:06 +0100 Message-ID: <45A3AC13.5080009@levkowetz.com> Date: Tue, 09 Jan 2007 15:52:03 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [proto-team] Re: I-D ACTION:draft-ietf-proto-wgchair-tracker-ext-01.txt References: <45A36E67.4000101@zurich.ibm.com> In-Reply-To: <45A36E67.4000101@zurich.ibm.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brc@zurich.ibm.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Brian, on 2007-01-09 11:28 Brian E Carpenter said the following: > Thanks for this - will the authors launch a discussion on the > WG Chairs list? Yep, writing the note now. > BTW, I'm still in need of the update to > draft-ietf-proto-wgchair-doc-shepherding, which > is in state "IESG Evaluation :: Revised ID Needed" Yes. Allison, could you send the latest XML source to the list? If Lars doesn't have time to fix this, I can do an update. Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 09 10:06:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IY7-0000ln-Kp; Tue, 09 Jan 2007 10:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4IY6-0000im-A5; Tue, 09 Jan 2007 10:06:02 -0500 Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4IXq-0008VQ-Gj; Tue, 09 Jan 2007 10:06:02 -0500 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 8AAC13816E; Tue, 9 Jan 2007 16:05:41 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 5164A381F0; Tue, 9 Jan 2007 16:05:41 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 3888D37E46; Tue, 9 Jan 2007 16:05:41 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H4IXk-0007o4-KX; Tue, 09 Jan 2007 16:05:40 +0100 Message-ID: <45A3AF42.9000101@levkowetz.com> Date: Tue, 09 Jan 2007 16:05:38 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: 'Working Group Chairs' X-Enigmail-Version: 0.94.1.2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: wgchairs@ietf.org, proto-team@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: proto-team@ietf.org Subject: [proto-team] WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1598546995==" Errors-To: proto-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1598546995== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0B4E79B953C5184B3443204E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B4E79B953C5184B3443204E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, The proto-team document that describes proposed changes to the ID-tracker (https://datatracker.ietf.org/) which makes it possible for WG chairs to use the I-D tracker for managing WG documents has been revised after the feedback from this list (May 2006). I've taken out all explicit state transitions; the tracker won't enforce or check the state transitions. I've also removed sub-states, and instead introduced annotations to capture such things as documents awaiting review. Multiple annotations may exist at the same time. As I also mentioned the last time: Since these changes and enhancements are explicitly meant for Your Use, Dear Fellow Chairs, it would be very good if you would read and comment on the document. Excluding boilerplate etc. the actual content is 6 pages long, so it should be manageable, especially if you check the diffs (see links below). The document is available from the internet-drafts repository: http://ietf.org/internet-drafts/draft-ietf-proto-wgchair-tracker-ext-01= =2Etxt Diffs between -00 and this version are available here: http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker-ext/dra= ft-ietf-proto-wgchair-tracker-ext-01-from-00.diff.html http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker-ext/dra= ft-ietf-proto-wgchair-tracker-ext-01-from-00.wdiff.html Please send comments to this list, with Cc: to proto-team@ietf.org . Thanks, Henrik --------------enig0B4E79B953C5184B3443204E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFFo69CeVhrtTJkXCMRAhUWAKDumd7znXjQCs1Ip02HxiEHZjAUqQCg+Lhq HoiihnwWCzbDkNoxZQeWLHY= =efVG -----END PGP SIGNATURE----- --------------enig0B4E79B953C5184B3443204E-- --===============1598546995== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1598546995==-- From proto-team-bounces@ietf.org Tue Jan 09 10:20:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ilz-0007wt-Qb; Tue, 09 Jan 2007 10:20:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Ilz-0007wo-Fu for proto-team@ietf.org; Tue, 09 Jan 2007 10:20:23 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Ily-0004lH-0R for proto-team@ietf.org; Tue, 09 Jan 2007 10:20:23 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B21482596BD; Tue, 9 Jan 2007 16:16:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15408-08; Tue, 9 Jan 2007 16:16:32 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A9182596B9; Tue, 9 Jan 2007 16:16:32 +0100 (CET) Message-ID: <45A3B2AE.4040003@alvestrand.no> Date: Tue, 09 Jan 2007 16:20:14 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [proto-team] Re: Tracking resolution of DISCUSSes References: <03dc01c73116$33fabb60$6a01a8c0@china.huawei.com> <073d01c731aa$f04e4090$0a23fea9@your029b8cecfe> <87ejq7f8ek.fsf@latte.josefsson.org><2F04242A9E159580681BB631@[192.168.1.108]><45A21835.1080000@zurich.ibm.com><08e201c73314$a4669fe0$0a23fea9@your029b8cecfe> <45A23A14.7040808@zurich.ibm.com> <09cf01c73353$8e3ccd40$0a23fea9@your029b8cecfe> <45A36FCA.2000308@zurich.ibm.com> <45A380A2.1040900@alvestrand.no> <45A3ABA2.70104@levkowetz.com> In-Reply-To: <45A3ABA2.70104@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Henrik Levkowetz wrote: > Hi Harald, > > on 2007-01-09 12:46 Harald Alvestrand said the following: > >> Brian E Carpenter wrote: >> >>> Cutting to the chase: >>> >>> >>>> How about allowing PROTO shepherds to post to the I-D tracker? >>>> >>> See whether draft-ietf-proto-wgchair-tracker-ext-01.txt >>> covers what you want. If not, immediately would be >>> a very good time to tell the PROTO team. >>> >>> Brian >>> >>> >> Since Brian asked for it... >> >> section 3.1: What is the value of the "WG state" variable when: >> >> - the document is an individual contribution >> > > "Not a WG Document" > > >> - the document is in IESG processing >> > > Hmm. I was thinking "Active WG Document", but with the > explanation of this state currently in the draft, this > doesn't fit. I think we should add a state for this. > What about "Completed WG Document", or "Submitted WG Document" ? > > >> - the document is in the RFC Editor's queue? >> > > As above. I.e., no distinction in the WG state once the > document is out of the WG's hands. > > >> It is fine if the answer is "WG state irrelevant", but then "WG state >> irrelevant" needs to be added to the state list. >> > > Agreed. But as indicated above, I'd like to split this into the > two states "Not a WG Document" and "Submitted WG Document" (or > whatever they should be called). > Looks good to me. > >> I'm assuming that the document is in state "Exists" or "AD is watching" >> when it is in one of the states where the WG state is relevant. >> > > That would be the case for "Not a WG Document", but not for "Submitted > WG Document", no? > Right. I was not thinking clearly here. > >> The document doesn't say that WG chairs are able to add entries to the >> comment log - was this thought "too obvious to mention"? >> > > No. Good point. Should the WG chairs have this access right? > Yes, otherwise the WG state annotation tag "Other - see Comment Log" makes no sense. Besides, it is ALWAYS good to be able to add comments. > >> The document does not say which state transitions a WG chair or document >> shepherd should be able to trigger, there's just section 2 bullet 3 >> saying which transitions they should not be able to trigger - is this >> thought to be "we'll make it up as we go along"? >> > > Since the tracker in general doesn't verify or control state transitions, > I've seen this as a matter of 'what isn't restricted is possible'. I'm > not sure we want to build in more smartness in the tracker for this > (at least until we have some experience with the new usage). > We started out this way, and I'm happy to see it continue. > >> BTW: that sentence uses "not all users" to mean "IESG only", I think. >> There are lots of users of the tracker who are not WG chairs or proto >> shepherds. >> > > Good point. What about: > > OLD: > 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: > > NEW: > o 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: works for me. The document doesn't say who it's restricted to, but that can vary. Somewhere, we should probably say that the public still has no authorization for changes; "unrestricted" features are still restricted to only those people who are authorized on the system. Hope to remember to look at -02 when it comes out - what's the open mailing list on which this is being discussed? document doesn't say.... _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 09 11:14:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Jch-0006B4-5S; Tue, 09 Jan 2007 11:14:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Jcg-0006Az-8p for proto-team@ietf.org; Tue, 09 Jan 2007 11:14:50 -0500 Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JcN-0003Uc-Ht for proto-team@ietf.org; Tue, 09 Jan 2007 11:14:50 -0500 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id AB1F938318; Tue, 9 Jan 2007 17:14:30 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 838C437EC0; Tue, 9 Jan 2007 17:14:30 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id CA1BB37E4A; Tue, 9 Jan 2007 17:14:26 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H4JcH-0002te-IW; Tue, 09 Jan 2007 17:14:25 +0100 Message-ID: <45A3BF59.4030601@levkowetz.com> Date: Tue, 09 Jan 2007 17:14:17 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [proto-team] Re: Tracking resolution of DISCUSSes References: <03dc01c73116$33fabb60$6a01a8c0@china.huawei.com> <073d01c731aa$f04e4090$0a23fea9@your029b8cecfe> <87ejq7f8ek.fsf@latte.josefsson.org><2F04242A9E159580681BB631@[192.168.1.108]><45A21835.1080000@zurich.ibm.com><08e201c73314$a4669fe0$0a23fea9@your029b8cecfe> <45A23A14.7040808@zurich.ibm.com> <09cf01c73353$8e3ccd40$0a23fea9@your029b8cecfe> <45A36FCA.2000308@zurich.ibm.com> <45A380A2.1040900@alvestrand.no> <45A3ABA2.70104@levkowetz.com> <45A3B2AE.4040003@alvestrand.no> In-Reply-To: <45A3B2AE.4040003@alvestrand.no> X-Enigmail-Version: 0.94.1.2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: harald@alvestrand.no, brc@zurich.ibm.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0293665665==" Errors-To: proto-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0293665665== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8CD3F13DC2D5F58582C080A0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8CD3F13DC2D5F58582C080A0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Harald, I've updated my source, with a first rev. towards a -02 available here as -02.a: http://www1.tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker-ext/= index.pyht This has the following changes: on 2007-01-09 16:20 Harald Alvestrand said the following: =2E.. =20 >> >> Agreed. But as indicated above, I'd like to split this into the >> two states "Not a WG Document" and "Submitted WG Document" (or >> whatever they should be called). >> =20 > Looks good to me. Ok. Added a new state, provisionally called "Submitted WG Document", with explanation. >>> I'm assuming that the document is in state "Exists" or "AD is watchin= g"=20 >>> when it is in one of the states where the WG state is relevant. >>> =20 >> >> That would be the case for "Not a WG Document", but not for "Submitted= >> WG Document", no? >> =20 > Right. I was not thinking clearly here. >> =20 >>> The document doesn't say that WG chairs are able to add entries to th= e=20 >>> comment log - was this thought "too obvious to mention"? >>> =20 >> >> No. Good point. Should the WG chairs have this access right? >> =20 > Yes, otherwise the WG state annotation tag "Other - see Comment Log"=20 > makes no sense. > Besides, it is ALWAYS good to be able to add comments. Ok. Added clarification of this in Section 2, bullet 3. >>> The document does not say which state transitions a WG chair or docum= ent=20 >>> shepherd should be able to trigger, there's just section 2 bullet 3=20 >>> saying which transitions they should not be able to trigger - is this= =20 >>> thought to be "we'll make it up as we go along"? >>> =20 >> >> Since the tracker in general doesn't verify or control state transitio= ns, >> I've seen this as a matter of 'what isn't restricted is possible'. I'm= >> not sure we want to build in more smartness in the tracker for this >> (at least until we have some experience with the new usage). >> =20 > We started out this way, and I'm happy to see it continue. >> =20 >>> BTW: that sentence uses "not all users" to mean "IESG only", I think.= =20 >>> There are lots of users of the tracker who are not WG chairs or proto= =20 >>> shepherds. >>> =20 >> >> Good point. What about: >> >> OLD: >> o Identification of the actions and information which may not be >> accessed by all users (R-002). Such actions and information wil= l >> be called 'restricted features' in the following. Some known >> restricted features are: >> >> NEW: >> o 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: > works for me. The document doesn't say who it's restricted to, but that= =20 > can vary. Replacement made. > Somewhere, we should probably say that the public still has no=20 > authorization for changes; "unrestricted" features are still restricted= =20 > to only those people who are authorized on the system. Added clarification of this point in Section 1, Introduction. > Hope to remember to look at -02 when it comes out - what's the open=20 > mailing list on which this is being discussed? document doesn't say....= Hmm. This would be the proto-team list, but I haven't verified that it's open. Henrik --------------enig8CD3F13DC2D5F58582C080A0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFFo79aeVhrtTJkXCMRAhGiAJ0ZVoCbZm8BqgFh+xdJrVsI6js6RgCgpNFX JVRmWjBrPlfAIgqyNEJbyY4= =jPvR -----END PGP SIGNATURE----- --------------enig8CD3F13DC2D5F58582C080A0-- --===============0293665665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0293665665==-- From proto-team-bounces@ietf.org Tue Jan 09 21:17:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4T1u-00030y-7R; Tue, 09 Jan 2007 21:17:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4T1t-0002xs-GJ; Tue, 09 Jan 2007 21:17:29 -0500 Received: from av9-1-sn3.vrr.skanova.net ([81.228.9.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4T1o-0000YV-Vb; Tue, 09 Jan 2007 21:17:29 -0500 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 62096382B1; Wed, 10 Jan 2007 03:17:20 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 2A1D537EF1; Wed, 10 Jan 2007 03:17:20 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id C3B5837E44; Wed, 10 Jan 2007 03:17:19 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H4T1i-0001AE-Mp; Wed, 10 Jan 2007 03:17:19 +0100 Message-ID: <45A44CAD.4040005@levkowetz.com> Date: Wed, 10 Jan 2007 03:17:17 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Dan Wing References: <0d7c01c73453$eea09620$c4f0200a@amer.cisco.com> In-Reply-To: <0d7c01c73453$eea09620$c4f0200a@amer.cisco.com> X-Enigmail-Version: 0.94.1.2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: dwing@cisco.com, wgchairs@ietf.org, proto-team@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'Working Group Chairs' , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0340176228==" Errors-To: proto-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0340176228== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig64119B366C0EBBD62A318124" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig64119B366C0EBBD62A318124 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dan, Thanks for reading and commenting. More inline: on 2007-01-10 02:09 Dan Wing said the following: > I applaud this effort - thank you very much. >=20 > * In several working groups, I have noticed an increased use of named > technical reviewers. It might be useful to have a place for those peop= le to > be listed, and also to get email notification of revisions of documents= they > are reviewing (similar to how chairs and the WG itself is informed of n= ew > revisions). Some of these reviewers don't necessarily subscribe to the= WG > mailing list itself (cross-area review, for example). The intention is to handle reviewer notification with a different new tool, which actually is a general notification engine. There's also a reviewer support tool in the works, which may be the most appropriate place to register reviewers. > * Of the defined working group states, what is the intended purpose of = the > "Not a WG Document" state? Is this intended for (1) individual documen= ts > which might be adopted by the working group, or (2) working group docum= ents > that have been abandoned by the working group (that is, more abandoned = than > the 'parked' state), or (3) is this the default state for all draft-* > documents? =20 The intention is (3). I've added some more explanatory text to this state in the source on my disk. (There's a preview here, too: http://www1.tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker-ext/= draft-ietf-proto-wgchair-tracker-ext-02.b.txt) > If (1), I suggest calling this state 'Potential WG document' or 'Chair = is > Watching' (similar to the existing IESG "AD is watching" state), or 'No= t Yet > a WG Document', or 'Impending WG Document'; if (2), I suggest 'Abandone= d'; > if (3), I suggest 'Individual Document' for draft-LASTNAME-*, and I sug= gest > creating 'IAB document' for draft-iab-*, 'IRTF' for draft-irtf-*, 'IESG= ', > 'ITU', etc. For (1), do people think there's a need for such a state? If so, I'll ad= d it to the spec. The same goes for (2) - do people think there's a need for such a state? For (3), there's a separate draft which will describe IAB and IRTF states= =2E I'd like to keep those separate, rather than create state dependencies between them and the WG document states. The WG document state should only be relevant for documents being handled (or considered) by a WG; others should simply be "Not a WG Document", and possibly have some other= state independently of the WG document state. I'll add some explanatory text about this, too. > In any event, it would be useful if there was a way for a chair to indi= cate > that an individual submission is interesting to the working group, some= time > prior to it being adopted by the WG. For example, perhaps the document= > doesn't fit in the WG's charter yet, or a milestone needs to be added. = But > I suppose that state is pretty short-lived. Anyway, I'll throw the ide= a out > there and see what y'all think about it. This is referring to (1) above, right? Let's hear what people think. > * It might be useful to show anticipated WGLC dates or dependencies, pe= rhaps > freeform in the WG state annotation. See, for example, > http://www.employees.org/behave/document-status.html Could this be handled by the annotation "Other - see Comment Log", or do you see a clear need for an explicit annotation tag for this? Henrik --------------enig64119B366C0EBBD62A318124 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFFpEyteVhrtTJkXCMRAojbAJ9YaahS7Tcw50hWleipziwQM7HSwACghL2u JU/52oZpUCT2ce10qY52HOs= =tVII -----END PGP SIGNATURE----- --------------enig64119B366C0EBBD62A318124-- --===============0340176228== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0340176228==-- From proto-team-bounces@ietf.org Wed Jan 10 11:30:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4gLP-0005LK-9t; Wed, 10 Jan 2007 11:30:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4gLM-0005L9-SZ; Wed, 10 Jan 2007 11:30:28 -0500 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4gLL-00082j-DB; Wed, 10 Jan 2007 11:30:28 -0500 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 9200338462; Wed, 10 Jan 2007 17:30:20 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5E9C937E55; Wed, 10 Jan 2007 17:30:20 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 943A737E42; Wed, 10 Jan 2007 17:30:19 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H4gLB-0004JB-9s; Wed, 10 Jan 2007 17:30:17 +0100 Message-ID: <45A51496.5030801@levkowetz.com> Date: Wed, 10 Jan 2007 17:30:14 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" References: In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bwijnen@alcatel-lucent.com, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Working Group Chairs , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Bert, on 2007-01-10 15:00 Wijnen, Bert (Bert) said the following: > I wwonder if we want/need a WG State annotation tag of > Dead WG document That seems to be very similar to Dan Wing's proposed 'Abandoned'. I've added "Dead WG Document" as a state in my working copy. > That is a document that once was a WG document, but has been > declared dead, or no longer on the WG agenda. > > I also wonder if it is possible (I know it is handy/useful) > to have the (next) milestone date for each WG document listed. Mmm. Good point. One question: is this best handled by manual annotation, or could / should it rather be calculated / deduced from other data (charter, a set of acceptable times between events, etc.) ? Henrik > Bert > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: dinsdag 9 januari 2007 16:06 >> To: 'Working Group Chairs' >> Cc: proto-team@ietf.org >> Subject: WG chair use of the ID-tracker: Proposed tool addition >> >> Hi, >> >> The proto-team document that describes proposed changes to >> the ID-tracker (https://datatracker.ietf.org/) which makes it >> possible for WG chairs to use the I-D tracker for managing WG >> documents has been revised after the feedback from this list >> (May 2006). >> >> I've taken out all explicit state transitions; the tracker >> won't enforce or check the state transitions. I've also >> removed sub-states, and instead introduced annotations to >> capture such things as documents awaiting review. Multiple >> annotations may exist at the same time. >> >> As I also mentioned the last time: >> >> Since these changes and enhancements are explicitly meant for >> Your Use, Dear Fellow Chairs, it would be very good if you >> would read and comment on the document. Excluding >> boilerplate etc. the actual content is 6 pages long, so it >> should be manageable, especially if you check the diffs (see >> links below). >> >> The document is available from the internet-drafts repository: >> >> http://ietf.org/internet-drafts/draft-ietf-proto-wgchair-track > er-ext-01.txt >> >> Diffs between -00 and this version are available here: >> >> http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracke > r-ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.diff.html >> >> http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracke > r-ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.wdiff.html >> >> >> Please send comments to this list, with Cc: to proto-team@ietf.org . >> >> >> Thanks, >> >> >> Henrik >> >> >> >> >> >> > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 12 09:15:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NBh-0001Jc-35; Fri, 12 Jan 2007 09:15:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NBf-0001IJ-EI; Fri, 12 Jan 2007 09:15:19 -0500 Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NBe-000337-4B; Fri, 12 Jan 2007 09:15:19 -0500 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 45D1F38EE8; Fri, 12 Jan 2007 15:15:17 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id F3C1F38E85; Fri, 12 Jan 2007 15:15:16 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id E120937E49; Fri, 12 Jan 2007 15:15:16 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H5NBc-0001S9-Fo; Fri, 12 Jan 2007 15:15:16 +0100 Message-ID: <45A797F3.5050801@levkowetz.com> Date: Fri, 12 Jan 2007 15:15:15 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" References: In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bwijnen@alcatel-lucent.com, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Working Group Chairs , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Bert, on 2007-01-11 11:42 Wijnen, Bert (Bert) said the following: ... >> > That is a document that once was a WG document, but has >> been declared >> > dead, or no longer on the WG agenda. >> > >> > I also wonder if it is possible (I know it is handy/useful) to have >> > the (next) milestone date for each WG document listed. >> >> Mmm. Good point. One question: is this best handled by >> manual annotation, or could / should it rather be calculated >> / deduced from other data (charter, a set of acceptable times >> between events, etc.) ? >> > > I always find it important/handy to see all info about a document in > one place (inlcuding the formal agreed upon milestone date (as per > the WG charter). Just my 2 cents. Ok. Will see if this can be addressed somehow. It may or may not be part of this set of tracker changes; I think there may be a number of different ways to address this. Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 12 09:18:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NEO-0003o8-Ji; Fri, 12 Jan 2007 09:18:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NEO-0003nz-At; Fri, 12 Jan 2007 09:18:08 -0500 Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NEM-0004Go-QX; Fri, 12 Jan 2007 09:18:08 -0500 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 3EA2F38C7A; Fri, 12 Jan 2007 15:18:03 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 410EC38101; Fri, 12 Jan 2007 15:17:59 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7BD1637E48; Fri, 12 Jan 2007 15:17:59 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H5NEE-00031D-RG; Fri, 12 Jan 2007 15:17:59 +0100 Message-ID: <45A79895.2000809@levkowetz.com> Date: Fri, 12 Jan 2007 15:17:57 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Tobias Gondrom References: <2666EB2A846BAC4BB2D7F593301A78689B378D@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A78689B378D@MUCXGC2.opentext.net> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: tgondrom@opentext.com, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Working Group Chairs , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Tobias, on 2007-01-11 15:00 Tobias Gondrom said the following: > Hello Henrik, > > I just read your draft and like it so far. > Two small (and not so important) comments: > 1. the last sentence of the abstract seems to have a strange grammar. > "Having the tracker support the working groups more fully is a primary > benefit,..." ??? This works just fine in my head, so I need some more explanation to understand the problem here. > 2. I would agree with the comment from Dan, and propose further > explanation in the text about the purpose of the "Not a WG > Document"-state Right. Already added in my working copy. > Thanks a lot for your work! You're welcome :-) Henrik > Tobias > > > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Tuesday, January 09, 2007 4:06 PM >> To: 'Working Group Chairs' >> Cc: proto-team@ietf.org >> Subject: WG chair use of the ID-tracker: Proposed tool addition >> >> Hi, >> >> The proto-team document that describes proposed changes to the >> ID-tracker (https://datatracker.ietf.org/) which makes it possible >> for WG chairs to use the I-D tracker for managing WG documents >> has been revised after the feedback from this list (May 2006). >> >> I've taken out all explicit state transitions; the tracker won't >> enforce or check the state transitions. I've also removed sub-states, >> and instead introduced annotations to capture such things as documents >> awaiting review. Multiple annotations may exist at the same time. >> >> As I also mentioned the last time: >> >> Since these changes and enhancements are explicitly meant for Your > Use, >> Dear Fellow Chairs, it would be very good if you would read and > comment >> on the document. Excluding boilerplate etc. the actual content is 6 >> pages long, so it should be manageable, especially if you check the >> diffs (see links below). >> >> The document is available from the internet-drafts repository: >> > http://ietf.org/internet-drafts/draft-ietf-proto-wgchair-tracker-ext- >> 01.txt >> >> Diffs between -00 and this version are available here: >> http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker- >> ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.diff.html >> http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracker- >> ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.wdiff.html >> >> >> Please send comments to this list, with Cc: to proto-team@ietf.org . >> >> >> Thanks, >> >> >> Henrik >> >> >> >> > > > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 12 09:21:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NHh-0005K1-Eb; Fri, 12 Jan 2007 09:21:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NHf-0005Ja-Ik for proto-team@ietf.org; Fri, 12 Jan 2007 09:21:31 -0500 Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NHd-0005oH-1T for proto-team@ietf.org; Fri, 12 Jan 2007 09:21:31 -0500 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 39E3C38563; Fri, 12 Jan 2007 15:21:26 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 0F171382DE; Fri, 12 Jan 2007 15:21:26 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 9E9BB37E4F; Fri, 12 Jan 2007 15:21:25 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H5NHY-0005BS-Ta; Fri, 12 Jan 2007 15:21:24 +0100 Message-ID: <45A79964.9060405@levkowetz.com> Date: Fri, 12 Jan 2007 15:21:24 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Jeffrey Hutzelman References: <16F2931DDE74756E0DAF998D@sirius.fac.cs.cmu.edu> In-Reply-To: <16F2931DDE74756E0DAF998D@sirius.fac.cs.cmu.edu> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jhutz@cmu.edu, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Working Group Chairs , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Jeff, on 2007-01-11 23:02 Jeffrey Hutzelman said the following: > > On Wednesday, January 10, 2007 03:00:04 PM +0100 "Wijnen, Bert (Bert)" > wrote: > >> I wwonder if we want/need a WG State annotation tag of >> Dead WG document >> That is a document that once was a WG document, but has been >> declared dead, or no longer on the WG agenda. > > IMHO we do want something like that, if it's not there already. My WG has > several documents like that, and they never got to the IESG and so aren't > in the current tracker, some of them have progressed far enough to be in a > tracker that contains WG-level documents, before dying or being absorbed > into another document. Right. As indicated earlier, I've added this state in my working copy. >> I also wonder if it is possible (I know it is handy/useful) >> to have the (next) milestone date for each WG document listed. > > Good question. I think most documents go through a period when it is > possible, at least in the abstract. OTOH, a WG may have a work item which > results in several documents, with no milestone being set for later > documents until most of the work on the earlier one is done (no, I can't > think offhand of an example that shouldn't involve separate milestones, but > I can imagine the possibility). > > Maybe it would be good to have an optional next-milestone field, even if it > ends up having to be maintained manually by the WG chair. I think there are various ways we could achieve this, as I indicated in reply to Bert. One is that the secretariat already has mechanisms to email chairs about missed milestone deadlines; so a lot of the needed information is already in the system, and just needs to be extracted and displayed. I'll be looking further at this. Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 12 09:22:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NID-0005Rl-6H; Fri, 12 Jan 2007 09:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NIC-0005RY-1b; Fri, 12 Jan 2007 09:22:04 -0500 Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NIA-0005s9-HU; Fri, 12 Jan 2007 09:22:04 -0500 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id C1D7238DB4; Fri, 12 Jan 2007 15:22:01 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 66BE238D91; Fri, 12 Jan 2007 15:22:01 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 4C42D37E45; Fri, 12 Jan 2007 15:22:01 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H5NI8-0005Up-Sd; Fri, 12 Jan 2007 15:22:01 +0100 Message-ID: <45A79988.8050208@levkowetz.com> Date: Fri, 12 Jan 2007 15:22:00 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: "Drage, Keith (Keith)" References: <5D1A7985295922448D5550C94DE29180AB0EA1@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180AB0EA1@DEEXC1U01.de.lucent.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: drage@alcatel-lucent.com, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Working Group Chairs , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Keith, on 2007-01-12 01:14 Drage, Keith (Keith) said the following: > I have been led to understand that the charter milestones are kept in a > separate database. > > We have also been encouraged (at least in RAI) to add WGLC dates to the > charter milestones. > > There would seem to therefore be a need to link the milestone database > and the ID-tracker tool, rather than create a separate set of events. Yes, exactly. Henrik > Regards > > Keith > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: 10 January 2007 16:30 >> To: Wijnen, Bert (Bert) >> Cc: Working Group Chairs; proto-team@ietf.org >> Subject: Re: WG chair use of the ID-tracker: Proposed tool addition >> >> Hi Bert, >> >> on 2007-01-10 15:00 Wijnen, Bert (Bert) said the following: >> > I wwonder if we want/need a WG State annotation tag of >> > Dead WG document >> >> That seems to be very similar to Dan Wing's proposed 'Abandoned'. >> I've added "Dead WG Document" as a state in my working copy. >> >> > That is a document that once was a WG document, but has >> been declared >> > dead, or no longer on the WG agenda. >> > >> > I also wonder if it is possible (I know it is handy/useful) to have >> > the (next) milestone date for each WG document listed. >> >> Mmm. Good point. One question: is this best handled by >> manual annotation, or could / should it rather be calculated >> / deduced from other data (charter, a set of acceptable times >> between events, >> etc.) ? >> >> >> Henrik >> >> > Bert >> > >> >> -----Original Message----- >> >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> >> Sent: dinsdag 9 januari 2007 16:06 >> >> To: 'Working Group Chairs' >> >> Cc: proto-team@ietf.org >> >> Subject: WG chair use of the ID-tracker: Proposed tool addition >> >> >> >> Hi, >> >> >> >> The proto-team document that describes proposed changes to the >> >> ID-tracker (https://datatracker.ietf.org/) which makes it possible >> >> for WG chairs to use the I-D tracker for managing WG documents has >> >> been revised after the feedback from this list (May 2006). >> >> >> >> I've taken out all explicit state transitions; the tracker won't >> >> enforce or check the state transitions. I've also removed >> >> sub-states, and instead introduced annotations to capture >> such things >> >> as documents awaiting review. Multiple annotations may >> exist at the >> >> same time. >> >> >> >> As I also mentioned the last time: >> >> >> >> Since these changes and enhancements are explicitly meant for Your >> >> Use, Dear Fellow Chairs, it would be very good if you >> would read and >> >> comment on the document. Excluding boilerplate etc. the actual >> >> content is 6 pages long, so it should be manageable, especially if >> >> you check the diffs (see links below). >> >> >> >> The document is available from the internet-drafts repository: >> >> >> >> http://ietf.org/internet-drafts/draft-ietf-proto-wgchair-track >> > er-ext-01.txt >> >> >> >> Diffs between -00 and this version are available here: >> >> >> >> http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracke >> > r-ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.diff.html >> >> >> >> http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracke >> > r-ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.wdiff.html >> >> >> >> >> >> Please send comments to this list, with Cc: to >> proto-team@ietf.org . >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Henrik >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 12 10:49:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Of1-0002kp-2O; Fri, 12 Jan 2007 10:49:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Oey-0002kU-GG; Fri, 12 Jan 2007 10:49:40 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Oew-0001J3-Tc; Fri, 12 Jan 2007 10:49:40 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0CFnc1B034496; Fri, 12 Jan 2007 15:49:38 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0CFnbIZ1835152; Fri, 12 Jan 2007 15:49:37 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0CFnbpE022057; Fri, 12 Jan 2007 15:49:37 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0CFna2a022043; Fri, 12 Jan 2007 15:49:37 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA354984; Fri, 12 Jan 2007 16:49:36 +0100 Message-ID: <45A7AE0F.2040509@zurich.ibm.com> Date: Fri, 12 Jan 2007 16:49:35 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Drage, Keith \(Keith\)" References: <5D1A7985295922448D5550C94DE29180AB0EA1@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180AB0EA1@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Working Group Chairs , Henrik Levkowetz , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org On 2007-01-12 01:14, Drage, Keith (Keith) wrote: > I have been led to understand that the charter milestones are kept in a > separate database. > > We have also been encouraged (at least in RAI) to add WGLC dates to the > charter milestones. > > There would seem to therefore be a need to link the milestone database > and the ID-tracker tool, rather than create a separate set of events. Well, there is also a theory that we should have an agreed format for metadata interchange between the various tools and databases. We're unlikely to ever have only one database, when you consider the IANA and RFC Editor as part of the overall picture. That's work in progress, and meanwhile there will be some limits on what we can do within a single tool. (But from a systems design view, you're certainly correct.) Brian > > Regards > > Keith > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: 10 January 2007 16:30 >> To: Wijnen, Bert (Bert) >> Cc: Working Group Chairs; proto-team@ietf.org >> Subject: Re: WG chair use of the ID-tracker: Proposed tool addition >> >> Hi Bert, >> >> on 2007-01-10 15:00 Wijnen, Bert (Bert) said the following: >>> I wwonder if we want/need a WG State annotation tag of >>> Dead WG document >> That seems to be very similar to Dan Wing's proposed 'Abandoned'. >> I've added "Dead WG Document" as a state in my working copy. >> >>> That is a document that once was a WG document, but has >> been declared >>> dead, or no longer on the WG agenda. >>> >>> I also wonder if it is possible (I know it is handy/useful) to have >>> the (next) milestone date for each WG document listed. >> Mmm. Good point. One question: is this best handled by >> manual annotation, or could / should it rather be calculated >> / deduced from other data (charter, a set of acceptable times >> between events, >> etc.) ? >> >> >> Henrik >> >>> Bert >>> >>>> -----Original Message----- >>>> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >>>> Sent: dinsdag 9 januari 2007 16:06 >>>> To: 'Working Group Chairs' >>>> Cc: proto-team@ietf.org >>>> Subject: WG chair use of the ID-tracker: Proposed tool addition >>>> >>>> Hi, >>>> >>>> The proto-team document that describes proposed changes to the >>>> ID-tracker (https://datatracker.ietf.org/) which makes it possible >>>> for WG chairs to use the I-D tracker for managing WG documents has >>>> been revised after the feedback from this list (May 2006). >>>> >>>> I've taken out all explicit state transitions; the tracker won't >>>> enforce or check the state transitions. I've also removed >>>> sub-states, and instead introduced annotations to capture >> such things >>>> as documents awaiting review. Multiple annotations may >> exist at the >>>> same time. >>>> >>>> As I also mentioned the last time: >>>> >>>> Since these changes and enhancements are explicitly meant for Your >>>> Use, Dear Fellow Chairs, it would be very good if you >> would read and >>>> comment on the document. Excluding boilerplate etc. the actual >>>> content is 6 pages long, so it should be manageable, especially if >>>> you check the diffs (see links below). >>>> >>>> The document is available from the internet-drafts repository: >>>> >>>> http://ietf.org/internet-drafts/draft-ietf-proto-wgchair-track >>> er-ext-01.txt >>>> Diffs between -00 and this version are available here: >>>> >>>> http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracke >>> r-ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.diff.html >>>> >>>> http://tools.ietf.org/wg/proto/draft-ietf-proto-wgchair-tracke >>> r-ext/draft-ietf-proto-wgchair-tracker-ext-01-from-00.wdiff.html >>>> >>>> Please send comments to this list, with Cc: to >> proto-team@ietf.org . >>>> >>>> Thanks, >>>> >>>> >>>> Henrik >>>> >>>> >>>> >>>> >>>> >>>> >> > > > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 12 11:03:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Osc-00064n-VW; Fri, 12 Jan 2007 11:03:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Osb-00064f-5d; Fri, 12 Jan 2007 11:03:45 -0500 Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5OsZ-0004a2-S3; Fri, 12 Jan 2007 11:03:45 -0500 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 5AF7B38E85; Fri, 12 Jan 2007 17:03:43 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 215DF38E81; Fri, 12 Jan 2007 17:03:43 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id EB13237E45; Fri, 12 Jan 2007 17:03:42 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H5OsY-0003ii-FX; Fri, 12 Jan 2007 17:03:42 +0100 Message-ID: <45A7B15D.1020801@levkowetz.com> Date: Fri, 12 Jan 2007 17:03:41 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Matt Mathis References: <16F2931DDE74756E0DAF998D@sirius.fac.cs.cmu.edu> <45A79964.9060405@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mathis@psc.edu, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Working Group Chairs , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Matt, on 2007-01-12 16:33 Matt Mathis said the following: >> >> I wwonder if we want/need a WG State annotation tag of >> >> Dead WG document >> >> That is a document that once was a WG document, but has been >> >> declared dead, or no longer on the WG agenda. >> Right. As indicated earlier, I've added this state in my working copy. > > "Dead" feels a little extreme due to it's finality. How about "dropped", > meaning it was under consideration (at any level) but is not any longer. > > This would also apply to documents that came to the WG as candidate documents, > and the WG said, "not ready yet", please go do some more research and > reintroduce the idea later. "Dead" sounds like "go away and don't come back". > > TSVWG often sees documents that are way out in left field but contain some > truly interesting innovations. If there is detectable good stuff in with the > chaff, the WG advice is often "fix XY and Z" and reintroduce it later. That sounds more like another of the proposed states, "Parked WG Document", I think... Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 12 11:26:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PEO-0005gl-2t; Fri, 12 Jan 2007 11:26:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PEM-0005gZ-3G; Fri, 12 Jan 2007 11:26:14 -0500 Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5PEK-0002cR-MR; Fri, 12 Jan 2007 11:26:14 -0500 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 41872383D7; Fri, 12 Jan 2007 17:25:47 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id EEAA737E8B; Fri, 12 Jan 2007 17:25:46 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 675A437E54; Fri, 12 Jan 2007 17:26:10 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H5PEH-0003yu-L2; Fri, 12 Jan 2007 17:26:09 +0100 Message-ID: <45A7B69E.1010203@levkowetz.com> Date: Fri, 12 Jan 2007 17:26:06 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Matt Mathis References: <16F2931DDE74756E0DAF998D@sirius.fac.cs.cmu.edu> <45A79964.9060405@levkowetz.com> <45A7B15D.1020801@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mathis@psc.edu, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Working Group Chairs , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Matt, on 2007-01-12 17:15 Matt Mathis said the following: >> > "Dead" feels a little extreme due to it's finality. How about "dropped", >> > meaning it was under consideration (at any level) but is not any longer. > >> > TSVWG often sees documents that are way out in left field but contain some >> > truly interesting innovations. If there is detectable good stuff in with the >> > chaff, the WG advice is often "fix XY and Z" and reintroduce it later. >> >> That sounds more like another of the proposed states, "Parked WG Document", >> I think... > > No, some never come back, and the ones that do are often total rewrites, with > new authors, etc. so they are really new documents. > > TSVWG is sort of an exception, because "oddball" documents are in scope. I > would not want to keep one of these documents in the system, since the next > iteration is completely at the whim of the author. If it comes back, it has > to be treated as a new document. In that case, "Dead" sounds quite appropriate to me. But if other folks want a state in between "Dead" and "Parked", I can add one, certainly. Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 12 13:15:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qvi-0003zY-EA; Fri, 12 Jan 2007 13:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qvg-0003zO-Qu; Fri, 12 Jan 2007 13:15:04 -0500 Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Qve-0003Bf-Gj; Fri, 12 Jan 2007 13:15:04 -0500 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id C467438452; Fri, 12 Jan 2007 19:14:59 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8ACA837EAD; Fri, 12 Jan 2007 19:14:59 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3CCA437E6D; Fri, 12 Jan 2007 19:14:59 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H5Qva-0002wq-RW; Fri, 12 Jan 2007 19:14:58 +0100 Message-ID: <45A7D021.5080603@levkowetz.com> Date: Fri, 12 Jan 2007 19:14:57 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Matt Mathis References: <16F2931DDE74756E0DAF998D@sirius.fac.cs.cmu.edu> <45A79964.9060405@levkowetz.com> <45A7B15D.1020801@levkowetz.com> <45A7B69E.1010203@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mathis@psc.edu, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Working Group Chairs , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Matt, on 2007-01-12 17:49 Matt Mathis said the following: >> In that case, "Dead" sounds quite appropriate to me. But if other folks >> want a state in between "Dead" and "Parked", I can add one, certainly. > > No I was not advocating a new state, just a more accurate, less harsh name for > dead, because I fear resistance to using it since it implies final, when it > does not need to. Ok. I guess I'm leaning towards 'Dead' because it seems quite appropriate in most cases. If we have consensus on something else, that's fine. For now I'm going to add a clarifying comment saying that 'Dead' documents can be resurrected. Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Sun Jan 14 03:09:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H60QF-00046o-DW; Sun, 14 Jan 2007 03:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H60QD-0003yr-Nl; Sun, 14 Jan 2007 03:08:57 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H60QB-0002Pr-AK; Sun, 14 Jan 2007 03:08:57 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0E88s7a135618; Sun, 14 Jan 2007 08:08:54 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0E88sOo1257660; Sun, 14 Jan 2007 08:08:54 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0E88r3o025223; Sun, 14 Jan 2007 08:08:54 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0E88r8a025218; Sun, 14 Jan 2007 08:08:53 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA286344; Sun, 14 Jan 2007 09:08:52 +0100 Message-ID: <45A9E516.7010903@zurich.ibm.com> Date: Sun, 14 Jan 2007 09:08:54 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: David Harrington References: <001401c73678$8c8e4d20$0600a8c0@china.huawei.com> In-Reply-To: <001401c73678$8c8e4d20$0600a8c0@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'Matt Mathis' , 'Working Group Chairs' , 'Henrik Levkowetz' , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org On 2007-01-12 19:36, David Harrington wrote: > I'm fine with dead. Also, it's the existing term used in the tracker, and ADs already have a way to resurrect a dead draft. "Inactive" would be a slightly kinder term but it would need to be changed generally, not just for the WG case. Brian > > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > > >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Friday, January 12, 2007 1:15 PM >> To: Matt Mathis >> Cc: Working Group Chairs; proto-team@ietf.org >> Subject: Re: WG chair use of the ID-tracker: Proposed tool addition >> >> Hi Matt, >> >> on 2007-01-12 17:49 Matt Mathis said the following: >>>> In that case, "Dead" sounds quite appropriate to me. But >> if other folks >>>> want a state in between "Dead" and "Parked", I can add >> one, certainly. >>> No I was not advocating a new state, just a more accurate, >> less harsh name for >>> dead, because I fear resistance to using it since it >> implies final, when it >>> does not need to. >> Ok. I guess I'm leaning towards 'Dead' because it seems >> quite appropriate >> in most cases. If we have consensus on something else, >> that's fine. For >> now I'm going to add a clarifying comment saying that 'Dead' >> documents can >> be resurrected. >> >> >> Henrik >> >> > > > > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jan 17 09:05:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BQG-0007DY-M0; Wed, 17 Jan 2007 09:05:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7BQF-0007DQ-Ux; Wed, 17 Jan 2007 09:05:51 -0500 Received: from av9-1-sn3.vrr.skanova.net ([81.228.9.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7BQE-0006oo-LR; Wed, 17 Jan 2007 09:05:51 -0500 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id DBFA437E57; Wed, 17 Jan 2007 15:05:45 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id CB68737E42; Wed, 17 Jan 2007 15:05:45 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A66E737E4B; Wed, 17 Jan 2007 15:05:45 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz with esmtp (Exim 4.63) (envelope-from ) id 1H7BQ8-00048K-UL; Wed, 17 Jan 2007 15:05:45 +0100 Message-ID: <45AE2D35.2090600@levkowetz.com> Date: Wed, 17 Jan 2007 15:05:41 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Brian E Carpenter References: <5D1A7985295922448D5550C94DE29180AEEA4E@DEEXC1U01.de.lucent.com> <45AD205D.6040009@nortel.com> <45AE0155.8030301@zurich.ibm.com> In-Reply-To: <45AE0155.8030301@zurich.ibm.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brc@zurich.ibm.com, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: wgchairs@ietf.org, proto-team@ietf.org Subject: [proto-team] Re: Comment on draft-ietf-proto-wgchair-doc-shepherding-08 X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi, on 2007-01-17 11:58 Brian E Carpenter said the following: > Adding it to the template is a Good Idea, and maybe the shepherd > also needs the ability to set it in the tracker, which is a comment > on draft-ietf-proto-wgchair-tracker-ext. Right. What about adding the following to the tracker extensions draft: 3.4. Intended Status Field As part of the WG status handling, a field should also be available to indicate the intended status of a draft, with the possible values being (R-026): o "Informational" o "Experimental" o "Best Current Practice" o "Proposed Standard" o "Draft Standard" o "Full Standard" o "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. Apart from this, the comments on -01 seems to have slowed to a stop; if there's agreement on the above addition and no other new comments, I propose to put out a -02 update later today or tomorrow. Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Thu Jan 18 18:05:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7gKM-0003v7-5E; Thu, 18 Jan 2007 18:05:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7gKL-0003uu-37; Thu, 18 Jan 2007 18:05:49 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7gKJ-0002mB-N9; Thu, 18 Jan 2007 18:05:49 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4198F14225D; Thu, 18 Jan 2007 15:05:45 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26832-06; Thu, 18 Jan 2007 15:05:45 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F7AE142258; Thu, 18 Jan 2007 15:05:44 -0800 (PST) In-Reply-To: <45A9E516.7010903@zurich.ibm.com> References: <001401c73678$8c8e4d20$0600a8c0@china.huawei.com> <45A9E516.7010903@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <8CEB2FEB-EEBA-4CBC-AEFC-9D6D4D488E33@osafoundation.org> From: Lisa Dusseault Date: Thu, 18 Jan 2007 15:05:41 -0800 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'Working Group Chairs' , David Harrington , 'Henrik Levkowetz' , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1964131380==" Errors-To: proto-team-bounces@ietf.org --===============1964131380== Content-Type: multipart/alternative; boundary=Apple-Mail-5--271703170 --Apple-Mail-5--271703170 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I just have to suggest it: "Pining for the Fjords" as a state name? Lisa On Jan 14, 2007, at 12:08 AM, Brian E Carpenter wrote: > On 2007-01-12 19:36, David Harrington wrote: >> I'm fine with dead. > > Also, it's the existing term used in the tracker, and > ADs already have a way to resurrect a dead draft. > > "Inactive" would be a slightly kinder term but it would > need to be changed generally, not just for the WG case. --Apple-Mail-5--271703170 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I just have to suggest it: = "Pining for the Fjords" as a state name?

Lisa

On = Jan 14, 2007, at 12:08 AM, Brian E Carpenter wrote:

On 2007-01-12 19:36, David = Harrington wrote:

I'm fine with dead.=A0


Also, it's the existing term used in the tracker, = and

ADs = already have a way to resurrect a dead draft.


"Inactive" would be a slightly kinder term but it = would

need to = be changed generally, not just for the WG case.

=

= --Apple-Mail-5--271703170-- --===============1964131380== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1964131380==-- From proto-team-bounces@ietf.org Thu Jan 18 18:39:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7gr8-00032w-Nt; Thu, 18 Jan 2007 18:39:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7gr7-00032o-3Y; Thu, 18 Jan 2007 18:39:41 -0500 Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7gr4-00007D-Q8; Thu, 18 Jan 2007 18:39:41 -0500 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id EEC0A37F12; Fri, 19 Jan 2007 00:39:08 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id DCFA737ECF; Fri, 19 Jan 2007 00:39:08 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 3DEFA37E43; Fri, 19 Jan 2007 00:39:33 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz with esmtp (Exim 4.63) (envelope-from ) id 1H7gqy-000152-NW; Fri, 19 Jan 2007 00:39:32 +0100 Message-ID: <45B00530.8030604@levkowetz.com> Date: Fri, 19 Jan 2007 00:39:28 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Lisa Dusseault References: <001401c73678$8c8e4d20$0600a8c0@china.huawei.com> <45A9E516.7010903@zurich.ibm.com> <8CEB2FEB-EEBA-4CBC-AEFC-9D6D4D488E33@osafoundation.org> In-Reply-To: <8CEB2FEB-EEBA-4CBC-AEFC-9D6D4D488E33@osafoundation.org> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lisa@osafoundation.org, brc@zurich.ibm.com, ietfdbh@comcast.net, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'Working Group Chairs' , Brian E Carpenter , David Harrington , proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org on 2007-01-19 00:05 Lisa Dusseault said the following: > I just have to suggest it: "Pining for the Fjords" as a state name? *Big Laugh* :-D Now, why haven't anybody suggested "Pushing up Daises", eh :-)) Henrik > Lisa > > On Jan 14, 2007, at 12:08 AM, Brian E Carpenter wrote: > >> On 2007-01-12 19:36, David Harrington wrote: >>> I'm fine with dead. >> >> Also, it's the existing term used in the tracker, and >> ADs already have a way to resurrect a dead draft. >> >> "Inactive" would be a slightly kinder term but it would >> need to be changed generally, not just for the WG case. > > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 23 03:47:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HJT-0002rc-2j; Tue, 23 Jan 2007 03:47:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9HJR-0002rQ-Fs for proto-team@ietf.org; Tue, 23 Jan 2007 03:47:29 -0500 Received: from mtagate5.uk.ibm.com ([195.212.29.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9HJQ-0001yp-2c for proto-team@ietf.org; Tue, 23 Jan 2007 03:47:29 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0N8lOY5113642 for ; Tue, 23 Jan 2007 08:47:24 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0N8lOd81859590 for ; Tue, 23 Jan 2007 08:47:24 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0N8lOdT017792 for ; Tue, 23 Jan 2007 08:47:24 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0N8lOcL017774; Tue, 23 Jan 2007 08:47:24 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA72614; Tue, 23 Jan 2007 09:47:21 +0100 Message-ID: <45B5CB9A.2030300@zurich.ibm.com> Date: Tue, 23 Jan 2007 09:47:22 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: proto-team@ietf.org, Henrik Levkowetz References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Ray Pelletier , Phil Roberts Subject: [proto-team] Re: New Version Notification - draft-ietf-proto-wgchair-tracker-ext-02.txt X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Thanks for this. I think it covers the comments received. Do we need any more work before this becomes input to the tool development process via Ray? (Of course, we need draft-ietf-proto-iab-irtf-tracker-ext updated too.) Brian On 2007-01-22 21:50, ID Tracker wrote: > New version (-02) has been submitted for draft-ietf-proto-wgchair-tracker-ext-02.txt. > http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-tracker-ext-02.txt _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 23 11:32:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9OZC-0005q6-9C; Tue, 23 Jan 2007 11:32:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9OZA-0005py-P4; Tue, 23 Jan 2007 11:32:12 -0500 Received: from mtagate8.uk.ibm.com ([195.212.29.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9OZ9-0003zV-Cn; Tue, 23 Jan 2007 11:32:12 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate8.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0NGWAq8226030; Tue, 23 Jan 2007 16:32:10 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0NGWAg31634332; Tue, 23 Jan 2007 16:32:10 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0NGWAkq004630; Tue, 23 Jan 2007 16:32:10 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0NGW99e004618; Tue, 23 Jan 2007 16:32:09 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA209270; Tue, 23 Jan 2007 17:32:08 +0100 Message-ID: <45B63888.8060403@zurich.ibm.com> Date: Tue, 23 Jan 2007 17:32:08 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Black_David@emc.com References: <45A3AF42.9000101@levkowetz.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: wgchairs@ietf.org, henrik@levkowetz.com, proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org > > (B) As a document shepherd, I regularly find myself writing draft RFC > Editor Notes, and I believe that the responsible AD finds this > very useful, as it's more effective to have someone who knows > the > doc well draft RFC Editor Notes. Currently, these notes have > to be sent to the AD for the AD to put into the tracker. Would > it make sense for doc shepherds to be able to put proposed RFC > Editor Notes into the tracker? That is probably a design challenge, since they are mixed in with other parts of the AD's ballot writeup. I wouldn't insist on this, in case it would need some expensive re-working of that part of the tracker. It could be an optional requirement? Brian _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 23 12:14:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PEX-0002cT-7F; Tue, 23 Jan 2007 12:14:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PEV-0002cN-Jo for proto-team@ietf.org; Tue, 23 Jan 2007 12:14:55 -0500 Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9PET-0004jt-A9 for proto-team@ietf.org; Tue, 23 Jan 2007 12:14:55 -0500 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 900083805D; Tue, 23 Jan 2007 18:14:52 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 80C0A37FDB; Tue, 23 Jan 2007 18:14:52 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 27F0B37E47; Tue, 23 Jan 2007 18:14:51 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H9PEQ-0004Vv-Jm; Tue, 23 Jan 2007 18:14:50 +0100 Message-ID: <45B64288.3050802@levkowetz.com> Date: Tue, 23 Jan 2007 18:14:48 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Brian E Carpenter References: <45B5CB9A.2030300@zurich.ibm.com> In-Reply-To: <45B5CB9A.2030300@zurich.ibm.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brc@zurich.ibm.com, proto-team@ietf.org, rpelletier@isoc.org, Phil.Roberts@motorola.com, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Ray Pelletier , Phil Roberts , proto-team@ietf.org Subject: [proto-team] Re: New Version Notification - draft-ietf-proto-wgchair-tracker-ext-02.txt X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi Brian, on 2007-01-23 09:47 Brian E Carpenter said the following: > Thanks for this. I think it covers the comments received. Do we > need any more work before this becomes input to the tool development > process via Ray? I'd like to announce it on the wgchairs list again, saying that if no adverse comments are received during the week, we'll go forward with this. > (Of course, we need draft-ietf-proto-iab-irtf-tracker-ext updated > too.) Yes. I don't think we really need to implement these at the same time, but Ray probably want to negotiate the work as one package. I'm waiting to hear from both Aaron and Phil in order to complete this one. Regards, Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 23 12:26:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PPy-00065M-4m; Tue, 23 Jan 2007 12:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PPx-00065E-LG; Tue, 23 Jan 2007 12:26:45 -0500 Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9PPw-0000AS-AB; Tue, 23 Jan 2007 12:26:45 -0500 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id E7C6F380D1; Tue, 23 Jan 2007 18:26:43 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id D721B37EA0; Tue, 23 Jan 2007 18:26:43 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id CA9EB37E44; Tue, 23 Jan 2007 18:26:43 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H9PPr-0001wl-PP; Tue, 23 Jan 2007 18:26:39 +0100 Message-ID: <45B6454D.104@levkowetz.com> Date: Tue, 23 Jan 2007 18:26:37 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: WG Chairs X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: wgchairs@ietf.org, brc@zurich.ibm.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Brian E Carpenter , proto-team@ietf.org Subject: [proto-team] Tracker extension for Chairs, again. (draft-ietf-proto-wgchair-tracker-ext-02.txt) X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi, A new revision (-02) of draft-ietf-proto-wgchair-tracker-ext is now available, where I've tried to incorporate all the comments received here on the previous version (with one exception, the introduction of state synonyms such as "Ex-Parrot", "Pushing up Daisies", "Kicked the Bucket" etc. :-) It would be splendid if you could check the changes, and verify that the comments has been addressed. Diffs are here: http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-proto-wgchair-tracker-ext-02.txt http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-proto-wgchair-tracker-ext-02.txt&difftype=--hwdiff If there are no adverse comments during the next 7 days or so, I'll consider this mature enough to forward for implementation. Regards, Henrik -------- Original Message -------- Subject: New Version Notification - draft-ietf-proto-wgchair-tracker-ext-02.txt Date: Mon, 22 Jan 2007 15:50:02 -0500 From: ID Tracker To: mankin@psg.com, henrik@levkowetz.com, brc@zurich.ibm.com New version (-02) has been submitted for draft-ietf-proto-wgchair-tracker-ext-02.txt. http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-tracker-ext-02.txt IETF Secretariat. _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 23 12:36:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PZj-0005Hk-6b; Tue, 23 Jan 2007 12:36:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PZh-0005Gs-Mm; Tue, 23 Jan 2007 12:36:49 -0500 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9PZN-0004WK-Dk; Tue, 23 Jan 2007 12:36:49 -0500 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 9DF1E37F82; Tue, 23 Jan 2007 18:36:28 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 8BE3737E94; Tue, 23 Jan 2007 18:36:28 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 1F09837E43; Tue, 23 Jan 2007 18:36:27 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H9PZL-0002xd-J3; Tue, 23 Jan 2007 18:36:27 +0100 Message-ID: <45B6479B.5030500@levkowetz.com> Date: Tue, 23 Jan 2007 18:36:27 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Brian E Carpenter References: <45A3AF42.9000101@levkowetz.com> <45B63888.8060403@zurich.ibm.com> In-Reply-To: <45B63888.8060403@zurich.ibm.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: brc@zurich.ibm.com, Black_David@emc.com, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: wgchairs@ietf.org, Black_David@emc.com, proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org on 2007-01-23 17:32 Brian E Carpenter said the following: >> >> (B) As a document shepherd, I regularly find myself writing draft RFC >> Editor Notes, and I believe that the responsible AD finds this >> very useful, as it's more effective to have someone who knows >> the >> doc well draft RFC Editor Notes. Currently, these notes have >> to be sent to the AD for the AD to put into the tracker. Would >> it make sense for doc shepherds to be able to put proposed RFC >> Editor Notes into the tracker? > > That is probably a design challenge, since they are mixed in with > other parts of the AD's ballot writeup. I wouldn't insist on this, > in case it would need some expensive re-working of that part of > the tracker. It could be an optional requirement? Aha. So the comment I just sent off regarding this was wrong. Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 23 12:50:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PYz-0005E4-Og; Tue, 23 Jan 2007 12:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9PYn-00057V-CS for proto-team@ietf.org; Tue, 23 Jan 2007 12:35:53 -0500 Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9PXL-0002Rj-Ii for proto-team@ietf.org; Tue, 23 Jan 2007 12:34:37 -0500 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id D479638033; Tue, 23 Jan 2007 18:34:22 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id AF7B837E58; Tue, 23 Jan 2007 18:34:22 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 3605037E44; Tue, 23 Jan 2007 18:34:21 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H9PXI-0002mL-Cd; Tue, 23 Jan 2007 18:34:20 +0100 Message-ID: <45B6471B.20707@levkowetz.com> Date: Tue, 23 Jan 2007 18:34:19 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Black_David@emc.com References: <45A3AF42.9000101@levkowetz.com> In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Black_David@emc.com, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: wgchairs@ietf.org, proto-team@ietf.org Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi David, on 2007-01-23 16:49 Black_David@emc.com said the following: > I looked at the -02 version of the draft, and have a couple of > suggestions: > > (A) Drafts don't atomically transition from WG Last Call to Submitted > for publication. I don't know about other WG chairs, but I > can't > always produce the PROTO writeups instantaneously (among other > things, I always reread the draft as part of producing the > writeup). An annotation tag to indicate that the WGLC is > complete > probably suffices for this situation, and the overall state > should > be called "Working Group Last Call" as opposed to "In Working > Group Last Call" so that this tag makes sense. Ah. Good point. So tweaking your suggestion a little bit, I think we maybe should have two states for this: * In WG Last Call * Waiting for Document Shepherd Writeup Works? > (B) As a document shepherd, I regularly find myself writing draft RFC > Editor Notes, and I believe that the responsible AD finds this > very useful, as it's more effective to have someone who knows > the > doc well draft RFC Editor Notes. Currently, these notes have > to be sent to the AD for the AD to put into the tracker. Would > it make sense for doc shepherds to be able to put proposed RFC > Editor Notes into the tracker? There would need to be a cutoff > at some point prior to the telechat to make sure that the IESG > has seen the notes, or perhaps a warning that draft RFC Editor > notes entered too close to the telechat risk document deferral > to the next telechat due to lack of time for ADs to review them. Works for me (and doesn't require any document changes, I think, since the document on purpose leaves access open when not explicitly restricted. Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 23 14:04:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Qw4-0005zd-M9; Tue, 23 Jan 2007 14:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Qw4-0005zU-1V; Tue, 23 Jan 2007 14:04:00 -0500 Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Qw1-0002Nf-1q; Tue, 23 Jan 2007 14:04:00 -0500 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 9BF363808A; Tue, 23 Jan 2007 20:03:55 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 887F937E43; Tue, 23 Jan 2007 20:03:55 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 74A1737E42; Tue, 23 Jan 2007 20:02:55 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1H9Qux-0000a6-5O; Tue, 23 Jan 2007 20:02:51 +0100 Message-ID: <45B65BDA.80700@levkowetz.com> Date: Tue, 23 Jan 2007 20:02:50 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: soohong.park@samsung.com References: <463470.249711169577770583.JavaMail.weblogic@ep_ml25> In-Reply-To: <463470.249711169577770583.JavaMail.weblogic@ep_ml25> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: soohong.park@samsung.com, wgchairs@ietf.org, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "wgchairs@ietf.org" , "proto-team@ietf.org" Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Hi, on 2007-01-23 19:42 Daniel Park said the following: > Hi, > > One question on the 02-version: > > Defined WG States: > > * Candidate WG Document > This document is under consideration for becoming a working group > document. > (R-009) > > > How to guage folks consensus before straw poll, and who is > responsible for this judgement ? by chair only ? My thoughts on this was that this is a state which is available to the chair to indicate that someone has asked that a document be made a WG document. It does not imply any consensus at all, and it does not imply any precedence or selection. It's simply a way to flag in the tracker that somebody has asked for a document to be considered for adoption. > For example: > > o X-Document: WG Status: Candidate WG Document > > What next ? No one can submit another document wrt. > the same subject ? In line with the above, no, not at all - having this indication in the tracker doesn't change any of our processes at all. > Or strong battle is coming ? In my > feeling, it seems not easy for other guys to work for > the same subject once seeing the WG Status: Candidate > WG Document since this document is already under > consideration for becoming a WG adoption. Umm. Should this maybe be an annotation, rather than a state? Would that be better? Thoughts? Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jan 24 04:46:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9eiH-0005sp-Dt; Wed, 24 Jan 2007 04:46:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9eiG-0005se-37 for proto-team@ietf.org; Wed, 24 Jan 2007 04:46:40 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9eiE-0006yZ-KD for proto-team@ietf.org; Wed, 24 Jan 2007 04:46:40 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0O9kXs8183786 for ; Wed, 24 Jan 2007 09:46:33 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0O9kXEv1634434 for ; Wed, 24 Jan 2007 09:46:33 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0O9kWLh025392 for ; Wed, 24 Jan 2007 09:46:33 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0O9kWUl025377; Wed, 24 Jan 2007 09:46:32 GMT Received: from [9.4.210.68] ([9.4.210.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA204664; Wed, 24 Jan 2007 10:46:25 +0100 Message-ID: <45B71F78.9050608@zurich.ibm.com> Date: Wed, 24 Jan 2007 09:57:28 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Henrik Levkowetz References: <45B5CB9A.2030300@zurich.ibm.com> <45B64288.3050802@levkowetz.com> In-Reply-To: <45B64288.3050802@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Ray Pelletier , Phil Roberts , proto-team@ietf.org Subject: [proto-team] Re: New Version Notification - draft-ietf-proto-wgchair-tracker-ext-02.txt X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org On 2007-01-23 18:14, Henrik Levkowetz wrote: > Hi Brian, > > on 2007-01-23 09:47 Brian E Carpenter said the following: >> Thanks for this. I think it covers the comments received. Do we >> need any more work before this becomes input to the tool development >> process via Ray? > > I'd like to announce it on the wgchairs list again, saying that if no > adverse comments are received during the week, we'll go forward with > this. Indeed, it looks as if there will be one or two afterthoughts... >> (Of course, we need draft-ietf-proto-iab-irtf-tracker-ext updated >> too.) > > Yes. I don't think we really need to implement these at the same time, > but Ray probably want to negotiate the work as one package. Indeed. And if Michael has to update the database design, it's half as many bugs to do it in one go :-) Brian > I'm waiting > to hear from both Aaron and Phil in order to complete this one. > > > Regards, > > Henrik > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jan 24 11:13:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kkE-00041g-VW; Wed, 24 Jan 2007 11:13:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kkD-00041N-Iv for proto-team@ietf.org; Wed, 24 Jan 2007 11:13:05 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kjw-0008Vw-Aj for proto-team@ietf.org; Wed, 24 Jan 2007 11:13:05 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0OGABiO009824 for ; Wed, 24 Jan 2007 18:10:17 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 18:13:21 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 Jan 2007 18:13:21 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <455D83A7.4080708@zurich.ibm.com> References: <455D83A7.4080708@zurich.ibm.com> Message-Id: <9F7B4CA1-9416-47B7-B374-DB0AEE35D640@nokia.com> From: Lars Eggert Date: Wed, 24 Jan 2007 18:12:44 +0200 To: proto-team@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 24 Jan 2007 16:13:21.0338 (UTC) FILETIME=[911939A0:01C73FD2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bf4233733b870aa4c7e4f05ee0048ef2 Subject: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0366579830==" Errors-To: proto-team-bounces@ietf.org --===============0366579830== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-25-221920006; protocol="application/pkcs7-signature" --Apple-Mail-25-221920006 Content-Type: multipart/mixed; boundary=Apple-Mail-24-221919882 --Apple-Mail-24-221919882 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed (Sending to the mailing list, too.) Hi, attached is an update to wgchair-doc-shepherding that addresses some of the IESG comments. In all cases where there were multiple proposed resolutions, I opted for the smallest possible change. I'm completely OK with people preferring to fix things a different way, but please send text in this case. On 2006-11-17, at 11:40, Brian E Carpenter wrote: > 1. Please make all the changes currently logged as an RFC Editor note > (attached below for convenience). done > 2. To deal with Sam's DISCUSS, which he cleared, I promised to request > text updates in the I-D tracker to > a) align terminology: always refer to "responsible AD" and never > to "shepherding AD" and always refer to "document shepherd" and > not to "PROTO shepherd" ("PROTO" being jargon). I couldn't find any of these terms in the document anymore - did Sam review an older version than -08? > b) add a "Personnel" section and rename "Protocol Quality" to > "Document Quality" in the blank writeup. was already done, too? > 4. Re Russ' DISCUSS. Russ wasn't on the call. > > Part 1: "The examples in Appendix A do not follow the outline > proposed in Section 3.1 paragraph (1.k)." Please fix. fixed > Part 2: "it seems like it would be > better to post the Document Shepherd Write-Up Template, and put a > pointer to it in this document. This document could include the > current template with an appropriate introduction, like: > > The initial Document Shepherd Write-Up Template is included here, > but changes are expected over time." > > Makes sense, and we can host the latest template in the IESG > pages, so you could add "The latest version is available > in the IESG section of the IETF web site." (I don't want to > assume the PROTO web site will exist for ever.) I will do > this when the draft is approved. added > 5. I'd like you to look at all the other AD comments in the tracker. > That should lead to a number of small changes. > > Sam is concerned that paragraph (b) at the very end of (3.h) > might be read to encourage appeals. Of course, that all depends on > the meaning of "last resort" so there may be nothing you can > change. Open issues: - Ted wanting to allow the possibility of shepherd teams - Ted wanting to have section 6 removed (or rewritten) - Sam and Cullen thinking that the appeals stuff in step 3.h is too much - Russ wanting to have security questions added to the writeup - whether or not this should become an ION Lars --Apple-Mail-24-221919882 Content-Transfer-Encoding: 7bit Content-Type: text/xml; x-unix-mode=0644; name=draft-ietf-proto-wgchair-doc-shepherding.xml Content-Disposition: attachment; filename=draft-ietf-proto-wgchair-doc-shepherding.xml Document Shepherding from Working Group Last Call to Publication
Torsgatan 71 S-113 37 Stockholm Sweden +46 708 32 16 08 henrik@levkowetz.com
1225 Kincaid St Eugene OR 97403 USA +1 541 346 1747 dmm@1-4-5.net
Nokia Research Center
P.O. Box 407 00045 Nokia Group Finland +49 50 48 24461 lars.eggert@nokia.com http://research.nokia.com/people/lars_eggert
+1-301-728-7199 mankin@psg.com http://www.psg.com/~mankin
General Area PROTO Team Document Shepherding IETF Documents This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. A Document Shepherd's responsibilities include: Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested. During AD Evaluation by the Responsible Area Director, managing the discussion between the editors, the working group, and the Responsible Area Director. During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document. Following up on IANA and RFC Editor requests in the post-approval shepherding of the document. In summary, a Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has cared for it while responsible for the document in the working group.
Early in 2004, the IESG undertook several experiments aimed at evaluating whether any of the proposed changes to the IETF document flow process would yield qualitative improvements in document throughput and quality. One such experiment, referred to as the "PROTO process" or "PROTO" (because it was created by the "PROcess and TOols" or PROTO team), is a set of methodologies designed to involve working group chairs or secretaries more directly in their documents' approval life cycle. In particular, the PROTO team focused on improvements to the part of a document's life cycle that occurs after the working group and document editor have forwarded it to the IESG for publication. By the end of 2004, the IESG had evaluated the utility of the PROTO methodologies based on data obtained through several pilot projects that had run throughout the year, and subsequently decided to adopt the PROTO process for all documents and working groups. This document describes this process. The methodologies developed and piloted by the PROTO team focus on the working group chair or secretary as the primary Document Shepherd. The primary objective of this document shepherding process is to improve document-processing throughput and document quality by enabling a partnership between the Responsible Area Director and the Document Shepherd. In particular, this partnership has the explicit goal of enfranchising the Document Shepherd while at the same time offloading a specific part of the follow-up work that has traditionally been responsibility of the Responsible Area Director. The Responsible Area Director has tens or many tens of documents to follow, while the Document Shepherd has only a few at a time. Flowing the responsibility to the working group level can ensure more attention and more timely response. Consequently, the document shepherding process includes follow-up work during all document-processing stages after Working Group Last Call, i.e., during AD Evaluation of a document, during IESG evaluation, and during post-approval processing by IANA and the RFC Editor. In these stages, it is the responsibility of the Document Shepherd to track and follow up on feedback received on a document from all relevant parties. The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd. The remainder of this document is organised as follows: outlines the overall document shepherding process. describes the Document Shepherd Write-Up that accompanies the publication request of a document. describes the AD Evaluation shepherding process and describes IESG DISCUSS shepherding. Finally, describes those cases in which the document shepherding process should not be used.
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 BCP 14, RFC 2119 .
The document shepherding process consists of the following tasks: Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested, as described in . During AD Evaluation of the document by the Responsible Area Director, managing the discussion between the editors, the working group and the Responsible Area Director, as described in . During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document, as described in . Following up on IANA and RFC Editor requests as described in and . The shepherd must keep the document moving forward, communicating about it with parties who review and comment it. The shepherd must obtain the working group's consensus for any substantive proposed changes. The shepherd is the leader for the document and for the working group, and maintains a critical and technical perspective. In summary, the Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has done while responsible for the document in the working group. Before any document shepherding takes place, a single Document Shepherd MUST be identified for a document (he or she will be named in the Document Shepherd Write-Up) . Frequently, the chairs and the Responsible Area Director will decide that the working group will adopt the PROTO process for all their future documents. After that decision, the chairs, in consultation with the Responsible Area Director, decide on who should act as Document Shepherd for any given document. This is typically and by default one of the chairs of the working group. In consultation with the Responsible Area Director, the chairs MAY also decide to appoint the working group secretary as Document Shepherd for a given document. The Document Shepherd SHOULD NOT be an editor of the shepherded document. It is intended that the Document Shepherd role is filled by one person during the entire shepherding process. However, situations may occur when the Document Shepherd role may be reassigned to different persons during the lifetime of a document. It is up to the chairs and Responsible Area Director to identify situations when this may become necessary, and then consult to appoint a new Document Shepherd. It is important to note that the document shepherding process only applies to documents that are the product of a working group. It does not apply to documents that originate elsewhere. Additionally, discusses other instances in which the document shepherding process does not apply.
When a working group decides that a document is ready for submission to the IESG for publication, it is the task of the Document Shepherd to complete a "Document Shepherd Write-Up" for the document. There are two parts to this task. First, the Document Shepherd answers questions (1.a) to (1.j) below to give the Responsible Area Director insight into the working group process that applied to this document. Note that while these questions may appear redundant in some cases, they are written to elicit information that the Responsible Area Director must be aware of (to this end, pointers to relevant entries in the WG archive are helpful). The goal here is to inform the Responsible Area Director about any issues that may have come up in IETF meetings, on the mailing list, or in private communication that they should be aware of prior to IESG evaluation of the shepherded document. Any significant issues mentioned in the questionnaire will probably lead to a follow-up discussion with the Responsible Area Director. The second part of the task is to prepare the "Document Announcement Write-Up" that is input to both the ballot for the IESG telechat and to the eventual IETF-wide announcement message. Item number (1.k) describes the elements of the Document Announcement Write-Up. Some examples of Document Announcement Write-Ups are included in , and there are many more examples with subject lines such as "Protocol Action" and "Document Action" in the IETF-announce mailing list archive. The initial template for the Document Shepherd Write-Up is included below, but changes are expected over time. The latest version of this template is available from the IESG section of the IETF web site. Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in ? If so, list these downward references to support the Area Director in the Last Call procedure for them . Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See . If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Who is the Document Shepherd for this document? Who is the Responsible Area Director? The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, lead to possible appeals or is personal information needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. The Document Shepherd Write-Up is entered into the ID Tracker as a "Comment." The name and email address of the Document Shepherd are entered into the ID Tracker, currently as a "Brief Note" (this may change in the future). The email address of the Document Shepherd MUST also be added to the "State or Version Change Notice To" field (typically the email addresses of all working group chairs, authors and the secretary will be added). Entering the name and email of the Document Shepherd into the ID Tracker is REQUIRED to ensure that he or she will be copied on the email exchange between the editors, chairs, the IESG, the IESG secretariat, IANA and the RFC Editor during the review and approval process. There are still manual steps required for these parties to ensure they include the Document Shepherd, but it is hoped that in future, automated tools will ensure that Document Shepherds (and others) receive necessary communications. The contact information for the Document Shepherd is also important for the Gen-ART Directorate and other directorates, so they can know to whom to address reviews, in addition to the Responsible Area Director.
The steps for document shepherding during AD Evaluation are as follows: The Responsible Area Director reads, evaluates and comments on the document, as is the case when not using the document shepherding process. If the Responsible Area Director determines that the document is ready for IESG Evaluation, he or she indicates this to the Document Shepherd and the document shepherding process continues as described in . If the Responsible Area Director has identified issues with a document that must be addressed before IESG Evaluation can commence, he or she sends a full evaluation to the Document Shepherd and SHOULD also enter the review into the ID Tracker. The Document Shepherd reads the AD Evaluation comments, making very certain that all comments are understood, so that it is possible to follow up on them with the editors and working group. If there is some uncertainty as to what is requested, this SHOULD be resolved with the Responsible Area Director. The Document Shepherd sends the AD Evaluation comments to the editors and to the working group mailing list, in order to have a permanent record of the comments. It is RECOMMENDED that the Document Shepherd solicit from the editors an estimate on when the required changes will be complete and a revised document can be expected. Working groups that use issue tracking SHOULD also record the issues (and eventually their resolution) in their issue tracker. During the production of a revised document that addresses the AD Evaluation comments, it is RECOMMENDED that the editors keep a list showing how each comment was addressed and what the revised text is. It is RECOMMENDED that this list be forwarded to the Responsible Area Director together with the revised document. In the event that the editors or working group disagrees with a comment raised by the Responsible Area Director or has previously considered and dismissed the issue, the Document Shepherd MUST resolve the issue with the Responsible Area Director before a revised document can be submitted. The Document Shepherd iterates with the editors (and working group, if required) until all outstanding issues have been resolved and a revised document is available. At this point, the Document Shepherd notifies the Responsible Area Director and provides him or her with the revised document, the summary of issues and the resulting text changes. The Responsible Area Director verifies that the issues he or she found during AD Evaluation are resolved in the revised version of the document by starting the process described in this section at step (2.a). If the document underwent an IETF Last Call and the AD concludes that significant issues were raised during the Last Call, then steps (2.b) through (2.h) need to be applied addressing the Last Call issues. This requires the Responsible Area Director to present to the Document Shepherd those Last Call Issues raised only to the IESG.
During IESG Evaluation of a document, ADs can bring forward two kinds of remarks about a document: DISCUSS item and COMMENT items. A DISCUSS blocks a document's approval process until it has been resolved; a COMMENT does not. This section details the steps that a Document Shepherd takes to resolve any DISCUSS and COMMENT items brought forward against a shepherded document during IESG Evaluation. Note that DISCUSS and COMMENT items are occasionally written in a manner that makes their intent unclear. In these cases, the Document Shepherd SHOULD start a discussion with the ADs who brought the items up to clarify their intent, keeping the Responsible Area Director informed. If this fails to clarify the intent, the Responsible Area Director may need to work towards a clarification inside the IESG. Leading up to the IESG conference call, the Document Shepherd may see emails about the document from directorate reviewers on behalf of one or more ADs and also emailed copies of DISCUSS and COMMENT items entered into the ID Tracker. The Document Shepherd SHOULD immediately begin to work on resolving DISCUSS and COMMENT items with the ADs who have raised them, keeping the Responsible Area Director copied on the email exchange, so that he or she is able to support the the activity during the conference call. When dealing with directorate reviews, the Document Shepherd MUST involve the ADs to whom these directorates report to ensure that these ADs consider the review comments that need resolving. Immediately following the conference call, when the document changes state from the "IESG Evaluation" state to one of the states requiring Document Shepherd action, e.g., "IESG Evaluation: Revised ID Needed" or "IESG Evaluation: AD Followup", the Document Shepherd will receive email. A state of "AD Followup" typically signifies the Responsible Area Director's hope that a resolution may be possible through a continued discussion or (more usually) through a small set of changes as "Notes to the RFC Editor." Note that there may be very exceptional cases when DISCUSS items are registered after an IESG conference call. In these cases, the AD who has raised the DISCUSS MUST notify the Document Shepherd about it. (The notification facility in the ID Tracker is very convenient for this purpose and also for the cases where the DISCUSS and COMMENT items are updated after they are partially resolved.) The Document Shepherd then queries the ID Tracker to collect the remaining DISCUSS and COMMENT items raised against the document. The Document Shepherd analyses these items and initialises contact with the ADs who have placed them. The Responsible Area Director MUST be copied on all correspondence related to active DISCUSS or COMMENT items. This does not place the Responsible Area Director in the critical path towards a resolution, but should keep him or her informed about the state of the discussion.
| (3.c) | ------------> | (3.d) | +-------+ Comments +-------+ Comments +-------+ collected /|\ | understood | | | | Comments not fully understood | | (Further AD/Document Shepherd | | discussion required) +---+ ]]>
The Document Shepherd then coordinates the resolution of DISCUSS and COMMENT items and builds a consistent interpretation of the comments. This step is similar to much of the process described in .
| (3.d) | +-------+ Consistent +-------+ /|\ interpretation | | | Further AD/Document Shepherd | | discussion required +--------------------------+ ]]>
The Document Shepherd then communicates the DISCUSS and COMMENT items to the document editors and the working group, alerting them of any changes to the document that have accumulated during IESG processing, such as "Notes to the RFC Editor." If any changes will be substantive, the Document Shepherd, in consultation with the Responsible Area Director, as during other stages, MUST confirm working group consensus or sometimes even IETF consensus. After the editors resolve the DISCUSS and COMMENT items, the Document Shepherd reviews the resulting new version of the document, which will be a revised document, a set of "Notes to the RFC Editor", or both, using his or her technical expertise to ensure that all raised DISCUSS and COMMENT issues have been resolved. Note that the Document Shepherd MAY also suggest resolutions to DISCUSS and COMMENT items, enter them into an issue tracker, or perform other steps to streamline the resolution of the evaluation comments. It is very important to resolve the comments in a timely way, while the discussion is current for everyone involved. When the Document Shepherd is satisfied that the revised document addresses the evaluation comments, he or she communicates the resolution to the Responsible Area Director and the ADs that had raised the DISCUSS and COMMENT items. Each AD who had raised a DISCUSS checks whether the communicated resolution addresses his or her items. If it does, the AD will clear the DISCUSS. It it does not, the AD notifies the Document Shepherd and adds information to the ID Tracker explaining why the DISCUSS was not resolved. The Document Shepherd informs the working group accordingly. (COMMENT items need not be checked and cleared, because they do not block the document, but ADs are encouraged to do so.) If a DISCUSS was not resolved to the satisfaction of the AD that has raised it or the Responsible Area Director, two possibilities exist: The process returns to step (3.d), or If no progress can be made on the resolution of the DISCUSS with the AD who has raised it, despite clarification and additional involvement of the Responsible Area Director, the Document Shepherd and working group might as a very last resort consider an appeal in accordance with the procedures described in and referred to in . The Document Shepherd SHOULD review the IESG's Discuss Criteria guidelines and discuss with the Responsible Area Director whether there might be consideration against the unresolved DISCUSS by the rest of the IESG due to these guidelines. Once the process above has cleared all DISCUSS items, document shepherding continues with step (3.i). The Responsible Area Director moves the document to the "Approved - Announcement to be sent" state in the ID Tracker. If he or she deems the changes to the revised document significant, there may be a new WG last call, or possibly a new IETF last call. The document goes through a new full IESG Evaluation process if there is a new IETF last call.
IETF working group documents often include considerations requiring actions by the IANA, such as creating a new registry or adding information to an existing registry, perhaps after consulting an IESG-appointed Expert. Sometimes, the IESG requires actions, such as appointment of a new Expert. IANA-related processing may also include a specified type of Expert review, such as review of proposed MIME media types on the designated ietf-types mailing list. The IANA reviews IETF documents and requests responses at any or all of the following times: in response to IETF Last Call, during the IESG Evaluation review of the document, and at the time when the IANA performs actions in its web-based registry for the document, usually but not always after IESG approval of the document. More details of the IANA process and IETF interaction are found in . At the time of this publication, RFC2434 is under revision and the updates are and will be of value to the Document Shepherd. Note that Document Shepherd MUST determine (by individual review and consultation with others) what is the most recent and the most applicable IANA information and guidance for his or her document, be it the overall guidance, or external documents in his or her area, or in other areas. An example of an external document is . Whenever an IANA request comes, during whatever phase of the shepherding process, the requester from IANA MUST ensure that the Document Shepherd and the Responsible Area Director both receive the request. The Document Shepherd is responsible for responding as rapidly as possible. He or she should discuss requests that introduce any possible concerns with the working group. The Document Shepherd and the Responsible Area Director may decide in consultation that an IANA request leads to a change that needs additional review or approval. In general, the Document Shepherd ensures that the IANA process completes, checks that the registry is correct and that the IANA Matrix (http://www.iana.org/numbers.html) is complete and consistent, and troubleshoots when all is not well. At the end of IANA processing, the Document Shepherd should be sure that the RFC Editor has acknowledged IANA conclusion, i.e., that the handoff has been made. In summary, the task of shepherding the IANA actions is often overlooked, but is as important to coordinate and manage as all the other document reviews the Document Shepherd has managed. As with those, the Document Shepherd contributes greatly to quality and timeliness of the document by effective and responsive shepherding of the IANA requests.
After the IESG evaluation and resolution described in , the IESG approves the document, and the Responsible Area Director uses the ID Tracker to ask for any final changes to the Document Announcement Write-Up and for it to be issued. The Document Shepherd may have some edits for the Responsible Area Director, such as minor "Notes to the RFC Editor", and this is the time to consult and provide them. The IESG approval announcement goes to the general community and to the RFC Editor, and now the Document Shepherd (identified in the Announcement Write-Up) continues to shepherd the document through its technical publication. The RFC Editor currently makes a number of types of requests to the authors, Document Shepherd and Responsible Area Director. The Document Shepherd SHOULD lead in responding to the RFC Editor and shepherd the document during the post-approval period to its publication. The RFC Editor request types include: editorial queries about dangling, missing, informative and normative citations (good shepherding should try to catch these earlier, but they happen); requests for the document source (e.g., XML or nroff); occasional technical comments; and copy-edits for review and close scrutiny by the authors (AUTH48). For the latter, the Document Shepherd SHOULD lead in checking that copy-edits have in no case affected a consensus wording of the working group which prepared the document, and SHOULD bring speed to this checking by multiple coauthors. The Document Shepherd also consults with the Responsible Area Director on reviewing proposed post-approval changes to the document by any author. These may require Area Director approval, and they often need to be presented to the working group for consent if not a full consensus procedure. As in other phases of document shepherding, the Document Shepherd provides attentiveness and timeliness by serving as the informed representative of the document and helping its advancement and its integrity.
As mentioned in , the Document Shepherd SHOULD NOT be an editor of the shepherded document. If this cannot be avoided by making another working group chair or secretary the Document Shepherd, the document shepherding process SHOULD NOT be used. There are several other cases in which the document shepherding process SHOULD NOT be used. These include: Cases, where the Document Shepherd is the primary author or editor of a large percentage of the documents produced by the working group. Cases, where the Responsible Area Director expects communication difficulties with the Document Shepherd (either due to experience, strong views stated by the Document Shepherd, or other issues). Cases, where the working group itself is either very old, losing energy, or winding down, i.e., cases, where it would not be productive to initiate new processes or procedures. Finally, note that other cases exist in which using the document shepherding process may not be productive. The final determination as to whether to use the document shepherding process or not is left to the Responsible Area Director. If the document shepherding process is not used, the Responsible Area Director acts as Document Shepherd, per the existing procedures of shepherding by Area Directors.
This document specifies a change to IETF document-processing procedures. As such, it neither raises nor considers protocol-specific security issues.
This document creates no new requirements on IANA namespaces or other IANA requirements.
This document is the product of PROTO team, which includes the authors as well as Bill Fenner, Barbara Fuller, and Margaret Wasserman. Aaron Falk worked actively in PROTO until the start of 2006 and worked on earlier versions of the document. The Document Shepherd Write-Up originated in an idea by John Klensin. Thomas Narten and Margaret Wasserman implemented it for the entire Internet Area, and their template was the basis of the version used today. Colin Perkins wrote the original Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format included in . David Black wrote the original Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel included in . Both original announcements have been modified to reflect changes to the Document Announcement Write-Up template since they were written. Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call.
The IETF Internet-Draft Tracker The IESG PROcess and TOols (PROTO) Team The General Area Review Team (GEN-ART)
This appendix includes two examples of Document Announcement Write-Ups. Many more examples with Subject lines such as "Protocol Action" and "Document Action" can be found in the IETF-announce mailing list archive.
These documents define the RTP Payload format for MIDI (Musical Instrument Digital Interface), and additional guidelines on implementation specifically concerning the timing of reception and transmission for best performance in different applications. MIDI is a real-time media, which however is brittle to losses and errors. Therefore the RTP payload format defines recovery journals as a way of avoiding persistent audible errors, and discusses congestion control handling for these journals. The RTP payload for MIDI encodes the broad range of MIDI commands. The format is suitable for interactive applications (such as network musical performance) and content-delivery (such as file streaming). There is consensus in the WG to publish these documents. This RTP Payload format has been implemented during the development of the specification and successfully tested over an IP network between two remote sites, thus showing that the technical solution is successfully working. It has been reviewed by the MIDI Manufacturers Association and their comments have been addressed. Magnus Westerlund and Colin Perkins jointly shepherded this document. Allison Mankin reviewed the document for the IESG, including a careful review with the editor of the media types, in parallel with ietf-types list review requested on 2006-01-08, which raised no issues.
This document specifies the encapsulation of IPv6, IPv4 and ARP packets over Fibre Channel. This document also specifies the methods for forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document (when published as RFC) obsoletes RFC2625 and RFC3831. This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG. There is solid support for this document both in the WG and from T11. This document replaces and consolidates two separate RFCs on IPv4 over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 3831). Most of its technical content is unchanged from those RFCs. The technical changes that have been made are primarily based on implementation experience. The protocol has been reviewed for the IESG by David L. Black (WG chair). Bert Wijnen has reviewed this document for the IESG. In addition, Brian Haberman has done a review for the INT Area as requested by WG-chair (David Black) via Margaret Wasserman.
--Apple-Mail-24-221919882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name=draft-ietf-proto-wgchair-doc-shepherding.txt Content-Disposition: attachment; filename=draft-ietf-proto-wgchair-doc-shepherding.txt PROTO Team H. Levkowetz Internet-Draft Ericsson Intended status: Informational D. Meyer Expires: July 28, 2007 Cisco/University of Oregon L. Eggert Nokia A. Mankin January 24, 2007 Document Shepherding from Working Group Last Call to Publication draft-ietf-proto-wgchair-doc-shepherding-09 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 July 28, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been Levkowetz, et al. Expires July 28, 2007 [Page 1] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. A Document Shepherd's responsibilities include: o Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested. o During AD Evaluation by the Responsible Area Director, managing the discussion between the editors, the working group, and the Responsible Area Director. o During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document. o Following up on IANA and RFC Editor requests in the post-approval shepherding of the document. In summary, a Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has cared for it while responsible for the document in the working group. Levkowetz, et al. Expires July 28, 2007 [Page 2] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6 3.2. Document Shepherding during AD Evaluation . . . . . . . . 10 3.3. Document Shepherding during IESG Evaluation . . . . . . . 11 4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14 5. Document Shepherding after IESG Approval . . . . . . . . . . . 15 6. When Not to Use the Document Shepherding Process . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Example Document Announcement Write-Ups . . . . . . . 18 A.1. Example Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 19 A.2. Example Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Levkowetz, et al. Expires July 28, 2007 [Page 3] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 1. Introduction Early in 2004, the IESG undertook several experiments aimed at evaluating whether any of the proposed changes to the IETF document flow process would yield qualitative improvements in document throughput and quality. One such experiment, referred to as the "PROTO process" or "PROTO" (because it was created by the "PROcess and TOols" or PROTO [PROTO] team), is a set of methodologies designed to involve working group chairs or secretaries more directly in their documents' approval life cycle. In particular, the PROTO team focused on improvements to the part of a document's life cycle that occurs after the working group and document editor have forwarded it to the IESG for publication. By the end of 2004, the IESG had evaluated the utility of the PROTO methodologies based on data obtained through several pilot projects that had run throughout the year, and subsequently decided to adopt the PROTO process for all documents and working groups. This document describes this process. The methodologies developed and piloted by the PROTO team focus on the working group chair or secretary as the primary Document Shepherd. The primary objective of this document shepherding process is to improve document-processing throughput and document quality by enabling a partnership between the Responsible Area Director and the Document Shepherd. In particular, this partnership has the explicit goal of enfranchising the Document Shepherd while at the same time offloading a specific part of the follow-up work that has traditionally been responsibility of the Responsible Area Director. The Responsible Area Director has tens or many tens of documents to follow, while the Document Shepherd has only a few at a time. Flowing the responsibility to the working group level can ensure more attention and more timely response. Consequently, the document shepherding process includes follow-up work during all document-processing stages after Working Group Last Call, i.e., during AD Evaluation of a document, during IESG evaluation, and during post-approval processing by IANA and the RFC Editor. In these stages, it is the responsibility of the Document Shepherd to track and follow up on feedback received on a document from all relevant parties. The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd. The remainder of this document is organised as follows: Section 3 Levkowetz, et al. Expires July 28, 2007 [Page 4] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 outlines the overall document shepherding process. Section 3.1 describes the Document Shepherd Write-Up that accompanies the publication request of a document. Section 3.2 describes the AD Evaluation shepherding process and Section 3.3 describes IESG DISCUSS shepherding. Finally, Section 6 describes those cases in which the document shepherding process should not be used. 2. Terminology 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 BCP 14, RFC 2119 [RFC2119]. 3. Process Description The document shepherding process consists of the following tasks: o Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested, as described in Section 3.1. o During AD Evaluation of the document by the Responsible Area Director, managing the discussion between the editors, the working group and the Responsible Area Director, as described in Section 3.2. o During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document, as described in Section 3.3. o Following up on IANA and RFC Editor requests as described in Section 4 and Section 5. The shepherd must keep the document moving forward, communicating about it with parties who review and comment it. The shepherd must obtain the working group's consensus for any substantive proposed changes. The shepherd is the leader for the document and for the working group, and maintains a critical and technical perspective. In summary, the Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has done while responsible for the document in the working group. Before any document shepherding takes place, a single Document Shepherd MUST be identified for a document (he or she will be named in the Document Shepherd Write-Up) . Frequently, the chairs and the Levkowetz, et al. Expires July 28, 2007 [Page 5] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Responsible Area Director will decide that the working group will adopt the PROTO process for all their future documents. After that decision, the chairs, in consultation with the Responsible Area Director, decide on who should act as Document Shepherd for any given document. This is typically and by default one of the chairs of the working group. In consultation with the Responsible Area Director, the chairs MAY also decide to appoint the working group secretary as Document Shepherd for a given document. The Document Shepherd SHOULD NOT be an editor of the shepherded document. It is intended that the Document Shepherd role is filled by one person during the entire shepherding process. However, situations may occur when the Document Shepherd role may be reassigned to different persons during the lifetime of a document. It is up to the chairs and Responsible Area Director to identify situations when this may become necessary, and then consult to appoint a new Document Shepherd. It is important to note that the document shepherding process only applies to documents that are the product of a working group. It does not apply to documents that originate elsewhere. Additionally, Section 6 discusses other instances in which the document shepherding process does not apply. 3.1. Document Shepherd Write-Up When a working group decides that a document is ready for submission to the IESG for publication, it is the task of the Document Shepherd to complete a "Document Shepherd Write-Up" for the document. There are two parts to this task. First, the Document Shepherd answers questions (1.a) to (1.j) below to give the Responsible Area Director insight into the working group process that applied to this document. Note that while these questions may appear redundant in some cases, they are written to elicit information that the Responsible Area Director must be aware of (to this end, pointers to relevant entries in the WG archive are helpful). The goal here is to inform the Responsible Area Director about any issues that may have come up in IETF meetings, on the mailing list, or in private communication that they should be aware of prior to IESG evaluation of the shepherded document. Any significant issues mentioned in the questionnaire will probably lead to a follow-up discussion with the Responsible Area Director. The second part of the task is to prepare the "Document Announcement Write-Up" that is input to both the ballot for the IESG telechat and to the eventual IETF-wide announcement message. Item number (1.k) describes the elements of the Document Announcement Write-Up. Levkowetz, et al. Expires July 28, 2007 [Page 6] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Some examples of Document Announcement Write-Ups are included in Appendix A, and there are many more examples with subject lines such as "Protocol Action" and "Document Action" in the IETF-announce mailing list archive. The initial template for the Document Shepherd Write-Up is included below, but changes are expected over time. The latest version of this template is available from the IESG section of the IETF web site. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Levkowetz, et al. Expires July 28, 2007 [Page 7] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Levkowetz, et al. Expires July 28, 2007 [Page 8] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, lead to possible appeals or is personal information needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. The Document Shepherd Write-Up is entered into the ID Tracker [IDTRACKER] as a "Comment." The name and email address of the Document Shepherd are entered into the ID Tracker, currently as a "Brief Note" (this may change in the future). The email address of the Document Shepherd MUST also be added to the "State or Version Change Notice To" field (typically the email addresses of all working group chairs, authors and the secretary will be added). Entering the name and email of the Document Shepherd into the ID Tracker is REQUIRED to ensure that he or she will be copied on the email exchange between the editors, chairs, the IESG, the IESG secretariat, IANA and the RFC Editor during the review and approval process. There are still manual steps required for these parties to ensure they include the Document Shepherd, but it is hoped that in future, automated tools will ensure that Document Shepherds (and Levkowetz, et al. Expires July 28, 2007 [Page 9] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 others) receive necessary communications. The contact information for the Document Shepherd is also important for the Gen-ART Directorate [GEN-ART] and other directorates, so they can know to whom to address reviews, in addition to the Responsible Area Director. 3.2. Document Shepherding during AD Evaluation The steps for document shepherding during AD Evaluation are as follows: (2.a) The Responsible Area Director reads, evaluates and comments on the document, as is the case when not using the document shepherding process. If the Responsible Area Director determines that the document is ready for IESG Evaluation, he or she indicates this to the Document Shepherd and the document shepherding process continues as described in Section 3.3. (2.b) If the Responsible Area Director has identified issues with a document that must be addressed before IESG Evaluation can commence, he or she sends a full evaluation to the Document Shepherd and SHOULD also enter the review into the ID Tracker. (2.c) The Document Shepherd reads the AD Evaluation comments, making very certain that all comments are understood, so that it is possible to follow up on them with the editors and working group. If there is some uncertainty as to what is requested, this SHOULD be resolved with the Responsible Area Director. (2.d) The Document Shepherd sends the AD Evaluation comments to the editors and to the working group mailing list, in order to have a permanent record of the comments. It is RECOMMENDED that the Document Shepherd solicit from the editors an estimate on when the required changes will be complete and a revised document can be expected. Working groups that use issue tracking SHOULD also record the issues (and eventually their resolution) in their issue tracker. (2.e) During the production of a revised document that addresses the AD Evaluation comments, it is RECOMMENDED that the editors keep a list showing how each comment was addressed and what the revised text is. It is RECOMMENDED that this list be forwarded to the Responsible Area Director together with the revised document. Levkowetz, et al. Expires July 28, 2007 [Page 10] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 (2.f) In the event that the editors or working group disagrees with a comment raised by the Responsible Area Director or has previously considered and dismissed the issue, the Document Shepherd MUST resolve the issue with the Responsible Area Director before a revised document can be submitted. (2.g) The Document Shepherd iterates with the editors (and working group, if required) until all outstanding issues have been resolved and a revised document is available. At this point, the Document Shepherd notifies the Responsible Area Director and provides him or her with the revised document, the summary of issues and the resulting text changes. (2.h) The Responsible Area Director verifies that the issues he or she found during AD Evaluation are resolved in the revised version of the document by starting the process described in this section at step (2.a). (2.i) If the document underwent an IETF Last Call and the AD concludes that significant issues were raised during the Last Call, then steps (2.b) through (2.h) need to be applied addressing the Last Call issues. This requires the Responsible Area Director to present to the Document Shepherd those Last Call Issues raised only to the IESG. 3.3. Document Shepherding during IESG Evaluation During IESG Evaluation of a document, ADs can bring forward two kinds of remarks about a document: DISCUSS item and COMMENT items. A DISCUSS blocks a document's approval process until it has been resolved; a COMMENT does not. This section details the steps that a Document Shepherd takes to resolve any DISCUSS and COMMENT items brought forward against a shepherded document during IESG Evaluation. Note that DISCUSS and COMMENT items are occasionally written in a manner that makes their intent unclear. In these cases, the Document Shepherd SHOULD start a discussion with the ADs who brought the items up to clarify their intent, keeping the Responsible Area Director informed. If this fails to clarify the intent, the Responsible Area Director may need to work towards a clarification inside the IESG. (3.a) Leading up to the IESG conference call, the Document Shepherd may see emails about the document from directorate reviewers on behalf of one or more ADs and also emailed copies of DISCUSS and COMMENT items entered into the ID Tracker. The Document Shepherd SHOULD immediately begin to work on resolving DISCUSS and COMMENT items with the ADs who have raised them, keeping the Responsible Area Director copied on Levkowetz, et al. Expires July 28, 2007 [Page 11] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 the email exchange, so that he or she is able to support the the activity during the conference call. When dealing with directorate reviews, the Document Shepherd MUST involve the ADs to whom these directorates report to ensure that these ADs consider the review comments that need resolving. (3.b) Immediately following the conference call, when the document changes state from the "IESG Evaluation" state to one of the states requiring Document Shepherd action, e.g., "IESG Evaluation: Revised ID Needed" or "IESG Evaluation: AD Followup", the Document Shepherd will receive email. A state of "AD Followup" typically signifies the Responsible Area Director's hope that a resolution may be possible through a continued discussion or (more usually) through a small set of changes as "Notes to the RFC Editor." Note that there may be very exceptional cases when DISCUSS items are registered after an IESG conference call. In these cases, the AD who has raised the DISCUSS MUST notify the Document Shepherd about it. (The notification facility in the ID Tracker is very convenient for this purpose and also for the cases where the DISCUSS and COMMENT items are updated after they are partially resolved.) (3.c) The Document Shepherd then queries the ID Tracker to collect the remaining DISCUSS and COMMENT items raised against the document. The Document Shepherd analyses these items and initialises contact with the ADs who have placed them. The Responsible Area Director MUST be copied on all correspondence related to active DISCUSS or COMMENT items. This does not place the Responsible Area Director in the critical path towards a resolution, but should keep him or her informed about the state of the discussion. +-------+ +-------+ +-------+ | (3.b) | -----------> | (3.c) | ------------> | (3.d) | +-------+ Comments +-------+ Comments +-------+ collected /|\ | understood | | | | Comments not fully understood | | (Further AD/Document Shepherd | | discussion required) +---+ Levkowetz, et al. Expires July 28, 2007 [Page 12] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 (3.d) The Document Shepherd then coordinates the resolution of DISCUSS and COMMENT items and builds a consistent interpretation of the comments. This step is similar to much of the process described in Section 3.2. +-------+ +-------+ | (3.c) | ---------------> | (3.d) | +-------+ Consistent +-------+ /|\ interpretation | | | Further AD/Document Shepherd | | discussion required +--------------------------+ (3.e) The Document Shepherd then communicates the DISCUSS and COMMENT items to the document editors and the working group, alerting them of any changes to the document that have accumulated during IESG processing, such as "Notes to the RFC Editor." If any changes will be substantive, the Document Shepherd, in consultation with the Responsible Area Director, as during other stages, MUST confirm working group consensus or sometimes even IETF consensus. (3.f) After the editors resolve the DISCUSS and COMMENT items, the Document Shepherd reviews the resulting new version of the document, which will be a revised document, a set of "Notes to the RFC Editor", or both, using his or her technical expertise to ensure that all raised DISCUSS and COMMENT issues have been resolved. Note that the Document Shepherd MAY also suggest resolutions to DISCUSS and COMMENT items, enter them into an issue tracker, or perform other steps to streamline the resolution of the evaluation comments. It is very important to resolve the comments in a timely way, while the discussion is current for everyone involved. (3.g) When the Document Shepherd is satisfied that the revised document addresses the evaluation comments, he or she communicates the resolution to the Responsible Area Director and the ADs that had raised the DISCUSS and COMMENT items. (3.h) Each AD who had raised a DISCUSS checks whether the communicated resolution addresses his or her items. If it does, the AD will clear the DISCUSS. It it does not, the AD notifies the Document Shepherd and adds information to the ID Tracker explaining why the DISCUSS was not resolved. The Document Shepherd informs the working group accordingly. (COMMENT items need not be checked and cleared, because they Levkowetz, et al. Expires July 28, 2007 [Page 13] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 do not block the document, but ADs are encouraged to do so.) If a DISCUSS was not resolved to the satisfaction of the AD that has raised it or the Responsible Area Director, two possibilities exist: (a) The process returns to step (3.d), or (b) If no progress can be made on the resolution of the DISCUSS with the AD who has raised it, despite clarification and additional involvement of the Responsible Area Director, the Document Shepherd and working group might as a very last resort consider an appeal in accordance with the procedures described in [RFC2026] and referred to in [RFC2418]. The Document Shepherd SHOULD review the IESG's Discuss Criteria guidelines [I-D.iesg-discuss-criteria] and discuss with the Responsible Area Director whether there might be consideration against the unresolved DISCUSS by the rest of the IESG due to these guidelines. Once the process above has cleared all DISCUSS items, document shepherding continues with step (3.i). (3.i) The Responsible Area Director moves the document to the "Approved - Announcement to be sent" state in the ID Tracker. If he or she deems the changes to the revised document significant, there may be a new WG last call, or possibly a new IETF last call. The document goes through a new full IESG Evaluation process if there is a new IETF last call. 4. Shepherding the Document's IANA Actions IETF working group documents often include considerations requiring actions by the IANA, such as creating a new registry or adding information to an existing registry, perhaps after consulting an IESG-appointed Expert. Sometimes, the IESG requires actions, such as appointment of a new Expert. IANA-related processing may also include a specified type of Expert review, such as review of proposed MIME media types on the designated ietf-types mailing list. The IANA reviews IETF documents and requests responses at any or all of the following times: in response to IETF Last Call, during the IESG Evaluation review of the document, and at the time when the IANA performs actions in its web-based registry for the document, usually but not always after IESG approval of the document. More details of the IANA process and IETF interaction are found in [RFC2434]. Levkowetz, et al. Expires July 28, 2007 [Page 14] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 At the time of this publication, RFC2434 is under revision [I-D.narten-iana-considerations-rfc2434bis] and the updates are and will be of value to the Document Shepherd. Note that Document Shepherd MUST determine (by individual review and consultation with others) what is the most recent and the most applicable IANA information and guidance for his or her document, be it the overall guidance, or external documents in his or her area, or in other areas. An example of an external document is [RFC4020]. Whenever an IANA request comes, during whatever phase of the shepherding process, the requester from IANA MUST ensure that the Document Shepherd and the Responsible Area Director both receive the request. The Document Shepherd is responsible for responding as rapidly as possible. He or she should discuss requests that introduce any possible concerns with the working group. The Document Shepherd and the Responsible Area Director may decide in consultation that an IANA request leads to a change that needs additional review or approval. In general, the Document Shepherd ensures that the IANA process completes, checks that the registry is correct and that the IANA Matrix (http://www.iana.org/numbers.html) is complete and consistent, and troubleshoots when all is not well. At the end of IANA processing, the Document Shepherd should be sure that the RFC Editor has acknowledged IANA conclusion, i.e., that the handoff has been made. In summary, the task of shepherding the IANA actions is often overlooked, but is as important to coordinate and manage as all the other document reviews the Document Shepherd has managed. As with those, the Document Shepherd contributes greatly to quality and timeliness of the document by effective and responsive shepherding of the IANA requests. 5. Document Shepherding after IESG Approval After the IESG evaluation and resolution described in Section 3.3, the IESG approves the document, and the Responsible Area Director uses the ID Tracker to ask for any final changes to the Document Announcement Write-Up and for it to be issued. The Document Shepherd may have some edits for the Responsible Area Director, such as minor "Notes to the RFC Editor", and this is the time to consult and provide them. The IESG approval announcement goes to the general community and to the RFC Editor, and now the Document Shepherd (identified in the Announcement Write-Up) continues to shepherd the document through its Levkowetz, et al. Expires July 28, 2007 [Page 15] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 technical publication. The RFC Editor currently makes a number of types of requests to the authors, Document Shepherd and Responsible Area Director. The Document Shepherd SHOULD lead in responding to the RFC Editor and shepherd the document during the post-approval period to its publication. The RFC Editor request types include: editorial queries about dangling, missing, informative and normative citations (good shepherding should try to catch these earlier, but they happen); requests for the document source (e.g., XML or nroff); occasional technical comments; and copy-edits for review and close scrutiny by the authors (AUTH48). For the latter, the Document Shepherd SHOULD lead in checking that copy-edits have in no case affected a consensus wording of the working group which prepared the document, and SHOULD bring speed to this checking by multiple coauthors. The Document Shepherd also consults with the Responsible Area Director on reviewing proposed post-approval changes to the document by any author. These may require Area Director approval, and they often need to be presented to the working group for consent if not a full consensus procedure. As in other phases of document shepherding, the Document Shepherd provides attentiveness and timeliness by serving as the informed representative of the document and helping its advancement and its integrity. 6. When Not to Use the Document Shepherding Process As mentioned in Section 3, the Document Shepherd SHOULD NOT be an editor of the shepherded document. If this cannot be avoided by making another working group chair or secretary the Document Shepherd, the document shepherding process SHOULD NOT be used. There are several other cases in which the document shepherding process SHOULD NOT be used. These include: 1. Cases, where the Document Shepherd is the primary author or editor of a large percentage of the documents produced by the working group. 2. Cases, where the Responsible Area Director expects communication difficulties with the Document Shepherd (either due to experience, strong views stated by the Document Shepherd, or other issues). 3. Cases, where the working group itself is either very old, losing energy, or winding down, i.e., cases, where it would not be productive to initiate new processes or procedures. Levkowetz, et al. Expires July 28, 2007 [Page 16] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Finally, note that other cases exist in which using the document shepherding process may not be productive. The final determination as to whether to use the document shepherding process or not is left to the Responsible Area Director. If the document shepherding process is not used, the Responsible Area Director acts as Document Shepherd, per the existing procedures of shepherding by Area Directors. 7. Security Considerations This document specifies a change to IETF document-processing procedures. As such, it neither raises nor considers protocol- specific security issues. 8. IANA Considerations This document creates no new requirements on IANA namespaces or other IANA requirements. 9. Acknowledgments This document is the product of PROTO team, which includes the authors as well as Bill Fenner, Barbara Fuller, and Margaret Wasserman. Aaron Falk worked actively in PROTO until the start of 2006 and worked on earlier versions of the document. The Document Shepherd Write-Up originated in an idea by John Klensin. Thomas Narten and Margaret Wasserman implemented it for the entire Internet Area, and their template was the basis of the version used today. Colin Perkins wrote the original Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black wrote the original Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both original announcements have been modified to reflect changes to the Document Announcement Write-Up template since they were written. Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call. 10. Informative References [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Levkowetz, et al. Expires July 28, 2007 [Page 17] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. [I-D.iesg-discuss-criteria] Peterson, J., "DISCUSS Criteria in IESG Review", draft-iesg-discuss-criteria-02 (work in progress), February 2006. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-05 (work in progress), September 2006. [IDTRACKER] "The IETF Internet-Draft Tracker", Web Application: https://datatracker.ietf.org/, 2002. [PROTO] "The IESG PROcess and TOols (PROTO) Team", Web Page: http://psg.com/~mrw/PROTO-Team, 2004. [GEN-ART] "The General Area Review Team (GEN-ART)", Web Page: http://www.alvestrand.no/ietf/gen/review-guidelines.html, 2005. Appendix A. Example Document Announcement Write-Ups This appendix includes two examples of Document Announcement Write- Ups. Many more examples with Subject lines such as "Protocol Action" and "Document Action" can be found in the IETF-announce mailing list Levkowetz, et al. Expires July 28, 2007 [Page 18] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 archive. A.1. Example Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format Technical Summary These documents define the RTP Payload format for MIDI (Musical Instrument Digital Interface), and additional guidelines on implementation specifically concerning the timing of reception and transmission for best performance in different applications. MIDI is a real-time media, which however is brittle to losses and errors. Therefore the RTP payload format defines recovery journals as a way of avoiding persistent audible errors, and discusses congestion control handling for these journals. The RTP payload for MIDI encodes the broad range of MIDI commands. The format is suitable for interactive applications (such as network musical performance) and content-delivery (such as file streaming). Working Group Summary There is consensus in the WG to publish these documents. Document Quality This RTP Payload format has been implemented during the development of the specification and successfully tested over an IP network between two remote sites, thus showing that the technical solution is successfully working. It has been reviewed by the MIDI Manufacturers Association and their comments have been addressed. Personnel Magnus Westerlund and Colin Perkins jointly shepherded this document. Allison Mankin reviewed the document for the IESG, including a careful review with the editor of the media types, in parallel with ietf-types list review requested on 2006-01-08, which raised no issues. A.2. Example Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel Levkowetz, et al. Expires July 28, 2007 [Page 19] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Technical Summary This document specifies the encapsulation of IPv6, IPv4 and ARP packets over Fibre Channel. This document also specifies the methods for forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document (when published as RFC) obsoletes RFC2625 and RFC3831. Working Group Summary This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG. There is solid support for this document both in the WG and from T11. Document Quality This document replaces and consolidates two separate RFCs on IPv4 over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 3831). Most of its technical content is unchanged from those RFCs. The technical changes that have been made are primarily based on implementation experience. Personnel The protocol has been reviewed for the IESG by David L. Black (WG chair). Bert Wijnen has reviewed this document for the IESG. In addition, Brian Haberman has done a review for the INT Area as requested by WG-chair (David Black) via Margaret Wasserman. Authors' Addresses Henrik Levkowetz Torsgatan 71 Stockholm S-113 37 Sweden Phone: +46 708 32 16 08 Email: henrik@levkowetz.com Levkowetz, et al. Expires July 28, 2007 [Page 20] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 David Meyer 1225 Kincaid St Eugene, OR 97403 USA Phone: +1 541 346 1747 Email: dmm@1-4-5.net Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +49 50 48 24461 Email: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert Allison Mankin Phone: +1-301-728-7199 Email: mankin@psg.com URI: http://www.psg.com/~mankin Levkowetz, et al. Expires July 28, 2007 [Page 21] =0C Internet-Draft Document Shepherding to IESG Approval January 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Levkowetz, et al. Expires July 28, 2007 [Page 22] =0C --Apple-Mail-24-221919882 Content-Transfer-Encoding: 7bit Content-Type: text/html; x-unix-mode=0644; name=draft-ietf-proto-wgchair-doc-shepherding-from--08.diff.html Content-Disposition: attachment; filename=draft-ietf-proto-wgchair-doc-shepherding-from--08.diff.html Diff: draft-ietf-proto-wgchair-doc-shepherding-08.txt - draft-ietf-proto-wgchair-doc-shepherding.txt
 draft-ietf-proto-wgchair-doc-shepherding-08.txt   draft-ietf-proto-wgchair-doc-shepherding.txt 
PROTO Team H. Levkowetz PROTO Team H. Levkowetz
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational D. Meyer Intended status: Informational D. Meyer
Expires: April 25, 2007 Cisco/University of Oregon Expires: July 28, 2007 Cisco/University of Oregon
L. Eggert L. Eggert
NEC Nokia
A. Mankin A. Mankin
October 22, 2006 January 24, 2007
Document Shepherding from Working Group Last Call to Publication Document Shepherding from Working Group Last Call to Publication
draft-ietf-proto-wgchair-doc-shepherding-08 draft-ietf-proto-wgchair-doc-shepherding-09
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 38 skipping to change at page 1, line 38
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 April 25, 2007. This Internet-Draft will expire on July 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes methodologies that have been designed to This document describes methodologies that have been designed to
improve and facilitate IETF document flow processing. It specifies a improve and facilitate IETF document flow processing. It specifies a
set of procedures under which a working group chair or secretary set of procedures under which a working group chair or secretary
serves as the primary Document Shepherd for a document that has been serves as the primary Document Shepherd for a document that has been
submitted to the IESG for publication. Before this, the Area submitted to the IESG for publication. Before this, the Area
Director responsible for the working group has traditionally filled Director responsible for the working group has traditionally filled
the shepherding role. the shepherding role.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6
3.2. Document Shepherding during AD Evaluation . . . . . . . . 10 3.2. Document Shepherding during AD Evaluation . . . . . . . . 10
3.3. Document Shepherding during IESG Evaluation . . . . . . . 11 3.3. Document Shepherding during IESG Evaluation . . . . . . . 11
4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14 4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14
5. Document Shepherding after IESG Approval . . . . . . . . . . . 15 5. Document Shepherding after IESG Approval . . . . . . . . . . . 15
6. When Not to Use the Document Shepherding Process . . . . . . . 16 6. When Not to Use the Document Shepherding Process . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. Informative References . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Example Document Announcement Write-Ups . . . . . . . 18 Appendix A. Example Document Announcement Write-Ups . . . . . . . 18
A.1. Example Document Announcement Write-Up for A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18 draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 19
A.2. Example Document Announcement Write-Up for A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19 draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19
Appendix B. Working Documents . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
Early in 2004, the IESG undertook several experiments aimed at Early in 2004, the IESG undertook several experiments aimed at
evaluating whether any of the proposed changes to the IETF document evaluating whether any of the proposed changes to the IETF document
flow process would yield qualitative improvements in document flow process would yield qualitative improvements in document
throughput and quality. One such experiment, referred to as the throughput and quality. One such experiment, referred to as the
"PROTO process" or "PROTO" (because it was created by the "PROcess "PROTO process" or "PROTO" (because it was created by the "PROcess
and TOols" or PROTO [PROTO] team, is a set of methodologies designed and TOols" or PROTO [PROTO] team), is a set of methodologies designed
to involve working group chairs or secretaries more directly in their to involve working group chairs or secretaries more directly in their
documents' approval life cycle. In particular, the PROTO team documents' approval life cycle. In particular, the PROTO team
focused on improvements to the part of a document's life cycle that focused on improvements to the part of a document's life cycle that
occurs after the working group and document editor have forwarded it occurs after the working group and document editor have forwarded it
to the IESG for publication. to the IESG for publication.
By the end of 2004, the IESG had evaluated the utility of the PROTO By the end of 2004, the IESG had evaluated the utility of the PROTO
methodologies based on data obtained through several pilot projects methodologies based on data obtained through several pilot projects
that had run throughout the year, and subsequently decided to adopt that had run throughout the year, and subsequently decided to adopt
the PROTO process for all documents and working groups. This the PROTO process for all documents and working groups. This
skipping to change at page 6, line 35 skipping to change at page 6, line 35
Section 6 discusses other instances in which the document shepherding Section 6 discusses other instances in which the document shepherding
process does not apply. process does not apply.
3.1. Document Shepherd Write-Up 3.1. Document Shepherd Write-Up
When a working group decides that a document is ready for submission When a working group decides that a document is ready for submission
to the IESG for publication, it is the task of the Document Shepherd to the IESG for publication, it is the task of the Document Shepherd
to complete a "Document Shepherd Write-Up" for the document. to complete a "Document Shepherd Write-Up" for the document.
There are two parts to this task. First, the Document Shepherd There are two parts to this task. First, the Document Shepherd
answers questions (1.a) to (1.i) below to give the Responsible Area answers questions (1.a) to (1.j) below to give the Responsible Area
Director insight into the working group process that applied to this Director insight into the working group process that applied to this
document. Note that while these questions may appear redundant in document. Note that while these questions may appear redundant in
some cases, they are written to elicit information that the some cases, they are written to elicit information that the
Responsible Area Director must be aware of (to this end, pointers to Responsible Area Director must be aware of (to this end, pointers to
relevant entries in the WG archive are helpful). The goal here is to relevant entries in the WG archive are helpful). The goal here is to
inform the Responsible Area Director about any issues that may have inform the Responsible Area Director about any issues that may have
come up in IETF meetings, on the mailing list, or in private come up in IETF meetings, on the mailing list, or in private
communication that they should be aware of prior to IESG evaluation communication that they should be aware of prior to IESG evaluation
of the shepherded document. Any significant issues mentioned in the of the shepherded document. Any significant issues mentioned in the
questionnaire will probably lead to a follow-up discussion with the questionnaire will probably lead to a follow-up discussion with the
Responsible Area Director. Responsible Area Director.
The second part of the task is to prepare the "Document Announcement The second part of the task is to prepare the "Document Announcement
Write-Up" that is input to both the ballot for the IESG telechat and Write-Up" that is input to both the ballot for the IESG telechat and
to the eventual IETF-wide announcement message. Item number (1.i) to the eventual IETF-wide announcement message. Item number (1.k)
describes the elements of the Document Announcement Write-Up. describes the elements of the Document Announcement Write-Up.
A final sentence of the Document Announcement Write-Up, simply placed
as a line at the end of the "Document Quality" section, can state the
names of the Document Shepherd and the Responsible Area Director,
because the announcement will not otherwise acknowledge them. The
Document Shepherd SHOULD add this information and the Responsible
Area Director SHOULD add it if it is not already there.
Some examples of Document Announcement Write-Ups are included in Some examples of Document Announcement Write-Ups are included in
Appendix A, and there are many more examples with subject lines such Appendix A, and there are many more examples with subject lines such
as "Protocol Action" and "Document Action" in the IETF-announce as "Protocol Action" and "Document Action" in the IETF-announce
mailing list archive. mailing list archive.
The initial template for the Document Shepherd Write-Up is included
below, but changes are expected over time. The latest version of
this template is available from the IESG section of the IETF web
site.
(1.a) Who is the Document Shepherd for this document? Has the (1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication? version is ready for forwarding to the IESG for publication?
(1.b) Has the document had adequate review both from key WG members (1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that any concerns about the depth or breadth of the reviews that
have been performed? have been performed?
skipping to change at page 7, line 39 skipping to change at page 7, line 37
e.g., security, operational complexity, someone familiar with e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML? AAA, internationalization or XML?
(1.d) Does the Document Shepherd have any specific concerns or (1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those that it still wishes to advance the document, detail those
concerns here. concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
(1.e) How solid is the WG consensus behind this document? Does it (1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and others being silent, or does the WG as a whole understand and
agree with it? agree with it?
(1.f) Has anyone threatened an appeal or otherwise indicated extreme (1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is should be in a separate email because this questionnaire is
skipping to change at page 8, line 28 skipping to change at page 8, line 28
so, list these downward references to support the Area so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967]. Director in the Last Call procedure for them [RFC3967].
(1.i) Has the Document Shepherd verified that the document IANA (1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body consideration section exists and is consistent with the body
of the document? If the document specifies protocol of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a procedure for future registrations? Does it suggest a
reasonable name for the new registry? See reasonable name for the new registry? See [RFC2434]. If the
[I-D.narten-iana-considerations-rfc2434bis]. If the document document describes an Expert Review process has Shepherd
describes an Expert Review process has Shepherd conferred with conferred with the Responsible Area Director so that the IESG
the Responsible Area Director so that the IESG can appoint the can appoint the needed Expert during the IESG Evaluation?
needed Expert during the IESG Evaluation?
(1.j) Has the Document Shepherd verified that sections of the (1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker? an automated checker?
(1.k) The IESG approval announcement includes a Document (1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval "Action" announcements for approved documents. The approval
announcement contains the following sections: announcement contains the following sections:
Technical Summary Technical Summary
Relevant content can frequently be found in the abstract Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract an indication that there are deficiencies in the abstract
or introduction. or introduction.
Working Group Summary Working Group Summary
skipping to change at page 9, line 29 skipping to change at page 9, line 29
what was its course (briefly)? In the case of a Media Type what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted? review, on what date was the request posted?
Personnel Personnel
Who is the Document Shepherd for this document? Who is the Who is the Document Shepherd for this document? Who is the
Responsible Area Director? Responsible Area Director?
The Document Shepherd MUST send the Document Shepherd Write-Up to the The Document Shepherd MUST send the Document Shepherd Write-Up to the
Responsible Area Director and iesg-secretary@ietf.org together with Responsible Area Director and iesg-secretary@ietf.org together with
the request to publish the document. The Document Shepherd SHOULD the request to publish the document. The Document Shepherd SHOULD
also send the entire Document Shepherd Write-up to the working group also send the entire Document Shepherd Write-Up to the working group
mailing list. If the Document Shepherd feels that information which mailing list. If the Document Shepherd feels that information which
may prove to be sensitive, lead to possible appeals or is personal may prove to be sensitive, lead to possible appeals or is personal
information needs to be written up, it SHOULD be sent in direct email information needs to be written up, it SHOULD be sent in direct email
to the Responsible Area Director, because the Document Shepherd to the Responsible Area Director, because the Document Shepherd
Write-Up is published openly in the tracker. Question 1(f) of the Write-Up is published openly in the ID Tracker. Question (1.f) of
Write-Up covers any material of this nature and specifies this more the Write-Up covers any material of this nature and specifies this
confidential handling. more confidential handling.
The Document Shepherd Write-Up is entered into the ID Tracker The Document Shepherd Write-Up is entered into the ID Tracker
[IDTRACKER] as a "Comment." The name and email address of the [IDTRACKER] as a "Comment." The name and email address of the
Document Shepherd are entered into the ID Tracker, currently as a Document Shepherd are entered into the ID Tracker, currently as a
"Brief Note" (this may change in the future). The email address of "Brief Note" (this may change in the future). The email address of
the Document Shepherd MUST also be added to the "State or Version the Document Shepherd MUST also be added to the "State or Version
Change Notice To" field (typically the email addresses of all working Change Notice To" field (typically the email addresses of all working
group chairs, authors and the Secretary will be added). group chairs, authors and the secretary will be added).
Entering the name and email of the Document Shepherd into the ID Entering the name and email of the Document Shepherd into the ID
Tracker is REQUIRED to ensure that he or she will be copied on the Tracker is REQUIRED to ensure that he or she will be copied on the
email exchange between the editors, chairs, the IESG, the IESG email exchange between the editors, chairs, the IESG, the IESG
secretariat, IANA and the RFC Editor during the review and approval secretariat, IANA and the RFC Editor during the review and approval
process. There are still manual steps required for these parties to process. There are still manual steps required for these parties to
ensure they include the Document Shepherd, but it is hoped that in ensure they include the Document Shepherd, but it is hoped that in
future, automated tools will ensure that Document Shepherds (and future, automated tools will ensure that Document Shepherds (and
others) receive necessary communications. others) receive necessary communications.
The contact information for the Document Shepherd is also important The contact information for the Document Shepherd is also important
for the Gen-ART [GEN-ART] Directorate and other directorates, so they for the Gen-ART Directorate [GEN-ART] and other directorates, so they
can know to whom to address reviews, in addition to the Responsible can know to whom to address reviews, in addition to the Responsible
Area Director. Area Director.
3.2. Document Shepherding during AD Evaluation 3.2. Document Shepherding during AD Evaluation
The steps for document shepherding during AD Evaluation are as The steps for document shepherding during AD Evaluation are as
follows: follows:
(2.a) The Responsible Area Director reads, evaluates and comments on (2.a) The Responsible Area Director reads, evaluates and comments on
the document, as is the case when not using the document the document, as is the case when not using the document
skipping to change at page 10, line 45 skipping to change at page 10, line 45
(2.d) The Document Shepherd sends the AD Evaluation comments to the (2.d) The Document Shepherd sends the AD Evaluation comments to the
editors and to the working group mailing list, in order to editors and to the working group mailing list, in order to
have a permanent record of the comments. It is RECOMMENDED have a permanent record of the comments. It is RECOMMENDED
that the Document Shepherd solicit from the editors an that the Document Shepherd solicit from the editors an
estimate on when the required changes will be complete and a estimate on when the required changes will be complete and a
revised document can be expected. Working groups that use revised document can be expected. Working groups that use
issue tracking SHOULD also record the issues (and eventually issue tracking SHOULD also record the issues (and eventually
their resolution) in their issue tracker. their resolution) in their issue tracker.
(2.e) During the production of a revised document that addresses the (2.e) During the production of a revised document that addresses the
AD Evaluation comments, it is strongly RECOMMENDED that the AD Evaluation comments, it is RECOMMENDED that the editors
editors keep a list showing how each comment was addressed and keep a list showing how each comment was addressed and what
what the revised text is. It is strongly RECOMMENDED that the revised text is. It is RECOMMENDED that this list be
this list be forwarded to the Responsible Area Director forwarded to the Responsible Area Director together with the
together with the revised document. revised document.
(2.f) In the event that the editors or working group disagrees with (2.f) In the event that the editors or working group disagrees with
a comment raised by the Responsible Area Director or has a comment raised by the Responsible Area Director or has
previously considered and dismissed the issue, the Document previously considered and dismissed the issue, the Document
Shepherd MUST resolve the issue with the Responsible Area Shepherd MUST resolve the issue with the Responsible Area
Director before a revised document can be submitted. Director before a revised document can be submitted.
(2.g) The Document Shepherd iterates with the editors (and working (2.g) The Document Shepherd iterates with the editors (and working
group, if required) until all outstanding issues have been group, if required) until all outstanding issues have been
resolved and a revised document is available. At this point, resolved and a revised document is available. At this point,
the Document Shepherd notifies the Responsible Area Director the Document Shepherd notifies the Responsible Area Director
and provides him or her with the revised document, the summary and provides him or her with the revised document, the summary
of issues and the resulting text changes. of issues and the resulting text changes.
(2.h) The Responsible Area Director verifies that the issues he or (2.h) The Responsible Area Director verifies that the issues he or
she found during AD Evaluation are resolved in the revised she found during AD Evaluation are resolved in the revised
version of the document by starting the process described in version of the document by starting the process described in
this section at step (2.a). this section at step (2.a).
(2.i) If the document underwent an IETF Last Call and the AD
concludes that significant issues were raised during the Last
Call, then steps (2.b) through (2.h) need to be applied
addressing the Last Call issues. This requires the
Responsible Area Director to present to the Document Shepherd
those Last Call Issues raised only to the IESG.
3.3. Document Shepherding during IESG Evaluation 3.3. Document Shepherding during IESG Evaluation
During IESG Evaluation of a document, ADs can bring forward two kinds During IESG Evaluation of a document, ADs can bring forward two kinds
of remarks about a document: DISCUSS item and COMMENT items. A of remarks about a document: DISCUSS item and COMMENT items. A
DISCUSS blocks a document's approval process until it has been DISCUSS blocks a document's approval process until it has been
resolved; a COMMENT does not. This section details the steps that a resolved; a COMMENT does not. This section details the steps that a
Document Shepherd takes to resolve any DISCUSS and COMMENT items Document Shepherd takes to resolve any DISCUSS and COMMENT items
brought forward against a shepherded document during IESG Evaluation. brought forward against a shepherded document during IESG Evaluation.
Note that DISCUSS and COMMENT items are occasionally written in a Note that DISCUSS and COMMENT items are occasionally written in a
skipping to change at page 13, line 19 skipping to change at page 13, line 23
| | Further AD/Document Shepherd | | Further AD/Document Shepherd
| | discussion required | | discussion required
+--------------------------+ +--------------------------+
(3.e) The Document Shepherd then communicates the DISCUSS and (3.e) The Document Shepherd then communicates the DISCUSS and
COMMENT items to the document editors and the working group, COMMENT items to the document editors and the working group,
alerting them of any changes to the document that have alerting them of any changes to the document that have
accumulated during IESG processing, such as "Notes to the RFC accumulated during IESG processing, such as "Notes to the RFC
Editor." If any changes will be substantive, the Document Editor." If any changes will be substantive, the Document
Shepherd, in consultation with the Responsible Area Director, Shepherd, in consultation with the Responsible Area Director,
as during other stages, MUST seek working group consensus. as during other stages, MUST confirm working group consensus
or sometimes even IETF consensus.
(3.f) After the editors resolve the DISCUSS and COMMENT items, the (3.f) After the editors resolve the DISCUSS and COMMENT items, the
Document Shepherd reviews the resulting new version of the Document Shepherd reviews the resulting new version of the
document, which will be a revised document, a set of "Notes to document, which will be a revised document, a set of "Notes to
the RFC Editor", or both, using his or her technical expertise the RFC Editor", or both, using his or her technical expertise
to ensure that all raised DISCUSS and COMMENT issues have been to ensure that all raised DISCUSS and COMMENT issues have been
resolved. resolved.
Note that the Document Shepherd MAY also suggest resolutions Note that the Document Shepherd MAY also suggest resolutions
to DISCUSS and COMMENT items, enter them into an issue to DISCUSS and COMMENT items, enter them into an issue
skipping to change at page 14, line 35 skipping to change at page 14, line 40
If he or she deems the changes to the revised document If he or she deems the changes to the revised document
significant, there may be a new WG last call, or possibly a significant, there may be a new WG last call, or possibly a
new IETF last call. The document goes through a new full IESG new IETF last call. The document goes through a new full IESG
Evaluation process if there is a new IETF last call. Evaluation process if there is a new IETF last call.
4. Shepherding the Document's IANA Actions 4. Shepherding the Document's IANA Actions
IETF working group documents often include considerations requiring IETF working group documents often include considerations requiring
actions by the IANA, such as creating a new registry or adding actions by the IANA, such as creating a new registry or adding
information to an existing registry, perhaps after consulting an information to an existing registry, perhaps after consulting an
IESG-appointed Expert. Sometimes the actions required are by the IESG-appointed Expert. Sometimes, the IESG requires actions, such as
IESG, such as appointment of a new Expert. IANA-related processing appointment of a new Expert. IANA-related processing may also
may also include a specified type of Expert review, such as review of include a specified type of Expert review, such as review of proposed
proposed MIME media types on the designated ietf-types mailing list. MIME media types on the designated ietf-types mailing list.
The IANA reviews IETF documents and requests responses at any or all The IANA reviews IETF documents and requests responses at any or all
of the following times: in response to IETF Last Call, during the of the following times: in response to IETF Last Call, during the
IESG Evaluation review of the document, and at the time when the IANA IESG Evaluation review of the document, and at the time when the IANA
performs actions in its web-based registry for the document, usually performs actions in its web-based registry for the document, usually
but not always after IESG approval of the document. More details of but not always after IESG approval of the document. More details of
the IANA process and IETF interaction are found in the IANA process and IETF interaction are found in [RFC2434].
[I-D.narten-iana-considerations-rfc2434bis].
Whenever an IANA request comes, in whatever period, the requester At the time of this publication, RFC2434 is under revision
from IANA MUST ensure that the Document Shepherd and the Responsible [I-D.narten-iana-considerations-rfc2434bis] and the updates are and
Area Director both receive the request. The Document Shepherd is will be of value to the Document Shepherd. Note that Document
responsible for responding as rapidly as possible. He or she should Shepherd MUST determine (by individual review and consultation with
discuss requests that introduce any possible concerns with the others) what is the most recent and the most applicable IANA
Working Group. The Document Shepherd and the Responsible Area information and guidance for his or her document, be it the overall
Director may decide in consultation that an IANA request leads to a guidance, or external documents in his or her area, or in other
change that needs additional review or approval. areas. An example of an external document is [RFC4020].
In general, the Working Group Shepherd ensures that the IANA process Whenever an IANA request comes, during whatever phase of the
shepherding process, the requester from IANA MUST ensure that the
Document Shepherd and the Responsible Area Director both receive the
request. The Document Shepherd is responsible for responding as
rapidly as possible. He or she should discuss requests that
introduce any possible concerns with the working group. The Document
Shepherd and the Responsible Area Director may decide in consultation
that an IANA request leads to a change that needs additional review
or approval.
In general, the Document Shepherd ensures that the IANA process
completes, checks that the registry is correct and that the IANA completes, checks that the registry is correct and that the IANA
Matrix (www.iana.org/numbers.html) is complete and consistent, and Matrix (http://www.iana.org/numbers.html) is complete and consistent,
troubleshoots when all is not well. At the end of IANA processing, and troubleshoots when all is not well. At the end of IANA
the Document Shepherd should be sure that the RFC Editor has processing, the Document Shepherd should be sure that the RFC Editor
acknowledged IANA conclusion, that the handoff has been made. has acknowledged IANA conclusion, i.e., that the handoff has been
made.
In summary, the task of shepherding the IANA actions is overlooked In summary, the task of shepherding the IANA actions is often
but is as important to coordinate and manage as all the other overlooked, but is as important to coordinate and manage as all the
document reviews the Document Shepherd has managed. As with those, other document reviews the Document Shepherd has managed. As with
the Document Shepherd contributes greatly to quality and timeliness those, the Document Shepherd contributes greatly to quality and
of the document by effective and responsive shepherding of the IANA timeliness of the document by effective and responsive shepherding of
requests. the IANA requests.
5. Document Shepherding after IESG Approval 5. Document Shepherding after IESG Approval
After the IESG Evaluation and resolution described in Section 3.3, After the IESG evaluation and resolution described in Section 3.3,
the IESG approves the document, and the Responsible Area Director the IESG approves the document, and the Responsible Area Director
uses the tracker to ask for any final changes to the Document uses the ID Tracker to ask for any final changes to the Document
Announcement Write-Up and to ask for it to be issued. The Document Announcement Write-Up and for it to be issued. The Document Shepherd
Shepherd may have some edits for the Responsible Area Director, such may have some edits for the Responsible Area Director, such as minor
as minor Notes to the RFC Editor, and this is the time to consult and "Notes to the RFC Editor", and this is the time to consult and
provide them. provide them.
The announcement goes to the general community and to the RFC Editor, The IESG approval announcement goes to the general community and to
and now the Document Shepherd (identified in the Announcemen the RFC Editor, and now the Document Shepherd (identified in the
Write-Up) continues to shepherd the document through its technical Announcement Write-Up) continues to shepherd the document through its
publication. The RFC Editor currently makes a number of types of technical publication. The RFC Editor currently makes a number of
requests to the authors, Document Shepherd and Responsible Area types of requests to the authors, Document Shepherd and Responsible
Director. The Document Shepherd SHOULD lead in responding to the RFC Area Director. The Document Shepherd SHOULD lead in responding to
editor and shepherding the document through its technical the RFC Editor and shepherd the document during the post-approval
publication, through the post-approval period. The RFC Editor period to its publication.
request types include: editorial queries about dangling, missing,
informative and normative citations (good shepherding should try to The RFC Editor request types include: editorial queries about
pre-catch these, but they happen); requests for unedited source, e.g. dangling, missing, informative and normative citations (good
xml; occasional technical comments; and copy-edits for review and shepherding should try to catch these earlier, but they happen);
close scrutiny by the authors (AUTH48). On the latter, the Document requests for the document source (e.g., XML or nroff); occasional
Shepherd SHOULD lead in checking that copy-edits have in no case technical comments; and copy-edits for review and close scrutiny by
affected a consensus wording of the working group which prepared the the authors (AUTH48). For the latter, the Document Shepherd SHOULD
document, and in bringing speed to this checking by multiple co- lead in checking that copy-edits have in no case affected a consensus
authors. The Document Shepherd also consults with the Responsible wording of the working group which prepared the document, and SHOULD
Area Director in reviewing proposed post-approval changes to the bring speed to this checking by multiple coauthors. The Document
document by any authors. These may require Area Director approval, Shepherd also consults with the Responsible Area Director on
and they often need to be presented to the working group for consent reviewing proposed post-approval changes to the document by any
if not a full consensus procedure. As in other periods of document author. These may require Area Director approval, and they often
review, the Document Shepherd provides attentiveness and timeliness need to be presented to the working group for consent if not a full
by serving as the informed representative of the document and helping consensus procedure.
its advancement and its integrity.
As in other phases of document shepherding, the Document Shepherd
provides attentiveness and timeliness by serving as the informed
representative of the document and helping its advancement and its
integrity.
6. When Not to Use the Document Shepherding Process 6. When Not to Use the Document Shepherding Process
As mentioned in Section 3, the Document Shepherd SHOULD NOT be an As mentioned in Section 3, the Document Shepherd SHOULD NOT be an
editor of the shepherded document. If this cannot be avoided by editor of the shepherded document. If this cannot be avoided by
making another working group chair or secretary the Document making another working group chair or secretary the Document
Shepherd, the document shepherding process SHOULD NOT be used. There Shepherd, the document shepherding process SHOULD NOT be used. There
are several other cases in which the document shepherding process are several other cases in which the document shepherding process
SHOULD NOT be used. These include: SHOULD NOT be used. These include:
skipping to change at page 16, line 37 skipping to change at page 17, line 10
3. Cases, where the working group itself is either very old, losing 3. Cases, where the working group itself is either very old, losing
energy, or winding down, i.e., cases, where it would not be energy, or winding down, i.e., cases, where it would not be
productive to initiate new processes or procedures. productive to initiate new processes or procedures.
Finally, note that other cases exist in which using the document Finally, note that other cases exist in which using the document
shepherding process may not be productive. The final determination shepherding process may not be productive. The final determination
as to whether to use the document shepherding process or not is left as to whether to use the document shepherding process or not is left
to the Responsible Area Director. If the document shepherding to the Responsible Area Director. If the document shepherding
process is not used, the Responsible Area Director acts as Document process is not used, the Responsible Area Director acts as Document
Shepherd, just as he or she did in the past. Shepherd, per the existing procedures of shepherding by Area
Directors.
7. Security Considerations 7. Security Considerations
This document specifies a change to IETF document-processing This document specifies a change to IETF document-processing
procedures. As such, it neither raises nor considers protocol- procedures. As such, it neither raises nor considers protocol-
specific security issues. specific security issues.
8. IANA Considerations 8. IANA Considerations
This document creates no new requirements on IANA namespaces or other This document creates no new requirements on IANA namespaces or other
IANA requirements. IANA requirements.
9. Acknowledgments 9. Acknowledgments
This document is the product of PROTO team, which includes the This document is the product of PROTO team, which includes the
authors as well as Bill Fenner, Barbara Fuller, and Margaret authors as well as Bill Fenner, Barbara Fuller, and Margaret
Wasserman. Aaron Falk worked actively in PROTO till the start of Wasserman. Aaron Falk worked actively in PROTO until the start of
2006 and worked on earlier versions of the document. 2006 and worked on earlier versions of the document.
The Document Shepherd Write-Up originated in an idea by John Klensin. The Document Shepherd Write-Up originated in an idea by John Klensin.
Thomas Narten and Margaret Wasserman implemented it for the entire Thomas Narten and Margaret Wasserman implemented it for the entire
Internet Area, and their template was the basis of the version used Internet Area, and their template was the basis of the version used
today. today.
Colin Perkins wrote the Document Announcement Write-Up for Colin Perkins wrote the original Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black
wrote the Document Announcement Write-Up for wrote the original Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both
original announcements have been modified to reflect changes to the
Document Announcement Write-Up template since they were written.
Frank Ellermann and Olafur Gudmundsson have suggested improvements to Frank Ellermann and Olafur Gudmundsson have suggested improvements to
the document during IETF Last Call. the document during IETF Last Call.
10. Informative References 10. Informative References
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020,
February 2005.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[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.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and [RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998. Procedures", BCP 25, RFC 2418, September 1998.
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track
skipping to change at page 19, line 4 skipping to change at page 19, line 36
There is consensus in the WG to publish these documents. There is consensus in the WG to publish these documents.
Document Quality Document Quality
This RTP Payload format has been implemented during the This RTP Payload format has been implemented during the
development of the specification and successfully tested over an development of the specification and successfully tested over an
IP network between two remote sites, thus showing that the IP network between two remote sites, thus showing that the
technical solution is successfully working. It has been reviewed technical solution is successfully working. It has been reviewed
by the MIDI Manufacturers Association and their comments have been by the MIDI Manufacturers Association and their comments have been
addressed. Allison Mankin reviewed the document for the IESG, addressed.
Personnel
Magnus Westerlund and Colin Perkins jointly shepherded this
document. Allison Mankin reviewed the document for the IESG,
including a careful review with the editor of the media types, in including a careful review with the editor of the media types, in
parallel with ietf-types list review requested on 2006-01-08, parallel with ietf-types list review requested on 2006-01-08,
which raised no issues. which raised no issues.
Magnus Westerlund and Colin Perkins jointly shepherded these
documents.
A.2. Example Document Announcement Write-Up for A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel draft-ietf-imss-ip-over-fibre-channel
Technical Summary Technical Summary
This document specifies the encapsulation of IPv6, IPv4 and ARP This document specifies the encapsulation of IPv6, IPv4 and ARP
packets over Fibre Channel. This document also specifies the packets over Fibre Channel. This document also specifies the
methods for forming IPv6 link-local addresses and statelessly methods for forming IPv6 link-local addresses and statelessly
autoconfigured IPv6 addresses on Fibre Channel networks, and a autoconfigured IPv6 addresses on Fibre Channel networks, and a
mechanism to perform IPv4 address resolution over Fibre Channel mechanism to perform IPv4 address resolution over Fibre Channel
networks. This document (when published as RFC) obsoletes RFC2625 networks. This document (when published as RFC) obsoletes RFC2625
and RFC3831. and RFC3831.
skipping to change at page 19, line 40 skipping to change at page 20, line 29
this document both in the WG and from T11. this document both in the WG and from T11.
Document Quality Document Quality
This document replaces and consolidates two separate RFCs on IPv4 This document replaces and consolidates two separate RFCs on IPv4
over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC
3831). Most of its technical content is unchanged from those 3831). Most of its technical content is unchanged from those
RFCs. The technical changes that have been made are primarily RFCs. The technical changes that have been made are primarily
based on implementation experience. based on implementation experience.
The protocol has been reviewed for the IESG by David L. Black (WG Personnel
chair).
Also Bert Wijnen has reviewed this document for the IESG.
In addition, Brian Haberman has done a review for the INT Area as The protocol has been reviewed for the IESG by David L. Black (WG
chair). Bert Wijnen has reviewed this document for the IESG. In
addition, Brian Haberman has done a review for the INT Area as
requested by WG-chair (David Black) via Margaret Wasserman. requested by WG-chair (David Black) via Margaret Wasserman.
Appendix B. Working Documents
(This section should be removed by the RFC editor before
publication.)
The current working documents for this document are available at this
web site:
http://tools.ietf.org/wg/proto/
draft-ietf-proto-wgchair-doc-shepherding/
Authors' Addresses Authors' Addresses
Henrik Levkowetz Henrik Levkowetz
Torsgatan 71 Torsgatan 71
Stockholm S-113 37 Stockholm S-113 37
Sweden Sweden
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
Email: henrik@levkowetz.com Email: henrik@levkowetz.com
David Meyer David Meyer
1225 Kincaid St 1225 Kincaid St
Eugene, OR 97403 Eugene, OR 97403
USA USA
Phone: +1 541 346 1747 Phone: +1 541 346 1747
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
Lars Eggert Lars Eggert
NEC Network Laboratories Nokia Research Center
Kurfuerstenanlage 36 P.O. Box 407
Heidelberg 69115 Nokia Group 00045
Germany Finland
Phone: +49 50 48 24461
Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert
Phone: +49 6221 4342 143
Fax: +49 6221 4342 155
Email: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Allison Mankin Allison Mankin
Phone: +1-301-728-7199 Phone: +1-301-728-7199
Email: mankin@psg.com Email: mankin@psg.com
URI: http://www.psg.com/~mankin URI: http://www.psg.com/~mankin
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 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
 End of changes. 49 change blocks. 
134 lines changed or deleted 155 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/
--Apple-Mail-24-221919882 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-24-221919882-- --Apple-Mail-25-221920006 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMjQxNjEyNDVaMCMGCSqGSIb3DQEJBDEWBBTs8PeTb+C/FwWA eBpMfohfRLMH4DCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAf5E2fZglr0NLvTpRUPFCeEbREV+G7c0G5fdJoCxKkeZSCCpeTaN3 5asGzbfuRTOmmY1KBdHoJmGZ4UJeX+Bje+EyPy5XQ8tHXWxVTbjQ39+mykDO+J2tkXXXyaFbyKm+ pRaVJedqgHF3fNXvrwsD6BgpAIAE7D4xOVWqRvFdC5pR4MXXta8sYoyB4kx8SXqLYf12sueMah8Y 15EoSYc8HACqACjnONk6zJbBXYG8F9oD28ufTTVhWnDXbsrxEPbcvH7GLb6iMhuzYJq2JAbsYJ1A fqxiRMS/IzlqWsJUAdil89uy7OC0HjOKEU8WEv/4BwMv+vybeWepOk8rh4QrjQAAAAAAAA== --Apple-Mail-25-221920006-- --===============0366579830== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0366579830==-- From proto-team-bounces@ietf.org Wed Jan 24 17:12:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qLw-0006sO-V0; Wed, 24 Jan 2007 17:12:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9qLv-0006lh-9J; Wed, 24 Jan 2007 17:12:23 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9qGy-0002SW-VV; Wed, 24 Jan 2007 17:07:18 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0OM7GnL057418; Wed, 24 Jan 2007 22:07:16 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0OM7FJv1888362; Wed, 24 Jan 2007 22:07:15 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0OM7FaY023257; Wed, 24 Jan 2007 22:07:15 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0OM7FUF023252; Wed, 24 Jan 2007 22:07:15 GMT Received: from [9.145.129.251] (chv04174-009145129251.de.ibm.com [9.145.129.251]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA128830; Wed, 24 Jan 2007 23:07:11 +0100 Message-ID: <45B7D88E.1030603@zurich.ibm.com> Date: Wed, 24 Jan 2007 23:07:10 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Henrik Levkowetz References: <463470.249711169577770583.JavaMail.weblogic@ep_ml25> <45B65BDA.80700@levkowetz.com> In-Reply-To: <45B65BDA.80700@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "wgchairs@ietf.org" , soohong.park@samsung.com, "proto-team@ietf.org" Subject: [proto-team] Re: WG chair use of the ID-tracker: Proposed tool addition X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org On 2007-01-23 20:02, Henrik Levkowetz wrote: > Hi, > > on 2007-01-23 19:42 Daniel Park said the following: >> Hi, >> >> One question on the 02-version: >> >> Defined WG States: >> >> * Candidate WG Document >> This document is under consideration for becoming a working group >> document. >> (R-009) >> >> >> How to guage folks consensus before straw poll, and who is >> responsible for this judgement ? by chair only ? > > My thoughts on this was that this is a state which is available > to the chair to indicate that someone has asked that a document > be made a WG document. It does not imply any consensus at all, > and it does not imply any precedence or selection. It's simply > a way to flag in the tracker that somebody has asked for a > document to be considered for adoption. And it's nothing new; this is a natural state today, and the concern Daniel raises applies today, as soon as a WG Chair asks the WG whether to consider a certain draft. As always, it is indeed the Chair's judgement to say that the candidate has been adopted by consensus. I don't thing adding a state in the tracker changes the reality. Brian > >> For example: >> >> o X-Document: WG Status: Candidate WG Document >> >> What next ? No one can submit another document wrt. >> the same subject ? > > In line with the above, no, not at all - having this indication > in the tracker doesn't change any of our processes at all. > >> Or strong battle is coming ? In my >> feeling, it seems not easy for other guys to work for >> the same subject once seeing the WG Status: Candidate >> WG Document since this document is already under >> consideration for becoming a WG adoption. > > Umm. Should this maybe be an annotation, rather than a state? > Would that be better? Thoughts? > > > Henrik > > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Fri Jan 26 08:35:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAREg-00035T-0C; Fri, 26 Jan 2007 08:35:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAREe-00035M-UX for proto-team@ietf.org; Fri, 26 Jan 2007 08:35:20 -0500 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAREW-0004op-OQ for proto-team@ietf.org; Fri, 26 Jan 2007 08:35:20 -0500 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 2AF0D38321; Fri, 26 Jan 2007 14:35:12 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id EE7BE3831E; Fri, 26 Jan 2007 14:35:11 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 9B89E37E5B; Fri, 26 Jan 2007 14:35:05 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HAREO-0002sX-Mp; Fri, 26 Jan 2007 14:35:05 +0100 Message-ID: <45BA0378.5090704@levkowetz.com> Date: Fri, 26 Jan 2007 14:34:48 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Lars Eggert References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> In-Reply-To: <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> X-Enigmail-Version: 0.94.1.2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lars.eggert@nokia.com, brc@zurich.ibm.com, dmm@1-4-5.net, mankin@psg.com, margaret@thingmagic.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: af9b2929377c0f32bd0f059f6c3fd7e4 Cc: David Meyer , Margaret Wasserman , Brian E Carpenter , proto-team@ietf.org, Allison Mankin Subject: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0587897205==" Errors-To: proto-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0587897205== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF2DC22C83010DAC3F6318EDE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2DC22C83010DAC3F6318EDE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lars, Your updates work for me. Thanks, Henrik on 2007-01-24 17:06 Lars Eggert said the following: > Hi, >=20 > attached is an update to wgchair-doc-shepherding that addresses some =20 > of the IESG comments. >=20 > In all cases where there were multiple proposed resolutions, I opted =20 > for the smallest possible change. I'm completely OK with people =20 > preferring to fix things a different way, but please send text in =20 > this case. >=20 > On 2006-11-17, at 11:40, Brian E Carpenter wrote: >> 1. Please make all the changes currently logged as an RFC Editor note >> (attached below for convenience). > done >> 2. To deal with Sam's DISCUSS, which he cleared, I promised to request= >> text updates in the I-D tracker to >> a) align terminology: always refer to "responsible AD" and never >> to "shepherding AD" and always refer to "document shepherd" and >> not to "PROTO shepherd" ("PROTO" being jargon). > I couldn't find any of these terms in the document anymore - did Sam =20 > review an older version than -08? >> b) add a "Personnel" section and rename "Protocol Quality" to >> "Document Quality" in the blank writeup. > was already done, too? >> 4. Re Russ' DISCUSS. Russ wasn't on the call. >> >> Part 1: "The examples in Appendix A do not follow the outline >> proposed in Section 3.1 paragraph (1.k)." Please fix. > fixed >> Part 2: "it seems like it would be >> better to post the Document Shepherd Write-Up Template, and put a >> pointer to it in this document. This document could include the >> current template with an appropriate introduction, like: >> >> The initial Document Shepherd Write-Up Template is included here,= >> but changes are expected over time." >> >> Makes sense, and we can host the latest template in the IESG >> pages, so you could add "The latest version is available >> in the IESG section of the IETF web site." (I don't want to >> assume the PROTO web site will exist for ever.) I will do >> this when the draft is approved. > added >> 5. I'd like you to look at all the other AD comments in the tracker. >> That should lead to a number of small changes. >> >> Sam is concerned that paragraph (b) at the very end of (3.h) >> might be read to encourage appeals. Of course, that all depends on= >> the meaning of "last resort" so there may be nothing you can =20 >> change. > Open issues: > - Ted wanting to allow the possibility of shepherd teams > - Ted wanting to have section 6 removed (or rewritten) > - Sam and Cullen thinking that the appeals stuff in step 3.h is =20 > too much > - Russ wanting to have security questions added to the writeup > - whether or not this should become an ION >=20 > Lars >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > > > > > > > > > > > > >=20 > > > > Document Shepherding from Working Group Last Call to Publication > >=20 > fullname=3D"Henrik Levkowetz"> > > >
> > Torsgatan 71 > S-113 37 > Stockholm > Sweden > > +46 708 32 16 08 > henrik@levkowetz.com >
> >=20 > fullname=3D"David Meyer"> > > >
> > 1225 Kincaid St > Eugene > OR > 97403 > USA > > +1 541 346 1747 > dmm@1-4-5.net >
>=20 > > > Nokia Research Center >
> > P.O. Box 407 > 00045 Nokia Group > Finland > > +49 50 48 24461 > lars.eggert@nokia.com > http://research.nokia.com/people/lars_eggert >
> >=20 > fullname=3D"Allison Mankin"> > >
> +1-301-728-7199 > mankin@psg.com > http://www.psg.com/~mankin >
> >=20 >=20 > > General Area > PROTO Team > Document Shepherding > IETF Documents >=20 > > > This document describes methodologies that have been > designed to improve and facilitate IETF document flow > processing. It specifies a set of procedures under which a working gr= oup > chair or secretary serves as the primary Document Shepherd for a > document that has been submitted to the IESG for > publication. Before this, the Area Director responsible for the workin= g group has traditionally filled the shepherding role. > > > A Document Shepherd's responsibilities include:=20 >=20 > > Providing the Document Shepherd Write-Up accompanying a d= ocument that > is forwarded to the IESG when publication is requested.=20 > >=20 > During AD Evaluation by the Responsible Area Director, managing = the discussion > between the editors, the working group, and the Responsible Area= Director. > =20 >=20 > During IESG evaluation, following up on all IESG feedback ("DISC= USS" and "COMMENT" items) > related to the shepherded document. > =20 > =20 > Following up on IANA and RFC Editor requests=20 > in the post-approval shepherding of the document. > > >=20 > In summary, a Document Shepherd continues to care for a shepher= ded document during > its post-WG lifetime just as he or she has cared for it w= hile responsible > for the document in the working group. > > >=20 > > >
> >=20 > Early in 2004, the IESG undertook several experiments > aimed at evaluating whether any of the proposed changes > to the IETF document flow process would yield > qualitative improvements in document throughput and > quality. One such experiment, referred to as the "PROTO process" or "= PROTO" > (because it was created by the "PROcess and TOols" or > PROTO team), is a set of methodologies > designed to involve working group chairs or secretaries more > directly in their documents' approval life cycle. In > particular, the PROTO team focused on improvements to the part of a > document's life cycle that occurs after the working > group and document editor have forwarded it to the IESG for publicatio= n. > > > By the end of 2004, the IESG had evaluated the utility of > the PROTO methodologies based on data obtained through > several pilot projects that had run throughout the year, > and subsequently decided to adopt the PROTO process for all documents = and working groups. This document describes this process. > > > The methodologies developed and piloted by the PROTO team > focus on the working group chair or secretary as the primary > Document Shepherd. The primary objective of this document shepherding = process is to improve > document-processing throughput and document quality by enabling a part= nership > between the Responsible Area Director and the Document Shepherd. > In particular, this partnership has the explicit goal of enfranchising= the > Document Shepherd while at the same time offloading a > specific part of the follow-up work that has > traditionally been responsibility of the Responsible Area Director. > The Responsible Area Director has tens or many tens of documents to = =09 > follow, while the Document Shepherd has only a few at a time. =09 > Flowing the responsibility to the working group level can ensure mor= e =09 > attention and more timely response. > =09 > > > Consequently, the document shepherding process includes follow-up work= during all document-processing stages > after Working Group Last Call, i.e., during AD Evaluation of a documen= t, during > IESG evaluation, and during post-approval processing by IANA and the R= FC Editor. > In these stages, it is the responsibility of the Document Shepherd to = track and follow > up on feedback received on a document from all relevant parties. > > > The Document Shepherd is usually a chair of the working group > that has produced the document.=20 > In consultation with the Responsible Area Director, the chairs may ins= tead decide to appoint the working group > secretary as the responsible Document Shepherd. > > > The remainder of this document is organised as follows: > outlines the overall document shepher= ding > process. > describes the Document Shepherd Write-Up that accompanies the publicat= ion > request of a document. > describes the AD Evaluation shepherding process and target=3D"proto.process.discuss"/> describes IESG > DISCUSS shepherding. Finally, target=3D"proto.when-not-to"/> describes those cases in > which the document shepherding process should not be used. > > =20 >
>=20 >
> > 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 BCP 14, RFC 2119 target=3D"RFC2119"/>. > >
>=20 >
>=20 > > The document shepherding process consists of the following task= s: > > >=20 > > Providing the Document Shepherd Write-Up accompanying a d= ocument that > is forwarded to the IESG when publication is requested, as descr= ibed in > . > >=20 > During AD Evaluation of the document by the Responsible Area Dir= ector, managing the discussion > between the editors, the working group and the Responsible Area = Director, as described in=20 > . > =20 >=20 > During IESG evaluation, following up on all IESG feedback ("DISC= USS" and "COMMENT" items) > related to the shepherded document, as described in=20 > . > =20 > =20 > Following up on IANA and RFC Editor requests=20 > as described in and= . > > >=20 > The shepherd must keep the document moving forward, communicating > about it with parties who review and comment it. The shepherd must > obtain the working group's consensus for any substantive proposed > changes. The shepherd is the leader for the document and for the > working group, and maintains a critical and technical perspective. > In summary, the Document Shepherd continues to care for a shepherded= > document during its post-WG lifetime just as he or she has done whil= e > responsible for the document in the working group. > > =20 > > Before any document shepherding takes place, a single Document > Shepherd MUST be identified for a document (he or she will be named > in the Document Shepherd Write-Up) . Frequently, the chairs and the= > Responsible Area Director will decide that the working group will > adopt the PROTO process for all their future documents. After that > decision, the chairs, in consultation with the Responsible Area > Director, decide on who should act as Document Shepherd for any give= n > document. This is typically and by default one of the chairs of the= > working group. In consultation with the Responsible Area Director, > the chairs MAY also decide to appoint the working group secretary as= > Document Shepherd for a given document. The Document Shepherd SHOUL= D > NOT be an editor of the shepherded document. > > > It is intended that the Document Shepherd role is filled by one > person during the entire shepherding process. However, situations > may occur when the Document Shepherd role may be reassigned to > different persons during the lifetime of a document. It is up to th= e > chairs and Responsible Area Director to identify situations when thi= s > may become necessary, and then consult to appoint a new Document > Shepherd. > > =20 > It is important to note that the document shepherding process only ap= plies to documents that are the product of > a working group. It does not apply to documents that originate elsewh= ere. Additionally, > discusses other instances in whi= ch the document shepherding process does not apply. > >=20 >=20 >
anchor=3D"proto.process.writeup"> >=20 > > When a working group decides that a document is ready for sub= mission to the IESG for publication, > it is the task of the Document Shepherd to complete a > "Document Shepherd Write-Up" for the document. > >=20 > > There are two parts to this task. First, the > Document Shepherd answers questions (1.a) to (1.j) below > to give the Responsible Area Director insight into the > working group process that applied to this document. Note > that while these questions may appear redundant in some > cases, they are written to elicit information that the > Responsible Area Director must be aware of (to this end, pointers to= relevant > entries in the WG archive are helpful). The goal > here is to inform the Responsible Area Director about any issues tha= t may have > come up in IETF meetings, on the mailing list, or in > private communication that they should be aware of > prior to IESG evaluation of the shepherded document. Any > significant issues mentioned in the questionnaire will > probably lead to a follow-up discussion with the Responsible Area Di= rector. > >=20 > > The second part of the task is to prepare the "Document Announcement= > Write-Up" that is input to both the ballot for the IESG telechat and= > to the eventual IETF-wide announcement message. Item number (1.k) > describes the elements of the Document Announcement Write-Up. > > > Some examples of=20 > Document Announcement Write-Ups are included in , > and there > are many more examples with subject lines such as "Protocol Action" = and > "Document Action" in the IETF-announce mailing list archive. > > > The initial template for the Document Shepherd Write-Up is included = below,=20 > but changes are expected over time. The latest version of this tem= plate is available=20 > from the IESG section of the IETF web site. >=20 > > =20 > > Who is the Document Shepherd for > this document? Has the Document Shepherd personally revie= wed this version of > the document and, in particular, does he or she=20 > believe this version is ready for forwarding to the IESG for > publication? =20 > > =20 > =20 > > Has the document had adequate review both from key > WG members and from key non-WG members? Does the Document Sheph= erd have any > concerns about the depth or breadth of the reviews > that have been performed? > > =20 > =20 > > Does the Document Shepherd have concerns that the documen= t needs more > review from a particular or broader perspective, > e.g., security, operational complexity, someone > familiar with AAA, internationalization or XML? > > =20 > =20 > > Does the Document Shepherd have any specific concerns or = issues with this > document that the Responsible Area Director and/or the IESG > should be aware of? For example, perhaps he or she is > uncomfortable with certain parts of the document, > or has concerns whether there really is a need for > it. In any event, if the WG has discussed those issues > and has indicated > that it still wishes to advance the document, > detail those concerns here. Has an IPR disclosure related to thi= s document been filed? > If so, please include a reference to the disclosure and summariz= e the WG discussion and conclusion on this issue. > > =20 > > How solid is the WG consensus behind this document? > Does it represent the strong concurrence of a few > individuals, with others being silent, or does the > WG as a whole understand and agree with it? > >=20 > > Has anyone threatened an appeal or otherwise > indicated extreme discontent? If so, please > summarise the areas of conflict in separate email messages > to the Responsible Area Director. (It should be in a=20 > separate email because this questionnaire is entered > into the ID Tracker.) >=20 > > =20 > > Has the Document Shepherd personally verified that the do= cument satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/= tools/idnits/). Boilerplate > checks are not enough; this check needs to be thorough. = Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > > =20 > =20 > > Has the document split its references into normative and > informative? Are there normative > references to documents that are not ready > for advancement or are otherwise in an unclear > state? If such normative references > exist, what is the strategy for their > completion? Are there > normative references that are downward references, > as described in ? > If so, list these downward references to support > the Area Director in the Last Call procedure for them . > =20 > >=20 > > Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body o= f > the document? If the document specifies protocol extensions, a= re > reservations requested in appropriate IANA registries? Are the= IANA > registries clearly identified? > If the document creates a new registry, does it > define the proposed initial contents of the registry and an al= location > procedure for future registrations? Does it suggest=20 > a reasonable name for the new registry? See . > If the document > describes an Expert Review process has Shepherd conferred wit= h > the Responsible Area Director so that the IESG can appoint th= e > needed Expert during the IESG Evaluation? > >=20 > > Has the Document Shepherd verified that sections of the document > that are written in a formal language, such as XML code, BNF rules, > MIB definitions, etc., validate correctly in an automated checker? > >=20 > > The IESG > approval announcement includes a Document Announcement > Write-Up. > Please provide such a Document Announcement > Write-Up? Recent examples can be found in the "Action" announcement= s > for approved documents. The approval announcement contains the f= ollowing sections: > > > > Relevant content can frequently be found in the abstr= act > and/or introduction of the document. If not, > this may be an indication that there are > deficiencies in the abstract or introduction. > > > > Was there > anything in WG process that is worth noting? > For example, was there controversy about > particular points or were there decisions where the consensus > was particularly rough? >=20 > >=20 > > > Are there existing implementations of the > protocol?=20 > Have a significant number of vendors > indicated their plan to implement the > specification? > Are there any reviewers that merit special > mention as having done a thorough review, > e.g., one that resulted in important changes > or a conclusion that the document had no > substantive issues? > If there was a MIB > Doctor, Media Type or other expert review, what was > its course (briefly)? In the case of a Media Type review, on what > date was the request posted? > >=20 > > > Who is the Document Shepherd for this document? Who > is the Responsible Area Director? > > > >=20 > > >=20 > > The Document Shepherd MUST send the Document Shepherd Write-Up to th= e > Responsible Area Director and iesg-secretary@ietf.org together with > the request to publish the document. The Document Shepherd SHOULD > also send the entire Document Shepherd Write-Up to the working > group mailing list. If the Document Shepherd feels that information= which may prove to > be sensitive, lead to possible appeals or is personal information ne= eds to be written up, it SHOULD be sent in direct email to the Responsibl= e Area Director, because the Document > Shepherd Write-Up is published openly in the ID Tracker. > Question (1.f) of the > Write-Up covers any material of this nature and specifies this more > confidential handling. >=20 > > > The Document Shepherd Write-Up is entered into the ID Tracker as a "Comment." > The name and email address of the Document > Shepherd are entered into the ID Tracker, currently as a "Bri= ef Note" (this may change in the future). The email address of the Docume= nt Shepherd MUST also be added to the "State or Version Change Notice To"= field (typically the email addresses of all working > group chairs, authors and the secretary will be added). > > > Entering the name and email of the Document Shepherd into the ID > Tracker is REQUIRED to ensure that he or she will be copied on the > email exchange between the editors, chairs, the IESG, the IESG > secretariat, IANA and the RFC Editor during the review and approval > process. There are still manual steps required for these parties to= > ensure they include the Document Shepherd, but it is hoped that in > future, automated tools will ensure that Document Shepherds (and > others) receive necessary communications. > > >=20 > The contact information for the Document Shepherd is also important > for the Gen-ART Directorate and othe= r directorates, so they > can know to whom to address reviews, in addition to the Responsible > Area Director. > >=20 >
>=20 >
> > The steps for document shepherding during AD Evaluation are a= s follows: >=20 > > > The Responsible Area Director reads, evaluates and comments on the do= cument, > as is the case when not using the document shepherding process. If th= e Responsible Area Director determines that the > document is ready for IESG Evaluation, he or she indicates this to th= e Document Shepherd > and the document shepherding process continues as described in . > > > If the Responsible Area Director has identified issues with a documen= t that must be addressed before IESG Evaluation can commence, he or she s= ends a full evaluation to the Document Shepherd and SHOULD > also enter the review into the ID Tracker. >=20 > > >=20 > The Document Shepherd reads the AD > Evaluation comments, making very certain that all > comments are understood, so that it is possible > to follow up on them with the editors and working > group. If there is some uncertainty as to what is > requested, this SHOULD be resolved with the Responsible Area > Director. >=20 > > >=20 > The Document Shepherd sends the AD Evaluation comments to > the editors and to the working group mailing > list, in order to have a permanent record of the > comments. It is RECOMMENDED that the Document Shepherd > solicit from the editors an estimate on when > the required changes will be complete and a revised > document can be expected. > Working groups that use issue tracking SHOULD > also record the issues (and eventually their > resolution) in their issue tracker. > > > During the production of a revised document that addresses the AD Eva= luation comments, it is RECOMMENDED > that the editors keep a list showing how each > comment was addressed and what the revised > text is. It is RECOMMENDED that this list > be forwarded to the Responsible Area Director > together with the revised document. =20 > > > In the event that the editors or working group disagrees > with a comment raised by the Responsible Area Director or has previou= sly > considered and dismissed the issue, the > Document Shepherd MUST resolve the issue with > the Responsible Area Director before a revised document can be submit= ted. > > > The Document Shepherd iterates with the > editors (and working group, if required) until all > outstanding issues have been resolved and a > revised document is available. At this point, > the Document Shepherd notifies the Responsible Area Director and prov= ides him or her with the revised document, the summary of issues and the = resulting text changes. >=20 > > > The Responsible Area Director verifies that the issues he or she > found during AD Evaluation are resolved in the > revised version of the document by starting the process described in = this section at step (2.a).=20 > > =20 > > If the document underwent an IETF Last Call and the AD > concludes that significant issues were raised during > the Last Call, then steps (2.b) through (2.h) need to be app= lied=20 > addressing the Last Call issues. This requires the Responsible > Area Director to present to the Document Shepherd those Last Call > Issues raised only to the IESG. > > =20 > >=20 > >
>
> > During IESG Evaluation of a document, ADs can bring forward two kinds= of remarks about a document: DISCUSS item and COMMENT items. A DISCUSS b= locks a document's approval process until it has been resolved; a COMMENT= does not.=20 > This section details the steps that a > Document Shepherd takes to resolve any DISCUSS and COMMENT items brou= ght forward against a shepherded document during IESG Evaluation. > > Note that DISCUSS and COMMENT items are occasionally written in a > manner that makes their intent unclear. > In these cases, the Document Shepherd SHOULD start a discussion with = the ADs who brought the items up > to clarify their intent, keeping the > Responsible Area Director informed. > If this fails to clarify the intent, the Responsible Area Director=20 > may need to work towards a clarification inside the IESG. > > > Leading up to the IESG conference > call, the Document Shepherd may see emails > about the document from directorate reviewers > on behalf of one or more ADs and also emailed > copies of DISCUSS and COMMENT items entered into the ID= Tracker. > The Document Shepherd SHOULD immediately begin > to work on resolving DISCUSS and COMMENT items with the= > ADs who have raised them, keeping the Responsible Area = Director > copied on the email exchange, so that he or she is able= to support the > the activity during the conference call. When > dealing with directorate reviews, the Document > Shepherd MUST involve the ADs to whom > these directorates report to ensure that these ADs > consider the review comments that need resolving. >=20 > > Immediately following the conference call, > when the document changes state from the > "IESG Evaluation" state to one of the states > requiring Document Shepherd action, e.g., "IESG > Evaluation: Revised ID Needed" or "IESG Evaluation: > AD Followup", the Document Shepherd will receive email. =20 > A state of "AD Followup" > typically signifies the Responsible Area Director's hop= e > that a resolution may be possible through a continued d= iscussion > or (more usually) through a small set of changes as "No= tes to the RFC Editor." >=20 > >=20 >=20 > Note that there may be very exceptional cases when > DISCUSS items are registered after an IESG > conference call. In these cases, the AD who has raised the DISCUSS M= UST notify the Document Shepherd about it. (The=20 > notification facility in the ID Tracker is very conveni= ent for > this purpose and also for the cases where the > DISCUSS and COMMENT items are updated after they are pa= rtially > resolved.) > >=20 > The Document Shepherd then queries the ID Tracker to collect the > remaining DISCUSS and COMMENT items raised against the document. =20 > The Document Shepherd analyses these items and initialises contact wi= th the > ADs who have placed them. The Responsible Area > Director MUST be copied on all correspondence related to active DISCU= SS or COMMENT items. > This does > not place the Responsible Area Director in the critical= path towards a resolution, but > should keep him or her informed about the state of the = discussion. >=20 >
+-------+ +-------+ +-------+ > | (3.b) | -----------> | (3.c) | ------------> | (3.d) | > +-------+ Comments +-------+ Comments +-------+ > collected /|\ | understood > | |=20 > | | Comments not fully understood > | | (Further AD/Document Shepherd > | | discussion required) > +---+ > ]]>
> =09 > >=20 > > The Document Shepherd then coordinates the resolution of DI= SCUSS and COMMENT > items and builds a consistent interpretation of > the comments. This step is similar to much of the process describ= ed in > . =20 >=20 >
+-------+ +-------+ > | (3.c) | ---------------> | (3.d) | > +-------+ Consistent +-------+ > /|\ interpretation | > | | Further AD/Document Shepherd > | | discussion required > +--------------------------+ > ]]>
>=20 > >=20 > >=20 > The Document Shepherd then communicates the DISCUSS and COMMENT items= > to the document editors and the working group, alerting them of any > changes to the document that have accumulated during IESG processing,= > such as "Notes to the RFC Editor." > If any changes will be substantive, the Document > Shepherd, in consultation with the Responsible Area Director,= > as during other stages, MUST confirm working group consensus = or sometimes even IETF consensus. > >=20 > >=20 > After the editors resolve the DISCUSS and COMMENT items, > the Document Shepherd reviews the > resulting new version of the document, which will be a revised docume= nt, > a set of "Notes to the RFC Editor", or both, using his or her technic= al expertise to ensure > that all raised DISCUSS and COMMENT issues have been resolved. > =09 > >=20 > Note that the Document Shepherd MAY also > suggest resolutions to DISCUSS and COMMENT items, enter them into > an issue tracker, or perform other steps to streamline > the resolution of the evaluation comments. It is very important to > resolve the comments in a timely way, while the > discussion is current for everyone involved. =20 >=20 >=20 > > >=20 > When the Document Shepherd is satisfied that the revised do= cument > addresses the evaluation comments, he or she communicates t= he > resolution to the Responsible Area Director and the > ADs that had raised the DISCUSS and COMMENT items. >=20 > >=20 > Each AD who had raised a DISCUSS checks whether the communi= cated > resolution addresses his or her items. If it does, the AD > will clear the DISCUSS. It it does not, the AD notifies the= > Document Shepherd and adds information to the ID > Tracker explaining why the DISCUSS was not resolved. > The Document Shepherd informs the working group > accordingly. (COMMENT items need not be checked and cleared, becau= se they do > not block the document, but ADs are encouraged to do so.) >=20 > >=20 > If a DISCUSS was not resolved > to the satisfaction of the AD that has raised it or the > Responsible Area Director, two possibilities exist: > =20 > > > The process returns to step (3.d), or > >=20 > If no progress can be made on the resolution of > the DISCUSS with the AD who has raised it, despite > clarification and additional involvement of the > Responsible Area Director, the Document Shepherd > and working group might as a very last resort consider an > appeal in accordance with the procedures > described in and referred to in target=3D"RFC2418"/>. The Document Shepherd > SHOULD review the IESG's Discuss Criteria guidelines > > and discuss with the Responsible Area Director whether > there might be consideration against the unresolved > DISCUSS by the rest of the IESG due to these guidelines= =2E > =20 > >=20 > Once the process above has cleared all DISCUSS items, docum= ent shepherding continues with step (3.i). >=20 > > The Responsible Area Director moves the document to the > "Approved - Announcement to be sent" state in the ID Tracker.= > If he or she deems the changes to the revised document > significant, there may be a new WG last call, or possibly a > new IETF last call. The document goes through a new full IES= G > Evaluation process if there is a new IETF last call. = > > >
>
>=20 >=20 >
> > IETF working group documents often include considerations requiring > actions by the IANA, such as creating a new registry or adding > information to an existing registry, perhaps after consulting an > IESG-appointed Expert. Sometimes, the IESG requires actions, such a= s appointment of a new Expert. IANA-related processing > may also include a specified type of Expert review, such as review o= f > proposed MIME media types on the designated ietf-types mailing list.= > > > The IANA reviews IETF documents and requests responses at any or all= > of the following times: in response to IETF Last Call, during the > IESG Evaluation review of the document, and at the time when the IAN= A > performs actions in its web-based registry for the document, usually= > but not always after IESG approval of the document. More details of= > the IANA process and IETF interaction are found in > . > > > At the time of this publication, RFC2434 is under revision > and > the updates are and will be of value to the Document Shepherd. > Note that Document Shepherd MUST determine (by individual review > and consultation with others) what is the most recent and the most > applicable IANA information and guidance for his or her document, > be it the overall guidance, or external documents in his or her area, > or in other areas. An example of an external document is . > > > Whenever an IANA request comes, during whatever phase of the shepher= ding process, the requester > from IANA MUST ensure that the Document Shepherd and the Responsible= > Area Director both receive the request. The Document Shepherd is > responsible for responding as rapidly as possible. He or she should= > discuss requests that introduce any possible concerns with the > working group. The Document Shepherd and the Responsible Area > Director may decide in consultation that an IANA request leads to a > change that needs additional review or approval. > > > In general, the Document Shepherd ensures that the IANA process > completes, checks that the registry is correct and that the IANA > Matrix (http://www.iana.org/numbers.html) is complete and consistent= , and > troubleshoots when all is not well. At the end of IANA processing, > the Document Shepherd should be sure that the RFC Editor has > acknowledged IANA conclusion, i.e., that the handoff has been made. > > > In summary, the task of shepherding the IANA actions is often overlo= oked, > but is as important to coordinate and manage as all the other > document reviews the Document Shepherd has managed. As with those, > the Document Shepherd contributes greatly to quality and timeliness > of the document by effective and responsive shepherding of the IANA > requests. > >
>=20 >
> > After the IESG evaluation and resolution described in , > the IESG approves the document, and the Responsible Area Director > uses the ID Tracker to ask for any final changes to the Document > Announcement Write-Up and for it to be issued. The Document > Shepherd may have some edits for the Responsible Area Director, such= > as minor "Notes to the RFC Editor", and this is the time to consult = and > provide them. > > > The IESG approval announcement goes to the general community and to = the RFC Editor, > and now the Document Shepherd (identified in the Announcement > Write-Up) continues to shepherd the document through its technical > publication. The RFC Editor currently makes a number of types of > requests to the authors, Document Shepherd and Responsible Area > Director. The Document Shepherd SHOULD lead in responding to the RF= C > Editor and shepherd the document during the post-approval period to = its > publication. > > > The RFC Editor > request types include: editorial queries about dangling, missing, > informative and normative citations (good shepherding should try to > catch these earlier, but they happen); requests for the document sou= rce (e.g., > XML or nroff); occasional technical comments; and copy-edits for rev= iew and > close scrutiny by the authors (AUTH48). For the latter, the Documen= t > Shepherd SHOULD lead in checking that copy-edits have in no case > affected a consensus wording of the working group which prepared the= > document, and SHOULD bring speed to this checking by multiple coauth= ors. The Document Shepherd also consults with the Responsible > Area Director on reviewing proposed post-approval changes to the > document by any author. These may require Area Director approval, > and they often need to be presented to the working group for consent= > if not a full consensus procedure. > > =20 > As in other phases of document > shepherding, the Document Shepherd provides attentiveness and timeli= ness > by serving as the informed representative of the document and helpin= g > its advancement and its integrity. > >
>=20 >=20 >
> > As mentioned in , the Document Shepher= d SHOULD NOT be an editor of the shepherded document. If this cannot be a= voided by making another working group chair or secretary the Document Sh= epherd, the document shepherding process SHOULD NOT be used. There are se= veral other cases in which the document shepherding process SHOULD NOT be= used. These include: > > Cases, where the Document Shepherd is the primary > author or editor of a large percentage of the > documents produced by the working group. > > Cases, where the Responsible Area Director > expects communication difficulties with the Document Shepherd > (either due to experience, strong views stated by the > Document Shepherd, or other issues). > > Cases, where the working group itself is > either very old, losing energy, or winding > down, i.e., cases, where it would not be > productive to initiate new processes or procedures. > > >=20 > Finally, note that other cases exist in which using the document sheph= erding process may not be productive. > The final determination as to whether to > use the document shepherding process or not is left to the Responsible= > Area Director. If the document shepherding process is not used, the Re= sponsible Area Director > acts as Document Shepherd, per the existing procedures of shepherding = by Area Directors. >=20 > >
>=20 > >=20 >
> >=20 > This document specifies a change to IETF document-processing > procedures. As such, it neither raises nor considers > protocol-specific security issues. >=20 > >
>=20 >
> >=20 > This document creates no new requirements on IANA > namespaces or other IANA requirements. >=20 > >
>=20 >
> >=20 > This document is the product of PROTO team, which > includes the authors as well as Bill Fenner, > Barbara Fuller, and Margaret Wasserman. Aaron Falk worked actively in = PROTO until the start of > 2006 and worked on earlier versions of the document. >=20 > > =20 > > =20 > The Document Shepherd Write-Up originated in an idea by John Klensin. > Thomas Narten and Margaret Wasserman implemented it for the entire Int= ernet > Area, and their template was the basis of the version used today. > >=20 > > Colin Perkins wrote the original Document Announcement Write-Up for dra= ft-ietf-avt-rtp-midi-format included in . Davi= d Black wrote the original Document Announcement Write-Up for draft-ietf-= imss-ip-over-fibre-channel included in . Both = original announcements have been modified to reflect changes to the Docum= ent Announcement Write-Up template since they were written. > >=20 > > Frank Ellermann and Olafur Gudmundsson have suggested improvements to t= he document during IETF Last Call. > >
>=20 > >=20 >=20 > > > > > > > > > > > =20 > > > The IETF Internet-Draft Tracker > > > > > > > > > > The IESG PROcess and TOols (PROTO) Team > > > > > > > > > > The General Area Review Team (GEN-ART) > > > > > > > > > >=20 >
> > This appendix includes two examples of=20 > Document Announcement Write-Ups. Many more examples with Subject lin= es such as "Protocol Action" and > "Document Action" can be found in the IETF-announce mailing list arc= hive. > > =09 >
> > > > > These documents define the RTP Payload format for MIDI (Musical=20 > Instrument Digital Interface), and additional > guidelines on implementation specifically concerning the timing of > reception and transmission for best performance in different > applications. MIDI is a real-time media, which however is brittle to > losses and errors. Therefore the RTP payload format defines recovery > journals as a way of avoiding persistent audible errors, and discusses > congestion control handling for these journals. >=20 > >=20 > The RTP payload for MIDI encodes the broad range of MIDI commands. > The format is suitable for interactive applications=20 > (such as network musical performance) and content-delivery > (such as file streaming). =20 > > > > There is consensus in the WG to publish these documents. > >=20 > > > This RTP Payload format has been implemented during the development of > the specification and successfully tested over an IP network between tw= o > remote sites, thus showing that the technical solution is successfully > working. It has been reviewed by the MIDI Manufacturers Association and= > their comments have been addressed. > >=20 > > > Magnus Westerlund and Colin Perkins jointly shepherded this document. = Allison Mankin reviewed the document > for the IESG, including a careful review with the editor of the media > types, in parallel with ietf-types list review requested on > 2006-01-08, which raised no issues. > > > >
>=20 >
> > > > > This document specifies the encapsulation of IPv6, IPv4 and ARP=20 > packets over Fibre Channel. This document also specifies the methods= > for forming IPv6 link-local addresses and statelessly autoconfigured = > IPv6 addresses on Fibre Channel networks, and a mechanism to perform = > IPv4 address resolution over Fibre Channel networks. This document > (when published as RFC) obsoletes RFC2625 and RFC3831. > > > > This document has been reviewed by Fibre Channel experts in > Technical Committee T11 (Fibre Channel standards organization) > in addition to members of the IMSS WG. There is solid support > for this document both in the WG and from T11. > >=20 > > > This document replaces and consolidates two separate RFCs on IPv4 ove= r > Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 3831). Mos= t > of its technical content is unchanged from those RFCs. The technical= > changes that have been made are primarily based on implementation > experience. > >=20 > > > The protocol has been reviewed for the IESG by David L. Black > (WG chair). Bert Wijnen has reviewed this document for the IESG. > In addition, Brian Haberman has done a review for the INT Area > as requested by WG-chair (David Black) via Margaret Wasserman. > > > >
>=20 >
> > >=20 >=20 > > > > > > > | (3.c) | ------------> | (3.d) | > +-------+ Comments +-------+ Comments +-------+ > collected /|\ | understood > | | > | | Comments not fully understood > | | (Further AD/Document Shepherd > | | discussion required) > +---+ >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 12= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > (3.d) The Document Shepherd then coordinates the resolution of > DISCUSS and COMMENT items and builds a consistent > interpretation of the comments. This step is similar to much= > of the process described in Section 3.2. >=20 > +-------+ +-------+ > | (3.c) | ---------------> | (3.d) | > +-------+ Consistent +-------+ > /|\ interpretation | > | | Further AD/Document Shepherd= > | | discussion required > +--------------------------+ >=20 > (3.e) The Document Shepherd then communicates the DISCUSS and > COMMENT items to the document editors and the working group, > alerting them of any changes to the document that have > accumulated during IESG processing, such as "Notes to the RFC= > Editor." If any changes will be substantive, the Document > Shepherd, in consultation with the Responsible Area Director,= > as during other stages, MUST confirm working group consensus > or sometimes even IETF consensus. >=20 > (3.f) After the editors resolve the DISCUSS and COMMENT items, the > Document Shepherd reviews the resulting new version of the > document, which will be a revised document, a set of "Notes t= o > the RFC Editor", or both, using his or her technical expertis= e > to ensure that all raised DISCUSS and COMMENT issues have bee= n > resolved. >=20 > Note that the Document Shepherd MAY also suggest resolutions > to DISCUSS and COMMENT items, enter them into an issue > tracker, or perform other steps to streamline the resolution > of the evaluation comments. It is very important to resolve > the comments in a timely way, while the discussion is current= > for everyone involved. >=20 > (3.g) When the Document Shepherd is satisfied that the revised > document addresses the evaluation comments, he or she > communicates the resolution to the Responsible Area Director > and the ADs that had raised the DISCUSS and COMMENT items. >=20 > (3.h) Each AD who had raised a DISCUSS checks whether the > communicated resolution addresses his or her items. If it > does, the AD will clear the DISCUSS. It it does not, the AD > notifies the Document Shepherd and adds information to the ID= > Tracker explaining why the DISCUSS was not resolved. The > Document Shepherd informs the working group accordingly. > (COMMENT items need not be checked and cleared, because they >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 13= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > do not block the document, but ADs are encouraged to do so.) >=20 > If a DISCUSS was not resolved to the satisfaction of the AD > that has raised it or the Responsible Area Director, two > possibilities exist: >=20 > (a) The process returns to step (3.d), or >=20 > (b) If no progress can be made on the resolution of the > DISCUSS with the AD who has raised it, despite > clarification and additional involvement of the > Responsible Area Director, the Document Shepherd and > working group might as a very last resort consider an > appeal in accordance with the procedures described in > [RFC2026] and referred to in [RFC2418]. The Document > Shepherd SHOULD review the IESG's Discuss Criteria > guidelines [I-D.iesg-discuss-criteria] and discuss with > the Responsible Area Director whether there might be > consideration against the unresolved DISCUSS by the rest= > of the IESG due to these guidelines. >=20 > Once the process above has cleared all DISCUSS items, documen= t > shepherding continues with step (3.i). >=20 > (3.i) The Responsible Area Director moves the document to the > "Approved - Announcement to be sent" state in the ID Tracker.= > If he or she deems the changes to the revised document > significant, there may be a new WG last call, or possibly a > new IETF last call. The document goes through a new full IES= G > Evaluation process if there is a new IETF last call. >=20 >=20 > 4. Shepherding the Document's IANA Actions >=20 > IETF working group documents often include considerations requiring > actions by the IANA, such as creating a new registry or adding > information to an existing registry, perhaps after consulting an > IESG-appointed Expert. Sometimes, the IESG requires actions, such a= s > appointment of a new Expert. IANA-related processing may also > include a specified type of Expert review, such as review of propose= d > MIME media types on the designated ietf-types mailing list. >=20 > The IANA reviews IETF documents and requests responses at any or all= > of the following times: in response to IETF Last Call, during the > IESG Evaluation review of the document, and at the time when the IAN= A > performs actions in its web-based registry for the document, usually= > but not always after IESG approval of the document. More details of= > the IANA process and IETF interaction are found in [RFC2434]. >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 14= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > At the time of this publication, RFC2434 is under revision > [I-D.narten-iana-considerations-rfc2434bis] and the updates are and > will be of value to the Document Shepherd. Note that Document > Shepherd MUST determine (by individual review and consultation with > others) what is the most recent and the most applicable IANA > information and guidance for his or her document, be it the overall > guidance, or external documents in his or her area, or in other > areas. An example of an external document is [RFC4020]. >=20 > Whenever an IANA request comes, during whatever phase of the > shepherding process, the requester from IANA MUST ensure that the > Document Shepherd and the Responsible Area Director both receive the= > request. The Document Shepherd is responsible for responding as > rapidly as possible. He or she should discuss requests that > introduce any possible concerns with the working group. The Documen= t > Shepherd and the Responsible Area Director may decide in consultatio= n > that an IANA request leads to a change that needs additional review > or approval. >=20 > In general, the Document Shepherd ensures that the IANA process > completes, checks that the registry is correct and that the IANA > Matrix (http://www.iana.org/numbers.html) is complete and consistent= , > and troubleshoots when all is not well. At the end of IANA > processing, the Document Shepherd should be sure that the RFC Editor= > has acknowledged IANA conclusion, i.e., that the handoff has been > made. >=20 > In summary, the task of shepherding the IANA actions is often > overlooked, but is as important to coordinate and manage as all the > other document reviews the Document Shepherd has managed. As with > those, the Document Shepherd contributes greatly to quality and > timeliness of the document by effective and responsive shepherding o= f > the IANA requests. >=20 >=20 > 5. Document Shepherding after IESG Approval >=20 > After the IESG evaluation and resolution described in Section 3.3, > the IESG approves the document, and the Responsible Area Director > uses the ID Tracker to ask for any final changes to the Document > Announcement Write-Up and for it to be issued. The Document Shepher= d > may have some edits for the Responsible Area Director, such as minor= > "Notes to the RFC Editor", and this is the time to consult and > provide them. >=20 > The IESG approval announcement goes to the general community and to > the RFC Editor, and now the Document Shepherd (identified in the > Announcement Write-Up) continues to shepherd the document through it= s >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 15= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > technical publication. The RFC Editor currently makes a number of > types of requests to the authors, Document Shepherd and Responsible > Area Director. The Document Shepherd SHOULD lead in responding to > the RFC Editor and shepherd the document during the post-approval > period to its publication. >=20 > The RFC Editor request types include: editorial queries about > dangling, missing, informative and normative citations (good > shepherding should try to catch these earlier, but they happen); > requests for the document source (e.g., XML or nroff); occasional > technical comments; and copy-edits for review and close scrutiny by > the authors (AUTH48). For the latter, the Document Shepherd SHOULD > lead in checking that copy-edits have in no case affected a consensu= s > wording of the working group which prepared the document, and SHOULD= > bring speed to this checking by multiple coauthors. The Document > Shepherd also consults with the Responsible Area Director on > reviewing proposed post-approval changes to the document by any > author. These may require Area Director approval, and they often > need to be presented to the working group for consent if not a full > consensus procedure. >=20 > As in other phases of document shepherding, the Document Shepherd > provides attentiveness and timeliness by serving as the informed > representative of the document and helping its advancement and its > integrity. >=20 >=20 > 6. When Not to Use the Document Shepherding Process >=20 > As mentioned in Section 3, the Document Shepherd SHOULD NOT be an > editor of the shepherded document. If this cannot be avoided by > making another working group chair or secretary the Document > Shepherd, the document shepherding process SHOULD NOT be used. Ther= e > are several other cases in which the document shepherding process > SHOULD NOT be used. These include: >=20 > 1. Cases, where the Document Shepherd is the primary author or > editor of a large percentage of the documents produced by the > working group. >=20 > 2. Cases, where the Responsible Area Director expects communication= > difficulties with the Document Shepherd (either due to > experience, strong views stated by the Document Shepherd, or > other issues). >=20 > 3. Cases, where the working group itself is either very old, losing= > energy, or winding down, i.e., cases, where it would not be > productive to initiate new processes or procedures. >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 16= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > Finally, note that other cases exist in which using the document > shepherding process may not be productive. The final determination > as to whether to use the document shepherding process or not is left= > to the Responsible Area Director. If the document shepherding > process is not used, the Responsible Area Director acts as Document > Shepherd, per the existing procedures of shepherding by Area > Directors. >=20 >=20 > 7. Security Considerations >=20 > This document specifies a change to IETF document-processing > procedures. As such, it neither raises nor considers protocol- > specific security issues. >=20 >=20 > 8. IANA Considerations >=20 > This document creates no new requirements on IANA namespaces or othe= r > IANA requirements. >=20 >=20 > 9. Acknowledgments >=20 > This document is the product of PROTO team, which includes the > authors as well as Bill Fenner, Barbara Fuller, and Margaret > Wasserman. Aaron Falk worked actively in PROTO until the start of > 2006 and worked on earlier versions of the document. >=20 > The Document Shepherd Write-Up originated in an idea by John Klensin= =2E > Thomas Narten and Margaret Wasserman implemented it for the entire > Internet Area, and their template was the basis of the version used > today. >=20 > Colin Perkins wrote the original Document Announcement Write-Up for > draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Blac= k > wrote the original Document Announcement Write-Up for > draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Bot= h > original announcements have been modified to reflect changes to the > Document Announcement Write-Up template since they were written. >=20 > Frank Ellermann and Olafur Gudmundsson have suggested improvements t= o > the document during IETF Last Call. >=20 >=20 > 10. Informative References >=20 > [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 17= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > Standards Track Code Points", BCP 100, RFC 4020, > February 2005. >=20 > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. >=20 > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > 3", BCP 9, RFC 2026, October 1996. >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [RFC2418] Bradner, S., "IETF Working Group Guidelines and > Procedures", BCP 25, RFC 2418, September 1998. >=20 > [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track > Documents may Refer Normatively to Documents at a Lower > Level", BCP 97, RFC 3967, December 2004. >=20 > [I-D.iesg-discuss-criteria] > Peterson, J., "DISCUSS Criteria in IESG Review", > draft-iesg-discuss-criteria-02 (work in progress), > February 2006. >=20 > [I-D.narten-iana-considerations-rfc2434bis] > Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", > draft-narten-iana-considerations-rfc2434bis-05 (work in > progress), September 2006. >=20 > [IDTRACKER] > "The IETF Internet-Draft Tracker", Web > Application: https://datatracker.ietf.org/, 2002. >=20 > [PROTO] "The IESG PROcess and TOols (PROTO) Team", Web > Page: http://psg.com/~mrw/PROTO-Team, 2004. >=20 > [GEN-ART] "The General Area Review Team (GEN-ART)", Web Page: > http://www.alvestrand.no/ietf/gen/review-guidelines.html= , > 2005. >=20 >=20 > Appendix A. Example Document Announcement Write-Ups >=20 > This appendix includes two examples of Document Announcement Write- > Ups. Many more examples with Subject lines such as "Protocol Action= " > and "Document Action" can be found in the IETF-announce mailing list= >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 18= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > archive. >=20 > A.1. Example Document Announcement Write-Up for > draft-ietf-avt-rtp-midi-format >=20 > Technical Summary >=20 > These documents define the RTP Payload format for MIDI (Musical > Instrument Digital Interface), and additional guidelines on > implementation specifically concerning the timing of reception an= d > transmission for best performance in different applications. MID= I > is a real-time media, which however is brittle to losses and > errors. Therefore the RTP payload format defines recovery > journals as a way of avoiding persistent audible errors, and > discusses congestion control handling for these journals. >=20 > The RTP payload for MIDI encodes the broad range of MIDI commands= =2E > The format is suitable for interactive applications (such as > network musical performance) and content-delivery (such as file > streaming). >=20 > Working Group Summary >=20 > There is consensus in the WG to publish these documents. >=20 > Document Quality >=20 > This RTP Payload format has been implemented during the > development of the specification and successfully tested over an > IP network between two remote sites, thus showing that the > technical solution is successfully working. It has been reviewed= > by the MIDI Manufacturers Association and their comments have bee= n > addressed. >=20 > Personnel >=20 > Magnus Westerlund and Colin Perkins jointly shepherded this > document. Allison Mankin reviewed the document for the IESG, > including a careful review with the editor of the media types, in= > parallel with ietf-types list review requested on 2006-01-08, > which raised no issues. >=20 > A.2. Example Document Announcement Write-Up for > draft-ietf-imss-ip-over-fibre-channel >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 19= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > Technical Summary >=20 > This document specifies the encapsulation of IPv6, IPv4 and ARP > packets over Fibre Channel. This document also specifies the > methods for forming IPv6 link-local addresses and statelessly > autoconfigured IPv6 addresses on Fibre Channel networks, and a > mechanism to perform IPv4 address resolution over Fibre Channel > networks. This document (when published as RFC) obsoletes RFC262= 5 > and RFC3831. >=20 > Working Group Summary >=20 > This document has been reviewed by Fibre Channel experts in > Technical Committee T11 (Fibre Channel standards organization) in= > addition to members of the IMSS WG. There is solid support for > this document both in the WG and from T11. >=20 > Document Quality >=20 > This document replaces and consolidates two separate RFCs on IPv4= > over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC > 3831). Most of its technical content is unchanged from those > RFCs. The technical changes that have been made are primarily > based on implementation experience. >=20 > Personnel >=20 > The protocol has been reviewed for the IESG by David L. Black (WG= > chair). Bert Wijnen has reviewed this document for the IESG. In= > addition, Brian Haberman has done a review for the INT Area as > requested by WG-chair (David Black) via Margaret Wasserman. >=20 >=20 > Authors' Addresses >=20 > Henrik Levkowetz > Torsgatan 71 > Stockholm S-113 37 > Sweden >=20 > Phone: +46 708 32 16 08 > Email: henrik@levkowetz.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 20= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > David Meyer > 1225 Kincaid St > Eugene, OR 97403 > USA >=20 > Phone: +1 541 346 1747 > Email: dmm@1-4-5.net >=20 >=20 > Lars Eggert > Nokia Research Center > P.O. Box 407 > Nokia Group 00045 > Finland >=20 > Phone: +49 50 48 24461 > Email: lars.eggert@nokia.com > URI: http://research.nokia.com/people/lars_eggert >=20 >=20 > Allison Mankin >=20 > Phone: +1-301-728-7199 > Email: mankin@psg.com > URI: http://www.psg.com/~mankin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 21= ] > =0C > Internet-Draft Document Shepherding to IESG Approval January 200= 7 >=20 >=20 > Full Copyright Statement >=20 > Copyright (C) The IETF Trust (2007). >=20 > 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. >=20 > This document and the information contained herein are provided on a= n > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENT= S > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AN= D > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS= > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE O= F > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >=20 >=20 > Intellectual Property >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed t= o > 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. Informatio= n > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. >=20 > 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 o= f > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository a= t > http://www.ietf.org/ipr. >=20 > 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. >=20 >=20 > Acknowledgment >=20 > Funding for the RFC Editor function is provided by the IETF > Administrative Support Activity (IASA). >=20 >=20 >=20 >=20 >=20 > Levkowetz, et al. Expires July 28, 2007 [Page 22= ] > =0C >=20 >=20 > -----------------------------------------------------------------------= - >=20 >=20 > draft-ietf-proto-wgchair-doc-shepherding-08.txt =20 > draft-ietf-proto-wgchair-doc-shepherding.txt =09 > =09 > PROTO Team H. Levkowetz PROTO Team H. Levkowetz=09 > Internet-Draft Ericsson Internet-Draft Ericsson=09 > Intended status: Informational D. Meyer Intended status: Informationa= l D. Meyer=09 > Expires: April 25, 2007 Cisco/University of Oregon Expires: July 28, = 2007=20 > Cisco/University of Oregon=09 > L. Eggert L. Eggert=09 > NEC Nokia=09 > A. Mankin A. Mankin=09 > October 22, 2006 January 24, 2007=09 > =09 > Document Shepherding from Working Group Last Call to Publication Docu= ment=20 > Shepherding from Working Group Last Call to Publication=09 > draft-ietf-proto-wgchair-doc-shepherding-08 =20 > draft-ietf-proto-wgchair-doc-shepherding-09=09 > =09 > Status of this Memo Status of this Memo=09 > =09 > By submitting this Internet-Draft, each author represents that any By= =20 > submitting this Internet-Draft, each author represents that any=09 > applicable patent or other IPR claims of which he or she is aware app= licable=20 > patent or other IPR claims of which he or she is aware=09 > have been or will be disclosed, and any of which he or she becomes ha= ve been=20 > or will be disclosed, and any of which he or she becomes=09 > aware will be disclosed, in accordance with Section 6 of BCP 79. awar= e will be=20 > disclosed, in accordance with Section 6 of BCP 79.=09 > =09 > Internet-Drafts are working documents of the Internet Engineering =20 > Internet-Drafts are working documents of the Internet Engineering=09 > Task Force (IETF), its areas, and its working groups. Note that Task = Force=20 > (IETF), its areas, and its working groups. Note that=09 > =09 > skipping to change at/ page 1, line 38/ skipping to change at/ page 1= , line 38/=09 > and may be updated, replaced, or obsoleted by other documents at any = and may=20 > be updated, replaced, or obsoleted by other documents at any=09 > time. It is inappropriate to use Internet-Drafts as reference time. I= t is=20 > inappropriate to use Internet-Drafts as reference=09 > material or to cite them other than as "work in progress." material o= r to cite=20 > them other than as "work in progress."=09 > =09 > The list of current Internet-Drafts can be accessed at The list of cu= rrent=20 > Internet-Drafts can be accessed at=09 > http://www.ietf.org/ietf/1id-abstracts.txt. =20 > http://www.ietf.org/ietf/1id-abstracts.txt.=09 > =09 > The list of Internet-Draft Shadow Directories can be accessed at The = list of=20 > Internet-Draft Shadow Directories can be accessed at=09 > http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.=09 > =09 > This Internet-Draft will expire on April 25, 2007. This Internet-Draf= t will=20 > expire on July 28, 2007.=09 > =09 > Copyright Notice Copyright Notice=09 > =09 > Copyright (C) The Internet Society (2006). Copyright (C) The IETF Tru= st (2007).=09 > =09 > Abstract Abstract=09 > =09 > This document describes methodologies that have been designed to This= document=20 > describes methodologies that have been designed to=09 > improve and facilitate IETF document flow processing. It specifies a = improve=20 > and facilitate IETF document flow processing. It specifies a=09 > set of procedures under which a working group chair or secretary set = of=20 > procedures under which a working group chair or secretary=09 > serves as the primary Document Shepherd for a document that has been = serves as=20 > the primary Document Shepherd for a document that has been=09 > submitted to the IESG for publication. Before this, the Area submitte= d to the=20 > IESG for publication. Before this, the Area=09 > Director responsible for the working group has traditionally filled D= irector=20 > responsible for the working group has traditionally filled=09 > the shepherding role. the shepherding role.=09 > =09 > skipping to change at/ page 3, line 16/ skipping to change at/ page 3= , line 16/=09 > =09 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1= =2E=20 > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=09 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.= =20 > Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5=09 > 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 3.= Process=20 > Description . . . . . . . . . . . . . . . . . . . . . 5=09 > 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6 3.1= =2E=20 > Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6=09 > 3.2. Document Shepherding during AD Evaluation . . . . . . . . 10 3.2= =2E=20 > Document Shepherding during AD Evaluation . . . . . . . . 10=09 > 3.3. Document Shepherding during IESG Evaluation . . . . . . . 11 3.3= =2E=20 > Document Shepherding during IESG Evaluation . . . . . . . 11=09 > 4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14 4= =2E=20 > Shepherding the Document's IANA Actions . . . . . . . . . . . 14=09 > 5. Document Shepherding after IESG Approval . . . . . . . . . . . 15 = 5.=20 > Document Shepherding after IESG Approval . . . . . . . . . . . 15=09 > 6. When Not to Use the Document Shepherding Process . . . . . . . 16 = 6. When=20 > Not to Use the Document Shepherding Process . . . . . . . 16=09 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7= =2E=20 > Security Considerations . . . . . . . . . . . . . . . . . . . 17=09 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8= =2E IANA=20 > Considerations . . . . . . . . . . . . . . . . . . . . . 17=09 > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9= =2E=20 > Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17=09 > 10. Informative References . . . . . . . . . . . . . . . . . . . . 17 = 10.=20 > Informative References . . . . . . . . . . . . . . . . . . . . 17=09 > Appendix A. Example Document Announcement Write-Ups . . . . . . . 18 = Appendix=20 > A. Example Document Announcement Write-Ups . . . . . . . 18=09 > A.1. Example Document Announcement Write-Up for A.1. Example Document= =20 > Announcement Write-Up for=09 > draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18 =20 > draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 19=09 > A.2. Example Document Announcement Write-Up for A.2. Example Document= =20 > Announcement Write-Up for=09 > draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19 =20 > draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19=09 > Appendix B. Working Documents . . . . . . . . . . . . . . . . . . 20 = =09 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 = Authors'=20 > Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20=09 > Intellectual Property and Copyright Statements . . . . . . . . . . 22 = =20 > Intellectual Property and Copyright Statements . . . . . . . . . . 22=09 > =09 > 1. Introduction 1. Introduction=09 > =09 > Early in 2004, the IESG undertook several experiments aimed at Early = in 2004,=20 > the IESG undertook several experiments aimed at=09 > evaluating whether any of the proposed changes to the IETF document e= valuating=20 > whether any of the proposed changes to the IETF document=09 > flow process would yield qualitative improvements in document flow pr= ocess=20 > would yield qualitative improvements in document=09 > throughput and quality. One such experiment, referred to as the throu= ghput and=20 > quality. One such experiment, referred to as the=09 > "PROTO process" or "PROTO" (because it was created by the "PROcess "P= ROTO=20 > process" or "PROTO" (because it was created by the "PROcess=09 > and TOols" or PROTO [PROTO] team, is a set of methodologies designed = and=20 > TOols" or PROTO [PROTO] team), is a set of methodologies designed=09 > to involve working group chairs or secretaries more directly in their = to=20 > involve working group chairs or secretaries more directly in their=09 > documents' approval life cycle. In particular, the PROTO team documen= ts'=20 > approval life cycle. In particular, the PROTO team=09 > focused on improvements to the part of a document's life cycle that f= ocused on=20 > improvements to the part of a document's life cycle that=09 > occurs after the working group and document editor have forwarded it = occurs=20 > after the working group and document editor have forwarded it=09 > to the IESG for publication. to the IESG for publication.=09 > =09 > By the end of 2004, the IESG had evaluated the utility of the PROTO B= y the end=20 > of 2004, the IESG had evaluated the utility of the PROTO=09 > methodologies based on data obtained through several pilot projects =20 > methodologies based on data obtained through several pilot projects=09 > that had run throughout the year, and subsequently decided to adopt t= hat had=20 > run throughout the year, and subsequently decided to adopt=09 > the PROTO process for all documents and working groups. This the PROT= O process=20 > for all documents and working groups. This=09 > =09 > skipping to change at/ page 6, line 35/ skipping to change at/ page 6= , line 35/=09 > Section 6 discusses other instances in which the document shepherding = Section=20 > 6 discusses other instances in which the document shepherding=09 > process does not apply. process does not apply.=09 > =09 > 3.1. Document Shepherd Write-Up 3.1. Document Shepherd Write-Up=09 > =09 > When a working group decides that a document is ready for submission = When a=20 > working group decides that a document is ready for submission=09 > to the IESG for publication, it is the task of the Document Shepherd = to the=20 > IESG for publication, it is the task of the Document Shepherd=09 > to complete a "Document Shepherd Write-Up" for the document. to compl= ete a=20 > "Document Shepherd Write-Up" for the document.=09 > =09 > There are two parts to this task. First, the Document Shepherd There = are two=20 > parts to this task. First, the Document Shepherd=09 > answers questions (1.a) to (1.i) below to give the Responsible Area a= nswers=20 > questions (1.a) to (1.j) below to give the Responsible Area=09 > Director insight into the working group process that applied to this = Director=20 > insight into the working group process that applied to this=09 > document. Note that while these questions may appear redundant in doc= ument.=20 > Note that while these questions may appear redundant in=09 > some cases, they are written to elicit information that the some case= s, they=20 > are written to elicit information that the=09 > Responsible Area Director must be aware of (to this end, pointers to = > Responsible Area Director must be aware of (to this end, pointers to=09 > relevant entries in the WG archive are helpful). The goal here is to = relevant=20 > entries in the WG archive are helpful). The goal here is to=09 > inform the Responsible Area Director about any issues that may have i= nform the=20 > Responsible Area Director about any issues that may have=09 > come up in IETF meetings, on the mailing list, or in private come up = in IETF=20 > meetings, on the mailing list, or in private=09 > communication that they should be aware of prior to IESG evaluation =20 > communication that they should be aware of prior to IESG evaluation=09 > of the shepherded document. Any significant issues mentioned in the o= f the=20 > shepherded document. Any significant issues mentioned in the=09 > questionnaire will probably lead to a follow-up discussion with the =20 > questionnaire will probably lead to a follow-up discussion with the=09 > Responsible Area Director. Responsible Area Director.=09 > =09 > The second part of the task is to prepare the "Document Announcement = The=20 > second part of the task is to prepare the "Document Announcement=09 > Write-Up" that is input to both the ballot for the IESG telechat and = Write-Up"=20 > that is input to both the ballot for the IESG telechat and=09 > to the eventual IETF-wide announcement message. Item number (1.i) to = the=20 > eventual IETF-wide announcement message. Item number (1.k)=09 > describes the elements of the Document Announcement Write-Up. describ= es the=20 > elements of the Document Announcement Write-Up.=09 > =09 > A final sentence of the Document Announcement Write-Up, simply placed = =09 > as a line at the end of the "Document Quality" section, can state the = =09 > names of the Document Shepherd and the Responsible Area Director, =09 > because the announcement will not otherwise acknowledge them. The =09 > Document Shepherd SHOULD add this information and the Responsible =09 > Area Director SHOULD add it if it is not already there. =09 > =09 > Some examples of Document Announcement Write-Ups are included in Some= examples=20 > of Document Announcement Write-Ups are included in=09 > Appendix A, and there are many more examples with subject lines such = Appendix=20 > A, and there are many more examples with subject lines such=09 > as "Protocol Action" and "Document Action" in the IETF-announce as "P= rotocol=20 > Action" and "Document Action" in the IETF-announce=09 > mailing list archive. mailing list archive.=09 > =09 > The initial template for the Document Shepherd Write-Up is included = > below, but changes are expected over time. The latest version of=09 > this template is available from the IESG section of the IETF web=09 > site.=09 > =09 > (1.a) Who is the Document Shepherd for this document? Has the (1.a) W= ho is the=20 > Document Shepherd for this document? Has the=09 > Document Shepherd personally reviewed this version of the Document Sh= epherd=20 > personally reviewed this version of the=09 > document and, in particular, does he or she believe this document and= , in=20 > particular, does he or she believe this=09 > version is ready for forwarding to the IESG for publication? version = is ready=20 > for forwarding to the IESG for publication?=09 > =09 > (1.b) Has the document had adequate review both from key WG members (= 1.b) Has=20 > the document had adequate review both from key WG members=09 > and from key non-WG members? Does the Document Shepherd have and from= key=20 > non-WG members? Does the Document Shepherd have=09 > any concerns about the depth or breadth of the reviews that any conce= rns about=20 > the depth or breadth of the reviews that=09 > have been performed? have been performed?=09 > =09 > =09 > skipping to change at/ page 7, line 39/ skipping to change at/ page 7= , line 37/=09 > e.g., security, operational complexity, someone familiar with e.g., s= ecurity,=20 > operational complexity, someone familiar with=09 > AAA, internationalization or XML? AAA, internationalization or XML?=09 > =09 > (1.d) Does the Document Shepherd have any specific concerns or (1.d) = Does the=20 > Document Shepherd have any specific concerns or=09 > issues with this document that the Responsible Area Director issues w= ith this=20 > document that the Responsible Area Director=09 > and/or the IESG should be aware of? For example, perhaps he and/or th= e IESG=20 > should be aware of? For example, perhaps he=09 > or she is uncomfortable with certain parts of the document, or or she= is=20 > uncomfortable with certain parts of the document, or=09 > has concerns whether there really is a need for it. In any has concer= ns=20 > whether there really is a need for it. In any=09 > event, if the WG has discussed those issues and has indicated event, = if the WG=20 > has discussed those issues and has indicated=09 > that it still wishes to advance the document, detail those that it st= ill=20 > wishes to advance the document, detail those=09 > concerns here. concerns here. Has an IPR disclosure related to this d= ocument=09 > been filed? If so, please include a reference to the=09 > disclosure and summarize the WG discussion and conclusion on=09 > this issue.=09 > =09 > (1.e) How solid is the WG consensus behind this document? Does it (1.= e) How=20 > solid is the WG consensus behind this document? Does it=09 > represent the strong concurrence of a few individuals, with represent= the=20 > strong concurrence of a few individuals, with=09 > others being silent, or does the WG as a whole understand and others = being=20 > silent, or does the WG as a whole understand and=09 > agree with it? agree with it?=09 > =09 > (1.f) Has anyone threatened an appeal or otherwise indicated extreme = (1.f) Has=20 > anyone threatened an appeal or otherwise indicated extreme=09 > discontent? If so, please summarise the areas of conflict in disconte= nt? If=20 > so, please summarise the areas of conflict in=09 > separate email messages to the Responsible Area Director. (It separat= e email=20 > messages to the Responsible Area Director. (It=09 > should be in a separate email because this questionnaire is should be= in a=20 > separate email because this questionnaire is=09 > =09 > skipping to change at/ page 8, line 28/ skipping to change at/ page 8= , line 28/=09 > so, list these downward references to support the Area so, list these= downward=20 > references to support the Area=09 > Director in the Last Call procedure for them [RFC3967]. Director in t= he Last=20 > Call procedure for them [RFC3967].=09 > =09 > (1.i) Has the Document Shepherd verified that the document IANA (1.i)= Has the=20 > Document Shepherd verified that the document IANA=09 > consideration section exists and is consistent with the body consider= ation=20 > section exists and is consistent with the body=09 > of the document? If the document specifies protocol of the document? = If the=20 > document specifies protocol=09 > extensions, are reservations requested in appropriate IANA extensions= , are=20 > reservations requested in appropriate IANA=09 > registries? Are the IANA registries clearly identified? If registries= ? Are the=20 > IANA registries clearly identified? If=09 > the document creates a new registry, does it define the the document = creates a=20 > new registry, does it define the=09 > proposed initial contents of the registry and an allocation proposed = initial=20 > contents of the registry and an allocation=09 > procedure for future registrations? Does it suggested a procedure for= future=20 > registrations? Does it suggest a=09 > reasonable name for the new registry? See reasonable name for the new= =20 > registry? See [RFC2434]. If the=09 > [I-D.narten-iana-considerations-rfc2434bis]. If the document document= =20 > describes an Expert Review process has Shepherd=09 > describes an Expert Review process has Shepherd conferred with confer= red with=20 > the Responsible Area Director so that the IESG=09 > the Responsible Area Director so that the IESG can appoint the can ap= point the=20 > needed Expert during the IESG Evaluation?=09 > needed Expert during the IESG Evaluation? =09 > =09 > (1.j) Has the Document Shepherd verified that sections of the (1.j) H= as the=20 > Document Shepherd verified that sections of the=09 > document that are written in a formal language, such as XML document = that are=20 > written in a formal language, such as XML=09 > code, BNF rules, MIB definitions, etc., validate correctly in code, B= NF rules,=20 > MIB definitions, etc., validate correctly in=09 > an automated checker? an automated checker?=09 > =09 > (1.k) The IESG approval announcement includes a Document (1.k) The IE= SG=20 > approval announcement includes a Document=09 > Announcement Write-Up. Please provide such a Document Announcement Wr= ite-Up.=20 > Please provide such a Document=09 > Announcement Writeup? Recent examples can be found in the Announcemen= t=20 > Write-Up? Recent examples can be found in the=09 > "Action" announcements for approved documents. The approval "Action" = > announcements for approved documents. The approval=09 > announcement contains the following sections: announcement contains t= he=20 > following sections:=09 > =09 > Technical Summary Technical Summary=09 > Relevant content can frequently be found in the abstract Relevant con= tent can=20 > frequently be found in the abstract=09 > and/or introduction of the document. If not, this may be and/or intro= duction=20 > of the document. If not, this may be=09 > an indication that there are deficiencies in the abstract an indicati= on that=20 > there are deficiencies in the abstract=09 > or introduction. or introduction.=09 > =09 > Working Group Summary Working Group Summary=09 > =09 > skipping to change at/ page 9, line 29/ skipping to change at/ page 9= , line 29/=09 > what was its course (briefly)? In the case of a Media Type what was i= ts course=20 > (briefly)? In the case of a Media Type=09 > review, on what date was the request posted? review, on what date was= the=20 > request posted?=09 > =09 > Personnel Personnel=09 > Who is the Document Shepherd for this document? Who is the Who is the= Document=20 > Shepherd for this document? Who is the=09 > Responsible Area Director? Responsible Area Director?=09 > =09 > The Document Shepherd MUST send the Document Shepherd Write-Up to the = The=20 > Document Shepherd MUST send the Document Shepherd Write-Up to the=09 > Responsible Area Director and iesg-secretary@ietf.org together with =20 > Responsible Area Director and iesg-secretary@ietf.org together with=09 > the request to publish the document. The Document Shepherd SHOULD the= request=20 > to publish the document. The Document Shepherd SHOULD=09 > also send the entire Document Shepherd Write-up to the working group = also send=20 > the entire Document Shepherd Write-Up to the working group=09 > mailing list. If the Document Shepherd feels that information which m= ailing=20 > list. If the Document Shepherd feels that information which=09 > may prove to be sensitive, lead to possible appeals or is personal ma= y prove=20 > to be sensitive, lead to possible appeals or is personal=09 > information needs to be written up, it SHOULD be sent in direct email = =20 > information needs to be written up, it SHOULD be sent in direct email=09 > to the Responsible Area Director, because the Document Shepherd to th= e=20 > Responsible Area Director, because the Document Shepherd=09 > Write-Up is published openly in the tracker. Question 1(f) of the Wri= te-Up is=20 > published openly in the ID Tracker. Question (1.f) of=09 > Write-Up covers any material of this nature and specifies this more t= he=20 > Write-Up covers any material of this nature and specifies this=09 > confidential handling. more confidential handling.=09 > =09 > The Document Shepherd Write-Up is entered into the ID Tracker The Doc= ument=20 > Shepherd Write-Up is entered into the ID Tracker=09 > [IDTRACKER] as a "Comment." The name and email address of the [IDTRAC= KER] as a=20 > "Comment." The name and email address of the=09 > Document Shepherd are entered into the ID Tracker, currently as a Doc= ument=20 > Shepherd are entered into the ID Tracker, currently as a=09 > "Brief Note" (this may change in the future). The email address of "B= rief=20 > Note" (this may change in the future). The email address of=09 > the Document Shepherd MUST also be added to the "State or Version the= Document=20 > Shepherd MUST also be added to the "State or Version=09 > Change Notice To" field (typically the email addresses of all working = Change=20 > Notice To" field (typically the email addresses of all working=09 > group chairs, authors and the Secretary will be added). group chairs,= authors=20 > and the secretary will be added).=09 > =09 > Entering the name and email of the Document Shepherd into the ID Ente= ring the=20 > name and email of the Document Shepherd into the ID=09 > Tracker is REQUIRED to ensure that he or she will be copied on the Tr= acker is=20 > REQUIRED to ensure that he or she will be copied on the=09 > email exchange between the editors, chairs, the IESG, the IESG email = exchange=20 > between the editors, chairs, the IESG, the IESG=09 > secretariat, IANA and the RFC Editor during the review and approval =20 > secretariat, IANA and the RFC Editor during the review and approval=09 > process. There are still manual steps required for these parties to p= rocess.=20 > There are still manual steps required for these parties to=09 > ensure they include the Document Shepherd, but it is hoped that in en= sure they=20 > include the Document Shepherd, but it is hoped that in=09 > future, automated tools will ensure that Document Shepherds (and futu= re,=20 > automated tools will ensure that Document Shepherds (and=09 > others) receive necessary communications. others) receive necessary=20 > communications.=09 > =09 > The contact information for the Document Shepherd is also important T= he=20 > contact information for the Document Shepherd is also important=09 > for the Gen-ART [GEN-ART] Directorate and other directorates, so they = for the=20 > Gen-ART Directorate [GEN-ART] and other directorates, so they=09 > can know to whom to address reviews, in addition to the Responsible c= an know=20 > to whom to address reviews, in addition to the Responsible=09 > Area Director. Area Director.=09 > =09 > 3.2. Document Shepherding during AD Evaluation 3.2. Document Shepherd= ing=20 > during AD Evaluation=09 > =09 > The steps for document shepherding during AD Evaluation are as The st= eps for=20 > document shepherding during AD Evaluation are as=09 > follows: follows:=09 > =09 > (2.a) The Responsible Area Director reads, evaluates and comments on = (2.a) The=20 > Responsible Area Director reads, evaluates and comments on=09 > the document, as is the case when not using the document the document= , as is=20 > the case when not using the document=09 > =09 > skipping to change at/ page 10, line 45/ skipping to change at/ page = 10, line 45/=09 > (2.d) The Document Shepherd sends the AD Evaluation comments to the (= 2.d) The=20 > Document Shepherd sends the AD Evaluation comments to the=09 > editors and to the working group mailing list, in order to editors an= d to the=20 > working group mailing list, in order to=09 > have a permanent record of the comments. It is RECOMMENDED have a per= manent=20 > record of the comments. It is RECOMMENDED=09 > that the Document Shepherd solicit from the editors an that the Docum= ent=20 > Shepherd solicit from the editors an=09 > estimate on when the required changes will be complete and a estimate= on when=20 > the required changes will be complete and a=09 > revised document can be expected. Working groups that use revised doc= ument can=20 > be expected. Working groups that use=09 > issue tracking SHOULD also record the issues (and eventually issue tr= acking=20 > SHOULD also record the issues (and eventually=09 > their resolution) in their issue tracker. their resolution) in their = issue=20 > tracker.=09 > =09 > (2.e) During the production of a revised document that addresses the = (2.e)=20 > During the production of a revised document that addresses the=09 > AD Evaluation comments, it is strongly RECOMMENDED that the AD Evalua= tion=20 > comments, it is RECOMMENDED that the editors=09 > editors keep a list showing how each comment was addressed and keep a= list=20 > showing how each comment was addressed and what=09 > what the revised text is. It is strongly RECOMMENDED that the revised= text is.=20 > It is RECOMMENDED that this list be=09 > this list be forwarded to the Responsible Area Director forwarded to = the=20 > Responsible Area Director together with the=09 > together with the revised document. revised document.=09 > =09 > (2.f) In the event that the editors or working group disagrees with (= 2.f) In=20 > the event that the editors or working group disagrees with=09 > a comment raised by the Responsible Area Director or has a comment ra= ised by=20 > the Responsible Area Director or has=09 > previously considered and dismissed the issue, the Document previousl= y=20 > considered and dismissed the issue, the Document=09 > Shepherd MUST resolve the issue with the Responsible Area Shepherd MU= ST=20 > resolve the issue with the Responsible Area=09 > Director before a revised document can be submitted. Director before = a revised=20 > document can be submitted.=09 > =09 > (2.g) The Document Shepherd iterates with the editors (and working (2= =2Eg) The=20 > Document Shepherd iterates with the editors (and working=09 > group, if required) until all outstanding issues have been group, if = required)=20 > until all outstanding issues have been=09 > resolved and a revised document is available. At this point, resolved= and a=20 > revised document is available. At this point,=09 > the Document Shepherd notifies the Responsible Area Director the Docu= ment=20 > Shepherd notifies the Responsible Area Director=09 > and provides him or her with the revised document, the summary and pr= ovides=20 > him or her with the revised document, the summary=09 > of issues and the resulting text changes. of issues and the resulting= text=20 > changes.=09 > =09 > (2.h) The Responsible Area Director verifies that the issues he or (2= =2Eh) The=20 > Responsible Area Director verifies that the issues he or=09 > she found during AD Evaluation are resolved in the revised she found = during AD=20 > Evaluation are resolved in the revised=09 > version of the document by starting the process described in version = of the=20 > document by starting the process described in=09 > this section at step (2.a). this section at step (2.a).=09 > =09 > (2.i) If the document underwent an IETF Last Call and the AD=09 > concludes that significant issues were raised during the Last=09 > Call, then steps (2.b) through (2.h) need to be applied=09 > addressing the Last Call issues. This requires the=09 > Responsible Area Director to present to the Document Shepherd=09 > those Last Call Issues raised only to the IESG.=09 > =09 > 3.3. Document Shepherding during IESG Evaluation 3.3. Document Shephe= rding=20 > during IESG Evaluation=09 > =09 > During IESG Evaluation of a document, ADs can bring forward two kinds = During=20 > IESG Evaluation of a document, ADs can bring forward two kinds=09 > of remarks about a document: DISCUSS item and COMMENT items. A of rem= arks=20 > about a document: DISCUSS item and COMMENT items. A=09 > DISCUSS blocks a document's approval process until it has been DISCUS= S blocks=20 > a document's approval process until it has been=09 > resolved; a COMMENT does not. This section details the steps that a r= esolved;=20 > a COMMENT does not. This section details the steps that a=09 > Document Shepherd takes to resolve any DISCUSS and COMMENT items Docu= ment=20 > Shepherd takes to resolve any DISCUSS and COMMENT items=09 > brought forward against a shepherded document during IESG Evaluation. = brought=20 > forward against a shepherded document during IESG Evaluation.=09 > =09 > Note that DISCUSS and COMMENT items are occasionally written in a Not= e that=20 > DISCUSS and COMMENT items are occasionally written in a=09 > =09 > skipping to change at/ page 13, line 19/ skipping to change at/ page = 13, line 23/=09 > | | Further AD/Document Shepherd | | Further AD/Document Shepherd=09 > | | discussion required | | discussion required=09 > +--------------------------+ +--------------------------+=09 > =09 > (3.e) The Document Shepherd then communicates the DISCUSS and (3.e) T= he=20 > Document Shepherd then communicates the DISCUSS and=09 > COMMENT items to the document editors and the working group, COMMENT = items to=20 > the document editors and the working group,=09 > alerting them of any changes to the document that have alerting them = of any=20 > changes to the document that have=09 > accumulated during IESG processing, such as "Notes to the RFC accumul= ated=20 > during IESG processing, such as "Notes to the RFC=09 > Editor." If any changes will be substantive, the Document Editor." If= any=20 > changes will be substantive, the Document=09 > Shepherd, in consultation with the Responsible Area Director, Shepher= d, in=20 > consultation with the Responsible Area Director,=09 > as during other stages, MUST seek working group consensus. as during = other=20 > stages, MUST confirm working group consensus=09 > or sometimes even IETF consensus.=09 > =09 > (3.f) After the editors resolve the DISCUSS and COMMENT items, the (3= =2Ef) After=20 > the editors resolve the DISCUSS and COMMENT items, the=09 > Document Shepherd reviews the resulting new version of the Document S= hepherd=20 > reviews the resulting new version of the=09 > document, which will be a revised document, a set of "Notes to docume= nt, which=20 > will be a revised document, a set of "Notes to=09 > the RFC Editor", or both, using his or her technical expertise the RF= C=20 > Editor", or both, using his or her technical expertise=09 > to ensure that all raised DISCUSS and COMMENT issues have been to ens= ure that=20 > all raised DISCUSS and COMMENT issues have been=09 > resolved. resolved.=09 > =09 > Note that the Document Shepherd MAY also suggest resolutions Note tha= t the=20 > Document Shepherd MAY also suggest resolutions=09 > to DISCUSS and COMMENT items, enter them into an issue to DISCUSS and= COMMENT=20 > items, enter them into an issue=09 > =09 > skipping to change at/ page 14, line 35/ skipping to change at/ page = 14, line 40/=09 > If he or she deems the changes to the revised document If he or she d= eems the=20 > changes to the revised document=09 > significant, there may be a new WG last call, or possibly a significa= nt, there=20 > may be a new WG last call, or possibly a=09 > new IETF last call. The document goes through a new full IESG new IET= F last=20 > call. The document goes through a new full IESG=09 > Evaluation process if there is a new IETF last call. Evaluation proce= ss if=20 > there is a new IETF last call.=09 > =09 > 4. Shepherding the Document's IANA Actions 4. Shepherding the Documen= t's IANA=20 > Actions=09 > =09 > IETF working group documents often include considerations requiring I= ETF=20 > working group documents often include considerations requiring=09 > actions by the IANA, such as creating a new registry or adding action= s by the=20 > IANA, such as creating a new registry or adding=09 > information to an existing registry, perhaps after consulting an info= rmation=20 > to an existing registry, perhaps after consulting an=09 > IESG-appointed Expert. Sometimes the actions required are by the =20 > IESG-appointed Expert. Sometimes, the IESG requires actions, such as=09 > IESG, such as appointment of a new Expert. IANA-related processing ap= pointment=20 > of a new Expert. IANA-related processing may also=09 > may also include a specified type of Expert review, such as review of = include=20 > a specified type of Expert review, such as review of proposed=09 > proposed MIME media types on the designated ietf-types mailing list. = MIME=20 > media types on the designated ietf-types mailing list.=09 > =09 > The IANA reviews IETF documents and requests responses at any or all = The IANA=20 > reviews IETF documents and requests responses at any or all=09 > of the following times: in response to IETF Last Call, during the of = the=20 > following times: in response to IETF Last Call, during the=09 > IESG Evaluation review of the document, and at the time when the IANA = IESG=20 > Evaluation review of the document, and at the time when the IANA=09 > performs actions in its web-based registry for the document, usually = performs=20 > actions in its web-based registry for the document, usually=09 > but not always after IESG approval of the document. More details of b= ut not=20 > always after IESG approval of the document. More details of=09 > the IANA process and IETF interaction are found in the IANA process a= nd IETF=20 > interaction are found in [RFC2434].=09 > [I-D.narten-iana-considerations-rfc2434bis]. =09 > =09 > Whenever an IANA request comes, in whatever period, the requester At = the time=20 > of this publication, RFC2434 is under revision=09 > from IANA MUST ensure that the Document Shepherd and the Responsible = > [I-D.narten-iana-considerations-rfc2434bis] and the updates are and=09 > Area Director both receive the request. The Document Shepherd is will= be of=20 > value to the Document Shepherd. Note that Document=09 > responsible for responding as rapidly as possible. He or she should S= hepherd=20 > MUST determine (by individual review and consultation with=09 > discuss requests that introduce any possible concerns with the others= ) what is=20 > the most recent and the most applicable IANA=09 > Working Group. The Document Shepherd and the Responsible Area informa= tion and=20 > guidance for his or her document, be it the overall=09 > Director may decide in consultation that an IANA request leads to a g= uidance,=20 > or external documents in his or her area, or in other=09 > change that needs additional review or approval. areas. An example of= an=20 > external document is [RFC4020].=09 > =09 > In general, the Working Group Shepherd ensures that the IANA process = Whenever=20 > an IANA request comes, during whatever phase of the=09 > shepherding process, the requester from IANA MUST ensure that the=09 > Document Shepherd and the Responsible Area Director both receive the= =09 > request. The Document Shepherd is responsible for responding as=09 > rapidly as possible. He or she should discuss requests that=09 > introduce any possible concerns with the working group. The Document= =09 > Shepherd and the Responsible Area Director may decide in consultatio= n=09 > that an IANA request leads to a change that needs additional review = > or approval.=09 > =09 > In general, the Document Shepherd ensures that the IANA process=09 > completes, checks that the registry is correct and that the IANA comp= letes,=20 > checks that the registry is correct and that the IANA=09 > Matrix (www.iana.org/numbers.html) is complete and consistent, and Ma= trix=20 > (http://www.iana.org/numbers.html) is complete and consistent,=09 > troubleshoots when all is not well. At the end of IANA processing, an= d=20 > troubleshoots when all is not well. At the end of IANA=09 > the Document Shepherd should be sure that the RFC Editor has processi= ng, the=20 > Document Shepherd should be sure that the RFC Editor=09 > acknowledged IANA conclusion, that the handoff has been made. has ack= nowledged=20 > IANA conclusion, i.e., that the handoff has been=09 > made.=09 > =09 > In summary, the task of shepherding the IANA actions is overlooked In= summary,=20 > the task of shepherding the IANA actions is often=09 > but is as important to coordinate and manage as all the other overloo= ked, but=20 > is as important to coordinate and manage as all the=09 > document reviews the Document Shepherd has managed. As with those, ot= her=20 > document reviews the Document Shepherd has managed. As with=09 > the Document Shepherd contributes greatly to quality and timeliness t= hose, the=20 > Document Shepherd contributes greatly to quality and=09 > of the document by effective and responsive shepherding of the IANA t= imeliness=20 > of the document by effective and responsive shepherding of=09 > requests. the IANA requests.=09 > =09 > 5. Document Shepherding after IESG Approval 5. Document Shepherding a= fter IESG=20 > Approval=09 > =09 > After the IESG Evaluation and resolution described in Section 3.3, Af= ter the=20 > IESG evaluation and resolution described in Section 3.3,=09 > the IESG approves the document, and the Responsible Area Director the= IESG=20 > approves the document, and the Responsible Area Director=09 > uses the tracker to ask for any final changes to the Document uses th= e ID=20 > Tracker to ask for any final changes to the Document=09 > Announcement Write-Up and to ask for it to be issued. The Document =20 > Announcement Write-Up and for it to be issued. The Document Shepherd=09 > Shepherd may have some edits for the Responsible Area Director, such = may have=20 > some edits for the Responsible Area Director, such as minor=09 > as minor Notes to the RFC Editor, and this is the time to consult and = "Notes=20 > to the RFC Editor", and this is the time to consult and=09 > provide them. provide them.=09 > =09 > The announcement goes to the general community and to the RFC Editor, = The IESG=20 > approval announcement goes to the general community and to=09 > and now the Document Shepherd (identified in the Announcemen the RFC = Editor,=20 > and now the Document Shepherd (identified in the=09 > Write-Up) continues to shepherd the document through its technical =20 > Announcement Write-Up) continues to shepherd the document through its=09 > publication. The RFC Editor currently makes a number of types of tech= nical=20 > publication. The RFC Editor currently makes a number of=09 > requests to the authors, Document Shepherd and Responsible Area types= of=20 > requests to the authors, Document Shepherd and Responsible=09 > Director. The Document Shepherd SHOULD lead in responding to the RFC = Area=20 > Director. The Document Shepherd SHOULD lead in responding to=09 > editor and shepherding the document through its technical the RFC Edi= tor and=20 > shepherd the document during the post-approval=09 > publication, through the post-approval period. The RFC Editor period = to its=20 > publication.=09 > request types include: editorial queries about dangling, missing, =09 > informative and normative citations (good shepherding should try to T= he RFC=20 > Editor request types include: editorial queries about=09 > pre-catch these, but they happen); requests for unedited source, e.g. = =20 > dangling, missing, informative and normative citations (good=09 > xml; occasional technical comments; and copy-edits for review and she= pherding=20 > should try to catch these earlier, but they happen);=09 > close scrutiny by the authors (AUTH48). On the latter, the Document r= equests=20 > for the document source (e.g., XML or nroff); occasional=09 > Shepherd SHOULD lead in checking that copy-edits have in no case tech= nical=20 > comments; and copy-edits for review and close scrutiny by=09 > affected a consensus wording of the working group which prepared the = the=20 > authors (AUTH48). For the latter, the Document Shepherd SHOULD=09 > document, and in bringing speed to this checking by multiple co- lead= in=20 > checking that copy-edits have in no case affected a consensus=09 > authors. The Document Shepherd also consults with the Responsible wor= ding of=20 > the working group which prepared the document, and SHOULD=09 > Area Director in reviewing proposed post-approval changes to the brin= g speed=20 > to this checking by multiple coauthors. The Document=09 > document by any authors. These may require Area Director approval, Sh= epherd=20 > also consults with the Responsible Area Director on=09 > and they often need to be presented to the working group for consent = reviewing=20 > proposed post-approval changes to the document by any=09 > if not a full consensus procedure. As in other periods of document au= thor.=20 > These may require Area Director approval, and they often=09 > review, the Document Shepherd provides attentiveness and timeliness n= eed to be=20 > presented to the working group for consent if not a full=09 > by serving as the informed representative of the document and helping = =20 > consensus procedure.=09 > its advancement and its integrity. =09 > As in other phases of document shepherding, the Document Shepherd=09 > provides attentiveness and timeliness by serving as the informed=09 > representative of the document and helping its advancement and its=09 > integrity.=09 > =09 > 6. When Not to Use the Document Shepherding Process 6. When Not to Us= e the=20 > Document Shepherding Process=09 > =09 > As mentioned in Section 3, the Document Shepherd SHOULD NOT be an As = mentioned=20 > in Section 3, the Document Shepherd SHOULD NOT be an=09 > editor of the shepherded document. If this cannot be avoided by edito= r of the=20 > shepherded document. If this cannot be avoided by=09 > making another working group chair or secretary the Document making a= nother=20 > working group chair or secretary the Document=09 > Shepherd, the document shepherding process SHOULD NOT be used. There = Shepherd,=20 > the document shepherding process SHOULD NOT be used. There=09 > are several other cases in which the document shepherding process are= several=20 > other cases in which the document shepherding process=09 > SHOULD NOT be used. These include: SHOULD NOT be used. These include:= =09 > =09 > =09 > skipping to change at/ page 16, line 37/ skipping to change at/ page = 17, line 10/=09 > =09 > 3. Cases, where the working group itself is either very old, losing 3= =2E Cases,=20 > where the working group itself is either very old, losing=09 > energy, or winding down, i.e., cases, where it would not be energy, o= r winding=20 > down, i.e., cases, where it would not be=09 > productive to initiate new processes or procedures. productive to ini= tiate new=20 > processes or procedures.=09 > =09 > Finally, note that other cases exist in which using the document Fina= lly, note=20 > that other cases exist in which using the document=09 > shepherding process may not be productive. The final determination sh= epherding=20 > process may not be productive. The final determination=09 > as to whether to use the document shepherding process or not is left = as to=20 > whether to use the document shepherding process or not is left=09 > to the Responsible Area Director. If the document shepherding to the = > Responsible Area Director. If the document shepherding=09 > process is not used, the Responsible Area Director acts as Document p= rocess is=20 > not used, the Responsible Area Director acts as Document=09 > Shepherd, just as he or she did in the past. Shepherd, per the existi= ng=20 > procedures of shepherding by Area=09 > Directors.=09 > =09 > 7. Security Considerations 7. Security Considerations=09 > =09 > This document specifies a change to IETF document-processing This doc= ument=20 > specifies a change to IETF document-processing=09 > procedures. As such, it neither raises nor considers protocol- proced= ures. As=20 > such, it neither raises nor considers protocol-=09 > specific security issues. specific security issues.=09 > =09 > 8. IANA Considerations 8. IANA Considerations=09 > =09 > This document creates no new requirements on IANA namespaces or other = This=20 > document creates no new requirements on IANA namespaces or other=09 > IANA requirements. IANA requirements.=09 > =09 > 9. Acknowledgments 9. Acknowledgments=09 > =09 > This document is the product of PROTO team, which includes the This d= ocument=20 > is the product of PROTO team, which includes the=09 > authors as well as Bill Fenner, Barbara Fuller, and Margaret authors = as well=20 > as Bill Fenner, Barbara Fuller, and Margaret=09 > Wasserman. Aaron Falk worked actively in PROTO till the start of Wass= erman.=20 > Aaron Falk worked actively in PROTO until the start of=09 > 2006 and worked on earlier versions of the document. 2006 and worked = on=20 > earlier versions of the document.=09 > =09 > The Document Shepherd Write-Up originated in an idea by John Klensin. = The=20 > Document Shepherd Write-Up originated in an idea by John Klensin.=09 > Thomas Narten and Margaret Wasserman implemented it for the entire Th= omas=20 > Narten and Margaret Wasserman implemented it for the entire=09 > Internet Area, and their template was the basis of the version used I= nternet=20 > Area, and their template was the basis of the version used=09 > today. today.=09 > =09 > Colin Perkins wrote the Document Announcement Write-Up for Colin Perk= ins wrote=20 > the original Document Announcement Write-Up for=09 > draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black = > draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black=09 > wrote the Document Announcement Write-Up for wrote the original Docum= ent=20 > Announcement Write-Up for=09 > draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. =20 > draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both=09 > original announcements have been modified to reflect changes to the = > Document Announcement Write-Up template since they were written.=09 > =09 > Frank Ellermann and Olafur Gudmundsson have suggested improvements to = Frank=20 > Ellermann and Olafur Gudmundsson have suggested improvements to=09 > the document during IETF Last Call. the document during IETF Last Cal= l.=09 > =09 > 10. Informative References 10. Informative References=09 > =09 > [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of=09 > Standards Track Code Points", BCP 100, RFC 4020,=09 > February 2005.=09 > =09 > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an=09 > IANA Considerations Section in RFCs", BCP 26, RFC 2434,=09 > October 1998.=09 > =09 > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision [R= FC2026]=20 > Bradner, S., "The Internet Standards Process -- Revision=09 > 3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.= =09 > =09 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC211= 9]=20 > Bradner, S., "Key words for use in RFCs to Indicate=09 > Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels= ", BCP=20 > 14, RFC 2119, March 1997.=09 > =09 > [RFC2418] Bradner, S., "IETF Working Group Guidelines and [RFC2418] B= radner,=20 > S., "IETF Working Group Guidelines and=09 > Procedures", BCP 25, RFC 2418, September 1998. Procedures", BCP 25, R= FC 2418,=20 > September 1998.=09 > =09 > [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track [R= FC3967]=20 > Bush, R. and T. Narten, "Clarifying when Standards Track=09 > =09 > skipping to change at/ page 19, line 4/ skipping to change at/ page 1= 9, line 36/=09 > =09 > There is consensus in the WG to publish these documents. There is con= sensus in=20 > the WG to publish these documents.=09 > =09 > Document Quality Document Quality=09 > =09 > This RTP Payload format has been implemented during the This RTP Payl= oad=20 > format has been implemented during the=09 > development of the specification and successfully tested over an deve= lopment=20 > of the specification and successfully tested over an=09 > IP network between two remote sites, thus showing that the IP network= between=20 > two remote sites, thus showing that the=09 > technical solution is successfully working. It has been reviewed tech= nical=20 > solution is successfully working. It has been reviewed=09 > by the MIDI Manufacturers Association and their comments have been by= the MIDI=20 > Manufacturers Association and their comments have been=09 > addressed. Allison Mankin reviewed the document for the IESG, address= ed.=09 > =09 > Personnel=09 > =09 > Magnus Westerlund and Colin Perkins jointly shepherded this=09 > document. Allison Mankin reviewed the document for the IESG,=09 > including a careful review with the editor of the media types, in inc= luding a=20 > careful review with the editor of the media types, in=09 > parallel with ietf-types list review requested on 2006-01-08, paralle= l with=20 > ietf-types list review requested on 2006-01-08,=09 > which raised no issues. which raised no issues.=09 > =09 > Magnus Westerlund and Colin Perkins jointly shepherded these =09 > documents. =09 > =09 > A.2. Example Document Announcement Write-Up for A.2. Example Document= =20 > Announcement Write-Up for=09 > draft-ietf-imss-ip-over-fibre-channel draft-ietf-imss-ip-over-fibre-c= hannel=09 > =09 > Technical Summary Technical Summary=09 > =09 > This document specifies the encapsulation of IPv6, IPv4 and ARP This = document=20 > specifies the encapsulation of IPv6, IPv4 and ARP=09 > packets over Fibre Channel. This document also specifies the packets = over=20 > Fibre Channel. This document also specifies the=09 > methods for forming IPv6 link-local addresses and statelessly methods= for=20 > forming IPv6 link-local addresses and statelessly=09 > autoconfigured IPv6 addresses on Fibre Channel networks, and a autoco= nfigured=20 > IPv6 addresses on Fibre Channel networks, and a=09 > mechanism to perform IPv4 address resolution over Fibre Channel mecha= nism to=20 > perform IPv4 address resolution over Fibre Channel=09 > networks. This document (when published as RFC) obsoletes RFC2625 net= works.=20 > This document (when published as RFC) obsoletes RFC2625=09 > and RFC3831. and RFC3831.=09 > =09 > =09 > skipping to change at/ page 19, line 40/ skipping to change at/ page = 20, line 29/=09 > this document both in the WG and from T11. this document both in the = WG and=20 > from T11.=09 > =09 > Document Quality Document Quality=09 > =09 > This document replaces and consolidates two separate RFCs on IPv4 Thi= s=20 > document replaces and consolidates two separate RFCs on IPv4=09 > over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC over F= ibre=20 > Channel (RFC 2625) and IPv6 over Fibre Channel (RFC=09 > 3831). Most of its technical content is unchanged from those 3831). M= ost of=20 > its technical content is unchanged from those=09 > RFCs. The technical changes that have been made are primarily RFCs. T= he=20 > technical changes that have been made are primarily=09 > based on implementation experience. based on implementation experienc= e.=09 > =09 > The protocol has been reviewed for the IESG by David L. Black (WG Per= sonnel=09 > chair). =09 > =09 > Also Bert Wijnen has reviewed this document for the IESG. =09 > =09 > In addition, Brian Haberman has done a review for the INT Area as The= protocol=20 > has been reviewed for the IESG by David L. Black (WG=09 > chair). Bert Wijnen has reviewed this document for the IESG. In=09 > addition, Brian Haberman has done a review for the INT Area as=09 > requested by WG-chair (David Black) via Margaret Wasserman. requested= by=20 > WG-chair (David Black) via Margaret Wasserman.=09 > =09 > Appendix B. Working Documents =09 > =09 > (This section should be removed by the RFC editor before =09 > publication.) =09 > =09 > The current working documents for this document are available at this = =09 > web site: =09 > =09 > http://tools.ietf.org/wg/proto/ =09 > draft-ietf-proto-wgchair-doc-shepherding/ =09 > =09 > Authors' Addresses Authors' Addresses=09 > =09 > Henrik Levkowetz Henrik Levkowetz=09 > Torsgatan 71 Torsgatan 71=09 > Stockholm S-113 37 Stockholm S-113 37=09 > Sweden Sweden=09 > =09 > Phone: +46 708 32 16 08 Phone: +46 708 32 16 08=09 > Email: henrik@levkowetz.com Email: henrik@levkowetz.com=09 > =09 > David Meyer David Meyer=09 > 1225 Kincaid St 1225 Kincaid St=09 > Eugene, OR 97403 Eugene, OR 97403=09 > USA USA=09 > =09 > Phone: +1 541 346 1747 Phone: +1 541 346 1747=09 > Email: dmm@1-4-5.net Email: dmm@1-4-5.net=09 > =09 > Lars Eggert Lars Eggert=09 > NEC Network Laboratories Nokia Research Center=09 > Kurfuerstenanlage 36 P.O. Box 407=09 > Heidelberg 69115 Nokia Group 00045=09 > Germany Finland=09 > =09 > Phone: +49 50 48 24461=09 > Email: lars.eggert@nokia.com=09 > URI: http://research.nokia.com/people/lars_eggert=09 > =09 > Phone: +49 6221 4342 143 =09 > Fax: +49 6221 4342 155 =09 > Email: lars.eggert@netlab.nec.de =09 > URI: http://www.netlab.nec.de/ =09 > Allison Mankin Allison Mankin=09 > =09 > Phone: +1-301-728-7199 Phone: +1-301-728-7199=09 > Email: mankin@psg.com Email: mankin@psg.com=09 > URI: http://www.psg.com/~mankin URI: http://www.psg.com/~mankin=09 > =09 > Full Copyright Statement Full Copyright Statement=09 > =09 > Copyright (C) The Internet Society (2006). Copyright (C) The IETF Tru= st (2007).=09 > =09 > This document is subject to the rights, licenses and restrictions Thi= s=20 > document is subject to the rights, licenses and restrictions=09 > contained in BCP 78, and except as set forth therein, the authors con= tained in=20 > BCP 78, and except as set forth therein, the authors=09 > retain all their rights. retain all their rights.=09 > =09 > This document and the information contained herein are provided on an = This=20 > document and the information contained herein are provided on an=09 > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS = "AS IS"=20 > basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=09 > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR= IS=20 > SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=09 > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, T= HE=20 > INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=09 > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPL= IED,=20 > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=09 > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE IN= FORMATION=20 > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=09 > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WA= RRANTIES=20 > OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=09 > =09 > Intellectual Property Intellectual Property=09 > =09 > The IETF takes no position regarding the validity or scope of any The= IETF=20 > takes no position regarding the validity or scope of any=09 > Intellectual Property Rights or other rights that might be claimed to = =20 > Intellectual Property Rights or other rights that might be claimed to=09 > pertain to the implementation or use of the technology described in p= ertain to=20 > the implementation or use of the technology described in=09 > this document or the extent to which any license under such rights th= is=20 > document or the extent to which any license under such rights=09 > might or might not be available; nor does it represent that it has mi= ght or=20 > might not be available; nor does it represent that it has=09 > made any independent effort to identify any such rights. Information = made any=20 > independent effort to identify any such rights. Information=09 > =09 > End of changes. 49 change blocks.=20 > /134 lines changed or deleted/ / / /155 lines changed or added/=09 >=20 > This html diff was produced by rfcdiff 1.33. The latest version is avai= lable=20 > from http://tools.ietf.org/tools/rfcdiff/=20 > >=20 >=20 > -----------------------------------------------------------------------= - >=20 >=20 --------------enigF2DC22C83010DAC3F6318EDE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFFugN5eVhrtTJkXCMRAloFAKC7zHvuHMwc0SqOLnFpjZ5SkkncxwCfdmYK 7b8lJO+8JBzam2FB6d2bOxg= =WUmH -----END PGP SIGNATURE----- --------------enigF2DC22C83010DAC3F6318EDE-- --===============0587897205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0587897205==-- From proto-team-bounces@ietf.org Fri Jan 26 16:19:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYU7-0006ce-E2; Fri, 26 Jan 2007 16:19:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYU5-0006cV-HK for proto-team@ietf.org; Fri, 26 Jan 2007 16:19:45 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAYU4-0000sp-0j for proto-team@ietf.org; Fri, 26 Jan 2007 16:19:45 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0QLJg46137630 for ; Fri, 26 Jan 2007 21:19:42 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0QLJgSJ921700 for ; Fri, 26 Jan 2007 22:19:42 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0QLJg30016434 for ; Fri, 26 Jan 2007 22:19:42 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0QLJf6Y016424; Fri, 26 Jan 2007 22:19:41 +0100 Received: from [9.145.131.38] (atv01356.de.ibm.com [9.145.131.38]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA303604; Fri, 26 Jan 2007 22:19:36 +0100 Message-ID: <45BA7068.2090104@zurich.ibm.com> Date: Fri, 26 Jan 2007 22:19:36 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Henrik Levkowetz References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BA0378.5090704@levkowetz.com> In-Reply-To: <45BA0378.5090704@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: David Meyer , Margaret Wasserman , proto-team@ietf.org, Allison Mankin Subject: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org I haven't had a chance to look yet (travel/meetings), sorry. Brian On 2007-01-26 14:34, Henrik Levkowetz wrote: > Hi Lars, > > Your updates work for me. > > Thanks, > > Henrik > > on 2007-01-24 17:06 Lars Eggert said the following: >> Hi, >> >> attached is an update to wgchair-doc-shepherding that addresses some >> of the IESG comments. >> >> In all cases where there were multiple proposed resolutions, I opted >> for the smallest possible change. I'm completely OK with people >> preferring to fix things a different way, but please send text in >> this case. >> >> On 2006-11-17, at 11:40, Brian E Carpenter wrote: >>> 1. Please make all the changes currently logged as an RFC Editor note >>> (attached below for convenience). >> done >>> 2. To deal with Sam's DISCUSS, which he cleared, I promised to request >>> text updates in the I-D tracker to >>> a) align terminology: always refer to "responsible AD" and never >>> to "shepherding AD" and always refer to "document shepherd" and >>> not to "PROTO shepherd" ("PROTO" being jargon). >> I couldn't find any of these terms in the document anymore - did Sam >> review an older version than -08? >>> b) add a "Personnel" section and rename "Protocol Quality" to >>> "Document Quality" in the blank writeup. >> was already done, too? >>> 4. Re Russ' DISCUSS. Russ wasn't on the call. >>> >>> Part 1: "The examples in Appendix A do not follow the outline >>> proposed in Section 3.1 paragraph (1.k)." Please fix. >> fixed >>> Part 2: "it seems like it would be >>> better to post the Document Shepherd Write-Up Template, and put a >>> pointer to it in this document. This document could include the >>> current template with an appropriate introduction, like: >>> >>> The initial Document Shepherd Write-Up Template is included here, >>> but changes are expected over time." >>> >>> Makes sense, and we can host the latest template in the IESG >>> pages, so you could add "The latest version is available >>> in the IESG section of the IETF web site." (I don't want to >>> assume the PROTO web site will exist for ever.) I will do >>> this when the draft is approved. >> added >>> 5. I'd like you to look at all the other AD comments in the tracker. >>> That should lead to a number of small changes. >>> >>> Sam is concerned that paragraph (b) at the very end of (3.h) >>> might be read to encourage appeals. Of course, that all depends on >>> the meaning of "last resort" so there may be nothing you can >>> change. >> Open issues: >> - Ted wanting to allow the possibility of shepherd teams >> - Ted wanting to have section 6 removed (or rewritten) >> - Sam and Cullen thinking that the appeals stuff in step 3.h is >> too much >> - Russ wanting to have security questions added to the writeup >> - whether or not this should become an ION >> >> Lars >> >> > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 30 10:27:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HButp-0000GY-3g; Tue, 30 Jan 2007 10:27:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HButn-0000GN-Rc for proto-team@ietf.org; Tue, 30 Jan 2007 10:27:55 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HButl-0007mu-Ar for proto-team@ietf.org; Tue, 30 Jan 2007 10:27:55 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0UFRo2d113676 for ; Tue, 30 Jan 2007 15:27:50 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0UFRnou1523932 for ; Tue, 30 Jan 2007 16:27:49 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0UFRnV7031986 for ; Tue, 30 Jan 2007 16:27:49 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0UFRmfn031967; Tue, 30 Jan 2007 16:27:49 +0100 Received: from [9.4.210.11] ([9.4.210.11]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA317220; Tue, 30 Jan 2007 16:27:47 +0100 Message-ID: <45BF63F2.2070303@zurich.ibm.com> Date: Tue, 30 Jan 2007 16:27:46 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Lars Eggert References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> In-Reply-To: <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: David Meyer , Margaret Wasserman , proto-team@ietf.org, Henrik Levkowetz , Allison Mankin Subject: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Thanks. I say ship it (but read below first). On 2007-01-24 17:06, Lars Eggert wrote: > Hi, > > attached is an update to wgchair-doc-shepherding that addresses some of > the IESG comments. > > In all cases where there were multiple proposed resolutions, I opted for > the smallest possible change. I'm completely OK with people preferring > to fix things a different way, but please send text in this case. > > On 2006-11-17, at 11:40, Brian E Carpenter wrote: >> 1. Please make all the changes currently logged as an RFC Editor note >> (attached below for convenience). > done >> 2. To deal with Sam's DISCUSS, which he cleared, I promised to request >> text updates in the I-D tracker to >> a) align terminology: always refer to "responsible AD" and never >> to "shepherding AD" and always refer to "document shepherd" and >> not to "PROTO shepherd" ("PROTO" being jargon). > I couldn't find any of these terms in the document anymore - did Sam > review an older version than -08? Yes, the document refers only to "Responsible Area Director", the issue was to remove the old term from the I-D tracker. And I guess Sam may well have reviewed -07. No change to the draft is required. >> b) add a "Personnel" section and rename "Protocol Quality" to >> "Document Quality" in the blank writeup. > was already done, too? >> 4. Re Russ' DISCUSS. Russ wasn't on the call. >> >> Part 1: "The examples in Appendix A do not follow the outline >> proposed in Section 3.1 paragraph (1.k)." Please fix. > fixed >> Part 2: "it seems like it would be >> better to post the Document Shepherd Write-Up Template, and put a >> pointer to it in this document. This document could include the >> current template with an appropriate introduction, like: >> >> The initial Document Shepherd Write-Up Template is included here, >> but changes are expected over time." >> >> Makes sense, and we can host the latest template in the IESG >> pages, so you could add "The latest version is available >> in the IESG section of the IETF web site." (I don't want to >> assume the PROTO web site will exist for ever.) I will do >> this when the draft is approved. > added OK, and remind me to create that page! >> 5. I'd like you to look at all the other AD comments in the tracker. >> That should lead to a number of small changes. >> >> Sam is concerned that paragraph (b) at the very end of (3.h) >> might be read to encourage appeals. Of course, that all depends on >> the meaning of "last resort" so there may be nothing you can change. > Open issues: > - Ted wanting to allow the possibility of shepherd teams > - Ted wanting to have section 6 removed (or rewritten) > - Sam and Cullen thinking that the appeals stuff in step 3.h is too much Those are comments. If the team doesn't want to implement them, I won't insist. > - Russ wanting to have security questions added to the writeup Does the team agree with Russ or want to push back? Why would we give security a special place here, since we already have mandatory security considerations? Can I add a question about IPv6 support? Can you add one about congestion control? Where does this end? > - whether or not this should become an ION I guess we should put that question when the document is otherwise clear of DISCUSSes. One trivial thing: The contact information for the Document Shepherd is also important for the Gen-ART Directorate [GEN-ART]... Gen-ART is not formally a Directorate; it's just a team. Brian _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 30 10:40:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBv5Z-0000J1-75; Tue, 30 Jan 2007 10:40:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBv5Y-0000Iv-12 for proto-team@ietf.org; Tue, 30 Jan 2007 10:40:04 -0500 Received: from corvus.nsf.gov ([198.181.231.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBv5S-00015f-PP for proto-team@ietf.org; Tue, 30 Jan 2007 10:40:04 -0500 Received: from nsf-fe-02.nsf.gov (HELO nsf-fe-02.ad.nsf.gov) ([128.150.4.152]) by corvus.nsf.gov with ESMTP; 30 Jan 2007 10:39:57 -0500 X-SBRS: None Received: from NSF-BE-03.ad.nsf.gov ([128.150.130.227]) by nsf-fe-02.ad.nsf.gov with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 10:40:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [proto-team] Re: One more spin ofdraft-ietf-proto-wgchair-doc-shepherding Date: Tue, 30 Jan 2007 10:40:08 -0500 Message-ID: <3E387C1C64088E499E7BF0E86B0E1BF72E2DC5@NSF-BE-03.ad.nsf.gov> In-Reply-To: <45BF63F2.2070303@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [proto-team] Re: One more spin ofdraft-ietf-proto-wgchair-doc-shepherding Thread-Index: AcdEg0fSWgzrAlroRpuwHJvV+TpppAAAL9Tg References: <455D83A7.4080708@zurich.ibm.com><5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> From: "Mankin, Allison J" To: "Brian E Carpenter" , "Lars Eggert" X-OriginalArrivalTime: 30 Jan 2007 15:40:12.0935 (UTC) FILETIME=[EE658170:01C74484] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: David Meyer , Margaret Wasserman , Allison Mankin , Henrik Levkowetz , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org > - Russ wanting to have security questions added to the writeup Does the team agree with Russ or want to push back? Why would we give security a special place here, since we already have mandatory security considerations? Can I add a question about IPv6 support? Can you add one about congestion control? Where does this end? *** I recall from (I think) joining a call or a chat that Russ said he did not actually want his questions to be added to the writeup, but rather he wanted a good pointer to mandatory considerations in other places. > - whether or not this should become an ION I guess we should put that question when the document is otherwise clear of DISCUSSes. *** I weigh in for this becoming an RFC. It's all about things we do for the process of shepherding documents through their states towards RFC. Let it be in the RFCs. Let it be findable in the tracker. _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 30 10:56:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvLI-00080P-Q5; Tue, 30 Jan 2007 10:56:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvLH-0007z2-WA for proto-team@ietf.org; Tue, 30 Jan 2007 10:56:20 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvLG-0004UX-IA for proto-team@ietf.org; Tue, 30 Jan 2007 10:56:19 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0UFrnoM019731; Tue, 30 Jan 2007 17:53:58 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 17:55:55 +0200 Received: from [172.21.38.109] ([172.21.38.109]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 30 Jan 2007 17:55:42 +0200 In-Reply-To: <45BF63F2.2070303@zurich.ibm.com> References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Date: Tue, 30 Jan 2007 17:55:53 +0200 To: ext Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jan 2007 15:55:42.0369 (UTC) FILETIME=[1861E110:01C74487] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: David Meyer , Margaret Wasserman , proto-team@ietf.org, Henrik Levkowetz , Allison Mankin Subject: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1760296593==" Errors-To: proto-team-bounces@ietf.org --===============1760296593== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-72-739309160; protocol="application/pkcs7-signature" --Apple-Mail-72-739309160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-30, at 17:27, ext Brian E Carpenter wrote: > On 2007-01-24 17:06, Lars Eggert wrote: >> Open issues: >> - Ted wanting to allow the possibility of shepherd teams I think we explicitly wanted one clearly identified person, to avoid having to chase down the shepherd-of-the-week. >> - Ted wanting to have section 6 removed (or rewritten) Don't care much. >> - Sam and Cullen thinking that the appeals stuff in step 3.h is >> too much I think Sam has a point. When appeals come into the picture, the AD needs to take over. What do others think? >> - Russ wanting to have security questions added to the writeup > > Does the team agree with Russ or want to push back? Why would we give > security a special place here, since we already have mandatory > security considerations? Can I add a question about IPv6 support? > Can you add one about congestion control? Where does this end? Right. I wouldn't want this, and I think Russ is relaying a comment from the audience. >> - whether or not this should become an ION > > I guess we should put that question when the document is > otherwise clear of DISCUSSes. I'm somewhat in favor of just letting it become an RFC. It's late in the game to switch. > One trivial thing: > > The contact information for the Document Shepherd is also important > for the Gen-ART Directorate [GEN-ART]... > > Gen-ART is not formally a Directorate; it's just a team. Fixed. Lars --Apple-Mail-72-739309160 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzAxNTU1NTRaMCMGCSqGSIb3DQEJBDEWBBSIiHF7/NCQR7xD zQQTrqC/miO2JzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAie1uej2WJMV3cNcTEi61oTxhOu2L5ck70SfOLfpyw+yJMKMc+LsE LOjjwUYQ+sdgQbldiJJ+1psS6SfEfkOJ/3gVj/NChOa0wqsZNFrGZ5FFYhePt6LGfFHETbgfWU3d LVCLAKzHZ4jy8isfqCF/jDGts0idm8wfytqzp/Q7ZxZ2msAImOyFFoZuShsB6Q43V9amkvVAzNFs e57r4E6Oyp6eRy8dkabYdUouyLoeEtuOf01gCSzJZmbcQyoxillgxd2v5l3C8kaKlcxjpVFZ93Vc z+qvxWkCdPoCE7zD5dRbIuBc41TZm6b2PEmzUwKH8UXW3TcEG3ZDzvnWFguvwQAAAAAAAA== --Apple-Mail-72-739309160-- --===============1760296593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1760296593==-- From proto-team-bounces@ietf.org Tue Jan 30 11:19:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvi2-0003iZ-3n; Tue, 30 Jan 2007 11:19:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvi0-0003iT-I4 for proto-team@ietf.org; Tue, 30 Jan 2007 11:19:48 -0500 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvhx-0000ej-4h for proto-team@ietf.org; Tue, 30 Jan 2007 11:19:48 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate7.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0UGJiH8160272 for ; Tue, 30 Jan 2007 16:19:44 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0UGJiZ91114238 for ; Tue, 30 Jan 2007 16:19:44 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0UGJhlc030528 for ; Tue, 30 Jan 2007 16:19:43 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0UGJhT2030508; Tue, 30 Jan 2007 16:19:43 GMT Received: from [9.4.210.11] ([9.4.210.11]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA302552; Tue, 30 Jan 2007 17:19:42 +0100 Message-ID: <45BF701E.1040901@zurich.ibm.com> Date: Tue, 30 Jan 2007 17:19:42 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Lars Eggert References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: David Meyer , Margaret Wasserman , proto-team@ietf.org, Henrik Levkowetz , Allison Mankin Subject: [proto-team] Appeal point [Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding] X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org > >>> - Sam and Cullen thinking that the appeals stuff in step 3.h is too much > > I think Sam has a point. When appeals come into the picture, the AD needs to take over. What do others think? In fact the 2026 appeal process is clear that the first step is the WG Chair, the second step is the AD, and third step is the IESG as a whole. We'd better be certain that this draft doesn't change that. Maybe a simple mention that the appeal process exists is sufficient. We certainly don't want to encourage appeals as a normal thing. Bfrian _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Tue Jan 30 19:09:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC32g-0004WH-Fz; Tue, 30 Jan 2007 19:09:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC32f-0004WC-Cr for proto-team@ietf.org; Tue, 30 Jan 2007 19:09:37 -0500 Received: from av9-2-sn2.hy.skanova.net ([81.228.8.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC32d-00083F-V9 for proto-team@ietf.org; Tue, 30 Jan 2007 19:09:37 -0500 Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id CE0DB3C30E; Wed, 31 Jan 2007 00:59:49 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 7EE623C308; Wed, 31 Jan 2007 00:59:49 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 5830A37E77; Wed, 31 Jan 2007 00:59:49 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HC2tB-0008Ij-4L; Wed, 31 Jan 2007 00:59:49 +0100 Message-ID: <45BFDBF4.2010109@levkowetz.com> Date: Wed, 31 Jan 2007 00:59:48 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lars.eggert@nokia.com, brc@zurich.ibm.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ext Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Inline... Henrik on 2007-01-30 16:55 Lars Eggert said the following: > On 2007-1-30, at 17:27, ext Brian E Carpenter wrote: >> On 2007-01-24 17:06, Lars Eggert wrote: >>> Open issues: >>> - Ted wanting to allow the possibility of shepherd teams > > I think we explicitly wanted one clearly identified person, to avoid > having to chase down the shepherd-of-the-week. Yes. >>> - Ted wanting to have section 6 removed (or rewritten) > > Don't care much. > >>> - Sam and Cullen thinking that the appeals stuff in step 3.h is >>> too much > > I think Sam has a point. When appeals come into the picture, the AD > needs to take over. What do others think? I agree. >>> - Russ wanting to have security questions added to the writeup >> >> Does the team agree with Russ or want to push back? Why would we give >> security a special place here, since we already have mandatory >> security considerations? Can I add a question about IPv6 support? >> Can you add one about congestion control? Where does this end? > > Right. I wouldn't want this, and I think Russ is relaying a comment > from the audience. Again, I agree. >>> - whether or not this should become an ION >> >> I guess we should put that question when the document is >> otherwise clear of DISCUSSes. > > I'm somewhat in favor of just letting it become an RFC. It's late in > the game to switch. RFC. >> One trivial thing: >> >> The contact information for the Document Shepherd is also important >> for the Gen-ART Directorate [GEN-ART]... >> >> Gen-ART is not formally a Directorate; it's just a team. > > Fixed. > > Lars _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jan 31 05:47:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCD0O-0004gY-Bu; Wed, 31 Jan 2007 05:47:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCD0M-0004fq-S6 for proto-team@ietf.org; Wed, 31 Jan 2007 05:47:54 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCD05-0000Fo-2J for proto-team@ietf.org; Wed, 31 Jan 2007 05:47:54 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0VAiTFK003153; Wed, 31 Jan 2007 12:44:42 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 12:47:05 +0200 Received: from [192.168.1.33] ([10.162.252.246]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 12:47:02 +0200 In-Reply-To: <45BFDBF4.2010109@levkowetz.com> References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> <45BFDBF4.2010109@levkowetz.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> From: Lars Eggert Subject: Re: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding Date: Wed, 31 Jan 2007 12:47:13 +0200 To: ext Henrik Levkowetz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 10:47:02.0260 (UTC) FILETIME=[23F34340:01C74525] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070131124443-0C29EBB0-60C1BC3F/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 9d76a562296b054aeb0e071235371771 Cc: ext Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0630963990==" Errors-To: proto-team-bounces@ietf.org --===============0630963990== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-91-807188912; protocol="application/pkcs7-signature" --Apple-Mail-91-807188912 Content-Type: multipart/mixed; boundary=Apple-Mail-90-807188784 --Apple-Mail-90-807188784 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I've tried to reflect your comments in the attached version. Good to go? Lars --Apple-Mail-90-807188784 Content-Transfer-Encoding: 7bit Content-Type: text/html; x-unix-mode=0644; name=draft-ietf-proto-wgchair-doc-shepherding-from--08.diff.html Content-Disposition: attachment; filename=draft-ietf-proto-wgchair-doc-shepherding-from--08.diff.html Diff: draft-ietf-proto-wgchair-doc-shepherding-08.txt - draft-ietf-proto-wgchair-doc-shepherding.txt
 draft-ietf-proto-wgchair-doc-shepherding-08.txt   draft-ietf-proto-wgchair-doc-shepherding.txt 
PROTO Team H. Levkowetz PROTO Team H. Levkowetz
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational D. Meyer Intended status: Informational D. Meyer
Expires: April 25, 2007 Cisco/University of Oregon Expires: August 4, 2007 Cisco/University of Oregon
L. Eggert L. Eggert
NEC Nokia
A. Mankin A. Mankin
October 22, 2006 January 31, 2007
Document Shepherding from Working Group Last Call to Publication Document Shepherding from Working Group Last Call to Publication
draft-ietf-proto-wgchair-doc-shepherding-08 draft-ietf-proto-wgchair-doc-shepherding-09
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 38 skipping to change at page 1, line 38
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 April 25, 2007. This Internet-Draft will expire on August 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes methodologies that have been designed to This document describes methodologies that have been designed to
improve and facilitate IETF document flow processing. It specifies a improve and facilitate IETF document flow processing. It specifies a
set of procedures under which a working group chair or secretary set of procedures under which a working group chair or secretary
serves as the primary Document Shepherd for a document that has been serves as the primary Document Shepherd for a document that has been
submitted to the IESG for publication. Before this, the Area submitted to the IESG for publication. Before this, the Area
Director responsible for the working group has traditionally filled Director responsible for the working group has traditionally filled
the shepherding role. the shepherding role.
A Document Shepherd's responsibilities include: A Document Shepherd's responsibilities include:
o Providing the Document Shepherd Write-Up accompanying a document o Providing the Document Shepherd Write-Up accompanying a document
that is forwarded to the IESG when publication is requested. that is forwarded to the IESG when publication is requested.
o During AD Evaluation by the Responsible Area Director, managing o During AD Evaluation by the Responsible Area Director, managing
the discussion between the editors, the working group, and the the discussion between the editors, the working group, and the
Responsible Area Director. Responsible Area Director.
o During an IETF Last Call, if performed for the shepherded
document, following up on community feedback and review comments.
o During IESG evaluation, following up on all IESG feedback o During IESG evaluation, following up on all IESG feedback
("DISCUSS" and "COMMENT" items) related to the shepherded ("DISCUSS" and "COMMENT" items) related to the shepherded
document. document.
o Following up on IANA and RFC Editor requests in the post-approval o Following up on IANA and RFC Editor requests in the post-approval
shepherding of the document. shepherding of the document.
In summary, a Document Shepherd continues to care for a shepherded In summary, a Document Shepherd continues to care for a shepherded
document during its post-WG lifetime just as he or she has cared for document during its post-WG lifetime just as he or she has cared for
it while responsible for the document in the working group. it while responsible for the document in the working group.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6
3.2. Document Shepherding during AD Evaluation . . . . . . . . 10 3.2. Document Shepherding during AD Evaluation . . . . . . . . 10
3.3. Document Shepherding during IESG Evaluation . . . . . . . 11 3.3. Document Shepherding during IESG Evaluation . . . . . . . 11
4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14 4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14
5. Document Shepherding after IESG Approval . . . . . . . . . . . 15 5. Document Shepherding after IESG Approval . . . . . . . . . . . 15
6. When Not to Use the Document Shepherding Process . . . . . . . 16 6. When Not to Use the Document Shepherding Process . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. Informative References . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Example Document Announcement Write-Ups . . . . . . . 18 Appendix A. Example Document Announcement Write-Ups . . . . . . . 18
A.1. Example Document Announcement Write-Up for A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18 draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 19
A.2. Example Document Announcement Write-Up for A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19 draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19
Appendix B. Working Documents . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
Early in 2004, the IESG undertook several experiments aimed at Early in 2004, the IESG undertook several experiments aimed at
evaluating whether any of the proposed changes to the IETF document evaluating whether any of the proposed changes to the IETF document
flow process would yield qualitative improvements in document flow process would yield qualitative improvements in document
throughput and quality. One such experiment, referred to as the throughput and quality. One such experiment, referred to as the
"PROTO process" or "PROTO" (because it was created by the "PROcess "PROTO process" or "PROTO" (because it was created by the "PROcess
and TOols" or PROTO [PROTO] team, is a set of methodologies designed and TOols" or PROTO [PROTO] team), is a set of methodologies designed
to involve working group chairs or secretaries more directly in their to involve working group chairs or secretaries more directly in their
documents' approval life cycle. In particular, the PROTO team documents' approval life cycle. In particular, the PROTO team
focused on improvements to the part of a document's life cycle that focused on improvements to the part of a document's life cycle that
occurs after the working group and document editor have forwarded it occurs after the working group and document editor have forwarded it
to the IESG for publication. to the IESG for publication.
By the end of 2004, the IESG had evaluated the utility of the PROTO By the end of 2004, the IESG had evaluated the utility of the PROTO
methodologies based on data obtained through several pilot projects methodologies based on data obtained through several pilot projects
that had run throughout the year, and subsequently decided to adopt that had run throughout the year, and subsequently decided to adopt
the PROTO process for all documents and working groups. This the PROTO process for all documents and working groups. This
skipping to change at page 5, line 31 skipping to change at page 5, line 31
o Providing the Document Shepherd Write-Up accompanying a document o Providing the Document Shepherd Write-Up accompanying a document
that is forwarded to the IESG when publication is requested, as that is forwarded to the IESG when publication is requested, as
described in Section 3.1. described in Section 3.1.
o During AD Evaluation of the document by the Responsible Area o During AD Evaluation of the document by the Responsible Area
Director, managing the discussion between the editors, the working Director, managing the discussion between the editors, the working
group and the Responsible Area Director, as described in group and the Responsible Area Director, as described in
Section 3.2. Section 3.2.
o During an IETF Last Call, if performed for the shepherded
document, following up on community feedback and review comments.
o During IESG evaluation, following up on all IESG feedback o During IESG evaluation, following up on all IESG feedback
("DISCUSS" and "COMMENT" items) related to the shepherded ("DISCUSS" and "COMMENT" items) related to the shepherded
document, as described in Section 3.3. document, as described in Section 3.3.
o Following up on IANA and RFC Editor requests as described in o Following up on IANA and RFC Editor requests as described in
Section 4 and Section 5. Section 4 and Section 5.
The shepherd must keep the document moving forward, communicating The shepherd must keep the document moving forward, communicating
about it with parties who review and comment it. The shepherd must about it with parties who review and comment it. The shepherd must
obtain the working group's consensus for any substantive proposed obtain the working group's consensus for any substantive proposed
skipping to change at page 6, line 35 skipping to change at page 6, line 39
Section 6 discusses other instances in which the document shepherding Section 6 discusses other instances in which the document shepherding
process does not apply. process does not apply.
3.1. Document Shepherd Write-Up 3.1. Document Shepherd Write-Up
When a working group decides that a document is ready for submission When a working group decides that a document is ready for submission
to the IESG for publication, it is the task of the Document Shepherd to the IESG for publication, it is the task of the Document Shepherd
to complete a "Document Shepherd Write-Up" for the document. to complete a "Document Shepherd Write-Up" for the document.
There are two parts to this task. First, the Document Shepherd There are two parts to this task. First, the Document Shepherd
answers questions (1.a) to (1.i) below to give the Responsible Area answers questions (1.a) to (1.j) below to give the Responsible Area
Director insight into the working group process that applied to this Director insight into the working group process that applied to this
document. Note that while these questions may appear redundant in document. Note that while these questions may appear redundant in
some cases, they are written to elicit information that the some cases, they are written to elicit information that the
Responsible Area Director must be aware of (to this end, pointers to Responsible Area Director must be aware of (to this end, pointers to
relevant entries in the WG archive are helpful). The goal here is to relevant entries in the WG archive are helpful). The goal here is to
inform the Responsible Area Director about any issues that may have inform the Responsible Area Director about any issues that may have
come up in IETF meetings, on the mailing list, or in private come up in IETF meetings, on the mailing list, or in private
communication that they should be aware of prior to IESG evaluation communication that they should be aware of prior to IESG evaluation
of the shepherded document. Any significant issues mentioned in the of the shepherded document. Any significant issues mentioned in the
questionnaire will probably lead to a follow-up discussion with the questionnaire will probably lead to a follow-up discussion with the
Responsible Area Director. Responsible Area Director.
The second part of the task is to prepare the "Document Announcement The second part of the task is to prepare the "Document Announcement
Write-Up" that is input to both the ballot for the IESG telechat and Write-Up" that is input to both the ballot for the IESG telechat and
to the eventual IETF-wide announcement message. Item number (1.i) to the eventual IETF-wide announcement message. Item number (1.k)
describes the elements of the Document Announcement Write-Up. describes the elements of the Document Announcement Write-Up.
A final sentence of the Document Announcement Write-Up, simply placed
as a line at the end of the "Document Quality" section, can state the
names of the Document Shepherd and the Responsible Area Director,
because the announcement will not otherwise acknowledge them. The
Document Shepherd SHOULD add this information and the Responsible
Area Director SHOULD add it if it is not already there.
Some examples of Document Announcement Write-Ups are included in Some examples of Document Announcement Write-Ups are included in
Appendix A, and there are many more examples with subject lines such Appendix A, and there are many more examples with subject lines such
as "Protocol Action" and "Document Action" in the IETF-announce as "Protocol Action" and "Document Action" in the IETF-announce
mailing list archive. mailing list archive.
The initial template for the Document Shepherd Write-Up is included
below, but changes are expected over time. The latest version of
this template is available from the IESG section of the IETF web
site.
(1.a) Who is the Document Shepherd for this document? Has the (1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication? version is ready for forwarding to the IESG for publication?
(1.b) Has the document had adequate review both from key WG members (1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that any concerns about the depth or breadth of the reviews that
have been performed? have been performed?
skipping to change at page 7, line 39 skipping to change at page 7, line 40
e.g., security, operational complexity, someone familiar with e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML? AAA, internationalization or XML?
(1.d) Does the Document Shepherd have any specific concerns or (1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those that it still wishes to advance the document, detail those
concerns here. concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
(1.e) How solid is the WG consensus behind this document? Does it (1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and others being silent, or does the WG as a whole understand and
agree with it? agree with it?
(1.f) Has anyone threatened an appeal or otherwise indicated extreme (1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is should be in a separate email because this questionnaire is
entered into the ID Tracker.) entered into the ID Tracker.)
(1.g) Has the Document Shepherd personally verified that the (1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews? Doctor, media type and URI type reviews?
(1.h) Has the document split its references into normative and (1.h) Has the document split its references into normative and
informative? Are there normative references to documents that informative? Are there normative references to documents that
skipping to change at page 8, line 28 skipping to change at page 8, line 34
so, list these downward references to support the Area so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967]. Director in the Last Call procedure for them [RFC3967].
(1.i) Has the Document Shepherd verified that the document IANA (1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body consideration section exists and is consistent with the body
of the document? If the document specifies protocol of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a procedure for future registrations? Does it suggest a
reasonable name for the new registry? See reasonable name for the new registry? See [RFC2434]. If the
[I-D.narten-iana-considerations-rfc2434bis]. If the document document describes an Expert Review process has Shepherd
describes an Expert Review process has Shepherd conferred with conferred with the Responsible Area Director so that the IESG
the Responsible Area Director so that the IESG can appoint the can appoint the needed Expert during the IESG Evaluation?
needed Expert during the IESG Evaluation?
(1.j) Has the Document Shepherd verified that sections of the (1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker? an automated checker?
(1.k) The IESG approval announcement includes a Document (1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval "Action" announcements for approved documents. The approval
announcement contains the following sections: announcement contains the following sections:
Technical Summary Technical Summary
Relevant content can frequently be found in the abstract Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract an indication that there are deficiencies in the abstract
or introduction. or introduction.
Working Group Summary Working Group Summary
skipping to change at page 9, line 29 skipping to change at page 9, line 35
what was its course (briefly)? In the case of a Media Type what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted? review, on what date was the request posted?
Personnel Personnel
Who is the Document Shepherd for this document? Who is the Who is the Document Shepherd for this document? Who is the
Responsible Area Director? Responsible Area Director?
The Document Shepherd MUST send the Document Shepherd Write-Up to the The Document Shepherd MUST send the Document Shepherd Write-Up to the
Responsible Area Director and iesg-secretary@ietf.org together with Responsible Area Director and iesg-secretary@ietf.org together with
the request to publish the document. The Document Shepherd SHOULD the request to publish the document. The Document Shepherd SHOULD
also send the entire Document Shepherd Write-up to the working group also send the entire Document Shepherd Write-Up to the working group
mailing list. If the Document Shepherd feels that information which mailing list. If the Document Shepherd feels that information which
may prove to be sensitive, lead to possible appeals or is personal may prove to be sensitive, lead to possible appeals or is personal
information needs to be written up, it SHOULD be sent in direct email information needs to be written up, it SHOULD be sent in direct email
to the Responsible Area Director, because the Document Shepherd to the Responsible Area Director, because the Document Shepherd
Write-Up is published openly in the tracker. Question 1(f) of the Write-Up is published openly in the ID Tracker. Question (1.f) of
Write-Up covers any material of this nature and specifies this more the Write-Up covers any material of this nature and specifies this
confidential handling. more confidential handling.
The Document Shepherd Write-Up is entered into the ID Tracker The Document Shepherd Write-Up is entered into the ID Tracker
[IDTRACKER] as a "Comment." The name and email address of the [IDTRACKER] as a "Comment." The name and email address of the
Document Shepherd are entered into the ID Tracker, currently as a Document Shepherd are entered into the ID Tracker, currently as a
"Brief Note" (this may change in the future). The email address of "Brief Note" (this may change in the future). The email address of
the Document Shepherd MUST also be added to the "State or Version the Document Shepherd MUST also be added to the "State or Version
Change Notice To" field (typically the email addresses of all working Change Notice To" field (typically the email addresses of all working
group chairs, authors and the Secretary will be added). group chairs, authors and the secretary will be added).
Entering the name and email of the Document Shepherd into the ID Entering the name and email of the Document Shepherd into the ID
Tracker is REQUIRED to ensure that he or she will be copied on the Tracker is REQUIRED to ensure that he or she will be copied on the
email exchange between the editors, chairs, the IESG, the IESG email exchange between the editors, chairs, the IESG, the IESG
secretariat, IANA and the RFC Editor during the review and approval secretariat, IANA and the RFC Editor during the review and approval
process. There are still manual steps required for these parties to process. There are still manual steps required for these parties to
ensure they include the Document Shepherd, but it is hoped that in ensure they include the Document Shepherd, but it is hoped that in
future, automated tools will ensure that Document Shepherds (and future, automated tools will ensure that Document Shepherds (and
others) receive necessary communications. others) receive necessary communications.
The contact information for the Document Shepherd is also important The contact information for the Document Shepherd is also important
for the Gen-ART [GEN-ART] Directorate and other directorates, so they for the Gen-ART team [GEN-ART], area directorates and other review
can know to whom to address reviews, in addition to the Responsible teams, so they can know to whom to address reviews, in addition to
Area Director. the Responsible Area Director.
3.2. Document Shepherding during AD Evaluation 3.2. Document Shepherding during AD Evaluation
The steps for document shepherding during AD Evaluation are as The steps for document shepherding during AD Evaluation are as
follows: follows:
(2.a) The Responsible Area Director reads, evaluates and comments on (2.a) The Responsible Area Director reads, evaluates and comments on
the document, as is the case when not using the document the document, as is the case when not using the document
shepherding process. If the Responsible Area Director shepherding process. If the Responsible Area Director
determines that the document is ready for IESG Evaluation, he determines that the document is ready for IESG Evaluation, he
skipping to change at page 10, line 45 skipping to change at page 11, line 6
(2.d) The Document Shepherd sends the AD Evaluation comments to the (2.d) The Document Shepherd sends the AD Evaluation comments to the
editors and to the working group mailing list, in order to editors and to the working group mailing list, in order to
have a permanent record of the comments. It is RECOMMENDED have a permanent record of the comments. It is RECOMMENDED
that the Document Shepherd solicit from the editors an that the Document Shepherd solicit from the editors an
estimate on when the required changes will be complete and a estimate on when the required changes will be complete and a
revised document can be expected. Working groups that use revised document can be expected. Working groups that use
issue tracking SHOULD also record the issues (and eventually issue tracking SHOULD also record the issues (and eventually
their resolution) in their issue tracker. their resolution) in their issue tracker.
(2.e) During the production of a revised document that addresses the (2.e) During the production of a revised document that addresses the
AD Evaluation comments, it is strongly RECOMMENDED that the AD Evaluation comments, it is RECOMMENDED that the editors
editors keep a list showing how each comment was addressed and keep a list showing how each comment was addressed and what
what the revised text is. It is strongly RECOMMENDED that the revised text is. It is RECOMMENDED that this list be
this list be forwarded to the Responsible Area Director forwarded to the Responsible Area Director together with the
together with the revised document. revised document.
(2.f) In the event that the editors or working group disagrees with (2.f) In the event that the editors or working group disagrees with
a comment raised by the Responsible Area Director or has a comment raised by the Responsible Area Director or has
previously considered and dismissed the issue, the Document previously considered and dismissed the issue, the Document
Shepherd MUST resolve the issue with the Responsible Area Shepherd MUST resolve the issue with the Responsible Area
Director before a revised document can be submitted. Director before a revised document can be submitted.
(2.g) The Document Shepherd iterates with the editors (and working (2.g) The Document Shepherd iterates with the editors (and working
group, if required) until all outstanding issues have been group, if required) until all outstanding issues have been
resolved and a revised document is available. At this point, resolved and a revised document is available. At this point,
the Document Shepherd notifies the Responsible Area Director the Document Shepherd notifies the Responsible Area Director
and provides him or her with the revised document, the summary and provides him or her with the revised document, the summary
of issues and the resulting text changes. of issues and the resulting text changes.
(2.h) The Responsible Area Director verifies that the issues he or (2.h) The Responsible Area Director verifies that the issues he or
she found during AD Evaluation are resolved in the revised she found during AD Evaluation are resolved in the revised
version of the document by starting the process described in version of the document by starting the process described in
this section at step (2.a). this section at step (2.a).
(2.i) If the document underwent an IETF Last Call and the AD
concludes that significant issues were raised during the Last
Call, then steps (2.b) through (2.h) need to be applied
addressing the Last Call issues. This requires the
Responsible Area Director to present to the Document Shepherd
those Last Call Issues raised only to the IESG.
3.3. Document Shepherding during IESG Evaluation 3.3. Document Shepherding during IESG Evaluation
During IESG Evaluation of a document, ADs can bring forward two kinds During IESG Evaluation of a document, ADs can bring forward two kinds
of remarks about a document: DISCUSS item and COMMENT items. A of remarks about a document: DISCUSS item and COMMENT items. A
DISCUSS blocks a document's approval process until it has been DISCUSS blocks a document's approval process until it has been
resolved; a COMMENT does not. This section details the steps that a resolved; a COMMENT does not. This section details the steps that a
Document Shepherd takes to resolve any DISCUSS and COMMENT items Document Shepherd takes to resolve any DISCUSS and COMMENT items
brought forward against a shepherded document during IESG Evaluation. brought forward against a shepherded document during IESG Evaluation.
Note that DISCUSS and COMMENT items are occasionally written in a Note that DISCUSS and COMMENT items are occasionally written in a
skipping to change at page 13, line 19 skipping to change at page 13, line 34
| | Further AD/Document Shepherd | | Further AD/Document Shepherd
| | discussion required | | discussion required
+--------------------------+ +--------------------------+
(3.e) The Document Shepherd then communicates the DISCUSS and (3.e) The Document Shepherd then communicates the DISCUSS and
COMMENT items to the document editors and the working group, COMMENT items to the document editors and the working group,
alerting them of any changes to the document that have alerting them of any changes to the document that have
accumulated during IESG processing, such as "Notes to the RFC accumulated during IESG processing, such as "Notes to the RFC
Editor." If any changes will be substantive, the Document Editor." If any changes will be substantive, the Document
Shepherd, in consultation with the Responsible Area Director, Shepherd, in consultation with the Responsible Area Director,
as during other stages, MUST seek working group consensus. as during other stages, MUST confirm working group consensus
or sometimes even IETF consensus.
(3.f) After the editors resolve the DISCUSS and COMMENT items, the (3.f) After the editors resolve the DISCUSS and COMMENT items, the
Document Shepherd reviews the resulting new version of the Document Shepherd reviews the resulting new version of the
document, which will be a revised document, a set of "Notes to document, which will be a revised document, a set of "Notes to
the RFC Editor", or both, using his or her technical expertise the RFC Editor", or both, using his or her technical expertise
to ensure that all raised DISCUSS and COMMENT issues have been to ensure that all raised DISCUSS and COMMENT issues have been
resolved. resolved.
Note that the Document Shepherd MAY also suggest resolutions Note that the Document Shepherd MAY also suggest resolutions
to DISCUSS and COMMENT items, enter them into an issue to DISCUSS and COMMENT items, enter them into an issue
skipping to change at page 14, line 8 skipping to change at page 14, line 26
(COMMENT items need not be checked and cleared, because they (COMMENT items need not be checked and cleared, because they
do not block the document, but ADs are encouraged to do so.) do not block the document, but ADs are encouraged to do so.)
If a DISCUSS was not resolved to the satisfaction of the AD If a DISCUSS was not resolved to the satisfaction of the AD
that has raised it or the Responsible Area Director, two that has raised it or the Responsible Area Director, two
possibilities exist: possibilities exist:
(a) The process returns to step (3.d), or (a) The process returns to step (3.d), or
(b) If no progress can be made on the resolution of the (b) If no progress can be made on the resolution of the
DISCUSS with the AD who has raised it, despite DISCUSS with the AD who has raised it, despite repeated
clarification and additional involvement of the clarifications and discussions, the Responsible Area
Responsible Area Director, the Document Shepherd and Director should take over continued shepherding of the
working group might as a very last resort consider an document. Such a situation may be indicative of larger
appeal in accordance with the procedures described in issues that the PROTO process was not designed to handle.
[RFC2026] and referred to in [RFC2418]. The Document
Shepherd SHOULD review the IESG's Discuss Criteria
guidelines [I-D.iesg-discuss-criteria] and discuss with
the Responsible Area Director whether there might be
consideration against the unresolved DISCUSS by the rest
of the IESG due to these guidelines.
Once the process above has cleared all DISCUSS items, document Once the process above has cleared all DISCUSS items, document
shepherding continues with step (3.i). shepherding continues with step (3.i).
(3.i) The Responsible Area Director moves the document to the (3.i) The Responsible Area Director moves the document to the
"Approved - Announcement to be sent" state in the ID Tracker. "Approved - Announcement to be sent" state in the ID Tracker.
If he or she deems the changes to the revised document If he or she deems the changes to the revised document
significant, there may be a new WG last call, or possibly a significant, there may be a new WG last call, or possibly a
new IETF last call. The document goes through a new full IESG new IETF last call. The document goes through a new full IESG
Evaluation process if there is a new IETF last call. Evaluation process if there is a new IETF last call.
4. Shepherding the Document's IANA Actions 4. Shepherding the Document's IANA Actions
IETF working group documents often include considerations requiring IETF working group documents often include considerations requiring
actions by the IANA, such as creating a new registry or adding actions by the IANA, such as creating a new registry or adding
information to an existing registry, perhaps after consulting an information to an existing registry, perhaps after consulting an
IESG-appointed Expert. Sometimes the actions required are by the IESG-appointed Expert. Sometimes, the IESG requires actions, such as
IESG, such as appointment of a new Expert. IANA-related processing appointment of a new Expert. IANA-related processing may also
may also include a specified type of Expert review, such as review of include a specified type of Expert review, such as review of proposed
proposed MIME media types on the designated ietf-types mailing list. MIME media types on the designated ietf-types mailing list.
The IANA reviews IETF documents and requests responses at any or all The IANA reviews IETF documents and requests responses at any or all
of the following times: in response to IETF Last Call, during the of the following times: in response to IETF Last Call, during the
IESG Evaluation review of the document, and at the time when the IANA IESG Evaluation review of the document, and at the time when the IANA
performs actions in its web-based registry for the document, usually performs actions in its web-based registry for the document, usually
but not always after IESG approval of the document. More details of but not always after IESG approval of the document. More details of
the IANA process and IETF interaction are found in the IANA process and IETF interaction are found in [RFC2434].
[I-D.narten-iana-considerations-rfc2434bis].
Whenever an IANA request comes, in whatever period, the requester At the time of this publication, RFC2434 is under revision
from IANA MUST ensure that the Document Shepherd and the Responsible [I-D.narten-iana-considerations-rfc2434bis] and the updates are and
Area Director both receive the request. The Document Shepherd is will be of value to the Document Shepherd. Note that Document
responsible for responding as rapidly as possible. He or she should Shepherd MUST determine (by individual review and consultation with
discuss requests that introduce any possible concerns with the others) what is the most recent and the most applicable IANA
Working Group. The Document Shepherd and the Responsible Area information and guidance for his or her document, be it the overall
Director may decide in consultation that an IANA request leads to a guidance, or external documents in his or her area, or in other
change that needs additional review or approval. areas. An example of an external document is [RFC4020].
In general, the Working Group Shepherd ensures that the IANA process Whenever an IANA request comes, during whatever phase of the
shepherding process, the requester from IANA MUST ensure that the
Document Shepherd and the Responsible Area Director both receive the
request. The Document Shepherd is responsible for responding as
rapidly as possible. He or she should discuss requests that
introduce any possible concerns with the working group. The Document
Shepherd and the Responsible Area Director may decide in consultation
that an IANA request leads to a change that needs additional review
or approval.
In general, the Document Shepherd ensures that the IANA process
completes, checks that the registry is correct and that the IANA completes, checks that the registry is correct and that the IANA
Matrix (www.iana.org/numbers.html) is complete and consistent, and Matrix (http://www.iana.org/numbers.html) is complete and consistent,
troubleshoots when all is not well. At the end of IANA processing, and troubleshoots when all is not well. At the end of IANA
the Document Shepherd should be sure that the RFC Editor has processing, the Document Shepherd should be sure that the RFC Editor
acknowledged IANA conclusion, that the handoff has been made. has acknowledged IANA conclusion, i.e., that the handoff has been
made.
In summary, the task of shepherding the IANA actions is overlooked In summary, the task of shepherding the IANA actions is often
but is as important to coordinate and manage as all the other overlooked, but is as important to coordinate and manage as all the
document reviews the Document Shepherd has managed. As with those, other document reviews the Document Shepherd has managed. As with
the Document Shepherd contributes greatly to quality and timeliness those, the Document Shepherd contributes greatly to quality and
of the document by effective and responsive shepherding of the IANA timeliness of the document by effective and responsive shepherding of
requests. the IANA requests.
5. Document Shepherding after IESG Approval 5. Document Shepherding after IESG Approval
After the IESG Evaluation and resolution described in Section 3.3, After the IESG evaluation and resolution described in Section 3.3,
the IESG approves the document, and the Responsible Area Director the IESG approves the document, and the Responsible Area Director
uses the tracker to ask for any final changes to the Document uses the ID Tracker to ask for any final changes to the Document
Announcement Write-Up and to ask for it to be issued. The Document Announcement Write-Up and for it to be issued. The Document Shepherd
Shepherd may have some edits for the Responsible Area Director, such may have some edits for the Responsible Area Director, such as minor
as minor Notes to the RFC Editor, and this is the time to consult and "Notes to the RFC Editor", and this is the time to consult and
provide them. provide them.
The announcement goes to the general community and to the RFC Editor, The IESG approval announcement goes to the general community and to
and now the Document Shepherd (identified in the Announcemen the RFC Editor, and now the Document Shepherd (identified in the
Write-Up) continues to shepherd the document through its technical Announcement Write-Up) continues to shepherd the document through its
publication. The RFC Editor currently makes a number of types of technical publication. The RFC Editor currently makes a number of
requests to the authors, Document Shepherd and Responsible Area types of requests to the authors, Document Shepherd and Responsible
Director. The Document Shepherd SHOULD lead in responding to the RFC Area Director. The Document Shepherd SHOULD lead in responding to
editor and shepherding the document through its technical the RFC Editor and shepherd the document during the post-approval
publication, through the post-approval period. The RFC Editor period to its publication.
request types include: editorial queries about dangling, missing,
informative and normative citations (good shepherding should try to The RFC Editor request types include: editorial queries about
pre-catch these, but they happen); requests for unedited source, e.g. dangling, missing, informative and normative citations (good
xml; occasional technical comments; and copy-edits for review and shepherding should try to catch these earlier, but they happen);
close scrutiny by the authors (AUTH48). On the latter, the Document requests for the document source (e.g., XML or nroff); occasional
Shepherd SHOULD lead in checking that copy-edits have in no case technical comments; and copy-edits for review and close scrutiny by
affected a consensus wording of the working group which prepared the the authors (AUTH48). For the latter, the Document Shepherd SHOULD
document, and in bringing speed to this checking by multiple co- lead in checking that copy-edits have in no case affected a consensus
authors. The Document Shepherd also consults with the Responsible wording of the working group which prepared the document, and SHOULD
Area Director in reviewing proposed post-approval changes to the bring speed to this checking by multiple coauthors. The Document
document by any authors. These may require Area Director approval, Shepherd also consults with the Responsible Area Director on
and they often need to be presented to the working group for consent reviewing proposed post-approval changes to the document by any
if not a full consensus procedure. As in other periods of document author. These may require Area Director approval, and they often
review, the Document Shepherd provides attentiveness and timeliness need to be presented to the working group for consent if not a full
by serving as the informed representative of the document and helping consensus procedure.
its advancement and its integrity.
As in other phases of document shepherding, the Document Shepherd
provides attentiveness and timeliness by serving as the informed
representative of the document and helping its advancement and its
integrity.
6. When Not to Use the Document Shepherding Process 6. When Not to Use the Document Shepherding Process
As mentioned in Section 3, the Document Shepherd SHOULD NOT be an As mentioned in Section 3, the Document Shepherd SHOULD NOT be an
editor of the shepherded document. If this cannot be avoided by editor of the shepherded document. If this cannot be avoided by
making another working group chair or secretary the Document making another working group chair or secretary the Document
Shepherd, the document shepherding process SHOULD NOT be used. There Shepherd, the document shepherding process SHOULD NOT be used. There
are several other cases in which the document shepherding process are several other cases in which the document shepherding process
SHOULD NOT be used. These include: SHOULD NOT be used. These include:
skipping to change at page 16, line 37 skipping to change at page 17, line 19
3. Cases, where the working group itself is either very old, losing 3. Cases, where the working group itself is either very old, losing
energy, or winding down, i.e., cases, where it would not be energy, or winding down, i.e., cases, where it would not be
productive to initiate new processes or procedures. productive to initiate new processes or procedures.
Finally, note that other cases exist in which using the document Finally, note that other cases exist in which using the document
shepherding process may not be productive. The final determination shepherding process may not be productive. The final determination
as to whether to use the document shepherding process or not is left as to whether to use the document shepherding process or not is left
to the Responsible Area Director. If the document shepherding to the Responsible Area Director. If the document shepherding
process is not used, the Responsible Area Director acts as Document process is not used, the Responsible Area Director acts as Document
Shepherd, just as he or she did in the past. Shepherd, per the existing procedures of shepherding by Area
Directors.
7. Security Considerations 7. Security Considerations
This document specifies a change to IETF document-processing This document specifies a change to IETF document-processing
procedures. As such, it neither raises nor considers protocol- procedures. As such, it neither raises nor considers protocol-
specific security issues. specific security issues.
8. IANA Considerations 8. IANA Considerations
This document creates no new requirements on IANA namespaces or other This document creates no new requirements on IANA namespaces or other
IANA requirements. IANA requirements.
9. Acknowledgments 9. Acknowledgments
This document is the product of PROTO team, which includes the This document is the product of PROTO team, which includes the
authors as well as Bill Fenner, Barbara Fuller, and Margaret authors as well as Bill Fenner, Barbara Fuller, and Margaret
Wasserman. Aaron Falk worked actively in PROTO till the start of Wasserman. Aaron Falk worked actively in PROTO until the start of
2006 and worked on earlier versions of the document. 2006 and worked on earlier versions of the document.
The Document Shepherd Write-Up originated in an idea by John Klensin. The Document Shepherd Write-Up originated in an idea by John Klensin.
Thomas Narten and Margaret Wasserman implemented it for the entire Thomas Narten and Margaret Wasserman implemented it for the entire
Internet Area, and their template was the basis of the version used Internet Area, and their template was the basis of the version used
today. today.
Colin Perkins wrote the Document Announcement Write-Up for Colin Perkins wrote the original Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black
wrote the Document Announcement Write-Up for wrote the original Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both
original announcements have been modified to reflect changes to the
Document Announcement Write-Up template since they were written.
Frank Ellermann and Olafur Gudmundsson have suggested improvements to Frank Ellermann and Olafur Gudmundsson have suggested improvements to
the document during IETF Last Call. the document during IETF Last Call.
10. Informative References 10. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
3", BCP 9, RFC 2026, October 1996. Standards Track Code Points", BCP 100, RFC 4020,
February 2005.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Documents may Refer Normatively to Documents at a Lower
Level", BCP 97, RFC 3967, December 2004. Level", BCP 97, RFC 3967, December 2004.
[I-D.iesg-discuss-criteria]
Peterson, J., "DISCUSS Criteria in IESG Review",
draft-iesg-discuss-criteria-02 (work in progress),
February 2006.
[I-D.narten-iana-considerations-rfc2434bis] [I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-05 (work in draft-narten-iana-considerations-rfc2434bis-05 (work in
progress), September 2006. progress), September 2006.
[IDTRACKER] [IDTRACKER]
"The IETF Internet-Draft Tracker", Web "The IETF Internet-Draft Tracker", Web
Application: https://datatracker.ietf.org/, 2002. Application: https://datatracker.ietf.org/, 2002.
skipping to change at page 19, line 4 skipping to change at page 19, line 35
There is consensus in the WG to publish these documents. There is consensus in the WG to publish these documents.
Document Quality Document Quality
This RTP Payload format has been implemented during the This RTP Payload format has been implemented during the
development of the specification and successfully tested over an development of the specification and successfully tested over an
IP network between two remote sites, thus showing that the IP network between two remote sites, thus showing that the
technical solution is successfully working. It has been reviewed technical solution is successfully working. It has been reviewed
by the MIDI Manufacturers Association and their comments have been by the MIDI Manufacturers Association and their comments have been
addressed. Allison Mankin reviewed the document for the IESG, addressed.
Personnel
Magnus Westerlund and Colin Perkins jointly shepherded this
document. Allison Mankin reviewed the document for the IESG,
including a careful review with the editor of the media types, in including a careful review with the editor of the media types, in
parallel with ietf-types list review requested on 2006-01-08, parallel with ietf-types list review requested on 2006-01-08,
which raised no issues. which raised no issues.
Magnus Westerlund and Colin Perkins jointly shepherded these
documents.
A.2. Example Document Announcement Write-Up for A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel draft-ietf-imss-ip-over-fibre-channel
Technical Summary Technical Summary
This document specifies the encapsulation of IPv6, IPv4 and ARP This document specifies the encapsulation of IPv6, IPv4 and ARP
packets over Fibre Channel. This document also specifies the packets over Fibre Channel. This document also specifies the
methods for forming IPv6 link-local addresses and statelessly methods for forming IPv6 link-local addresses and statelessly
autoconfigured IPv6 addresses on Fibre Channel networks, and a autoconfigured IPv6 addresses on Fibre Channel networks, and a
mechanism to perform IPv4 address resolution over Fibre Channel mechanism to perform IPv4 address resolution over Fibre Channel
skipping to change at page 19, line 40 skipping to change at page 20, line 24
this document both in the WG and from T11. this document both in the WG and from T11.
Document Quality Document Quality
This document replaces and consolidates two separate RFCs on IPv4 This document replaces and consolidates two separate RFCs on IPv4
over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC
3831). Most of its technical content is unchanged from those 3831). Most of its technical content is unchanged from those
RFCs. The technical changes that have been made are primarily RFCs. The technical changes that have been made are primarily
based on implementation experience. based on implementation experience.
The protocol has been reviewed for the IESG by David L. Black (WG Personnel
chair).
Also Bert Wijnen has reviewed this document for the IESG.
In addition, Brian Haberman has done a review for the INT Area as The protocol has been reviewed for the IESG by David L. Black (WG
chair). Bert Wijnen has reviewed this document for the IESG. In
addition, Brian Haberman has done a review for the INT Area as
requested by WG-chair (David Black) via Margaret Wasserman. requested by WG-chair (David Black) via Margaret Wasserman.
Appendix B. Working Documents
(This section should be removed by the RFC editor before
publication.)
The current working documents for this document are available at this
web site:
http://tools.ietf.org/wg/proto/
draft-ietf-proto-wgchair-doc-shepherding/
Authors' Addresses Authors' Addresses
Henrik Levkowetz Henrik Levkowetz
Torsgatan 71 Torsgatan 71
Stockholm S-113 37 Stockholm S-113 37
Sweden Sweden
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
Email: henrik@levkowetz.com Email: henrik@levkowetz.com
skipping to change at page 20, line 33 skipping to change at page 21, line 4
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
Email: henrik@levkowetz.com Email: henrik@levkowetz.com
David Meyer David Meyer
1225 Kincaid St 1225 Kincaid St
Eugene, OR 97403 Eugene, OR 97403
USA USA
Phone: +1 541 346 1747 Phone: +1 541 346 1747
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
Lars Eggert Lars Eggert
NEC Network Laboratories Nokia Research Center
Kurfuerstenanlage 36 P.O. Box 407
Heidelberg 69115 Nokia Group 00045
Germany Finland
Phone: +49 50 48 24461
Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert
Phone: +49 6221 4342 143
Fax: +49 6221 4342 155
Email: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Allison Mankin Allison Mankin
Phone: +1-301-728-7199 Phone: +1-301-728-7199
Email: mankin@psg.com Email: mankin@psg.com
URI: http://www.psg.com/~mankin URI: http://www.psg.com/~mankin
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 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
 End of changes. 56 change blocks. 
158 lines changed or deleted 169 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/
--Apple-Mail-90-807188784 Content-Transfer-Encoding: 7bit Content-Type: text/xml; x-unix-mode=0644; name=draft-ietf-proto-wgchair-doc-shepherding.xml Content-Disposition: attachment; filename=draft-ietf-proto-wgchair-doc-shepherding.xml Document Shepherding from Working Group Last Call to Publication
Torsgatan 71 S-113 37 Stockholm Sweden +46 708 32 16 08 henrik@levkowetz.com
1225 Kincaid St Eugene OR 97403 USA +1 541 346 1747 dmm@1-4-5.net
Nokia Research Center
P.O. Box 407 00045 Nokia Group Finland +49 50 48 24461 lars.eggert@nokia.com http://research.nokia.com/people/lars_eggert
+1-301-728-7199 mankin@psg.com http://www.psg.com/~mankin
General Area PROTO Team Document Shepherding IETF Documents This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. A Document Shepherd's responsibilities include: Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested. During AD Evaluation by the Responsible Area Director, managing the discussion between the editors, the working group, and the Responsible Area Director. During an IETF Last Call, if performed for the shepherded document, following up on community feedback and review comments. During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document. Following up on IANA and RFC Editor requests in the post-approval shepherding of the document. In summary, a Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has cared for it while responsible for the document in the working group.
Early in 2004, the IESG undertook several experiments aimed at evaluating whether any of the proposed changes to the IETF document flow process would yield qualitative improvements in document throughput and quality. One such experiment, referred to as the "PROTO process" or "PROTO" (because it was created by the "PROcess and TOols" or PROTO team), is a set of methodologies designed to involve working group chairs or secretaries more directly in their documents' approval life cycle. In particular, the PROTO team focused on improvements to the part of a document's life cycle that occurs after the working group and document editor have forwarded it to the IESG for publication. By the end of 2004, the IESG had evaluated the utility of the PROTO methodologies based on data obtained through several pilot projects that had run throughout the year, and subsequently decided to adopt the PROTO process for all documents and working groups. This document describes this process. The methodologies developed and piloted by the PROTO team focus on the working group chair or secretary as the primary Document Shepherd. The primary objective of this document shepherding process is to improve document-processing throughput and document quality by enabling a partnership between the Responsible Area Director and the Document Shepherd. In particular, this partnership has the explicit goal of enfranchising the Document Shepherd while at the same time offloading a specific part of the follow-up work that has traditionally been responsibility of the Responsible Area Director. The Responsible Area Director has tens or many tens of documents to follow, while the Document Shepherd has only a few at a time. Flowing the responsibility to the working group level can ensure more attention and more timely response. Consequently, the document shepherding process includes follow-up work during all document-processing stages after Working Group Last Call, i.e., during AD Evaluation of a document, during IESG evaluation, and during post-approval processing by IANA and the RFC Editor. In these stages, it is the responsibility of the Document Shepherd to track and follow up on feedback received on a document from all relevant parties. The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd. The remainder of this document is organised as follows: outlines the overall document shepherding process. describes the Document Shepherd Write-Up that accompanies the publication request of a document. describes the AD Evaluation shepherding process and describes IESG DISCUSS shepherding. Finally, describes those cases in which the document shepherding process should not be used.
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 BCP 14, RFC 2119 .
The document shepherding process consists of the following tasks: Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested, as described in . During AD Evaluation of the document by the Responsible Area Director, managing the discussion between the editors, the working group and the Responsible Area Director, as described in . During an IETF Last Call, if performed for the shepherded document, following up on community feedback and review comments. During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document, as described in . Following up on IANA and RFC Editor requests as described in and . The shepherd must keep the document moving forward, communicating about it with parties who review and comment it. The shepherd must obtain the working group's consensus for any substantive proposed changes. The shepherd is the leader for the document and for the working group, and maintains a critical and technical perspective. In summary, the Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has done while responsible for the document in the working group. Before any document shepherding takes place, a single Document Shepherd MUST be identified for a document (he or she will be named in the Document Shepherd Write-Up) . Frequently, the chairs and the Responsible Area Director will decide that the working group will adopt the PROTO process for all their future documents. After that decision, the chairs, in consultation with the Responsible Area Director, decide on who should act as Document Shepherd for any given document. This is typically and by default one of the chairs of the working group. In consultation with the Responsible Area Director, the chairs MAY also decide to appoint the working group secretary as Document Shepherd for a given document. The Document Shepherd SHOULD NOT be an editor of the shepherded document. It is intended that the Document Shepherd role is filled by one person during the entire shepherding process. However, situations may occur when the Document Shepherd role may be reassigned to different persons during the lifetime of a document. It is up to the chairs and Responsible Area Director to identify situations when this may become necessary, and then consult to appoint a new Document Shepherd. It is important to note that the document shepherding process only applies to documents that are the product of a working group. It does not apply to documents that originate elsewhere. Additionally, discusses other instances in which the document shepherding process does not apply.
When a working group decides that a document is ready for submission to the IESG for publication, it is the task of the Document Shepherd to complete a "Document Shepherd Write-Up" for the document. There are two parts to this task. First, the Document Shepherd answers questions (1.a) to (1.j) below to give the Responsible Area Director insight into the working group process that applied to this document. Note that while these questions may appear redundant in some cases, they are written to elicit information that the Responsible Area Director must be aware of (to this end, pointers to relevant entries in the WG archive are helpful). The goal here is to inform the Responsible Area Director about any issues that may have come up in IETF meetings, on the mailing list, or in private communication that they should be aware of prior to IESG evaluation of the shepherded document. Any significant issues mentioned in the questionnaire will probably lead to a follow-up discussion with the Responsible Area Director. The second part of the task is to prepare the "Document Announcement Write-Up" that is input to both the ballot for the IESG telechat and to the eventual IETF-wide announcement message. Item number (1.k) describes the elements of the Document Announcement Write-Up. Some examples of Document Announcement Write-Ups are included in , and there are many more examples with subject lines such as "Protocol Action" and "Document Action" in the IETF-announce mailing list archive. The initial template for the Document Shepherd Write-Up is included below, but changes are expected over time. The latest version of this template is available from the IESG section of the IETF web site. Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in ? If so, list these downward references to support the Area Director in the Last Call procedure for them . Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See . If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Who is the Document Shepherd for this document? Who is the Responsible Area Director? The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, lead to possible appeals or is personal information needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. The Document Shepherd Write-Up is entered into the ID Tracker as a "Comment." The name and email address of the Document Shepherd are entered into the ID Tracker, currently as a "Brief Note" (this may change in the future). The email address of the Document Shepherd MUST also be added to the "State or Version Change Notice To" field (typically the email addresses of all working group chairs, authors and the secretary will be added). Entering the name and email of the Document Shepherd into the ID Tracker is REQUIRED to ensure that he or she will be copied on the email exchange between the editors, chairs, the IESG, the IESG secretariat, IANA and the RFC Editor during the review and approval process. There are still manual steps required for these parties to ensure they include the Document Shepherd, but it is hoped that in future, automated tools will ensure that Document Shepherds (and others) receive necessary communications. The contact information for the Document Shepherd is also important for the Gen-ART team, area directorates and other review teams, so they can know to whom to address reviews, in addition to the Responsible Area Director.
The steps for document shepherding during AD Evaluation are as follows: The Responsible Area Director reads, evaluates and comments on the document, as is the case when not using the document shepherding process. If the Responsible Area Director determines that the document is ready for IESG Evaluation, he or she indicates this to the Document Shepherd and the document shepherding process continues as described in . If the Responsible Area Director has identified issues with a document that must be addressed before IESG Evaluation can commence, he or she sends a full evaluation to the Document Shepherd and SHOULD also enter the review into the ID Tracker. The Document Shepherd reads the AD Evaluation comments, making very certain that all comments are understood, so that it is possible to follow up on them with the editors and working group. If there is some uncertainty as to what is requested, this SHOULD be resolved with the Responsible Area Director. The Document Shepherd sends the AD Evaluation comments to the editors and to the working group mailing list, in order to have a permanent record of the comments. It is RECOMMENDED that the Document Shepherd solicit from the editors an estimate on when the required changes will be complete and a revised document can be expected. Working groups that use issue tracking SHOULD also record the issues (and eventually their resolution) in their issue tracker. During the production of a revised document that addresses the AD Evaluation comments, it is RECOMMENDED that the editors keep a list showing how each comment was addressed and what the revised text is. It is RECOMMENDED that this list be forwarded to the Responsible Area Director together with the revised document. In the event that the editors or working group disagrees with a comment raised by the Responsible Area Director or has previously considered and dismissed the issue, the Document Shepherd MUST resolve the issue with the Responsible Area Director before a revised document can be submitted. The Document Shepherd iterates with the editors (and working group, if required) until all outstanding issues have been resolved and a revised document is available. At this point, the Document Shepherd notifies the Responsible Area Director and provides him or her with the revised document, the summary of issues and the resulting text changes. The Responsible Area Director verifies that the issues he or she found during AD Evaluation are resolved in the revised version of the document by starting the process described in this section at step (2.a). If the document underwent an IETF Last Call and the AD concludes that significant issues were raised during the Last Call, then steps (2.b) through (2.h) need to be applied addressing the Last Call issues. This requires the Responsible Area Director to present to the Document Shepherd those Last Call Issues raised only to the IESG.
During IESG Evaluation of a document, ADs can bring forward two kinds of remarks about a document: DISCUSS item and COMMENT items. A DISCUSS blocks a document's approval process until it has been resolved; a COMMENT does not. This section details the steps that a Document Shepherd takes to resolve any DISCUSS and COMMENT items brought forward against a shepherded document during IESG Evaluation. Note that DISCUSS and COMMENT items are occasionally written in a manner that makes their intent unclear. In these cases, the Document Shepherd SHOULD start a discussion with the ADs who brought the items up to clarify their intent, keeping the Responsible Area Director informed. If this fails to clarify the intent, the Responsible Area Director may need to work towards a clarification inside the IESG. Leading up to the IESG conference call, the Document Shepherd may see emails about the document from directorate reviewers on behalf of one or more ADs and also emailed copies of DISCUSS and COMMENT items entered into the ID Tracker. The Document Shepherd SHOULD immediately begin to work on resolving DISCUSS and COMMENT items with the ADs who have raised them, keeping the Responsible Area Director copied on the email exchange, so that he or she is able to support the the activity during the conference call. When dealing with directorate reviews, the Document Shepherd MUST involve the ADs to whom these directorates report to ensure that these ADs consider the review comments that need resolving. Immediately following the conference call, when the document changes state from the "IESG Evaluation" state to one of the states requiring Document Shepherd action, e.g., "IESG Evaluation: Revised ID Needed" or "IESG Evaluation: AD Followup", the Document Shepherd will receive email. A state of "AD Followup" typically signifies the Responsible Area Director's hope that a resolution may be possible through a continued discussion or (more usually) through a small set of changes as "Notes to the RFC Editor." Note that there may be very exceptional cases when DISCUSS items are registered after an IESG conference call. In these cases, the AD who has raised the DISCUSS MUST notify the Document Shepherd about it. (The notification facility in the ID Tracker is very convenient for this purpose and also for the cases where the DISCUSS and COMMENT items are updated after they are partially resolved.) The Document Shepherd then queries the ID Tracker to collect the remaining DISCUSS and COMMENT items raised against the document. The Document Shepherd analyses these items and initialises contact with the ADs who have placed them. The Responsible Area Director MUST be copied on all correspondence related to active DISCUSS or COMMENT items. This does not place the Responsible Area Director in the critical path towards a resolution, but should keep him or her informed about the state of the discussion.
| (3.c) | ------------> | (3.d) | +-------+ Comments +-------+ Comments +-------+ collected /|\ | understood | | | | Comments not fully understood | | (Further AD/Document Shepherd | | discussion required) +---+ ]]>
The Document Shepherd then coordinates the resolution of DISCUSS and COMMENT items and builds a consistent interpretation of the comments. This step is similar to much of the process described in .
| (3.d) | +-------+ Consistent +-------+ /|\ interpretation | | | Further AD/Document Shepherd | | discussion required +--------------------------+ ]]>
The Document Shepherd then communicates the DISCUSS and COMMENT items to the document editors and the working group, alerting them of any changes to the document that have accumulated during IESG processing, such as "Notes to the RFC Editor." If any changes will be substantive, the Document Shepherd, in consultation with the Responsible Area Director, as during other stages, MUST confirm working group consensus or sometimes even IETF consensus. After the editors resolve the DISCUSS and COMMENT items, the Document Shepherd reviews the resulting new version of the document, which will be a revised document, a set of "Notes to the RFC Editor", or both, using his or her technical expertise to ensure that all raised DISCUSS and COMMENT issues have been resolved. Note that the Document Shepherd MAY also suggest resolutions to DISCUSS and COMMENT items, enter them into an issue tracker, or perform other steps to streamline the resolution of the evaluation comments. It is very important to resolve the comments in a timely way, while the discussion is current for everyone involved. When the Document Shepherd is satisfied that the revised document addresses the evaluation comments, he or she communicates the resolution to the Responsible Area Director and the ADs that had raised the DISCUSS and COMMENT items. Each AD who had raised a DISCUSS checks whether the communicated resolution addresses his or her items. If it does, the AD will clear the DISCUSS. It it does not, the AD notifies the Document Shepherd and adds information to the ID Tracker explaining why the DISCUSS was not resolved. The Document Shepherd informs the working group accordingly. (COMMENT items need not be checked and cleared, because they do not block the document, but ADs are encouraged to do so.) If a DISCUSS was not resolved to the satisfaction of the AD that has raised it or the Responsible Area Director, two possibilities exist: The process returns to step (3.d), or If no progress can be made on the resolution of the DISCUSS with the AD who has raised it, despite repeated clarifications and discussions, the Responsible Area Director should take over continued shepherding of the document. Such a situation may be indicative of larger issues that the PROTO process was not designed to handle. Once the process above has cleared all DISCUSS items, document shepherding continues with step (3.i). The Responsible Area Director moves the document to the "Approved - Announcement to be sent" state in the ID Tracker. If he or she deems the changes to the revised document significant, there may be a new WG last call, or possibly a new IETF last call. The document goes through a new full IESG Evaluation process if there is a new IETF last call.
IETF working group documents often include considerations requiring actions by the IANA, such as creating a new registry or adding information to an existing registry, perhaps after consulting an IESG-appointed Expert. Sometimes, the IESG requires actions, such as appointment of a new Expert. IANA-related processing may also include a specified type of Expert review, such as review of proposed MIME media types on the designated ietf-types mailing list. The IANA reviews IETF documents and requests responses at any or all of the following times: in response to IETF Last Call, during the IESG Evaluation review of the document, and at the time when the IANA performs actions in its web-based registry for the document, usually but not always after IESG approval of the document. More details of the IANA process and IETF interaction are found in . At the time of this publication, RFC2434 is under revision and the updates are and will be of value to the Document Shepherd. Note that Document Shepherd MUST determine (by individual review and consultation with others) what is the most recent and the most applicable IANA information and guidance for his or her document, be it the overall guidance, or external documents in his or her area, or in other areas. An example of an external document is . Whenever an IANA request comes, during whatever phase of the shepherding process, the requester from IANA MUST ensure that the Document Shepherd and the Responsible Area Director both receive the request. The Document Shepherd is responsible for responding as rapidly as possible. He or she should discuss requests that introduce any possible concerns with the working group. The Document Shepherd and the Responsible Area Director may decide in consultation that an IANA request leads to a change that needs additional review or approval. In general, the Document Shepherd ensures that the IANA process completes, checks that the registry is correct and that the IANA Matrix (http://www.iana.org/numbers.html) is complete and consistent, and troubleshoots when all is not well. At the end of IANA processing, the Document Shepherd should be sure that the RFC Editor has acknowledged IANA conclusion, i.e., that the handoff has been made. In summary, the task of shepherding the IANA actions is often overlooked, but is as important to coordinate and manage as all the other document reviews the Document Shepherd has managed. As with those, the Document Shepherd contributes greatly to quality and timeliness of the document by effective and responsive shepherding of the IANA requests.
After the IESG evaluation and resolution described in , the IESG approves the document, and the Responsible Area Director uses the ID Tracker to ask for any final changes to the Document Announcement Write-Up and for it to be issued. The Document Shepherd may have some edits for the Responsible Area Director, such as minor "Notes to the RFC Editor", and this is the time to consult and provide them. The IESG approval announcement goes to the general community and to the RFC Editor, and now the Document Shepherd (identified in the Announcement Write-Up) continues to shepherd the document through its technical publication. The RFC Editor currently makes a number of types of requests to the authors, Document Shepherd and Responsible Area Director. The Document Shepherd SHOULD lead in responding to the RFC Editor and shepherd the document during the post-approval period to its publication. The RFC Editor request types include: editorial queries about dangling, missing, informative and normative citations (good shepherding should try to catch these earlier, but they happen); requests for the document source (e.g., XML or nroff); occasional technical comments; and copy-edits for review and close scrutiny by the authors (AUTH48). For the latter, the Document Shepherd SHOULD lead in checking that copy-edits have in no case affected a consensus wording of the working group which prepared the document, and SHOULD bring speed to this checking by multiple coauthors. The Document Shepherd also consults with the Responsible Area Director on reviewing proposed post-approval changes to the document by any author. These may require Area Director approval, and they often need to be presented to the working group for consent if not a full consensus procedure. As in other phases of document shepherding, the Document Shepherd provides attentiveness and timeliness by serving as the informed representative of the document and helping its advancement and its integrity.
As mentioned in , the Document Shepherd SHOULD NOT be an editor of the shepherded document. If this cannot be avoided by making another working group chair or secretary the Document Shepherd, the document shepherding process SHOULD NOT be used. There are several other cases in which the document shepherding process SHOULD NOT be used. These include: Cases, where the Document Shepherd is the primary author or editor of a large percentage of the documents produced by the working group. Cases, where the Responsible Area Director expects communication difficulties with the Document Shepherd (either due to experience, strong views stated by the Document Shepherd, or other issues). Cases, where the working group itself is either very old, losing energy, or winding down, i.e., cases, where it would not be productive to initiate new processes or procedures. Finally, note that other cases exist in which using the document shepherding process may not be productive. The final determination as to whether to use the document shepherding process or not is left to the Responsible Area Director. If the document shepherding process is not used, the Responsible Area Director acts as Document Shepherd, per the existing procedures of shepherding by Area Directors.
This document specifies a change to IETF document-processing procedures. As such, it neither raises nor considers protocol-specific security issues.
This document creates no new requirements on IANA namespaces or other IANA requirements.
This document is the product of PROTO team, which includes the authors as well as Bill Fenner, Barbara Fuller, and Margaret Wasserman. Aaron Falk worked actively in PROTO until the start of 2006 and worked on earlier versions of the document. The Document Shepherd Write-Up originated in an idea by John Klensin. Thomas Narten and Margaret Wasserman implemented it for the entire Internet Area, and their template was the basis of the version used today. Colin Perkins wrote the original Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format included in . David Black wrote the original Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel included in . Both original announcements have been modified to reflect changes to the Document Announcement Write-Up template since they were written. Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call.
The IETF Internet-Draft Tracker The IESG PROcess and TOols (PROTO) Team The General Area Review Team (GEN-ART)
This appendix includes two examples of Document Announcement Write-Ups. Many more examples with Subject lines such as "Protocol Action" and "Document Action" can be found in the IETF-announce mailing list archive.
These documents define the RTP Payload format for MIDI (Musical Instrument Digital Interface), and additional guidelines on implementation specifically concerning the timing of reception and transmission for best performance in different applications. MIDI is a real-time media, which however is brittle to losses and errors. Therefore the RTP payload format defines recovery journals as a way of avoiding persistent audible errors, and discusses congestion control handling for these journals. The RTP payload for MIDI encodes the broad range of MIDI commands. The format is suitable for interactive applications (such as network musical performance) and content-delivery (such as file streaming). There is consensus in the WG to publish these documents. This RTP Payload format has been implemented during the development of the specification and successfully tested over an IP network between two remote sites, thus showing that the technical solution is successfully working. It has been reviewed by the MIDI Manufacturers Association and their comments have been addressed. Magnus Westerlund and Colin Perkins jointly shepherded this document. Allison Mankin reviewed the document for the IESG, including a careful review with the editor of the media types, in parallel with ietf-types list review requested on 2006-01-08, which raised no issues.
This document specifies the encapsulation of IPv6, IPv4 and ARP packets over Fibre Channel. This document also specifies the methods for forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document (when published as RFC) obsoletes RFC2625 and RFC3831. This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG. There is solid support for this document both in the WG and from T11. This document replaces and consolidates two separate RFCs on IPv4 over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 3831). Most of its technical content is unchanged from those RFCs. The technical changes that have been made are primarily based on implementation experience. The protocol has been reviewed for the IESG by David L. Black (WG chair). Bert Wijnen has reviewed this document for the IESG. In addition, Brian Haberman has done a review for the INT Area as requested by WG-chair (David Black) via Margaret Wasserman.
--Apple-Mail-90-807188784 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name=draft-ietf-proto-wgchair-doc-shepherding.txt Content-Disposition: attachment; filename=draft-ietf-proto-wgchair-doc-shepherding.txt PROTO Team H. Levkowetz Internet-Draft Ericsson Intended status: Informational D. Meyer Expires: August 4, 2007 Cisco/University of Oregon L. Eggert Nokia A. Mankin January 31, 2007 Document Shepherding from Working Group Last Call to Publication draft-ietf-proto-wgchair-doc-shepherding-09 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 4, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been Levkowetz, et al. Expires August 4, 2007 [Page 1] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. A Document Shepherd's responsibilities include: o Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested. o During AD Evaluation by the Responsible Area Director, managing the discussion between the editors, the working group, and the Responsible Area Director. o During an IETF Last Call, if performed for the shepherded document, following up on community feedback and review comments. o During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document. o Following up on IANA and RFC Editor requests in the post-approval shepherding of the document. In summary, a Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has cared for it while responsible for the document in the working group. Levkowetz, et al. Expires August 4, 2007 [Page 2] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 6 3.2. Document Shepherding during AD Evaluation . . . . . . . . 10 3.3. Document Shepherding during IESG Evaluation . . . . . . . 11 4. Shepherding the Document's IANA Actions . . . . . . . . . . . 14 5. Document Shepherding after IESG Approval . . . . . . . . . . . 15 6. When Not to Use the Document Shepherding Process . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Example Document Announcement Write-Ups . . . . . . . 18 A.1. Example Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 19 A.2. Example Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Levkowetz, et al. Expires August 4, 2007 [Page 3] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 1. Introduction Early in 2004, the IESG undertook several experiments aimed at evaluating whether any of the proposed changes to the IETF document flow process would yield qualitative improvements in document throughput and quality. One such experiment, referred to as the "PROTO process" or "PROTO" (because it was created by the "PROcess and TOols" or PROTO [PROTO] team), is a set of methodologies designed to involve working group chairs or secretaries more directly in their documents' approval life cycle. In particular, the PROTO team focused on improvements to the part of a document's life cycle that occurs after the working group and document editor have forwarded it to the IESG for publication. By the end of 2004, the IESG had evaluated the utility of the PROTO methodologies based on data obtained through several pilot projects that had run throughout the year, and subsequently decided to adopt the PROTO process for all documents and working groups. This document describes this process. The methodologies developed and piloted by the PROTO team focus on the working group chair or secretary as the primary Document Shepherd. The primary objective of this document shepherding process is to improve document-processing throughput and document quality by enabling a partnership between the Responsible Area Director and the Document Shepherd. In particular, this partnership has the explicit goal of enfranchising the Document Shepherd while at the same time offloading a specific part of the follow-up work that has traditionally been responsibility of the Responsible Area Director. The Responsible Area Director has tens or many tens of documents to follow, while the Document Shepherd has only a few at a time. Flowing the responsibility to the working group level can ensure more attention and more timely response. Consequently, the document shepherding process includes follow-up work during all document-processing stages after Working Group Last Call, i.e., during AD Evaluation of a document, during IESG evaluation, and during post-approval processing by IANA and the RFC Editor. In these stages, it is the responsibility of the Document Shepherd to track and follow up on feedback received on a document from all relevant parties. The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd. The remainder of this document is organised as follows: Section 3 Levkowetz, et al. Expires August 4, 2007 [Page 4] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 outlines the overall document shepherding process. Section 3.1 describes the Document Shepherd Write-Up that accompanies the publication request of a document. Section 3.2 describes the AD Evaluation shepherding process and Section 3.3 describes IESG DISCUSS shepherding. Finally, Section 6 describes those cases in which the document shepherding process should not be used. 2. Terminology 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 BCP 14, RFC 2119 [RFC2119]. 3. Process Description The document shepherding process consists of the following tasks: o Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested, as described in Section 3.1. o During AD Evaluation of the document by the Responsible Area Director, managing the discussion between the editors, the working group and the Responsible Area Director, as described in Section 3.2. o During an IETF Last Call, if performed for the shepherded document, following up on community feedback and review comments. o During IESG evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document, as described in Section 3.3. o Following up on IANA and RFC Editor requests as described in Section 4 and Section 5. The shepherd must keep the document moving forward, communicating about it with parties who review and comment it. The shepherd must obtain the working group's consensus for any substantive proposed changes. The shepherd is the leader for the document and for the working group, and maintains a critical and technical perspective. In summary, the Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has done while responsible for the document in the working group. Levkowetz, et al. Expires August 4, 2007 [Page 5] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Before any document shepherding takes place, a single Document Shepherd MUST be identified for a document (he or she will be named in the Document Shepherd Write-Up) . Frequently, the chairs and the Responsible Area Director will decide that the working group will adopt the PROTO process for all their future documents. After that decision, the chairs, in consultation with the Responsible Area Director, decide on who should act as Document Shepherd for any given document. This is typically and by default one of the chairs of the working group. In consultation with the Responsible Area Director, the chairs MAY also decide to appoint the working group secretary as Document Shepherd for a given document. The Document Shepherd SHOULD NOT be an editor of the shepherded document. It is intended that the Document Shepherd role is filled by one person during the entire shepherding process. However, situations may occur when the Document Shepherd role may be reassigned to different persons during the lifetime of a document. It is up to the chairs and Responsible Area Director to identify situations when this may become necessary, and then consult to appoint a new Document Shepherd. It is important to note that the document shepherding process only applies to documents that are the product of a working group. It does not apply to documents that originate elsewhere. Additionally, Section 6 discusses other instances in which the document shepherding process does not apply. 3.1. Document Shepherd Write-Up When a working group decides that a document is ready for submission to the IESG for publication, it is the task of the Document Shepherd to complete a "Document Shepherd Write-Up" for the document. There are two parts to this task. First, the Document Shepherd answers questions (1.a) to (1.j) below to give the Responsible Area Director insight into the working group process that applied to this document. Note that while these questions may appear redundant in some cases, they are written to elicit information that the Responsible Area Director must be aware of (to this end, pointers to relevant entries in the WG archive are helpful). The goal here is to inform the Responsible Area Director about any issues that may have come up in IETF meetings, on the mailing list, or in private communication that they should be aware of prior to IESG evaluation of the shepherded document. Any significant issues mentioned in the questionnaire will probably lead to a follow-up discussion with the Responsible Area Director. The second part of the task is to prepare the "Document Announcement Levkowetz, et al. Expires August 4, 2007 [Page 6] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Write-Up" that is input to both the ballot for the IESG telechat and to the eventual IETF-wide announcement message. Item number (1.k) describes the elements of the Document Announcement Write-Up. Some examples of Document Announcement Write-Ups are included in Appendix A, and there are many more examples with subject lines such as "Protocol Action" and "Document Action" in the IETF-announce mailing list archive. The initial template for the Document Shepherd Write-Up is included below, but changes are expected over time. The latest version of this template is available from the IESG section of the IETF web site. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Levkowetz, et al. Expires August 4, 2007 [Page 7] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Levkowetz, et al. Expires August 4, 2007 [Page 8] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, lead to possible appeals or is personal information needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. The Document Shepherd Write-Up is entered into the ID Tracker [IDTRACKER] as a "Comment." The name and email address of the Document Shepherd are entered into the ID Tracker, currently as a "Brief Note" (this may change in the future). The email address of the Document Shepherd MUST also be added to the "State or Version Change Notice To" field (typically the email addresses of all working group chairs, authors and the secretary will be added). Entering the name and email of the Document Shepherd into the ID Levkowetz, et al. Expires August 4, 2007 [Page 9] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Tracker is REQUIRED to ensure that he or she will be copied on the email exchange between the editors, chairs, the IESG, the IESG secretariat, IANA and the RFC Editor during the review and approval process. There are still manual steps required for these parties to ensure they include the Document Shepherd, but it is hoped that in future, automated tools will ensure that Document Shepherds (and others) receive necessary communications. The contact information for the Document Shepherd is also important for the Gen-ART team [GEN-ART], area directorates and other review teams, so they can know to whom to address reviews, in addition to the Responsible Area Director. 3.2. Document Shepherding during AD Evaluation The steps for document shepherding during AD Evaluation are as follows: (2.a) The Responsible Area Director reads, evaluates and comments on the document, as is the case when not using the document shepherding process. If the Responsible Area Director determines that the document is ready for IESG Evaluation, he or she indicates this to the Document Shepherd and the document shepherding process continues as described in Section 3.3. (2.b) If the Responsible Area Director has identified issues with a document that must be addressed before IESG Evaluation can commence, he or she sends a full evaluation to the Document Shepherd and SHOULD also enter the review into the ID Tracker. (2.c) The Document Shepherd reads the AD Evaluation comments, making very certain that all comments are understood, so that it is possible to follow up on them with the editors and working group. If there is some uncertainty as to what is requested, this SHOULD be resolved with the Responsible Area Director. (2.d) The Document Shepherd sends the AD Evaluation comments to the editors and to the working group mailing list, in order to have a permanent record of the comments. It is RECOMMENDED that the Document Shepherd solicit from the editors an estimate on when the required changes will be complete and a revised document can be expected. Working groups that use issue tracking SHOULD also record the issues (and eventually their resolution) in their issue tracker. Levkowetz, et al. Expires August 4, 2007 [Page 10] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 (2.e) During the production of a revised document that addresses the AD Evaluation comments, it is RECOMMENDED that the editors keep a list showing how each comment was addressed and what the revised text is. It is RECOMMENDED that this list be forwarded to the Responsible Area Director together with the revised document. (2.f) In the event that the editors or working group disagrees with a comment raised by the Responsible Area Director or has previously considered and dismissed the issue, the Document Shepherd MUST resolve the issue with the Responsible Area Director before a revised document can be submitted. (2.g) The Document Shepherd iterates with the editors (and working group, if required) until all outstanding issues have been resolved and a revised document is available. At this point, the Document Shepherd notifies the Responsible Area Director and provides him or her with the revised document, the summary of issues and the resulting text changes. (2.h) The Responsible Area Director verifies that the issues he or she found during AD Evaluation are resolved in the revised version of the document by starting the process described in this section at step (2.a). (2.i) If the document underwent an IETF Last Call and the AD concludes that significant issues were raised during the Last Call, then steps (2.b) through (2.h) need to be applied addressing the Last Call issues. This requires the Responsible Area Director to present to the Document Shepherd those Last Call Issues raised only to the IESG. 3.3. Document Shepherding during IESG Evaluation During IESG Evaluation of a document, ADs can bring forward two kinds of remarks about a document: DISCUSS item and COMMENT items. A DISCUSS blocks a document's approval process until it has been resolved; a COMMENT does not. This section details the steps that a Document Shepherd takes to resolve any DISCUSS and COMMENT items brought forward against a shepherded document during IESG Evaluation. Note that DISCUSS and COMMENT items are occasionally written in a manner that makes their intent unclear. In these cases, the Document Shepherd SHOULD start a discussion with the ADs who brought the items up to clarify their intent, keeping the Responsible Area Director informed. If this fails to clarify the intent, the Responsible Area Director may need to work towards a clarification inside the IESG. Levkowetz, et al. Expires August 4, 2007 [Page 11] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 (3.a) Leading up to the IESG conference call, the Document Shepherd may see emails about the document from directorate reviewers on behalf of one or more ADs and also emailed copies of DISCUSS and COMMENT items entered into the ID Tracker. The Document Shepherd SHOULD immediately begin to work on resolving DISCUSS and COMMENT items with the ADs who have raised them, keeping the Responsible Area Director copied on the email exchange, so that he or she is able to support the the activity during the conference call. When dealing with directorate reviews, the Document Shepherd MUST involve the ADs to whom these directorates report to ensure that these ADs consider the review comments that need resolving. (3.b) Immediately following the conference call, when the document changes state from the "IESG Evaluation" state to one of the states requiring Document Shepherd action, e.g., "IESG Evaluation: Revised ID Needed" or "IESG Evaluation: AD Followup", the Document Shepherd will receive email. A state of "AD Followup" typically signifies the Responsible Area Director's hope that a resolution may be possible through a continued discussion or (more usually) through a small set of changes as "Notes to the RFC Editor." Note that there may be very exceptional cases when DISCUSS items are registered after an IESG conference call. In these cases, the AD who has raised the DISCUSS MUST notify the Document Shepherd about it. (The notification facility in the ID Tracker is very convenient for this purpose and also for the cases where the DISCUSS and COMMENT items are updated after they are partially resolved.) (3.c) The Document Shepherd then queries the ID Tracker to collect the remaining DISCUSS and COMMENT items raised against the document. The Document Shepherd analyses these items and initialises contact with the ADs who have placed them. The Responsible Area Director MUST be copied on all correspondence related to active DISCUSS or COMMENT items. This does not place the Responsible Area Director in the critical path towards a resolution, but should keep him or her informed about the state of the discussion. Levkowetz, et al. Expires August 4, 2007 [Page 12] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 +-------+ +-------+ +-------+ | (3.b) | -----------> | (3.c) | ------------> | (3.d) | +-------+ Comments +-------+ Comments +-------+ collected /|\ | understood | | | | Comments not fully understood | | (Further AD/Document Shepherd | | discussion required) +---+ (3.d) The Document Shepherd then coordinates the resolution of DISCUSS and COMMENT items and builds a consistent interpretation of the comments. This step is similar to much of the process described in Section 3.2. +-------+ +-------+ | (3.c) | ---------------> | (3.d) | +-------+ Consistent +-------+ /|\ interpretation | | | Further AD/Document Shepherd | | discussion required +--------------------------+ (3.e) The Document Shepherd then communicates the DISCUSS and COMMENT items to the document editors and the working group, alerting them of any changes to the document that have accumulated during IESG processing, such as "Notes to the RFC Editor." If any changes will be substantive, the Document Shepherd, in consultation with the Responsible Area Director, as during other stages, MUST confirm working group consensus or sometimes even IETF consensus. (3.f) After the editors resolve the DISCUSS and COMMENT items, the Document Shepherd reviews the resulting new version of the document, which will be a revised document, a set of "Notes to the RFC Editor", or both, using his or her technical expertise to ensure that all raised DISCUSS and COMMENT issues have been resolved. Note that the Document Shepherd MAY also suggest resolutions to DISCUSS and COMMENT items, enter them into an issue tracker, or perform other steps to streamline the resolution of the evaluation comments. It is very important to resolve the comments in a timely way, while the discussion is current for everyone involved. Levkowetz, et al. Expires August 4, 2007 [Page 13] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 (3.g) When the Document Shepherd is satisfied that the revised document addresses the evaluation comments, he or she communicates the resolution to the Responsible Area Director and the ADs that had raised the DISCUSS and COMMENT items. (3.h) Each AD who had raised a DISCUSS checks whether the communicated resolution addresses his or her items. If it does, the AD will clear the DISCUSS. It it does not, the AD notifies the Document Shepherd and adds information to the ID Tracker explaining why the DISCUSS was not resolved. The Document Shepherd informs the working group accordingly. (COMMENT items need not be checked and cleared, because they do not block the document, but ADs are encouraged to do so.) If a DISCUSS was not resolved to the satisfaction of the AD that has raised it or the Responsible Area Director, two possibilities exist: (a) The process returns to step (3.d), or (b) If no progress can be made on the resolution of the DISCUSS with the AD who has raised it, despite repeated clarifications and discussions, the Responsible Area Director should take over continued shepherding of the document. Such a situation may be indicative of larger issues that the PROTO process was not designed to handle. Once the process above has cleared all DISCUSS items, document shepherding continues with step (3.i). (3.i) The Responsible Area Director moves the document to the "Approved - Announcement to be sent" state in the ID Tracker. If he or she deems the changes to the revised document significant, there may be a new WG last call, or possibly a new IETF last call. The document goes through a new full IESG Evaluation process if there is a new IETF last call. 4. Shepherding the Document's IANA Actions IETF working group documents often include considerations requiring actions by the IANA, such as creating a new registry or adding information to an existing registry, perhaps after consulting an IESG-appointed Expert. Sometimes, the IESG requires actions, such as appointment of a new Expert. IANA-related processing may also include a specified type of Expert review, such as review of proposed MIME media types on the designated ietf-types mailing list. Levkowetz, et al. Expires August 4, 2007 [Page 14] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 The IANA reviews IETF documents and requests responses at any or all of the following times: in response to IETF Last Call, during the IESG Evaluation review of the document, and at the time when the IANA performs actions in its web-based registry for the document, usually but not always after IESG approval of the document. More details of the IANA process and IETF interaction are found in [RFC2434]. At the time of this publication, RFC2434 is under revision [I-D.narten-iana-considerations-rfc2434bis] and the updates are and will be of value to the Document Shepherd. Note that Document Shepherd MUST determine (by individual review and consultation with others) what is the most recent and the most applicable IANA information and guidance for his or her document, be it the overall guidance, or external documents in his or her area, or in other areas. An example of an external document is [RFC4020]. Whenever an IANA request comes, during whatever phase of the shepherding process, the requester from IANA MUST ensure that the Document Shepherd and the Responsible Area Director both receive the request. The Document Shepherd is responsible for responding as rapidly as possible. He or she should discuss requests that introduce any possible concerns with the working group. The Document Shepherd and the Responsible Area Director may decide in consultation that an IANA request leads to a change that needs additional review or approval. In general, the Document Shepherd ensures that the IANA process completes, checks that the registry is correct and that the IANA Matrix (http://www.iana.org/numbers.html) is complete and consistent, and troubleshoots when all is not well. At the end of IANA processing, the Document Shepherd should be sure that the RFC Editor has acknowledged IANA conclusion, i.e., that the handoff has been made. In summary, the task of shepherding the IANA actions is often overlooked, but is as important to coordinate and manage as all the other document reviews the Document Shepherd has managed. As with those, the Document Shepherd contributes greatly to quality and timeliness of the document by effective and responsive shepherding of the IANA requests. 5. Document Shepherding after IESG Approval After the IESG evaluation and resolution described in Section 3.3, the IESG approves the document, and the Responsible Area Director uses the ID Tracker to ask for any final changes to the Document Announcement Write-Up and for it to be issued. The Document Shepherd Levkowetz, et al. Expires August 4, 2007 [Page 15] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 may have some edits for the Responsible Area Director, such as minor "Notes to the RFC Editor", and this is the time to consult and provide them. The IESG approval announcement goes to the general community and to the RFC Editor, and now the Document Shepherd (identified in the Announcement Write-Up) continues to shepherd the document through its technical publication. The RFC Editor currently makes a number of types of requests to the authors, Document Shepherd and Responsible Area Director. The Document Shepherd SHOULD lead in responding to the RFC Editor and shepherd the document during the post-approval period to its publication. The RFC Editor request types include: editorial queries about dangling, missing, informative and normative citations (good shepherding should try to catch these earlier, but they happen); requests for the document source (e.g., XML or nroff); occasional technical comments; and copy-edits for review and close scrutiny by the authors (AUTH48). For the latter, the Document Shepherd SHOULD lead in checking that copy-edits have in no case affected a consensus wording of the working group which prepared the document, and SHOULD bring speed to this checking by multiple coauthors. The Document Shepherd also consults with the Responsible Area Director on reviewing proposed post-approval changes to the document by any author. These may require Area Director approval, and they often need to be presented to the working group for consent if not a full consensus procedure. As in other phases of document shepherding, the Document Shepherd provides attentiveness and timeliness by serving as the informed representative of the document and helping its advancement and its integrity. 6. When Not to Use the Document Shepherding Process As mentioned in Section 3, the Document Shepherd SHOULD NOT be an editor of the shepherded document. If this cannot be avoided by making another working group chair or secretary the Document Shepherd, the document shepherding process SHOULD NOT be used. There are several other cases in which the document shepherding process SHOULD NOT be used. These include: 1. Cases, where the Document Shepherd is the primary author or editor of a large percentage of the documents produced by the working group. Levkowetz, et al. Expires August 4, 2007 [Page 16] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 2. Cases, where the Responsible Area Director expects communication difficulties with the Document Shepherd (either due to experience, strong views stated by the Document Shepherd, or other issues). 3. Cases, where the working group itself is either very old, losing energy, or winding down, i.e., cases, where it would not be productive to initiate new processes or procedures. Finally, note that other cases exist in which using the document shepherding process may not be productive. The final determination as to whether to use the document shepherding process or not is left to the Responsible Area Director. If the document shepherding process is not used, the Responsible Area Director acts as Document Shepherd, per the existing procedures of shepherding by Area Directors. 7. Security Considerations This document specifies a change to IETF document-processing procedures. As such, it neither raises nor considers protocol- specific security issues. 8. IANA Considerations This document creates no new requirements on IANA namespaces or other IANA requirements. 9. Acknowledgments This document is the product of PROTO team, which includes the authors as well as Bill Fenner, Barbara Fuller, and Margaret Wasserman. Aaron Falk worked actively in PROTO until the start of 2006 and worked on earlier versions of the document. The Document Shepherd Write-Up originated in an idea by John Klensin. Thomas Narten and Margaret Wasserman implemented it for the entire Internet Area, and their template was the basis of the version used today. Colin Perkins wrote the original Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black wrote the original Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both original announcements have been modified to reflect changes to the Levkowetz, et al. Expires August 4, 2007 [Page 17] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Document Announcement Write-Up template since they were written. Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call. 10. Informative References [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-05 (work in progress), September 2006. [IDTRACKER] "The IETF Internet-Draft Tracker", Web Application: https://datatracker.ietf.org/, 2002. [PROTO] "The IESG PROcess and TOols (PROTO) Team", Web Page: http://psg.com/~mrw/PROTO-Team, 2004. [GEN-ART] "The General Area Review Team (GEN-ART)", Web Page: http://www.alvestrand.no/ietf/gen/review-guidelines.html, 2005. Appendix A. Example Document Announcement Write-Ups This appendix includes two examples of Document Announcement Write- Ups. Many more examples with Subject lines such as "Protocol Action" and "Document Action" can be found in the IETF-announce mailing list archive. Levkowetz, et al. Expires August 4, 2007 [Page 18] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 A.1. Example Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format Technical Summary These documents define the RTP Payload format for MIDI (Musical Instrument Digital Interface), and additional guidelines on implementation specifically concerning the timing of reception and transmission for best performance in different applications. MIDI is a real-time media, which however is brittle to losses and errors. Therefore the RTP payload format defines recovery journals as a way of avoiding persistent audible errors, and discusses congestion control handling for these journals. The RTP payload for MIDI encodes the broad range of MIDI commands. The format is suitable for interactive applications (such as network musical performance) and content-delivery (such as file streaming). Working Group Summary There is consensus in the WG to publish these documents. Document Quality This RTP Payload format has been implemented during the development of the specification and successfully tested over an IP network between two remote sites, thus showing that the technical solution is successfully working. It has been reviewed by the MIDI Manufacturers Association and their comments have been addressed. Personnel Magnus Westerlund and Colin Perkins jointly shepherded this document. Allison Mankin reviewed the document for the IESG, including a careful review with the editor of the media types, in parallel with ietf-types list review requested on 2006-01-08, which raised no issues. A.2. Example Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel Technical Summary This document specifies the encapsulation of IPv6, IPv4 and ARP packets over Fibre Channel. This document also specifies the methods for forming IPv6 link-local addresses and statelessly Levkowetz, et al. Expires August 4, 2007 [Page 19] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document (when published as RFC) obsoletes RFC2625 and RFC3831. Working Group Summary This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG. There is solid support for this document both in the WG and from T11. Document Quality This document replaces and consolidates two separate RFCs on IPv4 over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 3831). Most of its technical content is unchanged from those RFCs. The technical changes that have been made are primarily based on implementation experience. Personnel The protocol has been reviewed for the IESG by David L. Black (WG chair). Bert Wijnen has reviewed this document for the IESG. In addition, Brian Haberman has done a review for the INT Area as requested by WG-chair (David Black) via Margaret Wasserman. Authors' Addresses Henrik Levkowetz Torsgatan 71 Stockholm S-113 37 Sweden Phone: +46 708 32 16 08 Email: henrik@levkowetz.com David Meyer 1225 Kincaid St Eugene, OR 97403 USA Phone: +1 541 346 1747 Email: dmm@1-4-5.net Levkowetz, et al. Expires August 4, 2007 [Page 20] =0C Internet-Draft Document Shepherding to IESG Approval January 2007 Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +49 50 48 24461 Email: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert Allison Mankin Phone: +1-301-728-7199 Email: mankin@psg.com URI: http://www.psg.com/~mankin Levkowetz, et al. Expires August 4, 2007 [Page 21] =0C Internet-Draft Document Shepherding to IESG Approval January 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Levkowetz, et al. Expires August 4, 2007 [Page 22] =0C --Apple-Mail-90-807188784 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-90-807188784-- --Apple-Mail-91-807188912 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzExMDQ3MTNaMCMGCSqGSIb3DQEJBDEWBBS7QDPFGXN9AWjU DRx48ipjq+RduDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAMnITUOVPucOWrUMjMHfrSCc9Lhs8MKFicgzcBaiCTBVg0TxLiee9 Vj+S88P5VGHprBYjiSXHdgsdGwckXVN0vi6p91Ar6lsW+bAuyemDJndCEbHNwTFmjgQUVuJ8ynzV jworJK1vSkkpQRa8j4d3p9QzUQChuViLs0j/84jUKN+fgxokW7Dq6RPEVBeioyugWDVYhE9aZY0E Q4J9nWDxNKiv3fYqdo80hNMJV8Lh5BjyoBYoVSYlLWtTx9SyBGujpt/6tw/UzuYUOAp5GU0f+gld wLkTldrMaDMyJSJIOcE9FLIgbxWoK/LI2TY6xbs0IUYFA+SjV3GA+mWn1ZjehQAAAAAAAA== --Apple-Mail-91-807188912-- --===============0630963990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0630963990==-- From proto-team-bounces@ietf.org Wed Jan 31 06:57:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCE5q-0001d8-T7; Wed, 31 Jan 2007 06:57:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCE5p-0001cm-Op for proto-team@ietf.org; Wed, 31 Jan 2007 06:57:37 -0500 Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCE5m-0004M0-Rh for proto-team@ietf.org; Wed, 31 Jan 2007 06:57:37 -0500 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 2117137F4E; Wed, 31 Jan 2007 12:57:34 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 0955637F3A; Wed, 31 Jan 2007 12:57:34 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 9507437E43; Wed, 31 Jan 2007 12:57:33 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HCE5l-0007bt-AM; Wed, 31 Jan 2007 12:57:33 +0100 Message-ID: <45C0842B.5010207@levkowetz.com> Date: Wed, 31 Jan 2007 12:57:31 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> <45BFDBF4.2010109@levkowetz.com> <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> In-Reply-To: <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lars.eggert@nokia.com, brc@zurich.ibm.com, proto-team@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ext Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org on 2007-01-31 11:47 Lars Eggert said the following: > I've tried to reflect your comments in the attached version. Good to go? > > Lars Looks good to me. I happened to see an editorial, though: Section 4, 3rd para., 3rd line: s/Note that Document Shepherd/Note that the Document Shepherd/ Henrik _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jan 31 07:19:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEQs-0003rA-Og; Wed, 31 Jan 2007 07:19:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEQs-0003r4-AQ for proto-team@ietf.org; Wed, 31 Jan 2007 07:19:22 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCEQo-0002qh-Oo for proto-team@ietf.org; Wed, 31 Jan 2007 07:19:22 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0VCJHjx208994 for ; Wed, 31 Jan 2007 12:19:17 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VCJHha811090 for ; Wed, 31 Jan 2007 13:19:17 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VCJH6m021081 for ; Wed, 31 Jan 2007 13:19:17 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VCJG8K021067; Wed, 31 Jan 2007 13:19:16 +0100 Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA303814; Wed, 31 Jan 2007 13:19:16 +0100 Message-ID: <45C08943.1040807@zurich.ibm.com> Date: Wed, 31 Jan 2007 13:19:15 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> <45BFDBF4.2010109@levkowetz.com> <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> In-Reply-To: <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ext Henrik Levkowetz , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org Looks good to me On 2007-01-31 11:47, Lars Eggert wrote: > I've tried to reflect your comments in the attached version. Good to go? > > Lars > > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jan 31 07:23:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEUv-0005Da-6h; Wed, 31 Jan 2007 07:23:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEUu-0005DU-11 for proto-team@ietf.org; Wed, 31 Jan 2007 07:23:32 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCEUs-0004Zh-9Z for proto-team@ietf.org; Wed, 31 Jan 2007 07:23:32 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0VCKNJ9002555; Wed, 31 Jan 2007 14:20:37 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:23:13 +0200 Received: from [192.168.1.33] ([10.162.252.246]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 14:23:14 +0200 In-Reply-To: <45C0842B.5010207@levkowetz.com> References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> <45BFDBF4.2010109@levkowetz.com> <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> <45C0842B.5010207@levkowetz.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0808EC79-84D2-426C-B107-CE684E3595D9@nokia.com> From: Lars Eggert Subject: Re: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding Date: Wed, 31 Jan 2007 14:23:09 +0200 To: ext Henrik Levkowetz X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 12:23:14.0105 (UTC) FILETIME=[943CEA90:01C74532] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ext Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0990923201==" Errors-To: proto-team-bounces@ietf.org --===============0990923201== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-93-812945146; protocol="application/pkcs7-signature" --Apple-Mail-93-812945146 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2007-1-31, at 13:57, ext Henrik Levkowetz wrote: > s/Note that Document Shepherd/Note that the Document Shepherd/ Fixed in my copy. Lars --Apple-Mail-93-812945146 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzExMjIzMTBaMCMGCSqGSIb3DQEJBDEWBBS67hGGm0dVmyWq q0K0rQTQ3GmLTjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEA2Btx6ZLQtMF9A5FeF86JGs597+iXVApl/nemywLv8/cFj+dtDm3d d3dv/mowY3Urpm6V3l1RFz+/e1muvQ82Qt4rkLf75FiIVUnNFmi3E0OhgJCx3eo02I9ms+4yxxUC CDUakhBFcvoPLF32VacUQbUbQ6xp25Qm5CQhOl/09bQu+o8auZPf4/TfozzwUBI/NAhQMvw+7Paa Fry5vCVzI5LVunI1dwW2DJdf4r+avylhMGqimWV8XbWYNMJleNQMOic3jVXTKrmhkPYXOY1/v8R7 VZhVDywassj3OrTgvBh/B+Z7eDe6HlkDVNfxOuC+pzt8m2ebSfCD26vT9p2kGwAAAAAAAA== --Apple-Mail-93-812945146-- --===============0990923201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0990923201==-- From proto-team-bounces@ietf.org Wed Jan 31 07:57:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCF1V-0002fV-NQ; Wed, 31 Jan 2007 07:57:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCF1U-0002fQ-DW for proto-team@ietf.org; Wed, 31 Jan 2007 07:57:12 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCF1T-0004v1-1g for proto-team@ietf.org; Wed, 31 Jan 2007 07:57:12 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l0VCvALJ107890 for ; Wed, 31 Jan 2007 12:57:10 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VCv9aq1147104 for ; Wed, 31 Jan 2007 12:57:09 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VCv9Lr024134 for ; Wed, 31 Jan 2007 12:57:09 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0VCv9CN024118; Wed, 31 Jan 2007 12:57:09 GMT Received: from [9.4.210.81] ([9.4.210.81]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA268016; Wed, 31 Jan 2007 13:57:08 +0100 Message-ID: <45C09223.7080206@zurich.ibm.com> Date: Wed, 31 Jan 2007 13:57:07 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [proto-team] Re: One more spin of draft-ietf-proto-wgchair-doc-shepherding References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> <45BFDBF4.2010109@levkowetz.com> <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> <45C0842B.5010207@levkowetz.com> <0808EC79-84D2-426C-B107-CE684E3595D9@nokia.com> In-Reply-To: <0808EC79-84D2-426C-B107-CE684E3595D9@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ext Henrik Levkowetz , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org This is kind of an experiment. My previous reply on this thread (which basically said "OK") was bounced by Nokia's spam filter. I've already difficulties with equally innocent mail to other Nokia people. gmail may be your friend. Brian On 2007-01-31 13:23, Lars Eggert wrote: > On 2007-1-31, at 13:57, ext Henrik Levkowetz wrote: >> s/Note that Document Shepherd/Note that the Document Shepherd/ > > Fixed in my copy. > > Lars > > _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jan 31 09:14:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGEC-0006GU-LP; Wed, 31 Jan 2007 09:14:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGEB-0006GJ-6L for proto-team@ietf.org; Wed, 31 Jan 2007 09:14:23 -0500 Received: from corvus.nsf.gov ([198.181.231.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGE9-0002iP-Tr for proto-team@ietf.org; Wed, 31 Jan 2007 09:14:23 -0500 Received: from nsf-fe-02.nsf.gov (HELO nsf-fe-02.ad.nsf.gov) ([128.150.4.152]) by corvus.nsf.gov with ESMTP; 31 Jan 2007 09:14:19 -0500 X-SBRS: None Received: from NSF-BE-03.ad.nsf.gov ([128.150.130.227]) by nsf-fe-02.ad.nsf.gov with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 09:14:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [proto-team] Re: One more spinof draft-ietf-proto-wgchair-doc-shepherding Date: Wed, 31 Jan 2007 09:14:35 -0500 Message-ID: <3E387C1C64088E499E7BF0E86B0E1BF72E1B9E@NSF-BE-03.ad.nsf.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [proto-team] Re: One more spinof draft-ietf-proto-wgchair-doc-shepherding Thread-Index: AcdFJVLrTVTQ5t9ESSi+RhaQ1s2CawAGwJwc References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> <45BFDBF4.2010109@levkowetz.com> <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> From: "Mankin, Allison J" To: "Lars Eggert" , "ext Henrik Levkowetz" X-OriginalArrivalTime: 31 Jan 2007 14:14:36.0111 (UTC) FILETIME=[23061DF0:01C74542] X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ext Brian E Carpenter , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1720461792==" Errors-To: proto-team-bounces@ietf.org This is a multi-part message in MIME format. --===============1720461792== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74542.226549D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74542.226549D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lars, I missed some thread where this change happened, but why does this = sentence say: Sometimes the IESG requires actions, such as the appointment of a new = Expert. In replacement for: Sometimes the actions required are by the IESG, such as the appointment = of=20 a new Expert. I wrote the original sentence too quickly, but what I wanted to say with this was: Sometimes the Document Shepherd must keep track of certain IANA actions = to be completed by the IESG, such as ratifying the appointment of=20 a designated Expert called for in the IANA Considerations. =20 Otherwise, I think the document is very good - ready to go. And again, I would like it to be an RFC. Allison =20 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Wed 1/31/2007 05:47 To: ext Henrik Levkowetz Cc: ext Brian E Carpenter; proto-team@ietf.org Subject: Re: [proto-team] Re: One more spinof = draft-ietf-proto-wgchair-doc-shepherding =20 I've tried to reflect your comments in the attached version. Good to go? Lars ------_=_NextPart_001_01C74542.226549D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [proto-team] Re: One more spinof = draft-ietf-proto-wgchair-doc-shepherding

Lars,

I missed some thread where this change happened, but why does this = sentence say:

 Sometimes the IESG requires actions, such as the appointment of a = new Expert.

In replacement for:

 Sometimes the actions required are by the IESG, such as the = appointment of
 a new Expert.

I wrote the original sentence too quickly, but what I wanted to say
with this was:

 Sometimes the Document Shepherd must keep track of certain IANA = actions
 to be completed by the IESG, such as ratifying the appointment = of
 a designated Expert called for in the IANA = Considerations. 

Otherwise, I think the document is very good - ready to go.

And again, I would like it to be an RFC.

Allison



-----Original Message-----
From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Wed 1/31/2007 05:47
To: ext Henrik Levkowetz
Cc: ext Brian E Carpenter; proto-team@ietf.org
Subject: Re: [proto-team] Re: One more spinof   = draft-ietf-proto-wgchair-doc-shepherding

I've tried to reflect your comments in the attached version. Good to = go?

Lars

------_=_NextPart_001_01C74542.226549D0-- --===============1720461792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1720461792==-- From proto-team-bounces@ietf.org Wed Jan 31 09:27:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGQs-0005G5-UL; Wed, 31 Jan 2007 09:27:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGQr-0005Fz-Vd for proto-team@ietf.org; Wed, 31 Jan 2007 09:27:29 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGQq-0007fz-IQ for proto-team@ietf.org; Wed, 31 Jan 2007 09:27:29 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0VEOM1s007318; Wed, 31 Jan 2007 16:24:39 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 16:26:59 +0200 Received: from [192.168.1.33] ([10.162.252.246]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 31 Jan 2007 16:27:13 +0200 In-Reply-To: <3E387C1C64088E499E7BF0E86B0E1BF72E1B9E@NSF-BE-03.ad.nsf.gov> References: <455D83A7.4080708@zurich.ibm.com> <5A835EB1-7C38-4F19-A378-1290D06F59A7@nokia.com> <45BF63F2.2070303@zurich.ibm.com> <45BFDBF4.2010109@levkowetz.com> <4283C6D6-3EB9-47A2-A308-F88A50EE4E67@nokia.com> <3E387C1C64088E499E7BF0E86B0E1BF72E1B9E@NSF-BE-03.ad.nsf.gov> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [proto-team] Re: One more spinof draft-ietf-proto-wgchair-doc-shepherding Date: Wed, 31 Jan 2007 16:27:11 +0200 To: "ext Mankin, Allison J" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Jan 2007 14:27:13.0963 (UTC) FILETIME=[E6BD27B0:01C74543] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ext Brian E Carpenter , ext Henrik Levkowetz , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0362237351==" Errors-To: proto-team-bounces@ietf.org --===============0362237351== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-105-820386958; protocol="application/pkcs7-signature" --Apple-Mail-105-820386958 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-1-31, at 16:14, ext Mankin, Allison J wrote: > Sometimes the Document Shepherd must keep track of certain IANA > actions > to be completed by the IESG, such as ratifying the appointment of > a designated Expert called for in the IANA Considerations. Rolled in. Can I assume silence by the rest of the team means this is good to go? Lars --Apple-Mail-105-820386958 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAxMzExNDI3MTFaMCMGCSqGSIb3DQEJBDEWBBSvpIUMFxkphV7k cnPgNzbbqypMLTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAjgB9Ndlk9In5hgLL3khl2VTu9sk+XkK8r9SMZvzGthsXvakgeXcd mFqaHuzjkaLMXoDELDVI4InwbVVUV6g35pa7We0deo7oEdLZFMSSG+jDvef8NpYwlycyAlLvlsgI kuhFrnpv9zbUF6Rw0EEihl8m8viNZXLR8UPJH+WTlcp9qjJFngorNIUGjbEHR2RUsfeE1+oqvyn5 cNFlrmdJGB0mOmMWxJrm+Oc6/LRx1LPvbG24dNifvQwlJFqZoh1NE1vaE1/F2QAKJMwACgJ+iSRK 1yexgMv2HAK2FeNXBnDKtnXN/9yIs+iMtoe4bY4OMHZ2/Um08acjFKIm2t1jlgAAAAAAAA== --Apple-Mail-105-820386958-- --===============0362237351== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0362237351==--