WDIFF

draft-ietf-proto-wgchair-doc-shepherding-01.txt --> draft-ietf-proto-wgchair-doc-shepherding-03.txt

Proto Team A. Falk
Internet-Draft H. Levkowetz
Internet-Draft
Expires: August 13, 2004 D. Meyer
Expires: January 17, 2005 A. Falk
July 19,
February 10, 2004

Workgroup

The PROTO Process: Working Group Chair Document Shepherding
<draft-ietf-proto-wgchair-doc-shepherding-01.txt>
draft-ietf-proto-wgchair-doc-shepherding-03

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with Section 6 of
RFC 3668.

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". progress."

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
http://www.ietf.org/shadow.html .
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 17, 2005. August 13, 2004.

Abstract

This

The methodologies described in this document describes a pilot implementation of have been designed to
facilitate a protocol change
within the IETF. The essence transition in IETF document flow processing. A set of
processes and procedures, known as the change is to have workgroup
chairs more involved PROTO process, are specified
in which a working group chair serves as the progress of the primary document after the
workgroup and
shepherd for a document editor have handed over which has been submitted to the document IESG for
publication. The activities involved in Note that this are: 1) providing a
writeup role has traditionally been filled by

Falk, et al. Expires August 13, 2004 [Page 1]

Internet-Draft Working Group Chair Document Shepherding February 2004

the AD responsible for the document, to accompany working group.

The shepherd's responsibilities include:

1. Providing the request for publication
which write-up accompanying a document that is sent forwarded
to the secretariat IESG for publication. Note that this write-up had
traditionally been provided by the "Shepherding Area Director".
Under the processes and procedures described here, the ADs (Area Directors); 2)
following working
group chair provides this write-up.

2. Following up on AD Evaluation comments on a draft to the authors and
workgroup; working
group, and 3) following

3. Following up on all IESG comments (DISCUSS comments as
well as other) on ("DISCUSSes") related to the
shepherded draft.

Levkowetz,

Falk, et al. Expires January 17, 2005 August 13, 2004 [Page 1] 2]

Internet-Draft Workgroup Working Group Chair Document Shepherding July February 2004

Table of Contents

1. Introduction

As part of the currently ongoing effort to improve the work flow
(particularly speed of approval) of documents, the PROTO team
[PROTO] is defining pilot projects to test possible protocol changes.
This document describes such a pilot.

The purpose of the pilot described here is to test offloading
follow-up work which an Area Director (AD) traditionally has done.
This includes both follow-up after the AD has read through and
evaluated a document submitted to the IESG for publication, and
follow-up on IESG comments (DISCUSS comments . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Process Description . . . . . . . . . . . . . . . . . . . . . 5
3.1 WG Chair Write-Up for Publication Request . . . . . . . . 5
3.2 AD Review Shepherding . . . . . . . . . . . . . . . . . . 7
3.3 IESG Discuss Shepherding . . . . . . . . . . . . . . . . . 9
4. When Not to Use PROTO . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
A. Working documents . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14

Falk, et al. Expires August 13, 2004 [Page 3]

Internet-Draft Working Group Chair Document Shepherding February 2004

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 others) quality. One such experiment, referred to as PROTO
[PROTO], is a set of methodologies designed to involve the working
group chairs more directly in their documents' approval life cycle.
In particular, the PROTO team focused on that part of the document's
life cycle which 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. It is hoped document that offloading 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 onto write-up.

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

3. Following up on all IESG comments ("DISCUSSes") related to the chair (or one
shepherded draft.

By the end of 2004, the IESG had evaluated the chairs) utility of the workgroup PROTO
methodologies based on data obtained though several pilot projects
which submitted had run throughout the draft will increase year, and subsequently decided to adopt
the speed PROTO process.

The primary objective of follow-up the PROTO process is to improve document
throughput and quality by enabling a partnership between the
Responsible Area Director and the transparency Shepherding Working Group Chair (or
her/his designee). In particular, this partnership has the explicit
goal of empowering the process, and
reduce Shepherding WG Chair while at the workload same time
offloading a specific part of the AD to boot. The pilot does not cover follow-up for drafts work which do not originate in a workgroup.

For a discussion had
traditionally been responsibility of the reasoning underlying piloting of process
changes, see [JULY14].

2. Pilot description

2.1 Participants

This pilot involves Responsible Area Directors of selected areas, and some or all
of Director.
As such, PROTO has been scoped to include both the chairs for which follow-up after
the Responsible Area Director is Area Advisor.

2.2 Running time has read through and pilot size

This pilot evaluated a
document submitted to the IESG for publication, as well as follow-up
on all IESG comments on a document (i.e., DISCUSSes). Finally, it is
important to be run note that PROTO does not less than 4 months, and cover follow-up for drafts
which do not more than 8
months, unless early experience shows it to be clearly detrimental.
It originate in a working group.

Falk, et al. Expires August 13, 2004 [Page 4]

Internet-Draft Working Group Chair Document Shepherding February 2004

The remainder of this document is expected that it will be started shortly after organised as follows: Section 3
outlines the IETF 60
meeting, and completed in time for overall PROTO process. Section 3.1 describes the results to be reported at
write-up which accompanies the
IETF 62 meeting. The pilot should be run with no fewer than 5
workgroups, up to publication request, Section 3.2
describes the number that ADs AD Review shepherding process, and WG Chairs feel mutually
they can support.

The running time Section 3.3
describes IESG Discuss Shepherding. Finally, Section 4 describes
those cases in which the PROTO process should not be chosen such that the participating ADs used.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
WG chairs have opportunity "OPTIONAL" in this
document are to get past the initial learning and
first-time execution barrier, be interpreted as described in BCP 14, RFC 2119
[RFC2119].

3. Process Description

The PROTO process involves Area Directors of selected areas, and get some familiarity with
or all of the
process before chairs for which the pilot Area Director is closed and evaluated.

3. Process Description Area Advisor.

The PROTO process changes described in this draft can be is divided into three tasks:

Levkowetz, et al. Expires January 17, 2005 [Page 2]
Internet-Draft Workgroup Chair Document Shepherding July 2004

o Doing a WG Chair Writeup Write-Up for a document, described in Section 3.1 document (Section 3.1),

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

o Following up on IESG DISCUSS comments, described in Section 3.3 comments (Section 3.3)

3.1 WG Chair Writeup Write-Up for Publication Request

When a draft is ready to be submitted for publication, it is the task
of the shepherding workgroup chair Shepherding WG Chair to do a document writeup write-up for the draft.

There are two parts to this task. First, the chairs need to answer Shepherding WG Chair
answers questions 1.a to 1.h below so that to give the responsible Responsible Area
Director can
get insight into the working group process as applied to this
draft.
These Note that while these questions may appear redundant in some cases but
cases, they are written to elicit any tidbits of information that the AD should must be
aware of.
(Pointers of (to this end, pointers to relevant entries in the WG archive
will be helpful.) helpful). The goal here is to inform the AD 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 taking this draft to IESG.
Don't be surprised if IESG
evaluation of the AD has further questions. shepherded draft. Any significant issues mentioned
in the questionnaire will probably lead to a
followup follow-up discussion
with the AD.

The second part of the task is to prepare the "Protocol Writeup" Write-Up"
which is dually used first as both for the ballot writeup write-up for the IESG telechat and then

Falk, et al. Expires August 13, 2004 [Page 5]

Internet-Draft Working Group Chair Document Shepherding February 2004

for the the IETF-wide protocol announcement. Item number 1.i
describes the elements of the writeup. For guidance for those who haven't done
this before, try looking at write-up. Please see other protocol
announcements (in in the IETF Announce archive) and expect some comments from the AD on the draft. archive for examples of such
write-ups.

1.a) Have the chairs personally reviewed this version of the ID Internet
Draft (ID), and in particular, do they believe this ID is sufficiently baked ready
to forward to the IESG for publication?

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have 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
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the

Levkowetz, et al. Expires January 17, 2005 [Page 3]
Internet-Draft Workgroup Chair Document Shepherding July 2004
document, or have concerns whether there really is a need for
it, etc. If
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the document anyway, note
if you continue to have concerns.
document, detail those concerns in the write-up.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about. the areas of conflict in
separate email to the Responsible Area Director.

1.g) Have the chairs verified that the document adheres to _all_ all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

1.h) Does Is the document a) split references into normative/
informative, normative and b) are informative references?
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state? (Note:
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup write-up section with the following
sections:

Falk, et al. Expires August 13, 2004 [Page 6]

Internet-Draft Working Group Chair Document Shepherding February 2004

* Technical Summary

* Working Group Summary

* Protocol Quality

1.j) Please provide such a writeup. (We will hopefully use it as is,
but may make some changes.) For recent examples, have a look at write-up. Recent examples can be found in
the "protocol action" announcements for approved documents.

1.k) Note:

* When doing the technical summary, one would expect that the The relevant information is for the technical summary can
frequently be found in the abstract and/or introduction of
the document. It turns out If not, this may be an indication that the step of producing
the writeup sometimes points out there
are deficiencies in the
introduction/abstract that are also worthy of rectifying. abstract or introduction.

* For the Working Group Summary, was Summary: Was there anything in WG
process that is worth noting? (E.g., For example, was there
controversy about particular points, decisions where
consensus was

Levkowetz, et al. Expires January 17, 2005 [Page 4]
Internet-Draft Workgroup Chair Document Shepherding July 2004 particularly rough, etc.) etc.

* For the protocol quality, useful information could include: includes:

+ is Are there existing implementations of the protocol already being implemented? protocol?

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

+ are Are there any reviewers (during the end stages) that merit explicit special mention as
having done a thorough review (i.e., that resulted in
important changes or a conclusion that the document was fine (except
had no substantive issues)?

The questionnaire and write-up is sent to the ADs and
iesg-secretary@ietf.org with a request to publish the document. The
questionnaire and write-up, minus any discussion of possible appeals,
is also sent to the working group mailing list. The publication
request SHOULD also indicate which chair will be shepherding the
document (this will be entered into the ID Tracker [IDTRACKER]). In
addition to making life easier for
maybe some nits?) the ADs, this lets the IETF chair
know where to send Gen-ART [GEN-ART] reviews.

3.2 AD Review Shepherding

The steps for workgroup working group chair shepherding of AD reviews are as
follows:

Falk, et al. Expires August 13, 2004 [Page 7]

Internet-Draft Working Group Chair Document Shepherding February 2004

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 can for instance MUST be done at the time before the
publication request is sent. It is
important sent, so that this is the information can be
included in the request, as mentioned above. This MUST be an
explicit agreement. agreement among the working group chairs.

2.b) The AD reads, evaluates and writes comments pretty much as
before. However, note that since on the communication between AD
and authors draft (as is not direct, the need for clear and
well-articulated review comments is somewhat larger.
case when not using PROTO).

2.c) Depending on the magnitude of the issues found (and other
considerations?), found, the AD returns
the full review to the chairs, and requests that either:

* that further workgroup Further editorial work must be undertaken to put done on the document into shape to before
it can be published published, or,

* that authors and workgroup are informed of ID Nits must be fixed before the issues found
and resolve them in a document before it can be
published, or

* A revised draft

* is is required to resolve issues that the authors fix nits as needed. have
been found in subsequent IESG review.

As covered below, the comments will be posted to the workgroup 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 the issues (and eventually
their

Levkowetz, et al. Expires January 17, 2005 [Page 5]
Internet-Draft Workgroup Chair Document Shepherding July 2004 resolution) in the issue tracker.

2.d) The chair responsible Shepherding WG Chair 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 workgroup.
working group. If there is some uncertainty as to what is
requested, this must be resolved with the Area Director.

2.e) The responsible chair Shepherding WG Chair sends the comments to the author(s) and
to the workgroup working group mailing list, in order to have a permanent
record of the comments. It is recommended that the chair
solicit from the author(s) an estimate on when the fixes will be done - i.e.,
done, that is, when the submission of a revised draft can be expected.

2.f) When incorporating the fixes in the new version of the draft, it
is strongly recommended RECOMMENDED that the revising editor keep a summary list showing how the issues were addressed
each issue by issue, was addressed and showing what the revised text is. If such a list
It is strongly RECOMMENDED that this list be forwarded to the AD
Responsible Area Director with the revised draft, it will make it possible for
the AD to verify the fixes very quickly. draft.

Falk, et al. Expires August 13, 2004 [Page 8]

Internet-Draft Working Group Chair Document Shepherding February 2004

2.g) The responsible chair follows-up, nudges and Shepherding WG Chair iterates until with the authors (and workgroup working
group if required) has fixed until the outstanding issues found, have been
resolved and submitted an updated draft. a revised draft has been submitted. At this point,
the AD is notified of the revised draft, 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 or has already previously considered and dismissed the
issue, the Shepherding WG Chair MUST resolve the issue and
previously ruled it out, this must be discussed and resolved with the
AD before the new version of the a revised draft is can be submitted.

2.h) The Area Director verifies that the issues he found during AD
Evaluation are resolved by the new version of the draft.

2.i) (Hopefully, that's it, but The shepherding process normally terminates at this point.
However, in the worst case this starts over at
1 again...) event that no resolution can be found, the
process goes to 1. above (i.e., essentially restarts).

3.3 IESG Discuss Shepherding

In this section we detail the steps that a shepherding Shepherding WG chair Chair will
take in resolving the DISCUSS items against a given ID. The steps
are given below, in the order that they are to be executed. Note
that occasionally DISCUSSes are 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 SHOULD meet
(either in person or electronically) to resolve the issue. In
addition, the Responsible Area Director SHOULD be notified of the
meeting. 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) Immediately after the weekly IESG conference call, the
shepherding
Shepherding WG chair Chair queries the ID tracker [IDTRACKER] to
collect any DISCUSS comments raised against the ID. In order to

Levkowetz, et al. Expires January 17, 2005 [Page 6]
Internet-Draft Workgroup Chair Document Shepherding July 2004
accomplish this, the shepherding Shepherding WG chair's Chair's email address must
be is
added to the "State Change Notice To:" field in the ID tracker.
This will result in an email to the shepherding Shepherding WG
chair Chair when
the document is moved changes state from the "IESG Evaluation" state to
one of the states requiring Shepherd actions: ("IESG actions (i.e., "IESG
Evaluation: Revised ID Needed", "IESG Evaluation: AD Followup").
This notification indicates to the the shepherding Shepherding WG chair Chair that
the DISCUSS comments have been registered.

Note that there may be exceptional cases when DISCUSS comments
are registered after the IESG teleconference. In these cases,
the DISCUSSing AD should notify the shepherding Shepherding WG chair Chair that

Falk, et al. Expires August 13, 2004 [Page 9]

Internet-Draft Working Group Chair Document Shepherding February 2004

new comments have been entered.

3.b) The shepherding Shepherding WG chair Chair analyses comments from the tracker, and
initialises contact with any AD's who have placed comments
(blocking or non-blocking) on a draft, notifying them the draft that is being
shepherded. In particular, the
shepherding Shepherding WG chair Chair MUST notify
the relevant ADs that the Shepherding WG Chair is the current
document shepherd and
seeking any additional clarification necessary to understand the
comment. shepherd. Note that the responsible AD must Responsible Area Director MUST
be copied on this correspondence.

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

3.c) The shepherding Shepherding WG chair Chair then coordinates DISCUSS comments, and
builds a a consistent interpretation of the comments. This step
may require iteration with step (2). above. That is:

+------+ Consistent +-------+
| (3.b)| ---------------> | (3.c) |
+------+ Interpretation +-------+
/|\ |
| | Further AD/shepherding AD/Shepherding WG
| | chair Discussion Required Chair discussion required
+--------------------------+

3.d) The DISCUSS comments are then communicated to the working group.

3.e) After the author(s) resolve the issues provided by the
shepherding
Shepherding WG chair Chair (i.e., the distilled summarised DISCUSS issues), the
shepherding
Shepherding WG chair Chair reviews the updated document to ensure that

Levkowetz, et al. Expires January 17, 2005 [Page 7]
Internet-Draft Workgroup Chair Document Shepherding July 2004
(in her/his option) the DISCUSS issues have been resolved.

Note that the shepherding Shepherding WG chair Chair may also propose resolutions
to these issues, file them in an issue tracker, or do other
steps to streamline the resolution of the comments.

3.f) The shepherding Shepherding WG chair Chair communicates the resolution-so-far to
the responsible AD and the DISCUSSing AD(s).

Falk, et al. Expires August 13, 2004 [Page 10]

Internet-Draft Working Group Chair Document Shepherding February 2004

3.g) DISCUSSing AD removes DISCUSS comment, or tells the shepherding
chair Shepherding
WG Chair and adds information to the I-D ID tracker about explaining why
the comment is not resolved. The shepherd Shepherding WG Chair informs
the workgroup working group accordingly.

If the DISCUSS comment in question was not resolved to the
satisfaction of the DISCUSSing AD(s) and responsible ADs, Responsible Area
Director, two possibilities exist:

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

(b) If no progress can be made on the resolution of the DISCUSS
with the DISCUSSING AD, despite clarification and
additional involvement of the Responsible AD, Area Director,
the
shepherding Shepherding WG chair Chair and the WG might at last resort
consider an appeal in accordance with the procedures
described in RFC 2026 [RFC2026] and referred to in RFC 2418
[RFC2418].

Otherwise, the process continues with step (3.h).

3.h) The responsible AD moves document to APPROVED state, or if the
changes are deemed significant, there is a short new WG last
call, and then the document goes to the IESG for re-review.

4. Wrap-up

At the end of the pilot lifetime, it is expected that an evaluation
of the experienced benefits is made, using input solicited from the
participating Area Directors and Workgroup Chairs by means of an
email questionnaire, web-page form or something similar. The
questions are given below, in Section 4.2. A per-review
questionnaire is also provided in Section 4.1.

4.1 Questionnaire to be done after each individual AD Review

To be done by both WG Chair and AD.

Levkowetz, et al. Expires January 17, 2005 [Page 8]
Internet-Draft Workgroup Chair Document Shepherding July 2004

R1. I'm submitting this questionnaire as
1. the process continues with step (3.h).

3.h) The Responsible Area Director
2. Workgroup Chair

R2. Document name:

R3. moves document to APPROVED state,
or if the changes are deemed significant, there may be a new WG Chair shepherding of this draft speeded up
last call. Finally, the procedure:
1. Strongly disagree
2. Disagree
3. Undecided document goes to the full IESG for
re-review.

4. Agree
5. Strongly agree

R4. WG Chair shepherding of this draft resulted When Not to Use PROTO

As mentioned above, there are several cases in which the comments
being resolved in a satisfactory manner: PROTO
process SHOULD NOT be used. These include

1. Strongly disagree
2. Disagree
3. Undecided
4. Agree
5. Strongly agree

R5. WG Chair shepherding of this draft resulted Those cases in a more
transparent process:
1. Strongly disagree
2. Disagree
3. Undecided
4. Agree
5. Strongly agree

R6. which the WG Chair shepherding chair primary document author or
editor, or the WG chair is the primary author or editor of this draft resulted in a more
well-documented process:
1. Strongly disagree
2. Disagree
3. Undecided
4. Agree
5. Strongly agree

R7. The interaction with
large percentage of the document editors in resolving documents produced by the
comments worked out well:
1. Strongly disagree working group,

2. Disagree
3. Undecided
4. Agree
5. Strongly agree

Levkowetz, et al. Expires January 17, 2005 [Page 9]
Internet-Draft Workgroup Chair Document Shepherding July 2004

R8. - Public Comments?

R9. - Comments to IESG and PROTO-Team only?

R10. Those cases in which the Responsible Area Director expects
communication difficulties with the WG Chair shepherding of this draft worked out well, overall:
1. Strongly disagree
2. Disagree
3. Undecided
4. Agree
5. Strongly agree

R11. - Public Comments?

R12. - Comments chair (either due to IESG
experience, strong views stated by the chair, or other issues),
and PROTO-Team only?

4.2 Questionnaire for

3. Those cases in which the Pilot as a Whole

To working group itself is either very old,
losing energy, or winding down. i.e., those cases in which it
would not be done by both WG Chair and AD.

X1. I'm submitting this questionnaire as
1. productive to initiate new processes or procedures.

Finally, note these guidelines are intended to help the Responsible
Area Director
2. Workgroup Chair

X2. I clearly understood what was expected of me in this pilot.
1. Strongly disagree
2. Disagree
3. Undecided
4. Agree
5. Strongly agree

Comments?

X3. What is your evaluation of determine when to use the benefit of PROTO process. The final
determination as to whether to use the procedure you've
tried out in this pilot?
1. Definitely harmful
2. Somewhat harmful
3. Mixed feelings
4. Somewhat beneficial
5. Definitely beneficial

Comments?

Levkowetz, PROTO process or not is left

Falk, et al. Expires January 17, 2005 August 13, 2004 [Page 10] 11]

Internet-Draft Workgroup Working Group Chair Document Shepherding July February 2004

X4. What is your evaluation of the added effort required for the
procedure you've tried out in this pilot?
1. Major increased effort
2. Somewhat increased
3. No change
4. Somewhat decreased effort
5. Major decreased effort

Comments?

X5. Considering all factors, this procedure should be made the
normal way of handling documents.
1. Strongly disagree
2. Disagree
3. Undecided
4. Agree
5. Strongly agree

Comments?

X6. What do you consider to be the major advantages of this
procedure change?

X7. What do you consider

to be the major disadvantages of this
procedure change?

X8. How would you change the procedure to minimise the
disadvantages?

X9. Comments to the IESG and PROTO-Team only: Responsible Area Director's discretion.

5. Security Considerations

This document specifies a pilot implementation of a change in to IETF document flow procedures. It does not raise or consider any
As such, it neither raises nor considers protocol-specific security
issues. When evaluating the result of the pilot, the IESG
should check if the changes has reduced the quality of security
review and consideration for protocols, and take this into
consideration when deciding whether the changes should be made
permanent.

6. Acknowledgments

The content of this

This document is based on contributions from the whole product of PROTO team, not only the named authors; specifically : Aaron Falk, which includes authors as
well as Allison Mankin, Bill Fenner, Barbara Fuller, and Margaret
Wasserman.
Thanks are due to all for the PROTO team work of which this

7. IANA Considerations

This document

Levkowetz, et al. Expires January 17, 2005 [Page 11]
Internet-Draft Workgroup Chair Document Shepherding July 2004

is a result.

7 creates no new requirements on IANA namespaces or other
IANA requirements.

8. Informative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.

[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, 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.

[JULY14] Klensin, J. and S. Dawkins, "A model for IETF Process
Experiments", draft-klensin-process-july14-02 (work in
progress), April 2004.

[SIRS] Carpenter, B. and D. Crocker, "Careful Additional Review
of Documents (CARD)by Senior IETF Reviewers (SIRS)",
draft-carpenter-solution-sirs-01 (work in progress), June
2003.

[IDTRACKER]
"The IETF Draft Tracker", Web
Application:
https://datatracker.ietf.org/. https://datatracker.ietf.org/, 2004.

[PROTO] "The IESG Process and Tools (PROTO) Team", Web
Page:
http://psg.com/~mrw/PROTO-Team. 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, 2004.

Falk, et al. Expires August 13, 2004 [Page 12]

Internet-Draft Working Group Chair Document Shepherding February 2004

Authors' Addresses

Aaron Falk

Email: falk@isi.edu

Henrik Levkowetz
Torsgatan 71
Stockholm S-113 37
SWEDEN

Phone: +46 708 32 16 08
EMail:
Email: henrik@levkowetz.com

David Meyer

EMail:
1225 Kincaid St
Eugene, OR 97403
USA

Phone: +1.541.346.1747
Email: dmm@1-4-5.net

Levkowetz, et al. Expires January 17, 2005 [Page 12]
Internet-Draft Workgroup Chair Document Shepherding July 2004

Aaron Falk

EMail: falk@isi.edu

Appendix A. Working documents

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

The current working documents for this draft are available at this
web site:

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

Levkowetz,

Falk, et al. Expires January 17, 2005 August 13, 2004 [Page 13]

Internet-Draft Workgroup Working Group Chair Document Shepherding July February 2004

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

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 (C) The Internet Society (2004). 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.

Levkowetz,

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Falk, et al. Expires January 17, 2005 August 13, 2004 [Page 14]

----