]> The University of Auckland

School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

RSWG Internet-Draft This document describes guidelines for assigning authorship in RFC documents, including guidelines for disclosing the use of artificial intelligence during document preparation. It also discusses the related issues of acknowledgements, editors and contributors. The various RFC streams may apply these guidelines, or set their own guidelines, which will have priority. About This Document Status information for this document may be found at . Discussion of this document takes place on the RSWG Working Group mailing list (), which is archived at .

Introduction and Scope Questions sometimes come up about who should be listed as the author(s) of an RFC, who should be listed as editors or contributors, and what acknowledgements are appropriate. Additionally, questions have arisen about the use of artificial intelligence tools during the drafting of future RFCs. The policy guidelines below address these questions and are applicable by default to all RFC streams as defined in and , and to any streams defined in future. Each stream has its own approving body , and may define exceptions to and variations from these guidelines. In case of discrepancies or gaps, the stream's policy and the preference of its approving body will prevail over this document. The guidelines are intended to be compatible with the RFC Editor's style guide, including , and with an earlier RFC Editor authorship policy . For the IETF stream, there is an existing IESG statement on Internet-Draft Authorship: . For the IAB stream, see Section 1 of . For the IRTF stream, Section 4 of covers this topic. covers some general aspects of authorship ethics as background information. Aspects not covered by this document are left as operational choices for the streams and for the RFC Production Centre (RPC).

Authors Authors are people who have made a substantial creative contribution to the document. This means writing text or drawing diagrams, or making a key conceptual or intellectual contribution. Sometimes, with the consent of the other authors, it means making some other substantial creative contribution to the document, for example by writing a software implementation as part of the design process. People who did not make any such substantial contribution should not be listed as authors. It is also worth noting that in an RFC, authorship by an employee does not automatically imply endorsement by the employer. Therefore, authors should not be added just because of who they work for. In normal circumstances, people should never be listed as authors without their explicit permission. In case of doubt, the person submitting the draft should check with each listed author in advance to avoid any misunderstandings. If an author wishes to withdraw, this should be honoured, although the person may then be listed as a contributor or be mentioned in the acknowledgements. The practical impact is that the authors will be listed as such on the front page, and in public bibliographies, if the document becomes an RFC.

Organisational authors Some standards development organisations always remove individual authorship when a document is formally adopted. This is not done for RFCs. Historically, organisations have sometimes been listed as RFC authors, including both community organisations such as "IAB", "IESG", "IANA" and "RFC Editor", and various external organisations and companies. This is discouraged unless specifically requested by an RFC stream. An example is which shows "IAB and IESG" as an author and an individual as the editor.

Contributors Contributors are people who made smaller creative contributions to the document than the authors, for example providing initial ideas that others have transformed into publishable text, or drafting only a few paragraphs. People who did not make any such contribution should not be listed as contributors. People should not normally be listed as contributors without their explicit permission. The dividing line between contributors and authors is a matter of judgement and cannot be rigidly defined. It may vary between the various RFC streams. However, the RPC's practice is to query any document that has more than five listed authors. Any list of more than five authors must be approved by the relevant RFC stream's approving body.

Editors When a document has a large number of contributors and potential authors, it may be appropriate to designate one or two people as both "Authors" and "Editors" and list the others as contributors. RFC streams may have specific procedures for appointing editors, e.g. . The editors will indeed do the actual work of editing the document on behalf of the community. The practical impact of this is that the editors will be listed as such on the front page, and in public bibliographies, if the document becomes an RFC. In some cases, it may be appropriate to retain a list of authors of which one or two are designated as editors. Ideally, the people concerned should all feel happy that the designations of editors, authors and contributors are fair and accurate. Historically, RFC streams have chosen to retain the word "Author" in most cases, with the formal designation of editors being exceptional.

List of Acknowledgements Acknowledgements should be given to people who have made significant creative contributions smaller than those from the authors and contributors, or to people who have made useful comments, provided critical reviews, or otherwise contributed significantly to the development of the document. The dividing line between people who are acknowledged and those listed as contributors is a matter of judgement and cannot be rigidly defined. Acknowledgements may also be given to people or organizations that have given material support and assistance, but this should not include the authors' regular employers unless there are exceptional circumstances. An acknowledgement should be written as a description of a fact. It does not and should not signify that the person acknowledged agrees with or supports the document. In general, people who do not wish to be listed as an author or a contributor, but have in fact made a significant contribution, should be given an acknowledgement. In unusual circumstances, acknowledgements of contributions have specifically indicated that the contributor does not support the document as posted. Language such as the following might be used:

• Thanks to <insert names> for their valuable comments and help during the development of this document, even though they did not fully agree with the WG's conclusion.

When in doubt, it is usually better to include an acknowledgement than to omit it.

Revised or Replacement Documents A common occurrence is that an RFC from some years ago requires updating. This is often done by people who were not the original authors. The question then arises of whether to list the original authors on the "bis" draft, even if they are long gone from active participation. When an RFC is drafted by one or more new people but reuses significant amounts of text from one or more earlier RFCs, a situation arises that often requires thought and careful handling. The criteria above suggest that the authors of the original documents should continue to be listed as authors. After all, there is rarely any question that the earlier publications constitute "a substantial creative contribution" to the revised document. However, there are no guarantees that the prior authors will want to be listed as authors of the new draft and take on whatever responsibilities that implies. Ideally, those assembling the newer version will consult with the authors of the previous ones and make mutually acceptable arrangements, but, especially when that is not feasible, sensitivity to all possible issues will be needed.

Other Exceptions and Discussions It goes without saying that normally nobody should be listed as an author, contributor or editor against their will. Ideally, the parties involved will agree among themselves, or defer to the preference of the relevant RFC stream approving body. However, we need flexibility to deal with unusual cases, such as these:

• As noted above, an acknowledgement is a statement of fact (the person contributed to the discussion). In some cases it may be included even if the person acknowledged objects, for example if they made a suggestion that might later be viewed as prior art.
• Generalising the point made in , an earlier author or contributor may deserve to be listed, even if they cannot be contacted when a document is updated after a long interval. Each such case needs to be considered on its merits.
• In particular, an author or contributor might be deceased.

Artificial Intelligence Tools Authors will use various editing programs and other tools for document preparation, and in general these do not raise any ethical concerns. For example, if tables, graphs or diagrams are generated using a specialized software program, this is of no concern. If formal notation is verified by specialized software, this is also of no concern. If an AI tool is used for document preparation, the following guidelines apply:

• The authors or editors remain entirely responsible for any content generated by AI.
• The authors or editors remain entirely responsible for all intellectual property matters.
• An AI tool must not be credited as an author.
• If a substantial part of the document was created by AI this must be disclosed, typically in the Acknowledgements section.
• The authors or editors must verify that no unacceptable plagiarism has been performed by AI. If material from earlier RFCs or drafts (as discussed in ) has been copied by AI, this must be clearly acknowledged.
• If, on the other hand, AI usage has been limited to improving English grammar, translating from a draft in another language, or other purely editorial uses, this is no different in principle from older tools like spelling checkers, so disclosure is not necessary.

Disputes Disputes about authorship, editorship, contributors and acknowledgements for future RFCs will not be settled by the RPC and must be resolved by the relevant RFC stream according to its own procedures.

Intellectual Property Rights This document does not discuss intellectual property rights (IPR) and in no way preempts or alters the various RFC streams' rules and requirements concerning IPR. All authors are strongly advised to be familiar with the applicable rules, e.g. ,. It is worth noting that if a document includes complete acknowledgements and references, it will be simpler to clarify its status as possible prior art in years to come. Copyright in RFCs is governed by the IETF document , the IETF Trust/IPMC's Legal Provisions, and applicable national and international law. The word "contributor" used in this document might not mean the same thing as the word "Contributor" used in the IETF document .

Security Considerations None, really.

IANA Considerations This memo includes no request to IANA.

Change log [RFC Editor: please remove.] draft-carpenter-rswg-authoring-ethics-00, 2026-04-11:

• Original version (derived from draft-carpenter-whats-an-author-03).

draft-carpenter-rswg-authoring-ethics-01, 2026-04-23:

• Many small changes after first round of comments.
• Underline that each stream can make its own rules.
• Added very short section on dispute resolution.

draft-carpenter-rswg-authoring-ethics-02, 2026-05-xx:

• Further clarified that each stream may establish its own guidelines.
• Replaced "stream manager" by "approving body".
• Moved background material to Appendix, and trimmed it.
• Removed reference to academia.
• Removed reference to order of author list.
• Removed some redundancy.
• Numerous minor edits.

Informative References The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879. Internet Architecture Board From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. This memo provides information for the Internet community. RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats. This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document specifies the Editorial Stream for publication of future policy definition documents produced through the processes defined herein. Since the publication of RFC 9280, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. This document obsoletes RFC 9280. This document updates RFCs 7841, 7991, 7992, 7993, 7994, 7995, 7996, 7997, 8729, 8730, and 9720. This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors". This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844. This document describes the code of conduct for participants in the Internet Research Task Force (IRTF). The IRTF believes that research is most effective when done in an open and inclusive forum that encourages diversity of ideas and participation. Through this code of conduct, the IRTF continues to strive to create and maintain an environment that encourages broad participation, and one in which people are treated with dignity, decency, and respect. This document is a product of the Internet Research Steering Group (IRSG). IAB and IESG This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. This memo provides information for the Internet community. Univ. of Auckland This draft suggests guidelines for assigning authorship in IETF stream Internet-Drafts. It also discusses the related issues of acknowledgements, editors and contributors. Akamai Technologies Google LLC SOBCO The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document obsoletes RFC2418, and RFC3934. It also includes the changes from RFC7475, and with [_2026bis], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. RFC Editor IESG n.d. n.d. n.d. n.d.

Background

General Authorship Ethics There are some quite general aspects of the ethics of professional authorship of academic or technical documents. The most important requirements are as follows.

• Factual accuracy, including accuracy about who wrote the document.
• Avoidance of misleading or obfuscating statements.
• Avoidance of misleading omissions.
• Balance between opposing arguments.
• Acknowledgement and citation of sources and references.
• Identification of quoted material, and avoidance of unacknowledged plagiarism.
• Conflicts of interest should be made public.
• Corrections, clarifications and retractions should be made promptly when needed.

There are quite a few subjective judgements to be made about whether a contribution is substantial enough to count as authorship. Funding support, professional reputation, managerial or supervisory status, and CV embellishment are irrelevant. What fraction of new or corrected text counts? Is a particular concept or brilliant idea enough? Should the author of a previous trail-blazing document be invited to join? Should someone who promised to contribute significantly, but only contributed fragments, be removed? It is hard to give definite guidelines for such cases. Many academic journals and universities have published policies about authorship. Two examples from medical science are and . An example from mathematics is . The IEEE also has clear guidance . Some organisations have adopted strict policies about the use of artificial intelligence (AI) during document preparation, e.g., .

The RFC Series The Internet technical community that contributes to the RFC series has some peculiarities. Perhaps the most important is that we generally encourage the free flow of ideas and their re-use in fresh documents. In other words, internal plagiarism between RFCs is normal. Sometimes that means that small or large sections of text are copied from one document into another, and subsequently changed as the discussion evolves. Within the RFC series, we consider this to be normal procedure as long as due acknowledgement is given. Indeed, when technical text has been carefully verified in a previous RFC, reuse of existing text is an important tool to avoid restating a specification or concept, and possibly introducing new unintended interpretations which might cause interoperability issues. The only exception to this is an RFC that carries a "no derivative works" legend according to .

Acknowledgements Valuable comments on this document and its 2015 predecessor were received from Loa Andersson, Andy Bierman, Carsten Bormann, Scott Bradner, Dave Crocker, Jay Daley, Martin Dürst, David Farmer, Russ Housley, John Klensin (who also contributed some text), Larry Kreeger, Mirja Kuehlewind, Watson Ladd, Eliot Lear, Jean Mahoney, S. Moonesamy, Craig Partridge, Colin Perkins, Tom Petch, Alexandru Petrescu, Eric Rescorla, Michael Richardson, Rich Salz, Rob Sayre, Yaron Sheffer, Martin Thomson, and Joe Touch. Related mailing list discussions included Jay Daley, Joel Halpern, and Lucas Pardue. Especially given the topic of this draft, the author apologises for any accidental omissions.