IESG Statement on Ethertypes
The IEEE Registration Authority (IEEE RA) assigns Ethertypes with oversight from the IEEE Registration Authority Committee (IEEE RAC).
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 IEEE Registration Authority (IEEE RA) assigns Ethertypes with oversight from the IEEE Registration Authority Committee (IEEE RAC).
RFC4395: Guidelines and Registration Procedures for New URI Schemes
RFC 3406: URN Namespace Definitions
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.
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 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.
Traditionally the IETF has focused its efforts "above the wire and below the application."