According to abbreviationfinder, IEFT stands for Internet Engineering Task Force. An open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet ‘s architecture and the proper functioning of the Internet. It is open to anyone interested. The IETF’s mission is documented in RFC 3935.
The Internet Engineering Task Force (IETF) develops and promotes Internet standards, collaborating closely with the W3C and ISO/IEC, standards bodies and those concerned in particular with the standards of the TCP/IP protocol and the Internet protocol suite. It is an open standards organization, with no formal participation or membership requirements. All participants and administrators are volunteers, although their work is often funded by their employers or sponsors.
The IETF is organized into a large number of working groups and informal discussion groups (BOFs), each devoted to a specific topic. Each group intends to complete work on that topic and then disband. Each working group has an appointed chair (or sometimes multiple co-chairs), along with a charter outlining its focus, and what and when it is expected to deliver.
The working groups are organized by themes. Current areas include: Applications, General, Internet, Real-time Application Operations and Management, and Infrastructure, Routing, Security, and Transport. Each area is overseen by an area director (AD), with most areas having two co-ADs. Area directors are responsible for appointing task force chairs. The area directors, along with the IETF Chair, form the Internet Engineering Steering Group (IESG), which is responsible for the overall operation of the IETF.
The IETF is formally part of the Internet Society. The IETF is overseen by the Internet Architecture Board (IAB), which oversees foreign relations, and relations with the RFC Publisher. The IAB is also co-responsible for the IETF Administrative Oversight Committee (IAOC), which oversees the IETF’s Administrative Support Activity (IASA), which provides logistical support, etc., for the IETF. The IAB also manages the Internet Research Task Force (IRTF), with which the IETF has a number of relationships through the group.
The first meeting of the IETF was on January 16, 1986, made up of 21 researchers funded by the US government. It was a continuation of the work of the previous EADG Task Group.
Initially, it met quarterly, but as of 1991, it has met three times a year. Representatives of non-governmental entities were invited from the fourth meeting of the IETF, in October of that year. Since then all IETF meetings have been open to the public. Most of the IETF’s work is done on mailing lists, and meeting attendance is not required for contributors.
The first meetings were very small, with fewer than 35 people in attendance at each of the first five meetings. Peak attendance for the first 13 games was just 120 in attendance. This happened at the 12th meeting held in January 1989. These meetings have grown in both participation and scope considerably since the 1990s, which had a peak attendance of nearly 3,000 at the December 2000 IETF meeting in San Diego, California. Attendance dropped due to industry restructuring during the early 2000s, and is currently around 1,200.
During the 1990s the IETF has changed its institutional form from being a US government activity to an independent, international activity related to the Internet society.
The IETF’s mission is to make the Internet work better by producing high-quality technical documents that influence the way people design, use, and manage the Internet.
The IETF will continue this mission by adhering to the following cardinal principles:
Open process – anyone interested can participate in the work, find out what was decided, and have their voice heard on the issue. Part of this principle is your commitment to make your documents, your Working Group mailing lists, your attendance lists, and your meeting minutes publicly available on the Internet.
Technical expertise – the topics on which the IETF produces its documents are topics that the IETF has the expertise to discuss, and that the IETF is willing to listen to technically competent input from any source. Technical competence also means that the IETF output is expected to have to be designed to look like network engineering principles – this is also often referred to as “quality engineering”.
Core Volunteers – Participants and leadership are people who come to the IETF because they want to do work that furthers the IETF’s mission of “making the Internet work better.”
Consensus and Code Execution – Makes standards based on the combined engineering judgment of its participants and their real-world experience in applying and deploying the specifications.
Protocol Ownership – When the IETF takes ownership of a protocol or function, it accepts responsibility for all aspects of the protocol, even though some aspects may very rarely or never be seen on the Internet. In contrast, when the IETF is not responsible for a protocol or function, it does not try to exercise control over it, although it can sometimes touch or affect the Internet.
The details of its operations have changed considerably as it has grown, but the basic mechanism remains publication of a draft specification, independent review and testing by participants, and re-publication. Interoperability is the primary test of IETF specifications becoming standards. Most of its specifications focus on individual protocols rather than strongly intertwined systems. This has allowed its protocols to be used in many different systems, and its standards are systematically re-used by organizations creating full-fledged architectures (eg 3GPP IMS).
Because it is volunteer-based and uses fuzzy consensus and code execution as its cornerstone, results can be slow when the number of volunteers is too small to advance, or so large as to make consensus difficult, or when volunteers lack the necessary experience. For protocols like SMTP, which is used to transport Email for a community of users numbering in the many hundreds of millions, there is also considerable resistance to any changes that are not fully supported. Work within the IETF on ways to improve the speed of the standards-setting process is ongoing, but because the number of volunteers with input in it is so large, consensus mechanisms on how to improve They have been slow.
Because the IETF has no members (nor is it an organization in itself), the Internet Society provides the financial and legal framework for the activities of the IETF and its related bodies (IAB, IRTF,…). Recently, the IETF has created an IETF conglomerate that manages the copyrighted materials produced by the IETF. IETF activities are funded by meeting fees, meeting sponsors, and by the Internet Society through its membership in the organization and the resources of the Public Interest Registry.
IETF meetings vary widely in where they are held. The list of past and future meeting locations can be found on the IETF Meetings page . The IETF has made an effort to hold meetings close to where most volunteers are. For a long time, the goal was 3 meetings a year, with 2 in North America and 1 in Europe or Asia (alternating between them every two years). The goal ratio is currently, over a two-year period, to have 3 in North America, 2 in Europe, and 1 in Asia. However, corporate sponsorship of meetings is often a more important factor and this program has not been strictly adhered to in order to lower operating costs.
The Internet Standards Process
The basic definition of the IETF standards process is found in RFC 2026 (BCP 9). However, this document has been modified several times. The intellectual property rules are now separate, in RFC 5378 (BCP 78) (contribution rights) and RFC 3979 (BCP 79) (technology rights). Another update is RFC 3932 (BCP 92) (independent communications to the RFC Editor). An overview of the process for many documents is available in the IETF Process: An Informal Guide.
The process of creating an Internet standard is straightforward: a specification that undergoes a period of development and several iterations of review by the Internet community and revision based on experience, is adopted as a standard by the appropriate authority, and is published. publish. In practice, the process is more complicated, due to the difficulty of creating high-quality technical specifications, the need to consider the interests of all affected parties, the importance of establishing a broad community consensus, and the difficulty of evaluating the usefulness of a particular specification to the Internet community.
The goals of the Internet Standards Process are
- Technical excellence;
- Before application and testing;
- Clear, concise and easy to understand documentation;
- Openness and fairness
The goal of technical competence, the prerequisite for implementation and testing, and the need for all interested parties to comment require a lot of time and effort. On the other hand, the rapid development of today’s networks, demands timely technological development of standards. The Internet standardization process is intended to balance these conflicting goals. The process is believed to be as short and simple as possible without sacrificing technical excellence, extensive testing prior to the adoption of a standard, or openness and fairness.