Telechat Review of draft-leiba-extended-doc-shepherd-06
review-leiba-extended-doc-shepherd-06-genart-telechat-campbell-2012-11-15-00

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-leiba-extended-doc-shepherd-01
Reviewer: Ben Campbell
Review Date: 2012-11-12
IESG Telechat date: 2012-11-15

Summary: I have mixed feelings about this draft being published as an IETF
stream RFC in it's current form.

Major issues:

This draft is not substantially changed since my Gen-ART review of version 00
at last call. I've copied that review in it's entirety below. There is a new
section indicating that the ideas herein should be adapted to the
circumstances. This helps, but I think my original comments still stand.

I am sympathetic to Adrian Farrel's DISCUSS position as updated on 2012-11-05.
OTOH, it seems like there should be a place to capture this sort of opinion
document, and it's a bit large and involved to simply send to a mailing list
for discussion.

On Oct 23, 2012, at 5:07 PM, Ben Campbell <ben at nostrum.com> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> <

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document:  draft-leiba-extended-doc-shepherd-00
>
> Reviewer: Ben Campbell
> Review Date: 2012-10-23
> IETF LC End Date: 2012-10-23
>
> Summary: I'm not sure what to make of this draft. I think the opinions herein
are worth capturing, but have mixed feelings about it belong in an
informational RFC. > > Major issues: > > -- Process: I share some of the
concerns that have been mentioned by others, namely that I'm not sure whether
an individual opinion paper should be published as an informational RFC. OTOH,
I'm not sure that it shouldn't. The operative words here are "I'm not sure."
The opinions contained in the document are interesting, and likely of use to
the community. I just wonder if another publication form might not be more
appropriate. > > -- Content: It's hard to disagree with most of the activities
in general, but it seems to me that much of the pre pubreq processes here are
just things that Chairs should be doing anyway. I guess it doesn't hurt to call
all of that "shepherding", but I don't think it's the same thing as "having a
shepherd" in the PROTO sense.  I see the potential value of having continuity
of responsibility throughout the entire process, but I also see value in the
flexibility of deferring the shepherd selection until time for the proto
writeup. (I recognize that you don't necessarily expect the same person to
shepherd all phases--but if I read correctly you also seem to indicate a
preference that they do so.) > > Minor issues: > > -- section 1, 4th paragraph:
"It adds to what’s in RFC 4858, intending to extend it, not replace it." > > Do
you intend this to formally update 4858? It doesn't seem like it from the rest
of the text, but one might infer otherwise from this sentence. > > -- section
4, 2nd paragraph: "... What it all boils down to is setting up one person who
takes responsibility for following the progress of a document from Call for
Adoption through Publication ..." > > The text offers examples of changing the
responsible person during the process, but also mentions the advantages of
continuity. If continuity is the real goal, then are the examples that show the
role changing over the life of the draft are counterproductive? > > >
Nits/editorial comments: > > None.