draft-ietf-proto-wgchair-doc-shepherding-06.txt   draft-ietf-proto-wgchair-doc-shepherding.txt 
Proto Team A. Falk PROTO Team A. Falk
Internet-Draft ISI Internet-Draft ISI
Expires: September 6, 2006 H. Levkowetz Intended status: Informational H. Levkowetz
Ericsson Expires: December 10, 2006 Ericsson
D. Meyer D. Meyer
Cisco/University of Oregon Cisco/University of Oregon
March 5, 2006 L. Eggert
NEC
June 8, 2006
The PROTO Process: Working Group Chair Document Shepherding The PROTO Process: Document Shepherding after Working Group Last Call
draft-ietf-proto-wgchair-doc-shepherding-06 draft-ietf-proto-wgchair-doc-shepherding
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 37 skipping to change at page 1, line 39
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 September 6, 2006. This Internet-Draft will expire on December 10, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The methodologies described in this document have been designed to This document describes methodologies that have been designed to
improve and facilitate IETF document flow processing. A set of improve and facilitate IETF document flow processing. It specifies a
procedures, known as the PROTO process (because it was created by the set of procedures under which a working group chair or secretary
PROcess and TOols or PROTO team), are specified in which a working serves as the primary Document Shepherd for a document that has been
group chair serves as the primary document shepherd for a document submitted to the IESG for publication. Before this, the shepherding
which has been submitted to the IESG for publication. Note that this role has traditionally been filled by the Responsible Area Director
role has traditionally been filled by the AD responsible for the for the working group.
working group.
The shepherd's responsibilities include: A Document Shepherd's responsibilities include:
1. Providing the write-up accompanying a document that is forwarded o Providing the PROTO Write-Up accompanying a document that is
to the IESG for publication. Note that this write-up had forwarded to the IESG when publication is requested.
traditionally been provided by the Shepherding Area Director.
Under the processes and procedures described here, the working
group chair provides this write-up.
2. Following up on AD Evaluation comments to the authors and working o During AD Evaluation by the Responsible Area Director, managing
group, and the discussion between the authors, the working group, and the
Responsible Area Director.
3. Following up on all IESG comments ("DISCUSSes") related to the o During IESG evaluation, following up on all IESG feedback
shepherded draft. ("DISCUSS" and "COMMENT" items) related to the shepherded
document.
4. Following up on IANA and RFC Editor questions in the post- o Following up on IANA and RFC Editor requests in the post-approval
approval shepherding of the document. shepherding of the document.
5. In summary, continuing to care for the document in its post-WG In summary, a Document Shepherd continues to care for a shepherded
lifetime, as he or she has done as a Chair, continuing to watch document during its post-WG lifetime similar to how how he or she has
over quality, transparency, WG concerns, and timeliness. done while responsible for the document in a working group.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. WG Chair Write-Up for Publication Request . . . . . . . . 5 3.1. PROTO Write-Up for Publication Request . . . . . . . . . . 6
3.2. AD Review Shepherding . . . . . . . . . . . . . . . . . . 8 3.2. Document Shepherding during AD Evaluation . . . . . . . . 8
3.3. IESG Discuss Shepherding . . . . . . . . . . . . . . . . . 9 3.3. Document Shepherding during IESG Evaluation . . . . . . . 9
4. When Not to Use PROTO . . . . . . . . . . . . . . . . . . . . 12 4. When Not to Use PROTO . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . . 13 8. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Working documents . . . . . . . . . . . . . . . . . . 14 Appendix A. Working Documents . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
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 PROTO throughput and quality. One such experiment, referred to as the
[PROTO], is a set of methodologies designed to involve the working "PROTO process" or "PROTO" (because it was created by the "PROcess
group chairs more directly in their documents' approval life cycle. and TOols" or PROTO [PROTO] team, is a set of methodologies designed
In particular, the PROTO team focused on that part of the document's to involve working group chairs or secretaries more directly in their
life cycle which occurs after the working group and document editor documents' approval life cycle. In particular, the PROTO team
would have traditionally forwarded the document to the IESG for focused on improvements to that part of a document's life cycle that
publication. occurs after the working group and document editor have forwarded it
to the IESG for publication.
The methodologies developed and piloted by the PROTO team (hereafter
referred to as the "PROTO process" or simply "PROTO") focus on the
working group chair as the primary document shepherd. In this
context, the shepherd's responsibilities include:
1. Providing the write-up accompanying a document that has been
forwarded to the IESG for publication. This write-up had
traditionally been provided by the "Shepherding Area Director".
Under PROTO, the Working Group Chair provides this write-up.
2. Following up on AD Evaluation comments to the authors and working
group, and
3. Following up on all IESG comments ("DISCUSSes", primarily)
related to the shepherded draft.
4. Following up on queries and requests by help from IANA and the
RFC Editor related to the shepherded draft in moving it to
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 though several pilot projects methodologies based on data obtained through several pilot projects
which had run throughout the year, and subsequently decided to adopt that had run throughout the year, and subsequently decided to adopt
the PROTO process. the PROTO process for all documents and working groups.
The methodologies developed and piloted by the PROTO team (hereafter
referred to as the "PROTO process" or simply "PROTO") focus on the
working group chair or secretary as the primary Document Shepherd.
The primary objective of the PROTO process is to improve document The primary objective of the PROTO process is to improve document
throughput and quality by enabling a partnership between the processing throughput and document quality by enabling a partnership
Responsible Area Director and the Shepherding Working Group Chair between the Responsible Area Director and the Document Shepherd. In
(note that the Working Group Chair, in consultation with the
Responsible Area Director, may designate the Working Group Secretary,
if one exists, to be the shepherd for a particular document). In
particular, this partnership has the explicit goal of empowering the particular, this partnership has the explicit goal of empowering the
Shepherding WG Chair while at the same time offloading a specific Document Shepherd while at the same time offloading a specific part
part of the follow-up work which had traditionally been of the follow-up work that has traditionally been responsibility of
responsibility of the Responsible Area Director. As such, PROTO has the Responsible Area Director.
been scoped to include both the follow-up after the Responsible Area
Director has read through and evaluated a document submitted to the Consequently, PROTO includes follow-up work during all document
IESG for publication, as well as follow-up on all IESG comments on a processing stages after Working Group Last Call, i.e., during AD
document (i.e., DISCUSSes). Finally, it is important to note that Evaluation of a document, during IESG evaluation, and during post-
PROTO does not cover follow-up for drafts which do not originate in a approval processing by IANA and the RFC Editor. In these stages, it
working group. 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 a working group
secretary as the responsible Document Shepherd.
The remainder of this document is organised as follows: Section 3 The remainder of this document is organised as follows: Section 3
outlines the overall PROTO process. Section 3.1 describes the outlines the overall PROTO process. Section 3.1 describes the PROTO
write-up which accompanies the publication request, Section 3.2 Write-Up that accompanies the publication request of a document.
describes the AD Review shepherding process, and Section 3.3 Section 3.2 describes the AD Evaluation shepherding process and
describes IESG Discuss Shepherding. Finally, Section 4 describes Section 3.3 describes IESG DISCUSS shepherding. Finally, Section 4
those cases in which the PROTO process should not be used. describes those cases in which the PROTO process should not be used.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
3. Process Description 3. Process Description
The PROTO process is divided into the following tasks: The PROTO process consists of the following tasks:
o Doing a WG Chair Write-Up for a document (Section 3.1), o Providing the PROTO Write-Up accompanying a document that is
forwarded to the IESG when publication is requested, as described
in Section 3.1.
o Following up on AD review comments (Section 3.2), and o During AD Evaluation of the document by the Responsible Area
Director, managing the discussion between the authors, the working
group and the Responsible Area Director, as described in
Section 3.2.
o Following up on IESG DISCUSS comments (Section 3.3) 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 Supporting the document in the post-approval period (for the IANA o Following up on IANA and RFC Editor requests in the post-approval
actions, the RFC Editor publication steps) is not described in the shepherding of the document.
general sense here.
3.1. WG Chair Write-Up for Publication Request In summary, a Document Shepherd continues to care for a shepherded
document during its post-WG lifetime similar to how how he or she has
done while responsible for the document in a working group.
When a draft is ready to be submitted for publication, it is the task Before any PROTO processing takes place, a single Document Shepherd
of the Shepherding WG Chair to do a document write-up for the draft. must be identified for a document. This is typically the chair of
the working group that has produced a document. If the working group
has more than one chair, the chairs decide on who should act as
Document Shepherd for a document. In consultation with the
Responsible Area Director, the chairs may also decide to appoint a
working group secretary as Document Shepherd. The Document Shepherd
SHOULD NOT be an author of the shepherded document.
There are two parts to this task. First, the Shepherding WG Chair It is important to note that PROTO only applies to documents that are
the product of a working group. It does not apply to documents that
originate elsewhere. Additionally, Section 4 discusses other
instances in which PROTO does not apply.
3.1. PROTO Write-Up for Publication Request
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 PROTO Write-Up for the document.
There are two parts to this task. First, the Document Shepherd
answers questions 1.a to 1.h below to give the Responsible Area answers questions 1.a to 1.h below to give the Responsible Area
Director insight into the working group process as applied to this Director insight into the working group process that applied to this
draft. Note that while these questions may appear redundant in some document. Note that while these questions may appear redundant in
cases, they are written to elicit information that the AD must be some cases, they are written to elicit information that the
aware of (to this end, pointers to relevant entries in the WG archive Responsible Area Director must be aware of (to this end, pointers to
will be helpful). The goal here is to inform the AD about any issues relevant entries in the WG archive will be helpful). The goal here
that may have come up in IETF meetings, on the mailing list, or in is to inform the Responsible Area Director about any issues that may
private communication that they should be aware of prior to IESG have come up in IETF meetings, on the mailing list, or in private
evaluation of the shepherded draft. Any significant issues mentioned communication that they should be aware of prior to IESG evaluation
in the questionnaire will probably lead to a follow-up discussion of the shepherded document. Any significant issues mentioned in the
with the AD. questionnaire will probably lead to a follow-up discussion with the
Responsible Area Director.
The second part of the task is to prepare the "Protocol Write-Up" The second part of the task is to prepare the PROTO Write-Up that is
which is used both for the ballot write-up for the IESG telechat and input to both the ballot for the IESG telechat and to the eventual
for the the IETF-wide protocol announcement. Item number 1.i IETF-wide announcement message. Item number 1.i describes the
describes the elements of the write-up. Please see other protocol elements of the write-up. Please see other protocol announcements in
announcements in the IETF Announce archive for examples of such the IETF Announce archive for examples of such write-ups.
write-ups.
1.a) Have the chairs personally reviewed this version of the Internet (1.a) Who is the Document Shepherd for this document? Has the
Draft (ID), and in particular, do they believe this ID is ready Document Shepherd personally reviewed this version of the
to forward to the IESG for publication? Which chair is the WG document and, in particular, does he or she believe this
Chair Shepherd for this document? version is ready for forwarding to the IESG for publication?
1.b) Has the document had adequate review from both key WG members (1.b) Has the document had adequate review both from key WG members
and key non-WG members? Do you have any concerns about the and from key non-WG members? Does the Document Shepherd have
depth or breadth of the reviews that have been performed? any concerns about the depth or breadth of the reviews that
have been performed?
1.c) Do you have concerns that the document needs more review from a (1.c) Does the Document Shepherd have concerns that the document
particular (broader) perspective (e.g., security, operational needs more review from a particular or broader perspective,
complexity, someone familiar with AAA, internationalization, e.g., security, operational complexity, someone familiar with
XML, etc.)? AAA, internationalization or XML?
1.d) Do you have any specific concerns/issues with this document that (1.d) Does the Document Shepherd have any specific concerns or
you believe the ADs and/or IESG should be aware of? For issues with this document that the Responsible Area Director
example, perhaps you are uncomfortable with certain parts of the and/or the IESG should be aware of? For example, perhaps you
document, or have concerns whether there really is a need for he or she is uncomfortable with certain parts of the document,
it. In any event, if your issues have been discussed in the WG or has concerns whether there really is a need for it. In any
and the WG has indicated it that it still wishes to advance the event, if those issues have been discussed in the WG and the
document, detail those concerns in the write-up. WG has indicated that it still wishes to advance the document,
detail those concerns here.
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 to the Responsible Area Director. (It should be separate email messages to the Responsible Area Director. (It
separate email because this questionnaire will be entered into should be in a separate email because this questionnaire will
the tracker). be entered into the ID Tracker.)
1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.
1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.
1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:
* Technical Summary
* Working Group Summary
* Protocol Quality
1.j) Please provide such a write-up. Recent examples can be found in
the "Action" announcements for approved documents.
1.k) Note: (1.g) Has the Document Shepherd 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.
* The relevant information for the technical summary can (1.h) Has the document split its references into normative and
frequently be found in the abstract and/or introduction of informative? Are there normative references to documents that
the document. If not, this may be an indication that there are not ready for advancement or are otherwise in an unclear
are deficiencies in the abstract or introduction. 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].
* For the Working Group Summary: Was there anything in WG (1.i) For Standards Track and BCP documents, the IESG approval
process that is worth noting? For example, was there announcement includes a write-up. Please provide such a
controversy about particular points, decisions where write-up. Recent examples can be found in the "Action"
consensus was particularly rough, etc. announcements for approved documents. The approval
announcement contains the following sections:
* For the protocol quality, useful information includes: 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.
+ Are there existing implementations of the protocol? 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?
Protocol 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?
+ Have a significant number of vendors indicated they The Document Shepherd MUST send the PROTO Write-Up to the Responsible
plan to implement the specification? Area Director and iesg-secretary@ietf.org together with the request
+ Are there any reviewers that merit special mention as to publish the document. The Document Shepherd SHOULD also send the
having done a thorough review (i.e., that resulted in write-up, minus any discussion of possible appeals, to the working
important changes or a conclusion that the document group mailing list.
had no substantive issues)?
The questionnaire and write-up is sent to the AD and The PROTO Write-Up is entered into the ID Tracker [IDTRACKER] as a
iesg-secretary@ietf.org with a request to publish the document. The "Comment." The name and email address of the Document Shepherd are
questionnaire and write-up, minus any discussion of possible appeals, entered into the ID Tracker, currently as a "Brief Note" (this may
is also sent to the working group mailing list. The questionnaire change in the future). The email address of the Document Shepherd
indicates which chair will be the WG Chair Shepherd. This MUST also be added to the "State or Version Change Notice To" field.
information should be entered into the ID Tracker (where it goes is In addition to making life easier during IESG Evaluation, this
in flux). In addition to making life easier for the ADs, this is information is important for the IETF Chair's Gen-ART [GEN-ART]
important for the IETF Chair's Gen-ART [GEN-ART] Directorate and Directorate and other directorates, so they can know where to address
other directorates, so they can know where to address reviews in reviews to, in addition to the Responsible Area Director.
addition to the Responsible Area Director.
3.2. AD Review Shepherding 3.2. Document Shepherding during AD Evaluation
The steps for working group chair shepherding of AD reviews are as The steps for document shepherding during AD Evaluation are as
follows: follows:
2.a) If there is more than one chair, the chairs decide on which one (2.a) The Responsible Area Director reads, evaluates and comments on
should be responsible for ensuring that the needed fixes are the document, as is the case when not using PROTO. If the
done when the AD returns comments. This MUST be done before the Responsible Area Director determines that the document is
publication request is sent, so that the information can be ready for IESG Evaluation, he or she indicates this to the
included in the request, as mentioned above. This MUST be an Document Shepherd and the PROTO process continues as described
explicit agreement among the working group chairs. in Section 3.3.
2.b) The AD reads, evaluates and comments on the draft (as is the
case when not using PROTO).
2.c) Depending on the magnitude of the issues found, the AD returns
the full review to the chairs, and requests that either:
* Further editorial work must be done on the document before
it can be published, or,
* ID Nits must be fixed before the document before it can be
published, or
* A revised draft is is required to resolve issues that have
been found in subsequent IESG review.
As covered below, the comments will be posted to the working (2.b) If the Responsible Area Director has identified issues with a
group mailing list. The comments will normally also be posted document that must be addressed before IESG Evaluation can
by the AD in the ID Tracker [IDTRACKER]. Working groups that commence, he or she sends a full evaluation to the Document
use issue tracking should also record the issues (and eventually Shepherd and should also enter the review into the ID Tracker.
their resolution) in the issue tracker.
2.d) The Shepherding WG Chair reads through the AD Evaluation (2.c) The Document Shepherd reads the AD Evaluation comments, making
comments, making very certain that all comments are understood, very certain that all comments are understood, so that it is
so that it is possible to follow up on them with the authors and possible to follow up on them with the authors and working
working group. If there is some uncertainty as to what is group. If there is some uncertainty as to what is requested,
requested, this must be resolved with the Area Director. this must be resolved with the Responsible Area Director.
2.e) The Shepherding WG Chair sends the comments to the author(s) and (2.d) The Document Shepherd sends the AD Evaluation comments to the
to the working group mailing list, in order to have a permanent authors and to the working group mailing list, in order to
record of the comments. It is recommended that the chair have a permanent record of the comments. It is RECOMMENDED
solicit from the author(s) an estimate on when the fixes will be that the Document Shepherd solicit from the authors an
done, that is, when the revised draft can be expected. 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.f) When incorporating the fixes in the new version of the draft, it (2.e) During the production of a revised document that addresses the
is strongly RECOMMENDED that the editor keep a list showing how AD Evaluation comments, it is strongly RECOMMENDED that the
each issue was addressed and showing what the revised text is. authors keep a list showing how each comment was addressed and
It is strongly RECOMMENDED that this list be forwarded to the what the revised text is. It is strongly RECOMMENDED that
Responsible Area Director with the revised draft. this list be forwarded to the Responsible Area Director
together with the revised document.
2.g) The Shepherding WG Chair iterates with the authors (and working (2.f) In the event that the authors or working group disagrees with
group if required) until the outstanding issues have been a comment raised by the Responsible Area Director or has
resolved and a revised draft has been submitted. At this point, previously considered and dismissed the issue, the Document
the AD is notified and provided with the summary list of issues Shepherd MUST resolve the issue with the Responsible Area
and resulting text changes. Director before a revised document can be submitted.
In the event that the working group disagrees with a comment (2.g) The Document Shepherd iterates with the authors (and working
raised by the AD or has previously considered and dismissed the group, if required) until all outstanding issues have been
issue, the Shepherding WG Chair MUST resolve the issue with the resolved and a revised document is available. At this point,
AD before a revised draft can be submitted. 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 Area Director verifies that the issues he or she found (2.h) The Responsible Area Director verifies that the issues he or
during AD Evaluation are resolved by the new version of the she found during AD Evaluation are resolved in the revised
draft. version of the document by starting the process described in
this section at step (2.a).
2.i) The shepherding process normally terminates at this point. 3.3. Document Shepherding during IESG Evaluation
However, in the event that no resolution can be found, the
process goes to 1. above (i.e., essentially restarts).
3.3. IESG Discuss Shepherding 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.
In this section we detail the steps that a Shepherding WG Chair will Note that DISCUSS and COMMENT items are occasionally written in a
take in resolving the DISCUSS items against a given ID. The steps manner that makes their intent unclear. In these cases, the Document
are given below, in the order that they are to be executed. Note Shepherd SHOULD start a discussion with the ADs who brought the items
that occasionally DISCUSSes are written in a manner that makes their up to clarify their intent, keeping the Responsible Area Director
primary intent unclear. In these cases, the Shepherding WG Chair informed. If this fails to clarify the intent, the Responsible Area
(and possibly the document editor) and DISCUSSing AD SHOULD meet Director may need to work towards a clarification inside the IESG.
(either in person or electronically) to resolve the issue. In
addition, the Responsible Area Director SHOULD be kept well informed.
If this process fails to clarify or resolve the DISCUSS, the
Shepherding WG Chair MAY further involve the Responsible Area
Director in the resolution process.
3.a) Leading up to the fortnightly IESG conference call, the (3.a) Leading up to the IESG conference call, the Document Shepherd
Shepherding WG Chair may see email about the document from may see emails about the document from directorate reviewers
directorate reviewers on behalf one or more ADs, and also on behalf one or more ADs and also emailed copies of DISCUSS
emailed copies of tracker DISCUSSes and COMMENTs. The ADs are and COMMENT items entered into the ID Tracker. The Document
now able to automatically send the comments to both the IESG and Shepherd SHOULD immediately begin to work on resolving DISCUSS
the addresses placed in the "State Change Notice To" field, and COMMENT items with the ADs who have raised them, keeping
which automatically includes all WG Chairs. The WG Chair the Responsible Area Director copied on the email exchange, so
shepherd SHOULD immediately begin to work on resolving DISCUSS that he or she is able support the the activity during the
items with the AD, keeping the Responsible Area Director copied conference call. When dealing with directorate reviews, the
so that he or she is able support the the activity during the Document Shepherd MUST involve the ADs to whom these
conference call. When dealing with directorate reviews, the WG directorates report to ensure that these ADs consider the
Chair shepherd MUST involve the Area Director to whom the review comments that need resolving.
directorate reports and be sure that AD considers the review
comments need resolving.
3.b) Immediately after the IESG conference call, the Shepherding WG (3.b) Immediately following the conference call, when the document
Chair queries the ID tracker [IDTRACKER] to collect remaining changes state from the "IESG Evaluation" state to one of the
DISCUSS comments raised against the ID. In order to ensure states requiring Document Shepherd action, e.g., "IESG
this, in addition to the Responsible Area Director and the
Shepherding Working Group Chair having discussion, which should
happen (!), the Shepherding Working Group Chair's will receive
State Change Notice email due to the "State Change Notice To:"
field in the ID tracker. Following the conference call, when
the document changes state from the "IESG Evaluation" state to
one of the states requiring Shepherd actions (i.e., "IESG
Evaluation: Revised ID Needed" or "IESG Evaluation: AD Evaluation: Revised ID Needed" or "IESG Evaluation: AD
Followup"), the Shepherd will receive mail. This notification Followup", the Document Shepherd will receive email. A state
indicates to the the Shepherding WG Chair that DISCUSS comments of "AD Followup" typically signifies the Responsible Area
have been registered. AD Followup signifies the Responsible Director's hope that a resolution may be possible through a
Area Director's hope that resolution may be possible through a continued discussion or (more usually) through a small set of
discussion till the other Area Director understands more, or changes as "Notes to the RFC Editor."
(more usually) through some Notes to the RFC Editor.
3.c)
Note that there may be very exceptional cases when DISCUSS Note that there may be very exceptional cases when DISCUSS
comments are registered after the IESG teleconference. In these items are registered after an IESG conference call. In these
cases, the DISCUSSing AD must notify the Shepherding WG Chair cases, the AD who has raised the DISCUSS MUST notify the
that new comments have been entered. The email notification Document Shepherd about it. (The notification facility in the
facility is very convenient for this purpose, and also for the ID Tracker is very convenient for this purpose and also for
cases where the DISCUSS comments are updated after they are the cases where the DISCUSS and COMMENT items are updated
partially resolved. after they are partially resolved.)
3.d) The Shepherding WG Chair analyses comments from the tracker, and (3.c) The Document Shepherd then queries the ID Tracker to collect
initialises contact with any AD's who have placed comments the remaining DISCUSS and COMMENT items raised against the
(blocking or non-blocking) on the draft that is being document. The Document Shepherd analyses these items and
shepherded. In particular, the Shepherding WG Chair MUST notify initialises contact with the ADs who have placed them. The
the relevant ADs that the Shepherding WG Chair is the current Responsible Area Director MUST be copied on all correspondence
document shepherd. Note that the Responsible Area Director MUST related to active DISCUSS or COMMENT items. This does not
be copied on correspondence for resolving comments, because the place the Responsible Area Director in the critical path
Responsible Area Director has a form of - um - responsibility. towards a resolution, but should keep him or her informed
This should not place the Responsible AD in the critical path about the state of the discussion.
but should keep the Responsible AD ready to help if needed.
+------+ Comments +--------+ Comments +-------+ +-------+ +-------+ +-------+
| (3.a)| ------------> | (3.b) | -------------> | (3.c) | | (3.b) | -----------> | (3.c) | ------------> | (3.d) |
+------+ Collected +--------+ Understood +-------+ +-------+ Comments +-------+ Comments +-------+
/|\ | collected /|\ | understood
| | Comments not fully understood
| | (Further AD/Shepherding WG
| | Chair Discussion Required)
| | | |
+----+ | | Comments not fully understood
| | (Further AD/Document Shepherd
| | discussion required)
+---+
3.e) The Shepherding WG Chair then coordinates DISCUSS comments, and (3.d) The Document Shepherd then coordinates the resolution of
builds a a consistent interpretation of the comments. This step DISCUSS and COMMENT items and builds a a consistent
may require iteration with step (2). above. That is: interpretation of the comments. This step is similar to much
of the process described in Section 3.2.
+------+ Consistent +-------+ +-------+ +-------+
| (3.b)| ---------------> | (3.c) | | (3.c) | ---------------> | (3.d) |
+------+ Interpretation +-------+ +-------+ Consistent +-------+
/|\ | /|\ interpretation |
| | Further AD/Shepherding WG | | Further AD/Document Shepherd
| | Chair discussion required | | discussion required
+--------------------------+ +--------------------------+
3.f) The DISCUSS comments are then communicated to the working group. (3.e) The Document Shepherd then communicates the DISCUSS and
COMMENT items to the document authors, the working group.
3.g) After the author(s) resolve the issues provided by the (3.f) After the authors resolve the DISCUSS and COMMENT items, the
Shepherding WG Chair (i.e., the summarised DISCUSS issues), the Document Shepherd reviews the resulting revised document,
Shepherding WG Chair reviews the updated document to ensure that using his or her technical expertise to ensure that all raised
(in her/his option) the DISCUSS issues have been resolved. DISCUSS and COMMENT issues have been resolved.
Note that the Shepherding WG Chair may also propose resolutions Note that the Document Shepherd may also suggest resolutions
to these issues, file them in an issue tracker, or do other to DISCUSS and COMMENT items, enter them into an issue
steps to streamline the resolution of the comments. It is very tracker, or perform other steps to streamline the resolution
important to resolve the comments in a timely way, while the of the evaluation comments. It is very important to resolve
discussion is current for everyone. the comments in a timely way, while the discussion is current
for everyone involved.
3.h) The Shepherding WG Chair communicates the resolution-so-far to (3.g) When the Document Shepherd is satisfied that the revised
the Responsible AD and the DISCUSSing AD(s). 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.i) DISCUSSing AD removes DISCUSS comment, or tells the Shepherding (3.h) Each AD that had raised a DISCUSS checks whether the
WG Chair and adds information to the ID tracker explaining why communicated resolution addresses their DISCUSS items. If it
the comment is not resolved. The Shepherding WG Chair informs does, the AD will clear the DISCUSS. It it does not, the AD
the working group accordingly. 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 the DISCUSS comment in question was not resolved to the If a DISCUSS was not resolved to the satisfaction of the AD
satisfaction of the DISCUSSing AD(s) and Responsible Area that has raised it or the Responsible Area Director, two
Director, two possibilities exist: possibilities exist:
(a) The process returns to step (3.c), or (a) The process returns to step (3.d), or
(b) If no progress can be made on the resolution of the DISCUSS (b) If no progress can be made on the resolution of the
with the DISCUSSING AD, despite clarification and DISCUSS with the AD who has raised it, despite
additional involvement of the Responsible Area Director, clarification and additional involvement of the
the Shepherding WG Chair and the WG might at last resort Responsible Area Director, the Document Shepherd and
consider an appeal in accordance with the procedures working group might as a very last resort consider an
described in RFC 2026 [RFC2026] and referred to in RFC 2418 appeal in accordance with the procedures described in
[RFC2418]. The Shepherding WG Chair should also review the [RFC2026] and referred to in [RFC2418]. The Document
IESG's Discuss Criteria guidelines [I-D.iesg-discuss- Shepherd SHOULD also review the IESG's Discuss Criteria
criteria] and discuss with the Responsible Area Director guidelines [I-D.iesg-discuss-criteria] and discuss with
whether there might be considerations against the the Responsible Area Director whether there might be
unresolved Discuss by the rest of the IESG due to these considerations against the unresolved DISCUSS by the rest
guidelines. of the IESG due to these guidelines.
Otherwise, the process continues with step (3.h). Once the process above has cleared all DISCUSS items, PROTO
continues with step (3.i).
3.j) The Responsible Area Director moves document to APPROVED state, (3.i) The Responsible Area Director moves document to the "Approved
or if the changes are deemed significant, there may be a new WG - Announcement to be sent" state in the ID Tracker, or, if he
last call. In that case, the document may go to the full IESG or she deems the changes to the revised document significant,
for a re-check. issues a new WG last call. In the latter case, the document
may go through a full IESG Evaluation process again.
4. When Not to Use PROTO 4. When Not to Use PROTO
As mentioned above, there are several cases in which the PROTO As mentioned in Section 3, the Document Shepherd SHOULD NOT be an
process SHOULD NOT be used. These include author of the shepherded document. If this cannot be avoided by
making another working group chair or secretary the Document
Shepherd, PROTO SHOULD NOT be used. There are several other cases in
which the PROTO process SHOULD NOT be used. These include:
1. Those cases in which the WG chair primary document author or 1. Cases, where the Document Shepherd is the primary author or
editor, or the WG chair is the primary author or editor of a editor of a large percentage of the documents produced by the
large percentage of the documents produced by the working group, working group.
2. Those cases in which the Responsible Area Director expects 2. Cases, where the Responsible Area Director expects communication
communication difficulties with the WG chair (either due to difficulties with the Document Shepherd (either due to
experience, strong views stated by the chair, or other issues), experience, strong views stated by the Document Shepherd, or
and other issues).
3. Those cases in which the working group itself is either very old,
losing energy, or winding down. i.e., those cases in which it
would not be productive to initiate new processes or procedures.
Finally, note these guidelines are intended to help the Responsible 3. Cases, where the working group itself is either very old, losing
Area Director determine when to use the PROTO process. The final energy, or winding down, i.e., cases, where it would not be
determination as to whether to use the PROTO process or not is left productive to initiate new processes or procedures.
to the Responsible Area Director's discretion.
Finally, note that other cases exist in which using PROTO may not be
productive. The final determination as to whether to use the PROTO
process or not is left to the Responsible Area Director. If PROTO is
not used, the Responsible Area Director acts as Document Shepherd,
just as he or she did before PROTO.
5. Security Considerations 5. Security Considerations
This document specifies a change to IETF document flow procedures. This document specifies a change to IETF document processing
As such, it neither raises nor considers protocol-specific security procedures. As such, it neither raises nor considers protocol-
issues. specific security issues.
6. Acknowledgments 6. IANA Considerations
This document creates no new requirements on IANA namespaces or other
IANA requirements.
7. 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 Allison Mankin, Bill Fenner, Barbara Fuller, and authors as well as Allison Mankin, Bill Fenner, Barbara Fuller, and
Margaret Wasserman. Margaret Wasserman.
7. IANA Considerations
This document creates no new requirements on IANA namespaces or other
IANA requirements.
8. Informative References 8. Informative References
[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.
skipping to change at page 14, line 6 skipping to change at page 14, line 11
[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] [I-D.iesg-discuss-criteria]
Peterson, J., "DISCUSS Criteria in IESG Review", Peterson, J., "DISCUSS Criteria in IESG Review",
draft-iesg-discuss-criteria-02 (work in progress), draft-iesg-discuss-criteria-02 (work in progress),
February 2006. February 2006.
[IDTRACKER] [IDTRACKER]
"The IETF Draft Tracker", Web "The IETF Internet-Draft Tracker", Web
Application: https://datatracker.ie= tf.org/, 2002. Application: https://datatracker.ietf.org/, 2002.
[PROTO] "The IESG Process and Tools (PROTO) Team", Web [PROTO] "The IESG Process and Tools (PROTO) Team", Web
Page: http://psg.com/~mrw/PROTO-Tea= m, 2004. Page: http://psg.com/~mrw/PROTO-Team, 2004.
[GEN-ART] "The General Area Review Team (GEN-ART)", Web [GEN-ART] "The General Area Review Team (GEN-ART)", Web Page:
Page: http://www.alvestrand.no/ietf= /gen/ http://www.alvestrand.no/ietf/gen/review-guidelines.html,
review-guidelines.html, 2005. 2005.
Appendix A. Working documents Appendix A. Working Documents
(This section should be removed by the RFC editor before publication) (This section should be removed by the RFC editor before
publication.)
The current working documents for this draft are available at this The current working documents for this document are available at this
we= b site: web site:
http://ietf.levkowetz.com/drafts/proto/wgchair-doc-shepherding/ http://tools.ietf.org/wg/proto/
draft-ietf-proto-wgchair-doc-shepherding/
Authors' Addresses Authors' Addresses
Aaron Falk Aaron Falk
Email: falk@isi.edu Email: falk@isi.edu
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
Intellectual Property Statement Lars Eggert
NEC Network Laboratories
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 143
Fax: +49 6221 4342 155
Email: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 16, line 29 skipping to change at page 16, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 97 change blocks. 
421 lines changed or deleted 430 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/