NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Designating RFCs as Historic" dated 20 July 2014.
RFC 2026 states the following:
A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level.
In practice, the Historic status is not automatically assigned to RFCs that have been "obsoleted". That is, when an RFC that contains the "Obsoletes: RFC XXXX" header is published the RFC editor does not automatically apply the Historic status to the XXXX RFC. Note that in some situations this is perfectly acceptable because multiple versions of an Internet Standard are permitted to "honor the installed base," as per RFC 2026.
If authors wish to change the status of RFCs that are in the obsoletes header to Historic, then the authors must include an explicit statement for the RFC editor to do so; preferably in the introduction. Further, when an AD sponsors a draft that includes the obsoletes header, then the AD should ask the authors whether the authors intended to move the RFC(s) listed in the obsoletes header to Historic status.
If an author wishes to publish a document directly to Historic status the preferred approach is to publish an I-D with the "Intended Status: Historic" in the header.
As allowed by RFC 2026 Section 6.4, anyone may request that the IESG move an RFC to Historic that is simply and obviously obsolete (and in A/S terms "not recommended") without the need to produce an I-D. The IESG can issue Last Calls to request that the RFC in question be moved to Historic.
If a document (whatever its intended status) moves another document to "Historic" status, the Last Call should go out saying, "Last Call:to Informational and RFC XXXX to Historic", the document should be handled as a Protocol Action on the IESG agenda using IESG Protocol Action procedures, and a "Protocol Action" announcement should be sent out when the document is approved.
Moving a document to Historic status means that the document is "not [an] Internet Standards in any sense," as per RFC 2026.
The intent behind this policy is to balance people's legitimate desire not to be photographed with the IETF's ability to document activities and enable remote participation. The following policy applies to all IETF events, including WG meetings, plenaries, and the hackathon.
Many working groups work with open source repositories, even for their work on specifications.
There is a class of documents that help guiding a working group to agree on the problem(s) and even converge on a solution. These support documents can include, for example, problem statements, use cases, and requirements.
This statement published on 2016-01-11 provides IESG guidance on interim IETF working group meetings, both face-to-face and virtual.
The IETF has recognised that the act of accessing public information required for routine tasks can be privacy sensitive and can benefit from using a confidentiality service, such as is provided by TLS. [BCP188]
The IESG has received some reports of IETF participants having been listed as document authors on drafts without their consent ("surprised authorship").
RFC 2026 defines a "Historic" status for documents: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level.
This document describes the role of the 'DISCUSS' position in the IESG review process. It gives some guidance on when a DISCUSS should and should not be issued. It also discusses procedures for DISCUSS resolution.
The IESG is aware of discussions in the OPS area and in a number of working groups about the current practice for standards-based approaches to configuration.
This IESG statement explains that the IETF strives to create and maintain an environment in which people of many different backgrounds are treated with dignity, decency, and respect.
The IEEE Registration Authority (IEEE RA) assigns Ethertypes with oversight from the IEEE Registration Authority Committee (IEEE RAC).
Internet-Drafts (I-Ds) are working documents of the IETF. RFC 2026, BCP 9, describes the purpose of I-Ds, and it also provides some policies that govern the I-D Repository.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Designating RFCs as Historic" dated 20 July 2014.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Designating RFCs as Historic" dated 20 July 2014.
This IESG statement describes the manner in which the IESG will process RFC Errata concerning RFC Metadata [RFC5741].
This statement provides guidance from the IESG on selection of a Document Shepherd for documents from IETF working groups and documents from individuals.
Protocol specifications and other documents intended for RFC publication often include useful examples with correctly formatted and syntactically valid codepoints, addresses or names.
RFC 3777 requires that voting members of the nominating committee (NomCom) be selected from volunteers that have attended at least three of the last five IETF meetings.
The IESG is providing this guidance to align current practice with RFC 5377, RFC 5378, and the resulting IETF Trust Legal Provisions (TLP). This IESG Statement obsoletes all earlier IESG Statements regarding Copyright statements in MIB and PIB Modules.
This IESG Statement deals with the proposed status for IETF documents reserving values, numbers, addresses, etc. for example purposes. In this statement we use the term 'resources' for these values, numbers, addresses, etc.
This statement dated 2008-09-02 provides IESG guidance on interim IETF Working Group meetings, conference calls, and jabber sessions. NOTE: This statement is superseded by the IESG Statement "Guidance on Face-to-Face and Virtual Interim Meetings" dated 2016-01-11.
The [below] describes the manner in which the IESG will be processing RFC Errata for the IETF Stream. The current tools on the RFC Editor site support "approved" and "rejected", but they need to be updated to also permit "hold for document update" as errata states.
The following principles apply to spam control on IETF mailing lists:
RFC4395: Guidelines and Registration Procedures for New URI Schemes
This IESG statement covers the guidelines in RFC3406 on the requirements for registering new formal namespaces include several review steps.
This statement provides advice to Chairs for dealing with off-topic posts to Working Group mailing lists.
The IESG re-affirms that its reading of RFC 2026 is that any action made by an Area Director or the IESG may be made the subject of the conflict resolution mechanisms set out in Section 6.5 of RFC 2026.
This document describes the process that the IETF transport area directors employ when new congestion control algorithms that differ significantly from currently-published IETF standards are brought to the IETF for specification and publication as Experimental RFCs.
This statement discusses the process related to "individual submissions", publication of RFCs by finding a sponsoring Area Director to take it through IETF and Internet Engineering Steering Group (IESG) review. This statement covers both the the processing in the IESG as well as guidance on when such sponsoring is appropriate.
Under RFC 2026, the IESG issues Last Calls to the IETF community for all draft Standards Track and BCP documents, and for selected draft Informational and Experimental documents.
Nearly all RFCs contain citations to other documents, and these are listed in a References section near the end of the RFC.
The IESG today makes the following statement, but will welcome community feedback on it.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Spam Control on IETF Mailing Lists" dated 14 April 2008.
The IESG has decided that as of now, any IESG-approved drafts that enter the AUTH48 state, where the RFC Editor waits for final text approval from all listed authors, may be released on the responsible AD's authority if any authors have not responded after a reasonable time, typically two weeks.
The IESG does not prescribe the use of any single syntax for format definitions.
IDNA [IDNA] specifies an encoding of characters in the Unicode character repertoire [UNICODE] which is backwards-compatible with the current definition of hostnames.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Copyright" dated 8 September 2009.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Spam Control on IETF Mailing Lists" dated 14 April 2008.
Design teams are mentioned in The Working Group Guidelines RFC (RFC 2418) as follows:
This temporary guideline has been prepared by the IESG in response to a specific case; it is intended that it be put into an Internet-Draft and progressed as an IETF consensus position.
NOTE: This statement formed the Sub-IP Area, and this Area has subsequently been closed.
Two weeks ago I sent a message informing the community of some plans to improve the organization of some significant work going on in the IETF on "sub-ip" technologies.
It has become increasingly clear that the IETF needs to develop a systematic approach to dealing with what we used to describe as "sub-IP" technologies. This approach should be able to help clarify what specific technologies the IETF should work on, what technologies we should forward to other organizations, and what technologies we need to work with other organizations to develop.
This is the IESG "Statement Guidance on Interim IETF Working Group Meetings and Conference Calls" dated 2000-08-29 . NOTE: This IESG Statement is superseded by the IESG Statement "Guidance on Interim Meetings, Conference Calls and Jabber Sessions" dated 2 September 2008.
In some cases, it is necessary and appropriate to moderate IETF mailing lists.
