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