I'm fine with any of the options Eran proposed. The document has become much more Eran's than anyone else's which leads me to lean towards just listing Eran as the editor.
-- Dick On 2011-03-27, at 1:43 AM, Peter Saint-Andre wrote: > <hat type='AD'/> > > On 3/27/11 12:36 AM, Eran Hammer-Lahav wrote: >> The security consideration section pending, this is the last open issue >> I have to close as editor before the document is ready to leave the >> working group. While this is silly business for many, it is very >> important to others, so bear with me. I want to make sure we give >> everyone the proper recognition they deserve. > > I'm all in favor of recognition. For those who care, allow me explain a > bit about the various roles and responsibilities here. > > Section 6.3 of RFC 2418 states: > > Most IETF working groups focus their efforts on a document, or set of > documents, that capture the results of the group's work. A working > group generally designates a person or persons to serve as the Editor > for a particular document. The Document Editor is responsible for > ensuring that the contents of the document accurately reflect the > decisions that have been made by the working group. > > In essence, the document editor is a special kind of author who is > appointed by the WG chairs and who is responsible for capturing the > consensus that emerges from WG discussions. > > Anyone who is listed as an author has a number of responsibilities: > > 1. Authors are exposed to comments received during IETF Last Call and > IESG review. Usually at least one of authors needs to reply to major > comments, although often document shepherds (typically one of the WG > chairs) and sponsoring ADs do that as well. As I can report from my own > experience, this can be a lot of work and it is time-sensitive. > > 2. After the document is approved for publication by the IESG, it is > sent to the RFC Editor team for editing. At the end of this process the > document moves to a state called AUTH48: > > http://www.rfc-editor.org/pubprocess.html#auth48 > > This is the last chance to fix some things in the document. During > AUTH48, all authors need to approve changes made by the RFC Editor and > other authors (often in consultation with the responsible Area Director, > the document shepherd, and the WG chairs). This is also time-sensitive. > Although the responsible Area Director can approve documents if some > authors are not responsive, all of the authors need to pay attention to > AUTH48 discussions and respond when asked. Any unresponsive author can > delay the document for a very long time (and in some cases even can > prevent publication). > > 3. Authors are notified when errata are posted on their RFCs, in > perpetuity. In many cases their opinions about submitted errata are > taken into consideration when the responsible Area Director decides what > to do with errata. > > 4. Authors might receive comments and questions on their documents, > again in perpetuity. In many cases, it might be inappropriate for > authors to provide substantive interpretations about standards-track > specifications without consulting mailing lists, Area Directors, etc., > so this can become a burden with a very long tail. > > The list of people mentioned in the Acknowledgements section is mostly > at the discretion of the authors. However, IETF IPR policies require > that anyone who makes significant contributions to a document be listed > in the Acknowledgments section. Although "significant" is something > about which the authors can make judgments, it is best to err on the > side of inclusion. In additional to textual contributions, such > contributions might be a careful review or ideas that had a major > influence on the results even if that person's particular suggestions > were not adopted. This kind of mention is not discretionary and cannot > be waived even if the contributor asks to be removed. If somebody > mentioned in the Acknowledgments contacts asks to be removed, please > talk to the WG chairs. > > Sometimes it is appropriate to mention major contributions in a section > entitled Contributors. This is usually reserved for people who have > written significant pieces of the document, for former co-editors or > co-authors, etc. > > The moral of the story is that having a small author list makes it > easier to handle IESG feedback and AUTH48 changes, and that if you want > to acknowledge people who made major contributions, create a section > called Contributors. > > As an example, see a document that Jeff Hodges and I recently worked on: > > http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14 > > HTH, > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
