Subject: Re: Last Call: <draft-leiba-extended-doc-shepherd-00.txt> (Document Shepherding Throughout a Document's Lifecycle) to Informational RFC

From: SM <[email-masked]>
Date: Tue, 25 Sep 2012 15:06:38 -0700

At 07:40 25-09-2012, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'Document Shepherding Throughout a Document's Lifecycle'
>   <draft-leiba-extended-doc-shepherd-00.txt> as Informational RFC
>
>The author is documenting his own opinion, and he is presenting that
>opinion to the community for consideration.  The author is not
>proposing any formal change, but he is interested in community
>comments.  Since this is the authors opinions, changes to the document
>based on received comments be at the author's discretion.  As a
>result, the finished document will not claim to reflect IETF community
>consensus.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2012-10-23. Exceptionally, comments may be

This Last Call is highly unusual.  If the changes that are accepted 
is a matter of author discretion, why is there a Last Call and what 
is the role of the IESG here?

My reading of the draft is that it is a mix of RFC 4858 and the 
document life cycle (see RFC 6174).

In the Introduction Section:

   "It seems reasonable and helpful to begin shepherding at the time there's
    a call for adoption as a working group document, and this document
    gives one Area Director's view of how that extended shepherding
    function might work, and what tasks might be involved throughout the
    document's lifecycle."

This is good advice.  It is however problematic to implement in my 
humble opinion.  The shepherding process does not always work 
well.  There are diligent shepherds and absent shepherds.  Some 
authors end up with a bad IETF experience because of that.  In my 
humble opinion, it cannot be fixed through methodologies.  I don't 
know whether that problem can be solved.  Extended shepherding means 
more work.  It leaves less leeway for choosing a shepherd based on 
individual availability.

In Section 3.1:

   "This is the time to choose a Responsible Chair for the document, much
    as it will eventually have a Responsible Area Director later in its
    life."

With the introduction of "Responsible Chair" the other Chairs might 
consider themselves as spectators.  Whether a Chair should take the 
lead on a document is up to the Chairs to decide.  In simple terms, 
they have the latitude to decide how to get the work done.

   "Giving significant responsibility can be an excellent training
    exercise, preparing participants to take on future roles as
    Working Group Chairs."

Once a draft clears the AD review stage it won't get published if it 
is not kept "moving".   This is where the document shepherd can be 
useful.  I would suggest having someone with adequate experience 
instead of using this stage as a training exercise.  The IETF idea of 
a training exercise is sending someone to face live rounds without an 
instruction manual.

   "And in a busy working group, offloading work from the Chairs to
    senior, experienced people (perhaps former Chairs or former ADs)
    can prevent the Chairs from being overcommitted, enabling the work
    to move forward much more efficiently."

Yes.  This is less about document shepherding though.

   "The issue tracker can be used to record not just the issues
    themselves, but significant parts of the discussion on both sides,
    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 significant work.  It is also a matter of style.

   "And as RFC 4858 says, the Shepherd should also email the writeup to
    the working group's mailing list, so the working group is aware of it."

There is a fairly good write-up at 
http://www.ietf.org/mail-archive/web/precis/current/msg00327.html  :-)

The draft may be a better fit as Wiki material.  If the draft is 
meant to help shepherds, I suggest discussing cases where things 
could be improved.  For example, "documents spend *months* in AD 
Review state, largely because of lack of good shepherding".  How long 
should the shepherd wait before sending the AD a reminder?  "Use your 
judgement" only works if one is aware of existing 
practices.  Sometimes it helps to say "remind me in a week or 
two".  The dead zone is from AD review to IESG evaluation.  I suggest 
focusing on that part instead of creating an extended shepherding process.

If I could paraphrase the draft, I'd say that the intent is to change 
shepherding from a mechanical exercise into a information 
gathering/input for decision-making/process-stumbling avoidance 
exercise.  The hurdle is political inappropriateness.

Regards,
-sm

---

From: Russ Housley <[email-masked]>
Date: Tue, 25 Sep 2012 19:24:46 -0400

SM:

> This Last Call is highly unusual.  If the changes that are accepted is a matter of author discretion, why is there a Last Call and what is the role of the IESG here?

Since the document is about one person's opinion on IETF process, I felt it useful to bring the document to the attention of the community.  Others may agree or disagree.  Hopefully it will spur discussion.  Perhaps it will spur a group to propose a change to the process.

After the Last Call, the IESG will make a decision about publication of this document as an IETF Stream RFC.

Russ

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 26 Sep 2012 11:11:08 +0200

Dated: 26/09/2012                                      By: Abdussalam
Baryun (AB)
This is a reply to below request call.

Reviewer Related Comment: The General Area Individual input
++++++++++++++++++++++++++++++++++++++++++++

Overall the reviewer disagrees to accept the document only after
modifications mentioned below and with referencing discussions/surveys
if available. I will name the I-D as a reflection report, which is
helpful for organisations' progress. Comments below:

1) the Abstract and Title of the document should represent the real
purpose of the document, it is not understood from them that the
document is an opinion, or point of view, or two points of view, or is
this document argumental. Informational track document related to such
subject SHOULD include references to history and practices as the
author witnesses while his experience, as a reflection report.

2) How can an individual submitter make input to produce RFC relating
to the administrative work of IETF, this will be without community
agreement or consultant.

3) IF there was no consultant from community of the Internet by the
author, and the I-D concerns their process, THEN the I-D SHOULD
mention that clearly. IF there was a questionnair or survey done by
the author, THEN he/she should include in the I-D. IF no such survey
done, nor questionnair distributed to get feedback, THEN it SHUOLD be
stated that there was no survey, in addition to the above.

4) IF the document represents the authors views THEN the Absract of
the I-D SHOULD state clearly, that : "this document is only the
opinion of the author(s) and not the Community. IF not mentioned THEN
the author must show prove of such claims/understandings.

Best regards
AB

End of Reply
++++++++++++++++++++++++++++++++++++++++++++++++++++++

On 9/25/12, The IESG <[email-masked]> wrote:
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>    RFC 4858 talks about "Document Shepherding from Working Group Last
>    Call to Publication".  There's a significant part of a document's
>    life that happens before working group last call, starting, really,
>    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
>    helpful to begin shepherding when there's a call for adoption as a
>    working group document, and this document gives one Area Director's
>    view of how that extended shepherding function might work, and what
>    tasks might be involved throughout the document's lifecycle.
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/ballot/
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>