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@xxxxxxxxxxx> 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.