< draft-leiba-extended-doc-shepherd-01.txt   draft-leiba-extended-doc-shepherd-02.txt >
Network Working Group B. Leiba Network Working Group B. Leiba
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational November 4, 2012 Updates: 4858 (if approved) July 10, 2013
Expires: May 8, 2013 Intended status: Informational
Expires: January 09, 2014
Document Shepherding Throughout a Document's Lifecycle Process Experiment: Document Shepherding Throughout a Document's
draft-leiba-extended-doc-shepherd-01 Lifecycle
draft-leiba-extended-doc-shepherd-02
Abstract Abstract
RFC 4858 talks about "Document Shepherding from Working Group Last RFC 4858 talks about "Document Shepherding from Working Group Last
Call to Publication". There's a significant part of a document's Call to Publication". There's a significant part of a document's
life that happens before working group last call, starting, really, life that happens before working group last call, starting, really,
at the time a working group begins discussing a version of the idea at the time a working group begins discussing a version of the idea
that's been posted as an individual draft. It seems reasonable and that's been posted as an individual draft. It seems reasonable and
helpful to begin shepherding when there's a call for adoption as a helpful in many situations to begin shepherding when there's a call
working group document, and this document gives one Area Director's for adoption as a working group document. This document extends RFC
view of how that extended shepherding function might work, and what 4858, describing how that extended shepherding function might work
tasks might be involved throughout the document's lifecycle. and what tasks might be involved throughout the document's lifecycle,
and suggesting how Working Group Chairs might choose to implement
extended shepherding.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on May 8, 2013. This Internet-Draft will expire on January 09, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
2. The Document Shepherd as a "Function" . . . . . . . . . . . . 3
2. The Document Shepherd as a "Function" . . . . . . . . . . . 5 3. Stages in a Document's Lifecycle . . . . . . . . . . . . . . . 4
3.1. Stage: Call for Adoption . . . . . . . . . . . . . . . . . . 5
3. Stages in a Document's Lifecycle . . . . . . . . . . . . . . 6 3.2. Stage: Working Group Document . . . . . . . . . . . . . . . 7
3.1. Stage: Call for Adoption . . . . . . . . . . . . . . . . . . 6 3.3. Stage: Working Group Last Call . . . . . . . . . . . . . . . 9
3.2. Stage: Working Group Document . . . . . . . . . . . . . . . 8 3.4. Stage: Shepherd Writeup Underway . . . . . . . . . . . . . . 10
3.3. Stage: Working Group Last Call . . . . . . . . . . . . . . . 10 3.5. Stage: AD Review . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Stage: Shepherd Writeup Underway . . . . . . . . . . . . . . 11 3.6. Stage: IETF Last Call . . . . . . . . . . . . . . . . . . . 12
3.5. Stage: AD Review . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Stage: Waiting for AD Go-Ahead . . . . . . . . . . . . . . . 14
3.6. Stage: IETF Last Call . . . . . . . . . . . . . . . . . . . 14 3.8. Stage: IESG Evaluation . . . . . . . . . . . . . . . . . . . 14
3.7. Stage: Waiting for AD Go-Ahead . . . . . . . . . . . . . . . 15 3.9. Stage: Approved by the IESG . . . . . . . . . . . . . . . . 16
3.8. Stage: IESG Evaluation . . . . . . . . . . . . . . . . . . . 15 3.10. Stage: In RFC Editor Queue . . . . . . . . . . . . . . . . . 16
3.9. Stage: Approved by the IESG . . . . . . . . . . . . . . . . 17 3.11. Stage: AUTH48 . . . . . . . . . . . . . . . . . . . . . . . 17
3.10. Stage: In RFC Editor Queue . . . . . . . . . . . . . . . . . 17 3.12. Stage: Published . . . . . . . . . . . . . . . . . . . . . . 18
3.11. Stage: AUTH48 . . . . . . . . . . . . . . . . . . . . . . . 18 4. Some Final Notes . . . . . . . . . . . . . . . . . . . . . . . 18
3.12. Stage: Published . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
4. Some Final Notes . . . . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . 21 7.2. Informative References . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
RFC 4858 talks about "Document Shepherding from Working Group Last RFC 4858 talks about "Document Shepherding from Working Group Last
Call to Publication" [RFC4858]. There's a significant part of a Call to Publication" [RFC4858]. There's a significant part of a
document's life that happens before Working Group Last Call, document's life that happens before Working Group Last Call,
starting, really, at the time a working group begins discussing a starting, really, at the time a working group begins discussing a
version of the idea that's been posted as an individual draft. It version of the idea that's been posted as an individual draft. It
seems reasonable and helpful to begin shepherding at the time there's seems reasonable and helpful in many situations to begin shepherding
a call for adoption as a working group document, and this document when there's a call for adoption as a working group document. This
gives one Area Director's view of how that extended shepherding document extends RFC 4858, describing how that extended shepherding
function might work, and what tasks might be involved throughout the function might work and what tasks might be involved throughout the
document's lifecycle. document's lifecycle, and suggesting how Working Group Chairs might
choose to implement extended shepherding.
It has been very common to see documents -- including some that I It is very common to see documents progress far too slowly, sometimes
have authored, and some for which I have been the Responsible Chair languishing for many months and even for years due to neglect.
-- progress far too slowly, sometimes languishing for many months and Sometimes a working group will intentionally set a document aside,
even for years due to neglect. Sometimes a working group will put it on a back burner while it works on more pressing things. But
intentionally set a document aside, put it on a back burner while it it's often not intentional: the document sits around because of lack
works on more pressing things. But it's often *not* intentional, and of follow-through, waking up occasionally when someone realizes that
the document sits around because of lack of follow-through, waking up the last version has expired and an IETF meeting is coming up soon.
occasionally when someone realizes that the last version has expired
and an IETF meeting is coming up soon.
We would really prefer to process documents efficiently, ensuring We would really prefer to process documents efficiently, ensuring
that whatever happens is intentional: that documents are set aside that whatever happens is intentional: that documents are set aside
only when it makes sense to do so, and that active documents move only when it makes sense to do so, and that active documents move
forward in the process, with someone assigned to make sure that forward in the process, with someone responsible for making sure that
happens. happens.
This document suggests specific tasks a Working Group Chair should be This document suggests specific tasks a Working Group Chair should be
doing or delegating in order to maintain forward progress, doing or delegating in order to maintain forward progress,
accountability, and quality control on a working group document. It accountability, and quality control on a working group document. It
adds to what's in RFC 4858, intending to extend it, not replace it. adds to what's in RFC 4858, intending to extend it, not replace it.
Major extensions involve assigning a Shepherd and defining specific Major extensions involve assigning a Shepherd and defining specific
tasks earlier in a document's life, and possibly delegating Document tasks earlier in a document's life, and possibly delegating Document
Shepherd tasks to a Shepherd who is neither a Chair nor the Working Shepherd tasks to a Shepherd who is neither a Chair nor the Working
Group Secretary (consistent with the IESG Statement on Document Group Secretary (consistent with the IESG Statement on Document
Shepherds [Stmt]). Shepherds [Stmt]).
By providing summaries in each section of the tasks expected at that The summaries in each section of the tasks expected at that stage in
stage in the document's lifecycle, I hope to make this an easy the document's lifecycle can make this an easy reference and
reference and checklist for Working Group Chairs and Document checklist for Working Group Chairs and Document Shepherds.
Shepherds.
I also want to stress that the specific mechanism suggested here will The specific mechanism suggested here will not be suitable for all
not be suitable for all working groups, all management models, and working groups, all management models, and all situations. While
all situations. While I think that it's still a good idea to have it's a good idea to have the stages laid out and the tasks at each
the stages laid out and the tasks at each stage identified, not all stage identified, not all working groups will benefit from having a
working groups will benefit from having a single document shepherd single document shepherd designated at the start. Indeed, when a
designated at the start. Indeed, when a document is legitimately document is legitimately years in the making, personnel may come and
years in the making, personnel may come and go and changes will be go and changes will be necessary. A particular working group might
necessary. A particular working group might be working only on one be working only on one document at a time, with all tasks shared
document at a time, with all tasks shared between the chairs. between the chairs.
For these and other reasons, the suggestions herein are meant to be For these and other reasons, the suggestions herein are meant to be
adapted to specific situations to retain the underlying objective of adapted to specific situations to retain the underlying objective of
maintaining progress through active involvement. maintaining progress through active involvement.
1.1. Notational Conventions 1.1. Notational Conventions
Because this document is specifically one individual's thoughts on It is important to note that this document makes no formal process
this matter, it's worth pointing out that the document makes no changes and there is no normative language here.
process changes and there is no normative language here.
I use Initial Capitals in some terms, such as "Document Shepherd", to Initial Capitals are used in some terms, such as "Document Shepherd",
indicate that those terms represent formal roles in the management to indicate that those terms represent specific roles in the
model I'm describing. management model that is described.
2. The Document Shepherd as a "Function" 2. The Document Shepherd as a "Function"
This document looks at the Document Shepherd as a "function", rather This document looks at the Document Shepherd as a "function", rather
than as a single person. The Document Shepherd Function has a set of than as a single person. The Document Shepherd Function has a set of
tasks that need to be performed, but the tasks do not all have to be tasks that need to be performed, but the tasks do not all have to be
performed by one individual. performed by one individual.
While, ultimately, it is the responsibility of the Working Group While, ultimately, it is the responsibility of the Working Group
Chairs to ensure that the shepherding tasks get done, the Chairs do Chairs to ensure that the shepherding tasks get done, the Chairs do
not have to do all those tasks by themselves. From Section 6.1 of not have to do all those tasks by themselves. From Section 6.1 of
the Working Group Guidelines and Procedures [RFC2418]: the Working Group Guidelines and Procedures [RFC2418]:
skipping to change at page 5, line 33 skipping to change at page 4, line 30
This document proposes an extended set of Document Shepherd tasks, This document proposes an extended set of Document Shepherd tasks,
well beyond those covered in RFC 4858. In many cases it will be well beyond those covered in RFC 4858. In many cases it will be
reasonable to assign the entire Document Shepherd Function to one reasonable to assign the entire Document Shepherd Function to one
person (to a Chair or to a non-chair delegate), but in many other person (to a Chair or to a non-chair delegate), but in many other
cases the Chairs will likely choose to delegate parts of that cases the Chairs will likely choose to delegate parts of that
function and keep other parts for themselves. In any case, the function and keep other parts for themselves. In any case, the
Chairs remain responsible for the management of the working group; Chairs remain responsible for the management of the working group;
they are whom the Area Director will come to if something goes wrong they are whom the Area Director will come to if something goes wrong
or things fail to make progress. or things fail to make progress.
As I talk, then, about what the "Document Shepherd" does, understand As we talk, then, about what the "Document Shepherd" does, understand
that the individual doing each particular task will be the one that the individual doing each particular task will be the one
assigned that task as the work on a particular document is laid out. assigned that task as the work on a particular document is laid out.
When I say that the Shepherd should do a task in consultation with When we say that the Shepherd should do a task in consultation with
the Chairs, that's automatically true when it's already a Chair who's the Chairs, that's automatically true when it's already a Chair who's
doing it. doing it.
And this bears repeating, so I will say it more than once here: And this bears repeating: Nothing in this document is suggesting that
Nothing in this document is suggesting that the Working Group Chairs the Working Group Chairs abdicate any responsibility. They have the
abdicate any responsibility. They have the final responsibility for final responsibility for managing each document's progress and for
managing each document's progress and for managing the working group managing the working group in general. Any Chair who chooses to
in general. Any Chair who chooses to delegate some of this delegate some of this responsibility must still ensure that it's
responsibility must still ensure that it's carried out properly. And carried out properly. And any Chair who does not feel comfortable
any Chair who does not feel comfortable delegating any of this should delegating any of this should not do so.
not do so.
3. Stages in a Document's Lifecycle 3. Stages in a Document's Lifecycle
From the time a working group is asked to take on a document as one From the time a working group is asked to take on a document as one
of its work items, the document will go through a number of stages: of its work items, the document will go through a number of stages:
1. Call for Adoption 1. Call for Adoption
2. Working Group Document 2. Working Group Document
3. Working Group Last Call 3. Working Group Last Call
4. Shepherd Writeup Underway 4. Shepherd Writeup Underway
5. AD Review 5. AD Review
6. IETF Last Call 6. IETF Last Call
7. Waiting for AD Go-Ahead 7. Waiting for AD Go-Ahead
8. IESG Evaluation 8. IESG Evaluation
9. Approved by the IESG 9. Approved by the IESG
10. In RFC Editor Queue 10. In RFC Editor Queue
11. AUTH48 11. AUTH48
12. Published 12. Published
Through most of those stages steps will have to be taken, tasks will Through most of those stages steps will have to be taken, tasks will
need to be performed, to make sure the document moves forward, that need to be performed, to make sure the document moves forward, that
consensus is reached, that the right reviews are done, that updates consensus is reached, that the right reviews are done, that updates
are made, that consensus still holds after significant changes, and are made, that consensus still holds after significant changes, and
so on. That set of tasks comprises the Document Shepherd Function. so on. The Document Shepherd Function comprises that set of tasks.
The following sections will discuss some of the tasks needed at each The following sections will discuss some of the tasks needed at each
stage, and will suggest how Working Group Chairs might handle those stage, and will suggest how Working Group Chairs might handle those
tasks and their delegation -- how the Document Shepherd Function tasks and their delegation -- how the Document Shepherd Function
might work. The details will vary, depending upon how each working might work. The details will vary, depending upon how each working
group is managed, but what follows should be a good example, and will group is managed, but what follows should be a good example, and will
provide a basis for adaptation. And see also Section 3 of [RFC4858]. provide a basis for adaptation. And see also [RFC4858], Section 3.
3.1. Stage: Call for Adoption 3.1. Stage: Call for Adoption
At the point that the working group begins considering adoption of a At the point that the working group begins considering adoption of a
document, the Working Group Chairs have some decisions to make. This document, the Working Group Chairs have some decisions to make. This
is the time to choose a Responsible Chair for the document, much as is the time to choose a Responsible Chair for the document, much as
it will eventually have a Responsible Area Director later in its it will eventually have a Responsible Area Director later in its
life. The Responsible Chair will be the one who oversees the life. The Responsible Chair will be the one who oversees the
Document Shepherd Function and has primary responsibility for making Document Shepherd Function and has primary responsibility for making
sure that everything gets done. sure that everything gets done.
skipping to change at page 7, line 34 skipping to change at page 6, line 22
to the Responsible Chair, and will be supervised at certain key to the Responsible Chair, and will be supervised at certain key
points. points.
o The Responsible Chair will appoint a non-chair Shepherd to handle o The Responsible Chair will appoint a non-chair Shepherd to handle
all shepherding tasks autonomously (perhaps for a very experienced all shepherding tasks autonomously (perhaps for a very experienced
Shepherd, well trusted by the Chairs). Shepherd, well trusted by the Chairs).
And so on... there may be many combinations, many levels of And so on... there may be many combinations, many levels of
supervision vs autonomy, many ways to divide the work. It's also supervision vs autonomy, many ways to divide the work. It's also
possible to delegate to more than one non-chair Shepherd at different possible to delegate to more than one non-chair Shepherd at different
stages, though I don't think that's a good idea -- the continuity and stages. The Chairs need to judge the extent to which continuity and
centralized responsibility of making it one other person (supervised centralized responsibility are important for the document in question
by one Responsible Chair) seems best. and the management style of the chairs, and whether making it one
other person (supervised by one Responsible Chair) is best.
Some Chairs may prefer to handle all tasks themselves, because, after Some Chairs may prefer to handle all tasks themselves, because, after
all, they remain responsible for their successful completion. Yet all, they remain responsible for their successful completion. Yet
there's a lot to be gained by delegating much of the work. there can be a lot gained by delegating much of the work. Delegating
Delegating work and giving a degree of responsibility to relatively work and giving a degree of responsibility to relatively more junior
more junior participants gets people more closely engaged with the participants gets people more closely engaged with the working group
working group and with the IETF. Giving significant responsibility and with the IETF. Giving significant responsibility can be an
can be an excellent training exercise, preparing participants to take excellent training exercise, preparing participants to take on future
on future roles as Working Group Chairs. And in a busy working roles as Working Group Chairs. And in a busy working group,
group, offloading work from the Chairs to senior, experienced people offloading work from the Chairs to senior, experienced people can
(perhaps former Chairs or former ADs) can prevent the Chairs from prevent the Chairs from being overcommitted, enabling the work to
being overcommitted, enabling the work to move forward much more move forward much more efficiently.
efficiently.
And, of course, a non-chair Shepherd can and should consult with the And, of course, a non-chair Shepherd can and should consult with the
Responsible Chair whenever she feels the need, and certainly whenever Responsible Chair whenever she feels the need, and certainly whenever
issues arise of which the Chairs should be aware, or about which the issues arise of which the Chairs should be aware, or about which the
Shepherd needs advice or other help. Shepherd needs advice or other help.
Once it is determined who will handle the Document Shepherd tasks, Once it is determined who will handle the Document Shepherd tasks,
the Shepherd needs to do the actual adoption process. The details the Shepherd needs to do the actual adoption process. The details
will vary based on how the particular working group is run, but a will vary based on how the particular working group is run, but a
typical process will start with posting a call for adoption to the typical process will start with posting a call for adoption to the
working group mailing list, pointing to the individual draft that's working group mailing list, pointing to the individual draft that's
being considered. There'll be a comment period for adoption being considered. There'll be a comment period for adoption
discussion, after which the Shepherd will, based on working group discussion, after which the Shepherd will, based on working group
discussion make a judgment and announce the result to the list. discussion, give a recommended judgment to the Chairs.
Assuming that the document was adopted, the Chairs will appoint one Assuming that the document was adopted, the Chairs will appoint one
or more Editors for the working group version of the document (these or more Editors for the working group version of the document (these
are often, but not always, the same people who wrote the individual are often, but not always, the same people who wrote the individual
version, and the Chairs should put some thought into who the right version, and the Chairs should put some thought into who the right
Editors should be), and will handle the datatracker updates (for Editors should be), and will handle the datatracker updates (for
which Chair access is required). The Chairs should not forget to which Chair access is required). The Chairs should not forget to
record the name and email address of the Document Shepherd in the record the name and email address of the Document Shepherd in the
tracker -- this will ensure that the Shepherd is copied on necessary tracker -- this will ensure that the Shepherd is copied on necessary
email later. email later.
In summary, the tasks at the Call for Adoption stage might be as In summary, the tasks at the Call for Adoption stage might be as
follows: follows:
1. Chairs: Select a Responsible Chair to handle the document. 1. Chairs: Select a Responsible Chair to handle the document.
2. Responsible Chair: Decide on a work/delegation plan. 2. Responsible Chair: Decide on a work/delegation plan.
3. Responsible Chair: Possibly appoint a non-chair Shepherd; else 3. Responsible Chair: Possibly appoint a non-chair Shepherd; else
the Responsible Chair becomes the Shepherd. the Responsible Chair becomes the Shepherd.
4. Shepherd: Make the call for adoption; set deadlines and schedule. 4. Shepherd: Make the call for adoption; set deadlines and schedule.
5. Shepherd: Announce the result; Chairs: appoint Document Editor(s) 5. Shepherd: Communicate the result to the Chairs;
for the WG document. 6. Chairs: Announce the result and appoint Document Editor(s) for
6. Chairs: Update the datatracker; approve -00 version submission. the WG document.
7. Chairs: Update the datatracker; approve -00 version submission.
3.2. Stage: Working Group Document 3.2. Stage: Working Group Document
Once a -00 version is posted, the Shepherd's primary task is to keep Once a -00 version is posted, the Shepherd's primary task is to keep
the document moving forward: keeping discussion going, making sure the document moving forward: keeping discussion going, making sure
issues are tracked and document updates are posted, and helping issues are tracked and document updates are posted, and helping
things toward consensus. Let's not downplay the importance of active things toward consensus. Let's not downplay the importance of active
management here: this is where things so often fall short, what management here: this is where things so often fall short, what
causes documents to take *years* to complete. The Shepherd should causes documents to take *years* to complete. The Shepherd should
not rush discussions that are useful, but the Shepherd should make not rush discussions that are useful, but the Shepherd should make
sure that things don't get lost in the forest either. sure that things don't get lost in the forest either.
The Chairs will decide how the working group should be managed, and The Chairs will decide how the working group should be managed, and
any non-chair Shepherd should be working with the Chairs at this any non-chair Shepherd should be working with the Chairs at this
stage, communicating any difficulties and getting help with issue stage, communicating any difficulties and getting help with issue
resolution when needed. Tools such as the issue tracker and the resolution when needed. Tools such as the issue tracker and the
working group wiki, which are available to every working group, may working group wiki, which are available to every working group, may
be helpful here -- particularly if many issues come up, if issues are be helpful here -- particularly if many issues come up, if issues are
often taking a long time to be resolved, or if the same issues tend often taking a long time to be resolved, or if the same issues tend
to come up repeatedly. The issue tracker can be used to record not to come up repeatedly.
just the issues themselves, but significant parts of the discussion
on both sides, helping to make it clearer what the resolution was and The issue tracker can be used to record not just the issues
why, and whether a particular request to re-open a closed issue themselves, but significant parts of the discussion on both sides,
really involves new points or is just a re-hash. helping to make it clearer what the resolution was and why, and
whether a particular request to re-open a closed issue really
involves new points or is just a re-hash. This is also a good time
to record implementation and interoperability information in the
working group wiki, along with any other information that will be
helpful to the community and the IESG when the document comes out of
the working group.
Discussions need to be steered, with a goal of avoiding unproductive, Discussions need to be steered, with a goal of avoiding unproductive,
circular discussions, re-hashing of old arguments, and tangential circular discussions, re-hashing of old arguments, and tangential
discussions that go "off into the weeds". Discussions also often discussions that go "off into the weeds". Discussions also often
need to be prodded. Lulls can be fine, but when it looks like need to be prodded. Lulls can be fine, but when it looks like
nothing is happening for a while, remind the participants of open nothing is happening for a while, remind the participants of open
issues, ask for reviews of updated document versions or of recent issues, ask for reviews of updated document versions or of recent
changes that don't seem to have been discussed. It's often useful to changes that don't seem to have been discussed. It's often useful to
make specific requests of participants off list. The goal here is to make specific requests of participants off list, not just relying on
sending "please review" messages to the list. The goal here is to
ensure that rough consensus is reached on the document, covering as ensure that rough consensus is reached on the document, covering as
much of the document as possible, and certainly covering the key much of the document as possible, and certainly covering the key
points. points.
Document Editors need to be prodded as well. We're all volunteers, Document Editors need to be prodded as well. We're all volunteers,
and many of us are working on a lot of things. A particular document and many of us are working on a lot of things. A particular document
can fall off to the side for a long while. It's best to avoid the can fall off to the side for a long while. It's best to avoid the
trap of getting updates only before each IETF meeting, just in time trap of getting updates only before each IETF meeting, just in time
to beat the submission cutoff. If updates aren't posted fairly to beat the submission cutoff. If updates aren't posted fairly
promptly after a set of issues is resolved, ask the Editors when promptly after a set of issues is resolved, ask the Editors when
they'll be able to get changes rolled into a new document version. they'll be able to get changes rolled into a new document version.
Check that the Editors are following working group consensus as they Check that the Editors are following working group consensus as they
make their updates. make their updates.
Even with plenty of prodding and reminding and steering, it happens Even with plenty of prodding and reminding and steering, it sometimes
that a document simply can't be finished and abandoning it needs to happens that a document simply can't be finished and abandoning it
be considered. Perhaps there's no longer the interest there was at needs to be considered. Perhaps there's no longer the interest there
adoption. Perhaps the document has been overtaken by other events. was at adoption. Perhaps the document has been overtaken by other
Or perhaps there's too much controversy over it, and rough consensus events. Or perhaps there's too much controversy over it, and rough
just isn't going to happen. The Shepherd should consult with the consensus just isn't going to happen. The Shepherd should consult
Chairs to decide whether the working group should stop work on the with the Chairs to decide whether the working group should stop work
document. on the document.
The Shepherd will know when the document is moving from this stage The Shepherd will know when the document is moving from this stage
into the next, and when she needs to shift the focus into preparation into the next, and when she needs to shift the focus into preparation
for last call and for getting the document to the AD. for last call and for getting the document to the AD.
In summary, the tasks for the Shepherd at the Working Group Document In summary, the tasks for the Shepherd at the Working Group Document
stage might be as follows: stage might be as follows:
1. Work with the Chairs to understand the desired mechanism for 1. Work with the Chairs to understand the desired mechanism for
managing discussions. managing discussions.
2. Watch the discussions as they unfold; call out and record 2. Watch the discussions as they unfold; call out and record
specific issues that come up. specific issues that come up.
3. Steer the discussion when necessary. 3. Steer the discussion when necessary.
4. Prod the discussions when necessary. 4. Prod the discussions when necessary.
5. Prod the Document Editors when necessary. 5. Prod the Document Editors when necessary.
6. Use appropriate tools, such as issue trackers and wikis. 6. Use appropriate tools, such as issue trackers and wikis.
7. Determine when it's time to start wrapping things up and moving 7. Determine when it's time to start wrapping things up and moving
to Working Group Last Call. to Working Group Last Call, and advise the chairs.
8. Alternatively, determine that it's not possible to move the 8. Alternatively, determine that it's not possible to move the
document forward, and the Chairs need to consider abandoning it. document forward, and the Chairs need to consider abandoning it.
3.3. Stage: Working Group Last Call 3.3. Stage: Working Group Last Call
When any contentious issues have been resolved and the document has When any contentious issues have been resolved and the document has
had a good level of review, the Shepherd should start looking at when had a good level of review, the Shepherd should start looking at when
it's time to wrap things up, have a last call within the working it's time to wrap things up, have a last call within the working
group, and get the document ready to send to the Responsible AD. group, and get the document ready to send to the Responsible AD.
What needs to be done now is largely the same as in the Working Group What needs to be done now is largely the same as in the Working Group
Document stage, but with a particular aim of getting remaining issues Document stage, but with a particular aim of getting remaining issues
closed and making sure that discussions are tightly focused. Where closed and making sure that discussions are tightly focused. Where
veering off to explore things that might be added to the document was veering off to explore things that might be added to the document was
a fine thing to do in the earlier stages, this is the time to say a fine thing to do in the earlier stages, this is the time to say
that the document is "feature complete", and to keep discussions that the document is "feature complete", and to keep discussions
reined in. reined in.
Working Group Last Call is a recommended step, though not a required Working Group Last Call is a recommended step, though not a required
one, and most working groups do issue a formal "last call" before one (it is not part of the formal process), and most working groups
sending the document to the Responsible AD. The Shepherd can take do issue a formal "last call" before sending the document to the
the responsibility of issuing that message and of analyzing comments Responsible AD. The Shepherd, in consultation with the chairs, can
to determine whether things are ready to go ahead. take the responsibility of issuing that message and of analyzing
comments to determine whether things are ready to go ahead.
This is also the time to make sure that important reviews are done. This is also the time to make sure that important reviews are done.
Ask for reviews from key working group contributors, and check Ask for reviews from key working group contributors, and check
whether any external reviews are needed. External reviews might whether any external reviews are needed. External reviews might
include expert reviews for IANA registrations, reviews of formal include expert reviews for IANA registrations (some registrations
require early review on specific mailing lists), reviews of formal
specifications such as MIBs, XML, and ABNF, and reviews from experts specifications such as MIBs, XML, and ABNF, and reviews from experts
in other areas (does the document need to be checked by a web in other areas (does the document need to be checked by a web
services expert, a security expert, a DNS expert?). Some of this services expert, a security expert, a DNS expert?). Some of this
will happen automatically later -- there will be a Security will happen automatically later -- there will be a Security
Directorate review at some point, for example -- but it's easier on Directorate review at some point, for example, and IANA will formally
the Document Editors and the working group if you know something is kick off expert review during Last Call -- but it's easier on the
Document Editors and the working group if you know something is
particularly necessary and arrange for it sooner. The IANA folks are particularly necessary and arrange for it sooner. The IANA folks are
willing to do an early review of the IANA actions at this stage, so willing to do an early review of the IANA actions at this stage, so
consider asking for that if the document has a large or unusually consider asking for that if the document has a large or unusually
involved set of IANA actions. involved set of IANA actions.
The shepherd writeup, which can be found in the IESG section of the The shepherd writeup, which can be found in the IESG section of the
IETF web site [Writeup], is a good reference to the Shepherd for IETF web site [Writeup], is a good reference to the Shepherd for
making sure the necessary bits are being covered, so this is also a making sure the necessary bits are being covered, so this is also a
good time to start the writeup. It will be finished later, when the good time to start the writeup. It will be finished later, when the
document is ready to be sent to the Responsible AD, but getting a document is ready to be sent to the Responsible AD, but getting a
skipping to change at page 11, line 29 skipping to change at page 10, line 33
sure they are focused on closing final issues and giving the sure they are focused on closing final issues and giving the
document final review. document final review.
3. Specifically ask (perhaps off list) for key reviews. 3. Specifically ask (perhaps off list) for key reviews.
4. Begin preparing the shepherd writeup, and request any external 4. Begin preparing the shepherd writeup, and request any external
reviews that will be needed. reviews that will be needed.
5. Analyze the results of Working Group Last Call and get final 5. Analyze the results of Working Group Last Call and get final
updates from the Document Editors. updates from the Document Editors.
3.4. Stage: Shepherd Writeup Underway 3.4. Stage: Shepherd Writeup Underway
Working Group Last Call is over, and the Shepherd has determined that Working Group Last Call is over, and the Shepherd and Chairs have
any issues that came out of that have been adequately resolved. It's determined that any issues that came out of that have been adequately
time to finish up the shepherd writeup, dotting the last of the "i"s resolved. It's time to finish up the shepherd writeup, dotting the
and crossing the final "t"s. last of the "i"s and crossing the final "t"s.
Remember that the shepherd writeup serves two major purposes: Remember that the shepherd writeup serves two major purposes:
1. It ensures that some key items have been double checked. 1. It ensures that some key items have been double checked.
2. It provides information to the IESG, which is useful during IESG 2. It provides information to the IESG, which is useful during IESG
Evaluation. Evaluation.
For the first purpose, "yes" and "no" are reasonable answers to some For the first purpose, "yes" and "no" are reasonable answers to some
of the writeup questions. In particular, a number of the questions of the writeup questions. In particular, a number of the questions
ask if something has been checked, or it some abnormal situation ask if something has been checked, or it some abnormal situation
exists. "Yes" to confirm that the check has been made, or "no" to exists. "Yes" to confirm that the check has been made, or "no" to
state that the abnormal situation does not exist are fine responses. state that the abnormal situation does not exist are fine responses.
Of course, if the answer to the first is "no" or to the second is Of course, if the answer to the first is "no" or to the second is
"yes", further explanation is necessary. In other words, "yes" could "yes", further explanation is necessary. In other words, "yes" could
be a reasonable answer by itself, but "no" would require more by way be a reasonable answer by itself, but "no" would require more by way
of explanation... or vice versa. of explanation... or vice versa.
But for the second purpose, providing useful information to the IESG, But for the second purpose, providing useful information to the IESG,
yes/no responses are of little or no use. Questions about the yes/no responses are often of little or no use. Questions about the
working group process and discussions are especially looking for some working group process and discussions are especially looking for some
sort of narrative information. Don't just say that there was much sort of narrative information. Don't just say that there was much
discussion that eventually reached consensus, or that there were a discussion that eventually reached consensus, or that there were a
number of controversial points that were resolved -- say something number of controversial points that were resolved -- say something
about the discussion, talk a bit about the controversies. If there about the discussion, talk a bit about the controversies. If there
were particular points that simply did not get any discussion but were particular points that simply did not get any discussion but
probably should have, say that. probably should have, say that.
Knowing the trouble spots, and the strong and weak points of the Knowing the trouble spots and the strong and weak points of the
discussion and consensus, will allow the IESG to properly evaluate discussion and consensus will allow the IESG to properly evaluate the
the document. That can avoid the IESG's revisiting issues that were document. That can avoid the IESG's revisiting issues that were
already done to death in the working group. It's common to have already done to death in the working group. It's common to have
DISCUSS positions in which ADs are questioning a point that the DISCUSS positions in which ADs are questioning a point that the
working group discussed at length, and a brief explanation in the working group discussed at length, and a brief explanation in the
writeup could have avoided having it come up again then. writeup could have avoided having it come up again then.
When the Shepherd has the writeup done, a non-chair Shepherd should When the Shepherd has the writeup done, a non-chair Shepherd should
consult with the Chairs to make sure they're happy with it and agree consult with the Chairs to make sure they're happy with it and agree
with what's in it. The Chairs will then need to make some with what's in it. The Chairs will then need to make some
datatracker updates that only they have authorization for: they will datatracker updates that only they have authorization for: they will
upload the writeup to the tracker and change the document state. upload the writeup to the tracker and change the document state.
Finally, the Shepherd (or the Responsible Chair) will email the Changing the document's working group state to "Submitted to IESG for
writeup to the Responsible AD, with CC to the IESG Secretary, asking Publication" will trigger the necessary email messages and IESG state
that the document be considered for publication. Including the changes, and will get the document into IESG "Publication Requested"
writeup in email, as well as in the tracker, and including the IESG state, from which the Responsible AD will begin her processing of the
Secretary on CC, are both meant to ensure that nothing gets lost and document. And as RFC 4858 says, the Shepherd should also email the
that a record is kept of the publication request. And as RFC 4858 writeup to the working group's mailing list, so the working group is
says, the Shepherd should also email the writeup to the working aware of it. The writeup will be public anyway, because it will be
group's mailing list, so the working group is aware of it. The in the datatracker, so it can only help the open process to make it
writeup will be public anyway, because it will be in the datatracker, more visible to the working group whose work it reflects.
so it can only help the open process to make it more visible to the
working group whose work it reflects.
See also Section 3.1 of [RFC4858], but note that the writeup template See also [RFC4858], Section 3.1, but note that the writeup template
has changed significantly since the version in that document. The has changed significantly since the version in that document. The
current writeup is in the IESG section of the IETF web site current writeup is in the IESG section of the IETF web site
[Writeup]. [Writeup].
The tasks at the Shepherd Writeup Underway stage might be as follows: The tasks at the Shepherd Writeup Underway stage might be as follows:
1. Shepherd: Complete the shepherd writeup and send it to the Chairs 1. Shepherd: Complete the shepherd writeup and send it to the Chairs
for approval. for approval.
2. Chairs: Work with the Shepherd to finalize the writeup. 2. Chairs: Work with the Shepherd to finalize the writeup.
3. Chairs: Put the writeup into the datatracker, and change the 3. Chairs: Put the writeup into the datatracker, and change the
tracker document state to the appropriate one for requesting tracker document state to the appropriate one for requesting
publication. publication.
4. Shepherd: Send the writeup to the Responsible AD (and the IESG 4. Shepherd: Send the writeup to the working group mailing list and
Secretary) and request publication. inform the working group that publication has been requested.
3.5. Stage: AD Review 3.5. Stage: AD Review
The next stage in the process is up to the Responsible Area Director, The next stage in the process is up to the Responsible Area Director,
and the Document Shepherd has but one easy task: make this stage as and the Document Shepherd has but one easy task: help make this stage
short as possible. The Responsible AD or the IESG Secretary will do as short as possible. The Responsible AD or the IESG Secretary will
some document state changes in the datatracker (to Publication do some document state changes in the datatracker (to Publication
Requested and then to AD Review), and the AD will review the document Requested and then to AD Review), and the AD will review the document
and either request IETF Last Call or respond to the authors (and, we and either request IETF Last Call or respond to the authors (and, we
hope, to the Shepherd as well; here's where it was useful to have put hope, to the Shepherd as well; here's where it was useful to have put
the Shepherd's email address in the tracker) with review comments and the Shepherd's email address in the tracker) with review comments and
suggested changes. In the latter case, the document's state will suggested changes. In the latter case, the document's state might
change to "AD Review, Revised I-D Needed". change to "AD Review, Revised I-D Needed".
The Shepherd needs to watch for the key state changes and the AD's The Shepherd needs to watch for the key state changes and the AD's
review. If the review doesn't happen in a reasonable time -- review. If the review doesn't happen in a reasonable time --
allowing for a busy AD's schedule and remembering that the document allowing for a busy AD's schedule and remembering that the document
you're shepherding isn't the only one on the AD's docket -- send a you're shepherding isn't the only one on the AD's docket -- send a
reminder... perhaps as a question, "How is the review on reminder... perhaps as a question, "How is the review on draft-ietf-
draft-ietf-frobozz-xyzzy coming?" Use your judgment to decide how frobozz-xyzzy coming?" Use your judgment to decide how long to wait,
long to wait, but most ADs will appreciate a reminder here and there but most ADs will appreciate a reminder here and there as long as
as long as it's not at the level of "pestering". it's not at the level of "pestering".
Once the review comes in, make sure the Document Editors are on top Once the review comes in, make sure the Document Editors are on top
of it and respond in a timely manner. Make sure that the working of it and respond in a timely manner. Make sure that the working
group is consulted on issues brought up in the review that are group is consulted on issues brought up in the review that are
significant enough to require the working group's engagement in the significant enough to require the working group's engagement in the
response. Editorial tweaks can arguably be handled by the editors response. Editorial tweaks can arguably be handled by the editors
alone at this point, and changes to the protocol clearly need to go alone at this point, and changes to the protocol clearly need to go
back to the working group, but many issues fall in between, and good back to the working group, but many issues fall in between, and good
judgment is important. judgment is important. The Chairs should be involved in deciding
where the line is drawn.
Many documents spend *months* in AD Review state, largely because of Many documents spend *months* in AD Review state, largely because of
lack of good shepherding. It may look like there's only one major lack of good shepherding. It may look like there's only one major
task here, but it's an important one. Please don't give it short task here, but it's an important one. Please don't give it short
shrift. shrift.
See also Section 3.2 of [RFC4858]. See also [RFC4858], Section 3.2.
The tasks for the Shepherd at the AD Review stage might be as The tasks for the Shepherd at the AD Review stage might be as
follows: follows:
1. Make sure the AD reviews the document in a timely manner, and 1. Make sure the AD reviews the document in a timely manner, and
send occasional reminders as needed. send occasional reminders as needed.
2. Make sure the Document Editors respond to the review in a timely 2. Make sure the Document Editors respond to the review in a timely
manner, and poke them as well, as needed. manner, and poke them as well, as needed.
3. Keep the dialogue going between the Responsible AD and the 3. Keep the dialogue going between the Responsible AD and the
editors until all issues have been dealt with and the document is editors until all issues have been dealt with and the document is
skipping to change at page 14, line 4 skipping to change at page 12, line 54
The tasks for the Shepherd at the AD Review stage might be as The tasks for the Shepherd at the AD Review stage might be as
follows: follows:
1. Make sure the AD reviews the document in a timely manner, and 1. Make sure the AD reviews the document in a timely manner, and
send occasional reminders as needed. send occasional reminders as needed.
2. Make sure the Document Editors respond to the review in a timely 2. Make sure the Document Editors respond to the review in a timely
manner, and poke them as well, as needed. manner, and poke them as well, as needed.
3. Keep the dialogue going between the Responsible AD and the 3. Keep the dialogue going between the Responsible AD and the
editors until all issues have been dealt with and the document is editors until all issues have been dealt with and the document is
ready for the next stage. ready for the next stage.
4. See to it that issues are brought back before the working group 4. See to it that issues are brought back before the working group
if they are significant enough to require it. if they are significant enough to require it.
3.6. Stage: IETF Last Call 3.6. Stage: IETF Last Call
Once the Responsible AD is satisfied that the document is ready to Once the Responsible AD is satisfied that the document is ready to
move ahead, she will put it in Last Call Requested state. That move ahead, she will put it in Last Call Requested state. That
prompts the IESG Secretary to send out the Last Call announcement and prompts the IESG Secretary to send out the Last Call announcement and
to put the document into "In Last Call". to put the document into "In Last Call".
The Shepherd's job in the IETF Last Call stage is very similar to The Shepherd's job in the IETF Last Call stage is very similar to
what's needed in AD Review. Start by watching for last-call what's needed in AD Review. Start by watching for last-call
comments, including various special reviews. Reviews will come in comments, including various special reviews. Reviews will come in
from the Security Directorate and the General Area Review Team from the Security Directorate and the General Area Review Team
(GenART), and some may also come from other review teams and (GenART), and some may also come from other review teams and
directorates. Reviews might also be coming in at this stage, if they directorates. Reviews might also be coming in at this stage, if they
haven't already, that were specifically requested by the Shepherd haven't already, that were specifically requested by the Shepherd
(see the Working Group Last Call stage). (see the Working Group Last Call stage in Section 3.3).
The Shepherd needs to make sure all of those reviews are addressed by The Shepherd needs to make sure all of those reviews are addressed by
the document editors, and that the specifically requested reviews get the document editors, and that the specifically requested reviews get
done. "Addressed" doesn't mean that every change asked for in every done. "Addressed" doesn't mean that every change asked for in every
last-call comment needs to be made. Sometimes, a reasonable response last-call comment needs to be made. Sometimes, a reasonable response
is to say that the working group discussed the point, and the is to say that the working group discussed the point, and the
document correctly reflects its consensus -- that is, the working document correctly reflects its consensus -- that is, the working
group disagrees with the last-call comment. At other times, it's group disagrees with the last-call comment. At other times, it's
reasonable to disagree with the reviewer and look for any other reasonable to disagree with the reviewer and look for any other
support for the reviewer's position. Rough consensus can be a tricky support for the reviewer's position. Rough consensus can be a tricky
thing, but the bottom line is that all comments need at least be thing, but the bottom line is that all comments need at least be
considered. Directorate and review-team reviews, in particular, considered. Directorate and review-team reviews, in particular,
require acknowledgment and response (though they, too, can be require acknowledgment and response (though they, too, can be
disagreed with). disagreed with).
During Last Call, IANA will review the document's IANA During Last Call, IANA will review the document's IANA
Considerations, will respond with their summary of what they think Considerations, will respond with their summary of what they think
needs to be done by IANA after the document is approved, and will ask needs to be done by IANA after the document is approved, and will ask
any questions they have. The Shepherd should watch for this review any questions they have. The Shepherd should watch for this review
and make sure that the actions IANA proposes are correct and that any and make sure that the actions IANA proposes are correct and that any
questions they have are answered. See also Section 4 of [RFC4858]. questions they have are answered. At this point, IANA will also
contact any Designated Experts required to formally approve any
registrations, so it will help if the shepherd has done the necessary
preparatory work (see Section 3.3). See also [RFC4858], Section 4.
Different Responsible ADs will have different preferences for whether Different Responsible ADs will have different preferences for whether
documents in IETF Last Call should be updated while they're still in documents in IETF Last Call should be updated while they're still in
that state. The Shepherd should check with the AD and advise the that state. The Shepherd should check with the AD and advise the
Document Editors. Sometimes it's best to keep a stable version Document Editors. Sometimes it's best to keep a stable version
throughout last-call review; other times it's better to get changes throughout last-call review; other times it's better to get changes
posted quickly, so the same issues aren't brought up by multiple posted quickly, so the same issues aren't brought up by multiple
reviewers. Work with the AD and the editors to handle this. reviewers. Work with the AD and the editors to handle this.
The tasks for the Shepherd at the IETF Last Call stage might be as The tasks for the Shepherd at the IETF Last Call stage might be as
skipping to change at page 15, line 12 skipping to change at page 14, line 4
posted quickly, so the same issues aren't brought up by multiple posted quickly, so the same issues aren't brought up by multiple
reviewers. Work with the AD and the editors to handle this. reviewers. Work with the AD and the editors to handle this.
The tasks for the Shepherd at the IETF Last Call stage might be as The tasks for the Shepherd at the IETF Last Call stage might be as
follows: follows:
1. Monitor the last-call comments, and make sure that specifically 1. Monitor the last-call comments, and make sure that specifically
requested reviews arrive. requested reviews arrive.
2. Make sure the Document Editors respond to all reviews and 2. Make sure the Document Editors respond to all reviews and
comments in a timely manner. comments in a timely manner.
3. Keep the dialogue going between the community and the editors 3. Keep the dialogue going between the community and the editors
until all issues have been dealt with. until all issues have been dealt with.
4. See to it that issues are brought back before the working group 4. See to it that issues are brought back before the working group
if they are significant enough to require it. if they are significant enough to require it.
3.7. Stage: Waiting for AD Go-Ahead 3.7. Stage: Waiting for AD Go-Ahead
When Last Call completes, the tracker state for the document will When Last Call completes, the tracker state for the document will
automatically go to "Waiting for AD Go-Ahead". This is the automatically go to "Waiting for AD Go-Ahead". This is the
Shepherd's signal to re-check the comments from last call, to make Shepherd's signal to re-check the comments from last call, to make
sure an updated I-D is posted that is ready for IESG Evaluation, and sure an updated I-D is posted that is ready for IESG Evaluation, and
to let the Responsible AD know when everything is set. The AD will to let the Responsible AD know when everything is set. The AD will
be watching for this as well, and in many cases the Shepherd won't be watching for this as well, but, as in the other stages, it's the
need to be involved here. But, as in the other stages, it's the
Shepherd's responsibility to keep an eye on things and make sure Shepherd's responsibility to keep an eye on things and make sure
what's needed gets done. what's needed gets done.
This is also a good time to remember that the document shepherd
writeup is not static. If significant time has elapsed, significant
discussion has happened, or significant changes have been made, it's
a good idea to work with the Chairs to update the shepherd writeup in
the datatracker, making sure that delays, discussions, and major
changes are outlined in the writeup for the IESG.
The tasks for the Shepherd at the Waiting for AD Go-Ahead stage might The tasks for the Shepherd at the Waiting for AD Go-Ahead stage might
be as follows: be as follows:
1. Make sure a new I-D is posted with the latest changes, unless 1. Make sure a new I-D is posted with the latest changes, and inform
there were no changes required. the Responsible AD that all changes have been incorporated and
2. Inform the Responsible AD that all changes have been that the document is ready for IESG Evaluation, or...
incorporated, and that the document is ready for IESG Evaluation. 2. ...inform the Responsible AD that no changes are required and
that the document is ready for IESG Evaluation.
3. Update the Shepherd writeup if anything has come up during Last 3. Update the Shepherd writeup if anything has come up during Last
Call that the IESG should know about. Call that the IESG should know about. The Chairs will update the
writeup in the datatracker.
3.8. Stage: IESG Evaluation 3.8. Stage: IESG Evaluation
As the ADs do their reviews they will record ballot positions on the As the ADs do their reviews they will record ballot positions on the
document. Ballot positions can be one of "Yes", "No Objection", document. Ballot positions can be one of "Yes", "No Objection",
"Discuss", and "Abstain" (there's also "Recuse" for cases when the AD "Discuss", and "Abstain" (there's also "Recuse" for cases when the AD
has a conflict of interest with the document (if, for example, the AD has a conflict of interest with the document, if, for example, the AD
is one of the authors/editors)). Any of these ballot positions can is one of the authors/editors). Any of these ballot positions can be
be accompanied by non-blocking review comments, and "Discuss" also accompanied by non-blocking review comments, and "Discuss" also comes
comes with blocking comments in addition -- these must be resolved to with blocking comments in addition -- these must be resolved to the
the satisfaction of the Discussing AD before the document can be satisfaction of the Discussing AD before the document can be approved
approved by by the IESG. The document will be scheduled for a bi- by by the IESG. The document will be scheduled for a bi-weekly
weekly "telechat" (at the time of this writing they're on Thursdays), "telechat" (at the time of this writing they're on Thursdays), and it
and it will be approved then or left in one of several follow-up will be approved then or left in one of several follow-up states.
states.
The IESG Evaluation period is normally somewhere between one and The IESG Evaluation period is normally somewhere between one and
three weeks, though it can be as little as a day or two in unusual three weeks, though it can be as little as a few days in unusual
circumstances. Be aware, though, that there's usually a burst of circumstances. Be aware, though, that there's usually a burst of
review activity in the final few days before the telechat, and expect review activity in the final few days before the telechat, and expect
most reviews to come in then. most reviews to come in then.
The IESG Evaluation comments and DISCUSS positions will be copied to The IESG Evaluation comments and DISCUSS positions will be copied to
the Document Shepherd (again, it was important to have put the the Document Shepherd (again, it was important to have put the
Shepherd's email address in the tracker), and the Shepherd should be Shepherd's email address in the tracker), and the Shepherd should be
watching for them and making sure that the Document Editors respond watching for them and making sure that the Document Editors respond
promptly -- at this stage, quick turnaround is most important. promptly -- at this stage, quick turnaround is most important.
Sometimes the Shepherd or Chairs might respond to AD questions and Sometimes the Shepherd or Chairs might respond to AD questions and
comments themselves, and sometimes they might leave it to the comments themselves, and sometimes they might leave it to the
editors. The process works best when everyone engages, with the goal editors. The process works best when everyone engages, with the goal
of resolving the issues brought up by the ADs as efficiently as of resolving the issues brought up by the ADs as efficiently as
possible. possible.
A word about DISCUSS positions: Many Document Editors treat these as A word about DISCUSS positions: Many Document Editors treat these as
adversarial situations created by aggressive ADs, but that's adversarial situations created by aggressive ADs, but that's
generally not the intent. First, many DISCUSSes are resolved quickly generally not the intent. First, many DISCUSSes are resolved quickly
and easily by a round of email with the Discussing AD, and that's as and easily by a round of email with the Discussing AD, and that's as
it should be: the point is that the AD has something to "discuss" it should be: the point is that the AD has something to "discuss"
with those responsible for the document before she can agree to the with those responsible for the document before she can agree to the
document's approval. Second, many DISCUSSes that do take more document's approval. Second, many DISCUSSes that do take more
effort, often significant back and forth with the Discussing AD and effort, often significant back and forth with the Discussing AD and
other IESG members, result in a better document, having cleared up other IESG members, result in a better document, having cleared up
some significant confusion or having closed a hole in the some significant confusion or having closed a hole in the
specification that was missed at earlier stages. Please try to treat specification that was missed at earlier stages. Please try to treat
skipping to change at page 16, line 45 skipping to change at page 15, line 41
Most often, ADs who record DISCUSS positions (and review comments) Most often, ADs who record DISCUSS positions (and review comments)
are quite responsive, and will work with the Editors and Shepherd to are quite responsive, and will work with the Editors and Shepherd to
get everything resolved. Sometimes, though, a busy AD can find get everything resolved. Sometimes, though, a busy AD can find
herself lacking the time to respond. The Shepherd should keep the herself lacking the time to respond. The Shepherd should keep the
ADs honest, pushing for quick responses. In earlier stages, too- ADs honest, pushing for quick responses. In earlier stages, too-
frequent reminders might be considered unreasonable, but at this frequent reminders might be considered unreasonable, but at this
stage discussion should be fairly brisk, and a delay of more than a stage discussion should be fairly brisk, and a delay of more than a
couple of days should be unusual, on either side. couple of days should be unusual, on either side.
Non-blocking IESG Evaluation comments should be treated as IETF Last
Call comments are: the Document Editors should respond to them and do
their best to address them, but failure to come to agreement on them
will not block the document's progress.
And, as at other stages, the Shepherd should work with the Chairs to
ensure that any changes of significance are brought back to the
working group for their review before the final approval notice goes
out.
The IESG web site has more details about IESG ballot positions The IESG web site has more details about IESG ballot positions
[Ballot] and about IESG DISCUSS ballots in particular [Discuss]. And [Ballot] and about IESG DISCUSS ballots in particular [Discuss]. And
see also Section 3.3 of [RFC4858]. see also [RFC4858], Section 3.3.
The tasks for the Shepherd at the IESG Evaluation stage might be as The tasks for the Shepherd at the IESG Evaluation stage might be as
follows: follows:
1. Keep track of the DISCUSS positions and review comments by the 1. Keep track of the DISCUSS positions and review comments by the
IESG. IESG.
2. Make sure all comments are addressed, and help the discussions of 2. Make sure all comments are addressed, and help the discussions of
DISCUSS positions reach closure. DISCUSS positions reach closure.
3. Keep both the Document Editors and the Discussing AD engaged in 3. Keep both the Document Editors and the Discussing AD engaged in
the resolution of the issues. the resolution of the issues.
4. See to it that issues are brought back before the working group
if they are significant enough to require it.
3.9. Stage: Approved by the IESG 3.9. Stage: Approved by the IESG
Once the document has been on a telechat, any necessary revised Once the document has been on a telechat, any necessary revised
versions have been posted, and all DISCUSS positions are "cleared", versions have been posted, and all DISCUSS positions are "cleared",
the Responsible AD (or the IESG Secretary) will put the document into the Responsible AD (or the IESG Secretary) will put the document into
the "Approved, Announcement to be Sent" state. If there's any the "Approved, Announcement to be Sent" state. If there's any
follow-up that needs to be done, it will be held with a sub-state follow-up that needs to be done, it will be held with a sub-state
(usually "Point Raised, Writeup Needed"), and the Shepherd should (usually "Point Raised, Writeup Needed"), and the Shepherd should
make sure whatever final checks that are needed get done, and that make sure that whatever final checks are needed get done, and that
the Responsible AD clears the sub-state and informs the IESG the Responsible AD clears the sub-state and informs the IESG
Secretary. Secretary.
At this stage, it's usually a matter of making sure that the latest At this stage, it's usually a matter of making sure that the latest
version of the document adequately addresses the non-blocking version of the document adequately addresses the non-blocking
comments by the ADs, and that any necessary RFC Editor notes are comments by the ADs, and that any necessary RFC Editor notes are
entered. The Shepherd should work with the Responsible AD to entered. The Shepherd should work with the Responsible AD to
understand what still needs to be done, and to make sure it happens. understand what still needs to be done, and to make sure it happens.
The tasks for the Shepherd at the Approved by the IESG stage might be The tasks for the Shepherd at the Approved by the IESG stage might be
skipping to change at page 18, line 33 skipping to change at page 17, line 33
of the document is required before the RFC Editor will finish the of the document is required before the RFC Editor will finish the
publication process. The Document Shepherd needs to make sure that publication process. The Document Shepherd needs to make sure that
the Editors all respond, and should take the lead in prompting them the Editors all respond, and should take the lead in prompting them
early and frequently. Remember that "AUTH48" is meant to refer to 48 early and frequently. Remember that "AUTH48" is meant to refer to 48
hours, not 48 days. Don't let this drag on. hours, not 48 days. Don't let this drag on.
The RFC Editor will often have questions that the Authors/Editors The RFC Editor will often have questions that the Authors/Editors
need to answer. The Document Editors often have minor changes to need to answer. The Document Editors often have minor changes to
insert at this point. The Shepherd should consider those answers, insert at this point. The Shepherd should consider those answers,
those changes, and the changes the RFC Editor has made leading into those changes, and the changes the RFC Editor has made leading into
AUTH48, and assess (in consultation with the Chairs and the AUTH48, and assess, in consultation with the Chairs and the
Responsible AD) whether any changes need to be passed back to the Responsible AD, whether any changes need to be passed back to the
working group -- remember that the document has been approved by working group -- remember that the document has been approved by
rough consensus of the working group, and then of the IETF as a rough consensus of the working group, and then of the IETF as a
whole, and the final, published version must continue to reflect that whole, and the final, published version must continue to reflect that
consensus. consensus.
It's unusual for there to be significant controversy at this stage, It's unusual for there to be significant controversy at this stage,
but it's been known to happen. Sometimes a change or a question by but it's been known to happen. Sometimes a change or a question by
the RFC Editor will raise a question with the Document Editors that the RFC Editor will raise a question with the Document Editors that
had not come up before. Sometimes, the right answer to one of those had not come up before. Sometimes, the right answer to one of those
questions will be more than just editorial, and sometimes it will questions will be more than just editorial, and sometimes it will
involve a significant technical decision. Decisions of that nature involve a significant technical decision. Decisions of that nature
should not be made by the Document Editors alone, and the Shepherd should not be made by the Document Editors alone, and the Shepherd
should arrange to have them discussed by the working group. should arrange with the Chairs to have those issues discussed by the
working group.
Most of the time, though, this stage will run smoothly, the Document Most of the time, though, this stage will run smoothly, the Document
Editors will respond to the AUTH48 messages with a minimum of Editors will respond to the AUTH48 messages with a minimum of
prodding, and the RFC Editor will announce their happiness and prodding, and the RFC Editor will announce their happiness and
proceed with the publication process. proceed with the publication process.
See also Section 5 of [RFC4858]. See also Section 5 of [RFC4858].
The tasks for the Shepherd at the AUTH48 stage might be as follows: The tasks for the Shepherd at the AUTH48 stage might be as follows:
skipping to change at page 20, line 7 skipping to change at page 18, line 18
need review by the working group. need review by the working group.
3.12. Stage: Published 3.12. Stage: Published
We're done. The RFC Editor has published the document, and the RFC We're done. The RFC Editor has published the document, and the RFC
announcement has been made. Many thanks to the Shepherd for having announcement has been made. Many thanks to the Shepherd for having
seen it through and for helping to assure a high quality document. seen it through and for helping to assure a high quality document.
4. Some Final Notes 4. Some Final Notes
I've outlined a Document Shepherding Function, above, in a lot of We have outlined a Document Shepherding Function, above, in a lot of
detail, so let's put the executive summary back here: detail, so let's put the executive summary back here:
What it all boils down to is setting up one person who takes What it all boils down to is setting up one person who takes
responsibility for following the progress of a document from Call for responsibility for following the progress of a document from Call for
Adoption through Publication, staying actively involved with managing Adoption through Publication, staying actively involved with managing
the discussion and issue resolution at every stage, and making sure the discussion and issue resolution at every stage, and making sure
the necessary participants are responsive and that things don't the necessary participants are responsive and that things don't
languish from inattention. languish from inattention.
And again, Working Group Chairs may delegate all or part of this And again, Working Group Chairs may delegate all or part of this
function to a non-chair participant, or retain all responsibility for function to a non-chair participant, or retain all responsibility for
it themselves. In the latter case, I don't think what I'm describing it themselves. In the latter case, what is described here is nothing
here is anything different to what should be happening already. different to what should be happening already. Setting it out as
Setting it out as clear tasks and a set of stages in the document's clear tasks and a set of stages in the document's lifecycle will make
lifecycle will make it easier to recognize what needs to be done it easier to recognize what needs to be done when, and to handle
when, and to handle delegation when the Chairs choose to delegate. delegation when the Chairs choose to delegate.
5. Security Considerations 5. Security Considerations
This document describes an individual's suggestion about IETF This document describes IETF process, and is entirely unrelated to
process, and is entirely unrelated to security in any way. security in any way.
6. IANA Considerations 6. IANA Considerations
No IANA actions are requested by this document, and the RFC Editor is No IANA actions are requested by this document, and the RFC Editor is
asked to remove this section before publication. asked to remove this section before publication.
7. References 7. References
7.1. Normative References 7.1. Normative References
[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.
[RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, [RFC4858] Levkowetz, H., Meyer, D., Eggert, L. and A. Mankin,
"Document Shepherding from Working Group Last Call to "Document Shepherding from Working Group Last Call to
Publication", RFC 4858, May 2007. Publication", RFC 4858, May 2007.
7.2. Informative References 7.2. Informative References
[Ballot] IESG, "IESG Ballot Procedures", May 2009, [Ballot] IESG, , "IESG Ballot Procedures", May 2009, <http://
<http://www.ietf.org/iesg/voting-procedures.html>. www.ietf.org/iesg/voting-procedures.html>.
[Discuss] IESG, "DISCUSS Criteria in IESG Review", July 2007, [Discuss] IESG, , "DISCUSS Criteria in IESG Review", July 2007,
<http://www.ietf.org/iesg/statement/ <http://www.ietf.org/iesg/statement/discuss-
discuss-criteria.html>. criteria.html>.
[Stmt] IESG, "IESG Statement on Document Shepherds", [Stmt] IESG, , "IESG Statement on Document Shepherds", October
October 2010, <http://www.ietf.org/iesg/statement/ 2010, <http://www.ietf.org/iesg/statement/document-
document-shepherds.html>. shepherds.html>.
[Writeup] IESG, "Working Group Submission Writeup", February 2012, [Writeup] IESG, , "Working Group Submission Writeup", February 2012,
<http://www.ietf.org/iesg/template/doc-writeup.txt>. <http://www.ietf.org/iesg/template/doc-writeup.txt>.
Author's Address Author's Address
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
 End of changes. 71 change blocks. 
220 lines changed or deleted 245 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/