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 <iesg-secretary@xxxxxxxx> 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 > ietf@xxxxxxxx mailing lists by 2012-10-23. Exceptionally, comments may be > sent to iesg@xxxxxxxx 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. > > >