<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/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
