Introduction
The ultimate goal of the IDMEFv2 Task Force is to publish one or more IETF RFCs about IDMEFv2. The process of standardization is long and complex. It’s also very unsure as hopefully not all proposition are accepted. Not all RFCs are equivalent, depending on the maturity of the standards described: proposed standards, drafts standards RFCs , internet standards RFCs ,informational RFCs, experimental RFCs, etc.
Obviously, IDMEFv2 is a very new format, it is still experimented, it needs to be more experimented. IDMEFv2 propose a solution to upcoming problems with convergence of cybersecurity and physical security. So out goal is not to define a final Internet Standards but to document a detailed format so people can use it, improve it and maybe one day end up with a real internet standard.
Although IETF working groups have been working on IDMEFv1, IODEF (Incident Object Definition Exchange Format) V1 and more recently V2, most of the standards defined by IETF are protocols. IDMEF is definitely a format and the transport is not very important and can be of multiple type (HTTP, Kafka, AMQP, etc.)
In 2020 an official Charter (which aimed a cyber format with inclusion of IoT) has been sent to IETF. At the same date we started collaboration with the 7Shield project an its cyber and physical needs. The decision was taken at the time to consolidate a first draft of a cyber-physical incident format then to go back to IETF to start standardization.
This time has come, V01 draft should be ready pretty soon (T2 2023)
The rest of this page details the way IETF works to prepare the next step of our work.
IETF : Internet Engineering Task Force
The Internet Engineering Task Force (IETF) is a large open community of network designers, operators, vendors, and researchers who are dedicated to the evolution and smooth operation of the Internet. It is an international organization that develops and promotes Internet standards, protocols, and procedures through a consensus-driven process.
The IETF’s mission is to make the Internet work better by producing high-quality, relevant technical documents that influence the way people design, use, and manage the Internet. The IETF has a number of working groups that focus on specific technical areas such as routing, security, and applications, as well as cross-cutting areas such as architecture and management. These working groups develop Internet standards and protocols through an open, collaborative process that involves input and feedback from experts and stakeholders around the world.
The IETF has been in existence since 1986 and has played a critical role in the development of the Internet as we know it today. Its contributions include the development of key Internet protocols such as TCP/IP, HTTP, and SMTP, as well as many other standards and guidelines that are widely used by network designers, operators, and users.
RFC : Request For Comments
An RFC (Request for Comments) is a document published by the Internet Engineering Task Force (IETF) that describes a proposed standard, protocol, or other technical topic related to the Internet. RFCs are the primary means by which the IETF develops and publishes technical specifications and standards for the Internet. RFCs are numbered sequentially, and each RFC has a unique number that identifies it.
RFCs may describe a wide range of topics, including networking protocols, Internet architecture, security standards, and other technical subjects. They may be authored by individuals, groups, or organizations within or outside of the IETF. RFCs are generally reviewed and commented on by the broader Internet community before they are finalized, and they may be revised and updated over time as new information or requirements emerge.
Types of RFCs
There are several types of Request for Comments (RFCs) published by the Internet Engineering Task Force (IETF). The different types of RFCs are used to categorize and differentiate between different types of documents, depending on their purpose and status. Some of the most common types of RFCs are:
- Standards Track RFCs: These RFCs define protocols, procedures, or conventions that are intended to be implemented and widely deployed on the Internet. Standards Track RFCs are further divided into several categories, including:
- Proposed Standard RFCs: These RFCs describe a protocol or specification that is well understood and has been reviewed by the IETF community, but may still undergo some changes before being widely deployed.
- Draft Standard RFCs: These RFCs describe a protocol or specification that is believed to be stable and ready for implementation, but may still be revised based on implementation experience.
- Internet Standard RFCs: These RFCs describe a protocol or specification that has been widely implemented and is considered stable and mature.
- Informational RFCs: These RFCs provide information, guidance, or best practices on a particular topic, but are not intended to define a standard or protocol.
- Experimental RFCs: These RFCs describe a protocol or specification that is being tested or evaluated, and may not be suitable for deployment in production environments.
- Historic RFCs: These RFCs describe a protocol or specification that was once widely used but is now obsolete or no longer in use.
- Best Current Practice (BCP) RFCs: These RFCs describe a best practice or guideline for a particular aspect of Internet architecture or operation.
- Independent Submission RFCs: These RFCs are submitted by individuals or organizations outside of the IETF, and may describe a proposed standard or other technical topic related to the Internet.
Number of published RFCs (March 2023)
Although IETF exists since since 1986 (nearly 40 years) the number of published RFCs is not so high, specially for (final) Internet Standard, a little bit more than one hundred.
- Standards Track RFCs:
- Proposed Standard RFCs: Approximately 3980
- Draft Standard RFCs: Approximately 139
- Internet Standard RFCs: Approximately 129 (HTTP, SMTP, NTP, FTP, etc.)
- Informational RFCs: Approximately 2861
- Experimental RFCs: Approximately 530 (Note : IDMEFv1 (RFC 4765) is an experimental RFC published in 2007)
- Historic RFCs: Approximately 388
- Best Current Practice (BCP) RFCs: Approximately 312
- Independent Submission RFCs: Approximately 500
The Security Area has published 629 RFCs, only 8 are Internet Standards.
Publication process : the big picture
Internet Drafts can be submitted by individuals or IETF working group.
Standard process
The process for defining a new standard at the Internet Engineering Task Force (IETF) typically involves the following steps:
- Proposal: A proposal for a new standard is first submitted to the IETF, typically in the form of an Internet-Draft. The proposal should describe the problem that the standard is intended to solve, the proposed solution, and any related protocols or technologies.
- Working Group: The proposal is reviewed by the appropriate working group within the IETF. Working groups are typically made up of volunteers who are experts in the relevant area, and who collaborate to refine and develop the proposal.
- Drafting: The proposal is then developed into a more detailed specification in the form of an Internet-Draft. This may involve several iterations of review and revision by the working group.
- Last Call: Once the Internet-Draft is considered complete by the working group, it is sent out for “last call” review. This means that the proposed standard is open to review and comment by anyone in the IETF community.
- IESG Review: After the last call period is over, the proposal is reviewed by the Internet Engineering Steering Group (IESG), which is responsible for approving or rejecting proposed standards. The IESG may request further revisions, or may approve the standard for publication as a Request for Comments (RFC).
- RFC Publication: Once approved, the standard is published as an RFC. RFCs are the official documents that define Internet standards, and they are freely available to the public.
It’s worth noting that the standardization process can take several years, and there is no guarantee that a proposed standard will be accepted. However, the IETF is committed to an open and transparent process, and all participants are encouraged to contribute their expertise and opinions to help shape the future of the Internet.
Working Group Creation
The process of creating a new working group (WG) within the Internet Engineering Task Force (IETF) typically involves the following steps:
- Proposal: A proposal for a new working group is first submitted to the IETF. The proposal should describe the problem or topic that the working group is intended to address, and should identify the individuals who will serve as chairs of the working group.
- Charter: If the proposal is accepted, a charter for the new working group is drafted. The charter should specify the goals, scope, and deliverables of the working group, as well as any milestones or deadlines. The charter should also define the working group’s relationship to other IETF groups and to external organizations.
- Approval: The charter is reviewed and approved by the Internet Engineering Steering Group (IESG), which is responsible for the overall management of the IETF. The IESG may request revisions to the charter before approving it.
- Call for Participation: Once the charter is approved, a call for participation is issued to the IETF community. Anyone who is interested in contributing to the working group’s efforts can join the group and participate in its activities.
- Working Group Meetings: The working group meets regularly, either in person or via teleconference, to discuss and develop its work. The chairs are responsible for managing the working group’s activities, and for ensuring that the group stays on track with its goals and milestones.
- Deliverables: The working group produces one or more deliverables, which may include Internet-Drafts, Request for Comments (RFCs), or other documents. These deliverables are reviewed and approved by the IESG before being published as official IETF standards.
Creating a new working group can take several months, and the process requires a significant amount of effort and coordination. However, working groups are an essential part of the IETF’s standardization process, and they provide a forum for experts to collaborate and address complex technical challenges in the Internet ecosystem.
Conclusion
Standardization process is long and uncertain. However, the IDMEFv2 task Force has produced a part of the way with the two published drafts. It needs more work and modification but it’s been already proven it’s working. As explained above, the final goal won’t be a “final” Internet Standard anyway, a good objective would probably be Experimental RFCs.