WDIFF

draft-ietf-proto-wgchair-doc-shepherding-06.txt --> draft-ietf-proto-wgchair-doc-shepherding-07.txt

Proto

PROTO Team A. Falk
Internet-Draft ISI
Expires: September 6, 2006
Intended status: Informational H. Levkowetz
Expires: December 25, 2006 Ericsson
D. Meyer
Cisco/University of Oregon
March 5,
L. Eggert
NEC
A. Mankin
June 23, 2006

The PROTO Process: Working Group Chair

Document Shepherding
draft-ietf-proto-wgchair-doc-shepherding-06 From Working Group Last Call to IESG Approval
draft-ietf-proto-wgchair-doc-shepherding-07

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 September 6, December 25, 2006.

Abstract

The methodologies described in this

This document describes methodologies that have been designed to
improve and facilitate IETF document flow processing. A It specifies a

Falk, et al. Expires December 25, 2006 [Page 1]

Internet-Draft Document Shepherding to IESG Approval June 2006

set of
procedures, known as the PROTO process (because it was created by the
PROcess and TOols or PROTO team), are specified in procedures under which a working group chair or secretary
serves as the primary document shepherd Document Shepherd for a document

Falk, et al. Expires September 6, 2006 [Page 1]

Internet-Draft Working Group Chair Document Shepherding March 2006

which that has been
submitted to the IESG for publication. Note that this Before this, the shepherding
role has traditionally been filled by the AD Area Director responsible
for the working group.

The shepherd's

A Document Shepherd's responsibilities include:

o Providing the write-up Document Shepherd Write-Up accompanying a document
that is forwarded to the IESG for publication. Note that this write-up had
traditionally been provided when publication is requested.

o During AD Evaluation by the Shepherding Responsible Area Director.
Under Director, managing
the processes and procedures described here, discussion between the working
group chair provides this write-up.

2. Following up on AD Evaluation comments to authors, the authors and working group, and

3. Following the
Responsible Area Director.

o During IESG evaluation, following up on all IESG comments ("DISCUSSes") feedback
("DISCUSS" and "COMMENT" items) related to the shepherded draft.

4.
document.

o Following up on IANA and RFC Editor questions requests in the post-
approval post-approval
shepherding of the document.

In summary, continuing a Document Shepherd continues to care for the a shepherded
document in during its post-WG
lifetime, as lifetime similar to the way he or she has done as
cared for it while responsible for the document in a Chair, continuing to watch
over quality, transparency, WG concerns, and timeliness. working group.

Falk, et al. Expires September 6, December 25, 2006 [Page 2]

Internet-Draft Working Group Chair Document Shepherding March to IESG Approval June 2006

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Process Description . . . . . . . . . . . . . . . . . . . . . 5
3.1. WG Chair Document Shepherd Write-Up for Publication Request . . . . . . . . 5
3.2. AD Review Shepherding . . . . . . . . . . 6
3.2. Document Shepherding during AD Evaluation . . . . . . . . 8
3.3. IESG Discuss Document Shepherding during IESG Evaluation . . . . . . . 10
4. When Not to Use the Document Shepherding Process . . . . . . . 12
5. Security Considerations . . . 9
4. When Not to Use PROTO . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations
8. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Working Documents . 13
8. Informative References . . . . . . . . . . . . . . . . . 14
Appendix B. Example Document Announcement Write-Ups . . . 13
Appendix A. Working documents . . . . 15
B.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 14 15
B.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 16
Intellectual Property and Copyright Statements . . . . . . . . . . 16 18

Falk, et al. Expires September 6, December 25, 2006 [Page 3]

Internet-Draft Working Group Chair Document Shepherding March to IESG Approval June 2006

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], [PROTO] team, is a set of methodologies designed
to involve the working group chairs or secretaries more directly in their
documents' approval life cycle. In particular, the PROTO team
focused on that improvements to the part of the a document's life cycle which that
occurs after the working group and document editor
would have traditionally forwarded the document 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 it
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
methodologies based on data obtained though through several pilot projects
which
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 the PROTO this document shepherding process
is to improve document processing throughput and document quality by
enabling a partnership between the Responsible Area Director and the Shepherding Working Group Chair
(note that
Document Shepherd. In particular, this partnership has the Working Group Chair, in consultation with explicit
goal of empowering 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
Shepherding WG Chair Document Shepherd while at the same time
offloading a specific part of the follow-up work which had that has
traditionally been responsibility of the Responsible Area Director. As such, PROTO has

Falk, et al. Expires September 6, 2006 [Page 4]

Internet-Draft Working Group Chair Document Shepherding March 2006

been scoped to include both

Consequently, the document shepherding process includes follow-up
work during all document processing stages after the Responsible Area
Director has read through and evaluated Working Group Last
Call, i.e., during AD Evaluation of a document submitted to the document, during IESG for publication, as well as follow-up
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 all IESG comments feedback received on a document (i.e., DISCUSSes). Finally, it
from all relevant parties.

The Document Shepherd is important to note usually a chair of the working group that
PROTO does not cover follow-up for drafts which do not originate in
has produced the document. In consultation with the Responsible Area
Director, the chairs may instead decide to appoint a working group. group
secretary as the responsible Document Shepherd.

The remainder of this document is organised as follows: Section 3
outlines the overall PROTO document shepherding process. Section 3.1
describes the
write-up which Document Shepherd Write-Up that accompanies the
publication request, request of a document. Section 3.2 describes the AD Review
Evaluation shepherding process, process and Section 3.3 describes IESG Discuss Shepherding. DISCUSS

Falk, et al. Expires December 25, 2006 [Page 4]

Internet-Draft Document Shepherding to IESG Approval June 2006

shepherding. Finally, Section 4 describes those cases in which the PROTO
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 PROTO document shepherding process is divided into consists of the following tasks:

o Doing a WG Chair Providing the Document Shepherd Write-Up for accompanying a document (Section 3.1),

o Following up on AD review comments (Section 3.2), and

o Following up on
that is forwarded to the IESG DISCUSS comments (Section 3.3) when publication is requested, as
described in Section 3.1.

o Supporting During AD Evaluation of the document in by the post-approval period (for Responsible Area
Director, managing the IANA
actions, discussion between the RFC authors, 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 publication steps) 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 similar to how how he or she has
done while responsible for the document in a working group.

Before any document shepherding takes place, a single Document
Shepherd 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.

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 described apply to documents that originate elsewhere. Additionally,

Falk, et al. Expires December 25, 2006 [Page 5]

Internet-Draft Document Shepherding to IESG Approval June 2006

Section 4 discusses other instances in which the
general sense here. document shepherding
process does not apply.

3.1. WG Chair Document Shepherd Write-Up for Publication Request

When a draft working group decides that a document is ready for submission
to be submitted the IESG for publication, it is the task of the Shepherding WG Chair Document Shepherd
to do complete a document write-up "Document Shepherd Write-Up" for the draft. document.

There are two parts to this task. First, the Shepherding WG Chair Document Shepherd
answers questions 1.a to 1.h below to give the Responsible Area
Director insight into the working group process as that applied to this
draft.
document. Note that while these questions may appear redundant in
some cases, they are written to elicit information that the AD
Responsible Area Director must be aware of (to this end, pointers to
relevant entries in the WG archive

Falk, et al. Expires September 6, 2006 [Page 5]

Internet-Draft Working Group Chair Document Shepherding March 2006 will be helpful). The goal here
is to inform the AD 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 draft. document. Any significant issues mentioned in the
questionnaire will probably lead to a follow-up discussion with the AD.
Responsible Area Director.

The second part of the task is to prepare the "Protocol "Document Announcement
Write-Up"
which that is used input to both for the ballot write-up for the IESG telechat and
for the
to the eventual IETF-wide protocol announcement. announcement message. Item number 1.i (1.i)
describes the elements of the write-up. Please see other protocol
announcements in the IETF Announce archive for Document Announcement Write-Up. Some
examples of Document Announcement Write-Ups are included in
Appendix B, and there are many more examples with Subject lines such
write-ups.

1.a) Have
as "Protocol Action" and "Document Action" in the chairs IETF-announce
mailing list archive.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the Internet
Draft (ID), and
document and, in particular, do they does he or she believe this ID
version is ready
to forward for forwarding to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

1.b)

(1.b) Has the document had adequate review from both from key WG members
and from key non-WG members? Do you Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

1.c) Do you

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular (broader) perspective (e.g., or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization,
XML, etc.)?

1.d) Do you internationalization or XML?

Falk, et al. Expires December 25, 2006 [Page 6]

Internet-Draft Document Shepherding to IESG Approval June 2006

(1.d) Does the Document Shepherd have any specific concerns/issues concerns or
issues with this document that
you believe the ADs Responsible Area Director
and/or the IESG should be aware of? For example, perhaps you are he
or she is uncomfortable with certain parts of the document, or have
has concerns whether there really is a need for it. In any
event, if your those issues have been discussed in the WG and the
WG has indicated it that it still wishes to advance the document,
detail those concerns in the write-up.

1.e) here.

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

(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 will
be entered into the tracker).

Falk, et al. Expires September 6, 2006 [Page 6]

Internet-Draft Working Group Chair Document Shepherding March 2006

1.g) Have ID Tracker.)

(1.g) Has the chairs Document Shepherd verified that the document checks out against satisfies
all the ID nits? (see http://www.ietf.org/ID-Checklist.html). (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.

1.h)

(1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs documents that
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 such normative references are behind, exist, what is the
strategy for their completion? On a related matter, are Are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing If
so, list these supports downward references to support the Area
Director in the Last Call downref procedure specified in RFC 3967.

1.i) For Standards Track and BCP documents, the for them [RFC3967].

(1.i) The IESG approval announcement includes a write-up section with the following
sections:

* Technical Summary

* Working Group Summary

* Protocol Quality

1.j) Document
Announcement Write-Up. Please provide such a write-up. Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents.

1.k) Note:

* The relevant information for approval
announcement contains the technical summary 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.

* For the Working Group Summary: Was there anything in WG
process that is

Falk, et al. Expires December 25, 2006 [Page 7]

Internet-Draft Document Shepherding to IESG Approval June 2006

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points, points or
were there decisions where the consensus was particularly rough, etc.

* For the protocol quality, useful information includes:

+
rough?

Document Quality
Are there existing implementations of the protocol?

+ Have a
significant number of vendors indicated they their plan to
implement the specification?

Falk, et al. Expires September 6, 2006 [Page 7]

Internet-Draft Working Group Chair Document Shepherding March 2006

+ Are there any reviewers that
merit special mention as having done a thorough review (i.e., review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues)? issues?

The questionnaire and write-up is sent Document Shepherd MUST send the Document Shepherd Write-Up to the AD
Responsible Area Director and iesg-secretary@ietf.org together with a
the request to publish the document. The
questionnaire and write-up, minus any discussion of possible appeals,
is Document Shepherd SHOULD
also sent send the entire Document Shepherd Write-up to the working group
mailing list. The questionnaire
indicates If there is information which chair will may prove to be the WG Chair Shepherd. This
sensitive, lead to possible appeals or is personal information that
the Document Shepherd feels should be written up, it should be sent
in direct email to the Responsible Area Director, because the
Document Shepherd Write-Up will be published openly in the tracker.

The Document Shepherd Write-Up is entered into the ID Tracker (where it goes is
[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 flux). the future). The email address of
the Document Shepherd MUST also be added to the "State or Version
Change Notice To" field. In addition to making life easier for the ADs, during
IESG Evaluation, this information is important for the IETF Chair's
Gen-ART [GEN-ART] Directorate and other directorates, so they can
know where to address reviews to, in addition to the Responsible Area
Director.

3.2. AD Review Document Shepherding during AD Evaluation

The steps for working group chair document shepherding of during AD reviews Evaluation are as
follows:

2.a) If there is more than one chair, the chairs decide on which one
should be responsible for ensuring that the needed fixes are
done when the AD returns comments. This MUST be done before the
publication request is sent, so that the information can be
included in the request, as mentioned above. This MUST be an
explicit agreement among the working group chairs.

2.b)

(2.a) The AD Responsible Area Director reads, evaluates and comments on
the draft (as document, 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 document
shepherding process. If the chairs, and requests Responsible Area Director
determines 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 ready for IESG review.

As covered below, the comments will be posted Evaluation, he
or she indicates this to the working
group mailing list. The comments will normally also be posted
by the AD in the ID Tracker [IDTRACKER]. Working groups that
use issue tracking should also record Document Shepherd and the issues (and eventually
their resolution)
document shepherding process continues as described in the issue tracker.
Section 3.3.

Falk, et al. Expires September 6, December 25, 2006 [Page 8]

Internet-Draft Working Group Chair Document Shepherding March to IESG Approval June 2006

2.d)

(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 Shepherding WG Chair Document Shepherd reads through the AD Evaluation comments, making
very certain that all comments are understood, so that it is
possible to follow up on them with the authors and working
group. If there is some uncertainty as to what is requested,
this must be resolved with the Responsible Area Director.

2.e)

(2.d) The Shepherding WG Chair Document Shepherd sends the AD Evaluation comments to the author(s)
authors and to the working group mailing list, in order to
have a permanent record of the comments. It is recommended RECOMMENDED
that the chair Document Shepherd solicit from the author(s) authors an
estimate on when the fixes required changes will be
done, that is, when the complete and a
revised draft document can be expected.

2.f) When incorporating Working groups that use
issue tracking should also record the fixes issues (and eventually
their resolution) in their issue tracker.

(2.e) During the new version production of a revised document that addresses the draft,
AD Evaluation comments, it is strongly RECOMMENDED that the editor
authors keep a list showing how each issue comment was addressed and showing
what the revised text is. It is strongly RECOMMENDED that
this list be forwarded to the Responsible Area Director
together with the revised draft.

2.g) The Shepherding WG Chair iterates with document.

(2.f) In the event that the authors (and or working group if required) until the outstanding issues have been
resolved and disagrees with
a revised draft has been submitted. At this point, comment raised by the AD is notified and provided with the summary list of issues
and resulting text changes.

In the event that the working group disagrees with a comment
raised by the AD Responsible Area Director or has
previously considered and dismissed the issue, the Shepherding WG Chair Document
Shepherd MUST resolve the issue with the
AD Responsible Area
Director before a revised draft document can be submitted.

2.h)

(2.g) The Document Shepherd iterates with the authors (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 by in the new revised
version of the
draft.

2.i) The shepherding process normally terminates at this point.
However, in the event that no resolution can be found, document by starting the process goes described in
this section at step (2.a).

Falk, et al. Expires December 25, 2006 [Page 9]

Internet-Draft Document Shepherding to 1. above (i.e., essentially restarts).

3.3. IESG Discuss Approval June 2006

3.3. Document Shepherding

In this 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 we detail details the steps that a Shepherding WG Chair will
take in resolving the
Document Shepherd takes to resolve any DISCUSS and COMMENT items
brought forward against a given ID. The steps
are given below, in the order that they are to be executed. shepherded document during IESG Evaluation.

Note that occasionally DISCUSSes DISCUSS and COMMENT items are occasionally written in a
manner that makes their
primary intent unclear. In these cases, the Shepherding WG Chair
(and possibly the document editor) and DISCUSSing AD Document
Shepherd SHOULD meet
(either in person or electronically) to resolve start a discussion with the issue. In
addition, ADs who brought the items
up to clarify their intent, keeping the Responsible Area Director SHOULD be kept well
informed. If this process fails to clarify or resolve the DISCUSS, the

Falk, et al. Expires September 6, 2006 [Page 9]

Internet-Draft Working Group Chair Document Shepherding March 2006

Shepherding WG Chair MAY further involve intent, the Responsible Area
Director in may need to work towards a clarification inside the resolution process.

3.a) IESG.

(3.a) Leading up to the fortnightly IESG conference call, the
Shepherding WG Chair Document Shepherd
may see email emails about the document from directorate reviewers
on behalf one or more ADs, ADs and also emailed copies of tracker DISCUSSes and COMMENTs. The ADs are
now able to automatically send the comments to both the IESG DISCUSS
and COMMENT items entered into the addresses placed in the "State Change Notice To" field,
which automatically includes all WG Chairs. ID Tracker. The WG Chair
shepherd Document
Shepherd SHOULD immediately begin to work on resolving DISCUSS
and COMMENT items with the AD, ADs who have raised them, keeping
the Responsible Area Director copied on the email exchange, so
that he or she is able support the the activity during the
conference call. When dealing with directorate reviews, the WG
Chair shepherd
Document Shepherd MUST involve the Area Director ADs to whom the
directorate reports and be sure these
directorates report to ensure that AD considers these ADs consider the
review comments that need resolving.

3.b)

(3.b) Immediately after the IESG conference call, the Shepherding WG
Chair queries the ID tracker [IDTRACKER] to collect remaining
DISCUSS comments raised against the ID. In order to ensure
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 following the conference call, when the document
changes state from the "IESG Evaluation" state to one of the
states requiring Document Shepherd actions (i.e., action, e.g., "IESG
Evaluation: Revised ID Needed" or "IESG Evaluation: AD
Followup"),
Followup", the Document Shepherd will receive mail. This notification
indicates to the the Shepherding WG Chair that DISCUSS comments
have been registered. AD Followup email. A state
of "AD Followup" typically signifies the Responsible Area
Director's hope that a resolution may be possible through a
continued discussion till the other Area Director understands more, or (more usually) through some Notes a small set of
changes as "Notes to the RFC Editor.

3.c) Editor."

Note that there may be very exceptional cases when DISCUSS
comments
items are registered after the an IESG teleconference. conference call. In these
cases, the DISCUSSing AD must who has raised the DISCUSS MUST notify the Shepherding WG Chair
that new comments have been entered. The email
Document Shepherd about it. (The notification facility in the
ID Tracker is very convenient for this purpose, purpose and also for
the cases where the DISCUSS comments and COMMENT items are updated
after they are partially resolved. resolved.)

Falk, et al. Expires September 6, December 25, 2006 [Page 10]

Internet-Draft Working Group Chair Document Shepherding March to IESG Approval June 2006

3.d)

(3.c) The Shepherding WG Chair analyses comments from Document Shepherd then queries the tracker, ID Tracker to collect
the remaining DISCUSS and COMMENT items raised against the
document. The Document Shepherd analyses these items and
initialises contact with any AD's the ADs who have placed comments
(blocking or non-blocking) on the draft that is being
shepherded. In particular, the Shepherding WG Chair MUST notify
the relevant ADs that the Shepherding WG Chair is the current
document shepherd. Note that the Responsible Area Director MUST
be copied them. The
Responsible Area Director MUST be copied on all correspondence for resolving comments, because the
Responsible Area Director has a form of - um - responsibility.
related to active DISCUSS or COMMENT items. This should does not
place the Responsible AD Area Director in the critical path
towards a resolution, but should keep him or her informed
about the Responsible AD ready to help if needed.

+------+ Comments +--------+ Comments state of the discussion.

+-------+ +-------+ +-------+
| (3.a)| ------------>
| (3.b) | -------------> -----------> | (3.c) |
+------+ Collected +--------+ Understood ------------> | (3.d) |
+-------+ Comments +-------+ Comments +-------+
collected /|\ | understood
| |
| | Comments not fully understood
| | (Further AD/Shepherding WG
| | Chair Discussion Required) AD/Document Shepherd
| |
+----+

3.e) discussion required)
+---+

(3.d) The Shepherding WG Chair Document Shepherd then coordinates the resolution of
DISCUSS comments, and COMMENT items and builds a a consistent
interpretation of the comments. This step
may require iteration with step (2). above. That is:

+------+ Consistent is similar to much
of the process described in Section 3.2.

+-------+ +-------+
| (3.c) | (3.b)| ---------------> | (3.c) (3.d) |
+------+ Interpretation
+-------+ Consistent +-------+
/|\ interpretation |
| | Further AD/Shepherding WG AD/Document Shepherd
| | Chair discussion required
+--------------------------+

3.f)

(3.e) The DISCUSS comments are Document Shepherd then communicated communicates the DISCUSS and
COMMENT items to the document authors and the working group.

3.g)

(3.f) After the author(s) authors resolve the issues provided by the
Shepherding WG Chair (i.e., the summarised DISCUSS issues), and COMMENT items, the
Shepherding WG Chair
Document Shepherd reviews the updated document resulting revised document,
using his or her technical expertise to ensure that
(in her/his option) the all raised
DISCUSS and COMMENT issues have been resolved.

Note that the Shepherding WG Chair Document Shepherd may also propose suggest resolutions
to these issues, file DISCUSS and COMMENT items, enter them in into an issue
tracker, or do 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. everyone involved.

Falk, et al. Expires September 6, December 25, 2006 [Page 11]

Internet-Draft Working Group Chair Document Shepherding March to IESG Approval June 2006

3.h) The Shepherding WG Chair

(3.g) When the Document Shepherd is satisfied that the revised
document addresses the evaluation comments, he or she
communicates the resolution-so-far resolution to the Responsible AD Area Director
and the DISCUSSing AD(s).

3.i) DISCUSSing ADs that had raised the DISCUSS and COMMENT items.

(3.h) Each AD removes that had raised a DISCUSS comment, or tells checks whether the Shepherding
WG Chair
communicated resolution addresses their DISCUSS 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
Tracker explaining why the comment is DISCUSS was not resolved. The Shepherding WG Chair
Document Shepherd informs the working group accordingly.

If the DISCUSS comment in question was
(COMMENT items need not resolved 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 DISCUSSing AD(s) and AD
that has raised it or the Responsible Area Director, two
possibilities exist:

(a) The process returns to step (3.c), (3.d), or

(b) If no progress can be made on the resolution of the
DISCUSS with the DISCUSSING AD, AD who has raised it, despite
clarification and additional involvement of the
Responsible Area Director, the Shepherding WG Chair Document Shepherd and the WG
working group might at as a very last resort consider an
appeal in accordance with the procedures described in RFC 2026
[RFC2026] and referred to in RFC 2418 [RFC2418]. The Shepherding WG Chair should Document
Shepherd SHOULD also review the IESG's Discuss Criteria
guidelines [I-D.iesg-discuss-
criteria] [I-D.iesg-discuss-criteria] and discuss with
the Responsible Area Director whether there might be
considerations against the unresolved Discuss DISCUSS by the rest
of the IESG due to these guidelines.

Otherwise,

Once the process above has cleared all DISCUSS items, document
shepherding continues with step (3.h).

3.j) (3.i).

(3.i) The Responsible Area Director moves document to APPROVED state,
or the "Approved
- Announcement to be sent" state in the ID Tracker, or, if he
or she deems the changes are deemed to the revised document significant,
there may be a new WG last call. In that the latter case, the
document may go to the through a full IESG
for a re-check. Evaluation process again.

4. When Not to Use PROTO the Document Shepherding Process

As mentioned above, there in Section 3, the Document Shepherd SHOULD NOT be an
author of the shepherded document. If this cannot be avoided by
making another working group chair or secretary the Document

Falk, et al. Expires December 25, 2006 [Page 12]

Internet-Draft Document Shepherding to IESG Approval June 2006

Shepherd, the document shepherding process SHOULD NOT be used. There
are several other cases in which the PROTO document shepherding process
SHOULD NOT be used. These include include:

1. Those cases in which the WG chair primary document author or
editor, or Cases, where the WG chair Document Shepherd is the primary author or
editor of a large percentage of the documents produced by the
working group, group.

2. Those cases in which Cases, where the Responsible Area Director expects communication
difficulties with the WG chair Document Shepherd (either due to
experience, strong views stated by the chair, Document Shepherd, or
other issues),
and

Falk, et al. Expires September 6, 2006 [Page 12]

Internet-Draft Working Group Chair Document Shepherding March 2006 issues).

3. Those cases in which Cases, where the working group itself is either very old, losing
energy, or winding down. down, i.e., those cases in which cases, where it would not be
productive to initiate new processes or procedures.

Finally, note these guidelines are intended to help the Responsible
Area Director determine when to use that other cases exist in which using the PROTO process. document
shepherding process may not be productive. The final determination
as to whether to use the PROTO document shepherding process or not is left
to the Responsible Area Director's discretion. Director. If the document shepherding
process is not used, the Responsible Area Director acts as Document
Shepherd, just as he or she did in the past.

5. Security Considerations

This document specifies a change to IETF document flow processing
procedures. As such, it neither raises nor considers protocol-specific protocol-
specific security issues.

6. Acknowledgments 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
authors as well as Allison Mankin, Bill Fenner, Barbara Fuller, and Margaret
Wasserman.

7. IANA Considerations

This document creates no new requirements on IANA namespaces or other
IANA requirements.

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.

Falk, et al. Expires December 25, 2006 [Page 13]

Internet-Draft Document Shepherding to IESG Approval June 2006

Colin Perkins wrote the Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format included in Appendix B.1. David Black
wrote the Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel included in Appendix B.2.

8. Informative References

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

Falk, et al. Expires September 6, 2006 [Page 13]

Internet-Draft Working Group Chair Document Shepherding March 2006

[IDTRACKER]
"The IETF Draft Internet-Draft Tracker", Web
Application: https://datatracker.ie= tf.org/, https://datatracker.ietf.org/, 2002.

[PROTO] "The IESG Process PROcess and Tools TOols (PROTO) Team", Web
Page: http://psg.com/~mrw/PROTO-Tea= m, 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,
http://www.alvestrand.no/ietf/gen/review-guidelines.html,
2005.

Appendix A. Working documents Documents

(This section should be removed by the RFC editor before publication)
publication.)

The current working documents for this draft document are available at this
we= b
web site:

http://ietf.levkowetz.com/drafts/proto/wgchair-doc-shepherding/

http://tools.ietf.org/wg/proto/
draft-ietf-proto-wgchair-doc-shepherding/

Falk, et al. Expires December 25, 2006 [Page 14]

Internet-Draft Document Shepherding to IESG Approval June 2006

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

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

Magnus Westerlund and Colin Perkins jointly shepherded these
documents.

Falk, et al. Expires December 25, 2006 [Page 15]

Internet-Draft Document Shepherding to IESG Approval June 2006

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

The protocol has been reviewed for the IESG by David L. Black (WG
chair).

Also 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

Aaron Falk

Email: falk@isi.edu

Falk, et al. Expires September 6, December 25, 2006 [Page 14] 16]

Internet-Draft Working Group Chair Document Shepherding March to IESG Approval June 2006

Authors' Addresses

Aaron Falk

Email: falk@isi.edu

Henrik Levkowetz
Torsgatan 71
Stockholm S-113 37
SWEDEN
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 +1 541 346 1747
Email: dmm@1-4-5.net

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/

Allison Mankin

Email: mankin@psg.com

Falk, et al. Expires September 6, December 25, 2006 [Page 15] 17]

Internet-Draft Working Group Chair Document Shepherding March to IESG Approval June 2006

Full Copyright Statement

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 Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

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

Funding for the RFC Editor function is currently provided by the
Internet Society. IETF
Administrative Support Activity (IASA).

Falk, et al. Expires September 6, December 25, 2006 [Page 16] 18]

----