Independent Submission S. Moonesamy Internet-Draft 9 September 2026 Intended status: Informational Expires: 13 March 2027 Reflections on IETF Authorship draft-moonesamy-authorship-ietf-00 Abstract [RFC825] was intended to provide guidance to authors of future RFCs. The memo also listed several reasons for publishing a memo as an RFC. It did not discuss who would be listed as author. This memo discusses authorship within the IETF and the use of generative Artificial Intelligence for IETF RFCs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 13 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Moonesamy Expires 13 March 2027 [Page 1] Internet-Draft Reflections on IETF Authorship September 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Authorship . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Request for Comments . . . . . . . . . . . . . . . . . . . . 3 4. IETF RFC . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Artificial Intelligence . . . . . . . . . . . . . . . . . . . 3 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction [RFC825] was intended to provide guidance to authors of future RFCs. The memo also listed several reasons for publishing a memo as an RFC. It did not discuss who would be listed as author. 2. Authorship Discussions of authorship within IETF working groups go as far back as 1995. An IETF Area Director set a policy to only have the editor listed on the front page of a RFC. The first description of an editorial policy for RFCs was in [RFC1543]. The memo discussed listing the author's name on the front page of a RFC. [RFC1603] defined staff roles which would be conducive to the proper functioning of an IETF working group. The task of working group Editor/Secretary was described as editing working group documents. [RFC2418] described two roles; a working group Secretary role, and a Document Editor role. The task of working group Secretary was described as editing working group documents. The task of the Document Editor was to serve as the editor for a particular document. In 2002, the RFC Editor announced that there growing tendency towards long lists of authors on RFCs. The RFC Editor argued that while most standard bodies publish anonymous standards, the practice in the RFC Series was to attach the names of real people, who get both credit and blame, for the RFC. The Acting RFC Series Editor discussed the question of author overload in 2011 as huge author lists were causing practical and ideological objections. It was viewed as impractical to have a huge author list on the front page of a RFC as there would not be any space left to include the Abstract Section on the first page. The Moonesamy Expires 13 March 2027 [Page 2] Internet-Draft Reflections on IETF Authorship September 2026 Internet community's tradition, according to the Acting RFC Series Editor, was to focus on the author as an individual instead of the author's affiliation being used as a demonstration of corporate interest in a specification. 3. Request for Comments RFC was an acronym for Request for Comments. [RFC1111] updated the instructions to authors of RFCs. A requirement for an Author's Address was described in the memo. The objective of that requirement was to inform the reader about how to contact the author to send him/ her comments. The acronym would be a misnomer if an RFC did not include any information on how to contact the author. The title of the contact section of a RFC was initially "Author's Address". The intent, in 2004, was to change the title to "Contact Information" The RFC Editor did not follow through by making the change. 4. IETF RFC The term "IETF RFC" initially appeared in [RFC3160] in 2001. It marked the formal introduction of the term as the acronym outgrew its initial scope. The term was used interchangeably to mean IETF standard. The number of authors was limited to five in response to discussions within the IETF. The argument was that there were industry participants vying to be credited as authors of IETF RFCs. It is odd to list more than five authors on the front page of an IETF RFC while claiming that the memo represents IETF consensus. 5. Artificial Intelligence There was an IETF thread on using generative Artificial Intelligence (AI) to write Internet-Drafts in 2025 [i-d-genai]. The number of Internet-Draft submissions increased significantly in 2026 [i-d-heatmap]. The change could be explained by a decrease in the skills needed, mainly through the general availability of generative AI, to write an Internet-Draft. A move from Internet-Draft to IETF RFC is possible, assuming that there is IETF consensus on the Internet-Draft and it is approved by the Internet Engineering Steering Group (IESG). "Software engineers find it difficult to interpret specifications in large part because natural language can be ambiguous" [yen]. Should the Internet community be expected to adopt or implement IETF specifications (RFCs) which were written using generative AI? Moonesamy Expires 13 March 2027 [Page 3] Internet-Draft Reflections on IETF Authorship September 2026 The IETF community side-stepped the issues surrounding authorship and editorship since 1995. There were recurring questions regarding authors, contributors, and acknowledgments over the years[sb][rpc]. There was an appeal to the IESG in 2013 regarding acknowledgements. Could the IETF community shape up procedural guidelines on the use of generative AI for authorship/editorship or could it side-step the question by leaving it to author/editor discretion? A "cut and thrust" discussion is a quick exchange of arguments. It is generally viewed as a spontaneous discussion as the speaker cannot make extensive use of a pre-written script. A working group could consider it for verbal discussions of an Internet-Draft with the author. That would give working group attendees a sense of the human element. 6. Security Considerations Security issues were not discussed in this memo given that it is a reflection about authorship within the IETF. 7. IANA Considerations This memo does not require any IANA actions. 8. References [RFC825] Postel, J., "Request for comments on Requests For Comments", RFC 825, DOI 10.17487/RFC825, November 1982, . [RFC1111] Postel, J., "Request for comments on Request for Comments: Instructions to RFC authors", RFC 1111, DOI 10.17487/RFC1111, August 1989, . [RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, DOI 10.17487/RFC1543, October 1993, . [RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and Procedures", RFC 1603, DOI 10.17487/RFC1603, March 1994, . [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, . Moonesamy Expires 13 March 2027 [Page 4] Internet-Draft Reflections on IETF Authorship September 2026 [RFC3160] Harris, S., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", RFC 3160, DOI 10.17487/RFC3160, August 2001, . [i-d-genai] Snijders, J., "BCP 78 policy / copyright / Generative AI / LLM .. is there a FAQ?", August 2025, . [i-d-heatmap] Moonesamy, S., "IETF -00 Draft Submissions Seasonality Heatmap", URL https://www.elandsys.com/r/88015, September 2026, . [yen] Yen, J., Lévai, T., Ye, Q., Ren, X., Govindan, R., and B. Raghavan, "Semi-Automated Protocol Disambiguation and Code Generation", DOI 10.1145/3452296.3472910, ACM SIGCOMM Conference pp. 272–286, August 2021, . [sb] Bradner, S., "RE: How IETF treats contributors", August 2004, . [rpc] Mahoney, J., "[Rswg] RPC procedures regarding authors, contributors, and acknowledgments", August 2026, . Author's Address Subramanian Moonesamy Email: sm+ietf@elandsys.com Moonesamy Expires 13 March 2027 [Page 5]