A new page, "RFC Status Changes", has been released that lists the RFCs whose statuses have changed since publication. The list indicates the date of the status change and links to the Document or Protocol Action or the RFC requesting the change are provided where possible.
In addition, the RFC Editor is retiring the practice of publishing RFCs xx99, the Request for Comments Summary for RFC Numbers xx00-xx99 because this information is readily available online (e.g., search results). RFC numbers typically reserved for these documents (i.e., numbers ending with 99) may be assigned to future RFCs. See the message to the IETF Announce list and the discussion on the RFC Interest list for more information (October and November mail).
On 14 March 2013, the IAB approved for publication the RFC Series Format Requirements and Future Development draft. This document sets the current requirements and direction for the format of RFCs and indicates that there will be changes forthcoming to both the traditional 100% ASCII format as well as to the RFC Style Guide.
2012 was a intense year of progress and change for the RFC Editor. With a new RFC Series Editor, a revival of the RFC Format discussion, several changes to the RFC Editor website, the beta rollout of a new search page, and 338 RFCs published, the RFC Editor is picking up the pace for an even more intense 2013. 2013 starts with final comments being received on the RFC Format Requirements draft and ramp up of the work on the Style Guide.
The RFC Series Format Development draft describing the requirements for changes in the format for RFCs has been posted. Discussions regarding the requirements will ooccur on the rfc-interest mailing list and at a BoF at IETF #85.
The focus this month, updating information on Copyright. See RFC Copyrights & IPR and RFC Editor Guidelines and Procedures.
Curious about the latest editorial queue stats? They are looking good: Current Stats
A new mail list was created to handle email that is specifically related to the Independent Submission stream process (rfc-ise@rfc-editor.org).
See the related announcement for more information.
http://www.rfc-editor.org/pipermail/rfc-interest/2010-February/001729.html
Even before the Web was invented, ISI offered an SMTP-based online search and retrieval service. With a few software patches over the years, this now rather crufty Perl code has continued to provide service.
However, maintenance of this very old code is not feasible, so ISI and AMS did not attempt to transition it to AMS. The RFC Editor has decided to de-commit the rfc-info service. It is rare today that a user does not have access to a web browser. However, the rfc-info mailbox has been redirected to rfc-editor@rfc-editor.org, and Production House staff will respond to email to the old address.
Transition from USC/ISI to AMS will take place on 12 January 2010. During this time, the static RFC Editor pages at rfc-editor.org will continue to be available, including RFC and errata search and retrieval. However, the errata submission and verification portals will be temporarily disabled. Additionally, email sent to the RFC Editor will not be read or processed until after the transition is complete. For more information, please see the announcement available at http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=7324&tid=1263251951.
The IETF Trust has adopted a new version of the Trust Legal Provisions (TLP 4.0), which addresses the requests from the RFC Editor (RFC 5744), the IRTF (RFC 5743), and the IAB (RFC 5745) for the Trust to manage the outgoing rights for documents originating in their streams.
The approval of TLP 4.0 allows for the Independent and the IRTF stream documents to be published. The RFC Editor will be working to update the files accordingly and will contact the authors when the updated documents can be viewed.
With the publication of RFC 5741, the headers and boilerplate material for each document has changed. RFC document headers will now indicate the stream that originated the document, and the Status of This Memo will indicate the level of review associated with the document. Julian Reschke has put together a document that details the various combinations; please see http://greenbytes.de/tech/webdav/draft-reschke-hab-05.html.
The publication of Independent and IRTF stream documents continues to be suspended while the streams work with the Trust to identify the appropriate copyright for these documents.
As of 1 July 2009, the RFC Editor is publishing RFCs with the
abstract placed between the title and the Status of This Memo. For
more details, see our announcement at
http://mailman.rfc-editor.org/pipermail/rfc-interest/2009-June/001373.html.
On 12 February 2009, the IETF Trust announced a revision to the "Legal Provisions Relating to IETF Documents", effective 15 February 2009, which contains optional text in Section 6.c.iii to address the issue of pre-RFC 5378 material. Please review RFC 5378 and the text located at http://trustee.ietf.org/license-info/. The RFC Editor will update the copyright notice and legends of documents in our queue accordingly.
For more information regarding the copyright notice and legends, please see the discussion at ietf@ietf.org. Also, you can send copyright questions to copyright-questions@ietf.org.
Independent Submissions publications are on hold until the RFC Editor has made a decision regarding the copyright to be applied to Independent stream documents. This is in progress and we expect to have this issue resolved shortly.
The publication of BCP 78/RFC 5378 has caused some transitional issues that require the RFC Editor to temporarily suspend publication. The RFC Editor is only publishing RFCs if each author explicitly approves the RFC 5378 copyright notice and legends. If the authors cannot agree to the terms of the RFC 5378 copyright notice and legends, the document will be placed on hold until the issues have been resolved.
The publication of BCP 78/RFC 5378 has caused some transitional issues that require the RFC Editor to temporarily suspend publication. We are working with the appropriate parties to determine the process moving forward. We will provide an update shortly and an email to explain the proper process.
With the publication of BCP 78/RFC 5378, "Rights Contributors Provide to the IETF Trust", the RFC Editor has adopted a new IETF copyright policy. The RFC Editor will now include the following Copyright Notice, which will appear on the front page of RFCs:
Copyright (c) YYYY 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 (http://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.
The Full Copyright Statement, which was the standard last page of an RFC, will no longer be included in RFCs.
Please see Legal Provisions Relating to IETF Documents for more details.
Additionally, Independent Submissions publications are on hold until the RFC Editor has made a decision regarding the copyright to be applied to Independent stream documents. This is in progress and we expect to have this issue resolved shortly.
The RFC series has now been assigned a universal ISSN number, bringing it into the world of librarians. This number is displayed on the main web page.
The file queue.html is updated daily to display the current "Publication queue" button on the main web page. We recently created a new version of this queue, file queue2.html (http://www.rfc-editor.org/queue2.html). Its major new features are:
The "Publication Queue" link on the main page now points to queue2.html. However, we intend to maintain queue.html as well as queue2.html, so that queue.html can be a stable source for "screen scrapers".
Corresponding to the new queue2.html, there is also a queue2.xml. This differs from queue.xml in tag changes to more accurately reflect component semantics. Additional informartion may be added to queue2.html, .xml in the future.
The RFC Editor has transitioned to a new errata system, which allows for online errata submission. Please see:
http://www.rfc-editor.org/errata.php
The records have been updated to include all reports from the pending file.
The process allows for SSPs (stream-specific parties) to edit, verify, or reject reports using an online verification system.
With the approval of the IAOC, the RFC Editor will make two minor changes (deletions) from the standard RFC boilerplate in future RFC publications.
First, the "Copyright (C) The IETF Trust" declaration will be removed from the front page of future RFCs. We have known for a long time that this declaration is redundant with the complete boilerplate at the end of the documents, but inertia kept it alive. Second, the funding acknowledgment to the Internet Society at the end of the document will be removed. This acknowledgment was added around 1998 when funding shifted from US Government to the Internet Society, and at a time when the Internet Society was not yet closely linked into the IETF community. Much has changed since then, including the establishment of the IAOC and the IAD. The funding acknowledgment no longer seems necessary, and it will be dropped from future RFCs.
In October 2006, the RFC Editor published RFC 4748 as an update to RFC 3978, which concerns RFC copyrights. Together, these documents form BCP 78.
RFC 3978 obsoletes RFC 3667 as BCP 78. The revisions incorporate very minor changes in the boilerplate to recognize the IETF Trust. The RFC Editor's copyright web page was updated accordingly. This web page also has links to previous versions of the RFC Editor copyright rules.
As we have added new material over the past 8 years, the RFC Editor web site has grown increasingly confusing. We have now updated the main page and several of the subsidiary pages. The result should be to make the more important information immediately available and to make it easier to find what you want. Please address comments and suggestions to us at rfc-editor@rfc-editor.org.
Over many years, Joyce has made major contributions to the IANA, to the RFC Editor, and to the IETF.
She worked with Jon Postel to perform the IANA functions, leaving her name on many related RFCs. She was IANA liaison to the IESG 1998-2001 and consulted with IANA after they separated from ISI. She played a key early role in shaping the protocol parameter registration function.
Joyce has been a member of the IETF since 1988. She developed, organized, and led the User Services area of the IETF from 1988-1998, and was thus an IESG member. In her User Services role, she was an international keynote speakder and panelist in over 90 conferences around the world, spreading the word on the Internet. She established the user-service oriented document subseries of RFCs, the FYIs. She worked with Jon on documenting a number of protocol specifications, including POP, FTP, and Telnet Options.
For a number of years, Joyce worked with Jon Postel on editing RFCs. Since 1998, she has been co-leader of the RFC Editor function, and she performed the final quality control function on most RFC publications. She also served as RFC Editor liaison to the IAB and to the IESG. Her knowledge of the IETF process and community and her good judgment were immensely helpful, and we will miss her help and advice a great deal.
We expect that Joyce will still have a presence in the IETF, but she will be much missed at ISI! We know that Jon Postel joins us in wishing her the very best future in her new job.
As part its role in supporting the RFC Editor function, the Internet Architecture Board (IAB) has created a public mailing list for the discussion of the RFC Independent Submissions process. The purpose of this discussion is to achieve consensus, in the coming weeks, on a process for fair and appropriate approval of independent submissions to the RFC series. These are separate from IETF, IAB or IRTF approved submissions. Individuals familiar with the RFC series and working in the Internet research and engineering community are invited to join this mailing list and participate. independent < at > ietf.org http://www1.ietf.org/mailman/listinfo/independent There is an initial draft proposal, available at http://www.ietf.org/internet-drafts/draft-klensin-rfc-independent-02.txt
Here are examples of such messages:
The document draft-ietf-sipping-conferencing-framework-05 has hanged from EDIT*R state to RFC-EDITOR state. The document draft-ietf-avt-uncomp-video-ext-01 has changed from EDIT*A state to EDIT state.
If present, the suffix "*A" in the state listed in this message means: "IANA actions are needed". This is an encoding of the keyword "IANA" in the queue entry for the Draft.
If present, the suffix "*R" in the state listed in this message means: "Contains one or more normative references to drafts that are not yet published." Any such references are detailed after the keyword "REF" in the queue entry for the Draft.
One feature has been added to the queue: each normative reference entry ("REF") now indicates whether the referenced document is in the queue. Our current policy is to not begin editing a document until all its normative references are also in the queue (or already published, of course). For example, the following partial entry shows a document in the EDIT state with two unpublished Normative references, one of which has not been received by the RFC Editor:
2005-03-31 draft-ietf-simple-event-filter-funct-05.txt EDIT REF draft-ietf-simple-event-list NOT-RECEIVED draft-ietf-simple-filter-format IN-QUEUE
RFC 3978 obsoletes RFC 3667 as BCP 78, and RFC 3979 obsoletes RFC 3668 as BCP 79. The revisions incorporate very minor changes in boilerplate. The RFC Editor's copyright web page was updated accordingly. This web page also has links to previous versions of the RFC Editor copyright rules.
http://www.rfc-editor.org/queue.html#draft-name
where "draft-name" is the stem of the Internet Draft name, without the version number or .txt suffix. For example, try:
http://www.rfc-editor.org/queue.html#draft-ietf-sip-referredby
EG try searching for 3885.
This list was created to facilitate community discussion on the RFC series and to make suggestions about RFC Editor functions. The RFC Editor hopes that this mailing list will provide a focal point for input, information, and discussion about the details of the RFC process, as well as an archive to avoid the continual re-hashing of some issues. Topics appropriate to this list may include formatting, tools, style, content, and indexing aspects of the RFC series. It will not be used for discussion of the IETF standards process, general IETF organizational issues, or issues for which the NOTE WELL admonition is needed for IPR reasons. The posting policy is subscriber-only to reduce spam. It will initially be unmoderated, but the RFC Editor will cut off any discussions that are inappropriate according to the guidelines above. Subscribe at the following address:
http://www.rfc-editor.org/mailman/listinfo/rfc-interest
Archives are available at:
http://www.rfc-editor.org/pipermail/rfc-interest/
For the implications of these new rules for RFCs, see the new RFC Editor web page.
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
Corresponding to every ASCII file ftp://ftp.rfc-editor.org/in-notes/rfcxxxx.txt, there is a PDF file:
ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfcxxxx.txt.pdf.
The RFC search engine at www.rfc-editor.org/rfcsearch.html now has buttons labeled:
RFC File: [X] ASCII+ [ ] PDF.Choosing "PDF" will return the PDF version when the Number hyperlink is activated.
In addition, the standardized MIBs defined in RFC1229-1233 are now in the directory.
Meanwhile, we have a particular problem with RFC1142, a very large and complex RFC (OSI IS-IS definition). We found that both the .ps and the .txt files were mangled. Dave Oran supplied us with the original base document, which is in .pdf. We have used it to renew rfc1142.ps and are working on converting it to a new rfc1142.txt (stay tuned). In any case, it seemed desirable to make the original .pdf file available in the RFC editor archive, so rfc1142.pdf has appeared.
In general, we want to encourage the inclusion of a TOC in all except the shortest RFCs. A TOC of the appropriate density can be a significant aid to readers. Note that automatic TOC generation by your text preparation tool may produce a TOC that is too dense (and long) to be really useful. If many successive TOC entries point to the same page, your TOC probably needs to be "thinned".
The TOC must be positioned after the Abstract and before the Introduction section (i.e., after the boiler plate and before the body) of your RFC.