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 <[email protected]> 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.
