The IEEE Registration Authority (IEEE RA) assigns Ethertypes with oversight from the IEEE Registration Authority Committee (IEEE RAC).
(See http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF protocol specification make use of Ethertypes. All Ethertype requests are subject to review by a consultant to the IEEE RA followed by IEEE RAC confirmation.
Since Ethertypes are a fairly scarce resource, the IEEE RAC has let us know that they will not assign a new Ethertype to a new IETF protocol specification until the IESG has approved the protocol specification for publication as an RFC. In exceptional cases, the IEEE RA is willing to consider "early allocation" of an Ethertype for an IETF protocol that is still under development as long as the request comes from and has been vetted by the IESG.
To let the IEEE RAC know that the IESG has approved the request for an Ethernet assignment for an IETF protocol, all future requests for assignment of Ethertypes for IETF protocols will be made by the IESG.
Note that playpen Ethertypes have been assigned in IEEE 802 [1] for use during protocol development and experimentation.
[1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001).
IEEE standard for Local and Metropolitan Area Networks:
Overview and Architecture -- Amendment 1: Ethertypes for
Prototype and Vendor-Specific Protocol Development.
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.
