IAB Stream RFCs (RFC 4845) are seen as documents that speak 'for the IAB'. The quality of those documents reflects on the IAB as an institution.
In order to improve the understanding and create a common ground for IAB document processing we will attempt use the following steps for adoption, review, and tracking IAB documents.
This is not a full fledged process flow and there are a few places where there is the possibility for the process to go astray. It is the intention for this document to be a living document.
There are three types of IAB documents:
RFC 4845 section 3 explains the document process:
- IAB RFC Publication Process
The following is a description of the process used by the IAB to
publish IAB documents as RFCs.
The document is determined to be an IAB document by the IAB, as
described in Section 1.The IAB publishes an IAB draft (draft-iab-*). Comments on the
draft are reviewed and may be integrated into successive
iterations of the draft. In addition to considering comments
received on the draft, the IAB may elect to refer the document to
individuals or groups and explicitly solicit comments as
appropriate.For documents intended to be published as BCPs, the document is
passed to the Internet Engineering Steering Group (IESG) with a
sponsoring Area Director (AD), and follows the process outlined
in [SPONSOR].For documents intended to be Informational RFCs, the remainder of
this process is followed.The chair of the IAB issues an IETF-wide Call for Comment on the
IETF Announce mailing list. The comment period is normally no
shorter than four weeks.Comments received are considered for integration into the
document. The IAB shall determine whether the document is ready
for publication based on the comments received, or whether
another round of document editing and, optionally, a further call
for input is required.The document is passed to the RFC Editor for publication as an
IAB document Informational RFC.
| Action | Datatracker State |
|---|---|
| The IAB sends email to architecture-discuss announcing that they are considering adopting a document | Candidate IAB Document |
| The IAB adopts the document | Active IAB Document |
| The IAB reviews, discusses, and updates the document as needed | Active IAB Document |
| The IAB sends an IETF-wide Call for Comments | Community Review |
| The IAB reviews community feedback and decides next steps | IAB Review |
| The IAB approves the document for publication as an RFC | Sent to the RFC Editor |
The following sections elaborate on the current process in more detail, but the details are flexible. The point here is to document what our current working procedure is.
When an IAB member considers a document for IAB consideration that document will be presented to the IAB as an Internet Draft. Normally these documents will be posted to the repository as individual submissions but in rare occassions the draft can be circulated on the IAB mailinglist (e.g. when a document is a result of an IAB action or a workshop report).
A draft does not necessarily need to be authored by an IAB member. Any member of the community can ask an IAB to bring a document to the IAB for adoption as an IAB document.
If a draft is brought to the IAB there the chair will reserve the next available techchat slot for discussion of the document (if that would cause undue delay a business slot will be used).
When the IAB considers adoption of a draft (i.e., renaming it to draft-iab-foo), a notice should be sent to architecture-discuss@ietf.org
The original announcement of this policy.
The IAB will discuss adoption of DRAFT at its meeting on DATE.
The draft can be found here: https://datatracker.ietf.org/doc/DRAFT
The agenda for the meeting will be posted 48 hours ahead of the meeting here: https://www.iab.org/wiki/index.php/AgendaFeedback about this draft can be sent in response to this mail on architecture-discuss@ietf.org, or to the IAB directly at iab@iab.org.
During that slot the IAB will need to approve the adoption of the document as an IAB document. It is expected that all IAB members read the document so that they can engage in the discussion. The decision to purue publication as IAB Stream RFC will need to be made on rough consensus and the following questions act as a guide to the discussion:
The result of the discussion should be documented in such a way that it offers the background for future IABs om why an effort was finished.
In addition the document shepherd will provide and document a timeline for concluding the document.
The shepherd will work with the document to resolve issues. High-level issues that speak to the point that the IAB tries to make will need to be brought to the IAB.
The editor will use some sort of issue tracker (e.g. trac).
When the editor considers the document finished the IAB shepherd will bring the document to the IAB for a 2 weeks last call (or longer if multiple documents are to be reviewed at the same time, IAB members may ask for a little extra time).
Since we had a high barrier for entrance we should not end up in the situation that we have discussions about the topic being worthy for IAB publication. Obviously we may find out that the quality of the document is not satisfactory.
The document editor will work with the individuals who identified the issues to resolve those issues. Once that is done the document is ready for Call for Comments.
RFC 4845 section 3 states:
The chair of the IAB issues an IETF-wide Call for Comment on the
IETF Announce mailing list. The comment period is normally no
shorter than four weeks.
The Call for Comments is often done with a bias to close on a Sunday so that Monday start of business matters can be evaluated.
Any significant feedback, beyond nits, is brought to the IAB and are resolved as appropriate, preferably through e-mail.
After the feedback from the community has been incorporated the document is approved (pro-forma) by the IAB at its next meeting.
The appendix lists a "IAB Members at the Time of Approval" section. This section is factual since it only speaks about the membership at a certain time. In rare cases the section might document that there was a rough consensus for publication but we strive to have all people mentioned. Disagreements with publication can appear in the public meeting minutes.
Issues brought up during this last call should be addressed.
The reasons for this section were articulated by Olaf Kolkman as "It takes a lot of in-depth knowledge to sort out who were on the IAB at the time the document was approved. I believe it is important that (in particular with non-workshop reports) the members at that time are willing to take responsibility and stand for the consensus achieved within the IAB." Leslie Daigle added: "part of the reason for listing the folks who were on the IAB when it was approved was to facilitate documents being edited across the annual membership boundary. I.e., you didn't have a flurry of publications in February, or a lull as the new IAB read through the all-but-finished IAB documents leftover from the previous team."
Reports on IAB-sponsored workshops do not reflect IAB consensus and follow a different model, even though they are still published in the IAB Stream. See published workshop reports for additional examples of language used in prior reports.
The following paragraph (based on text in RFC 4417 and RFC 4984) should be added at the end of the abstract:
Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are
those of the workshop participants and do not necessarily reflect IAB
views and positions.
Sample abstract 1:
This document reports the outcome of the [topic] Workshop
that was held by the Internet Architecture Board (IAB) on
[dates], in [place]. The primary goal of the workshop was
to [goal]. This report summarizes the discussions and
conclusions of the workshop.[boilerplate trailer paragraph from above]
Sample abstract 2:
This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on [topic]. The workshop was
hosted by [host] in [place] on [dates]. The
goal of the workshop was to [goal]. This report
summarizes the discussions and lists the conclusions and
recommendations to the Internet Engineering Task Force (IETF)
community.[boilerplate trailer paragraph from above]
The following boilerplate (from RFC 1862) MAY be used in the introduction.
The Internet Architecture Board (IAB) holds occasional workshops
designed to consider long-term issues and strategies for the
Internet, and to suggest future directions for the Internet
architecture. This long-term planning function of the IAB is
complementary to the ongoing engineering efforts performed by working
groups of the Internet Engineering Task Force (IETF), under the
leadership of the Internet Engineering Steering Group (IESG) and area
directorates.
An appendix lists the workshop participants. Workshop reports do not contain an "IAB members at approval" section, since they are not IAB consensus documents.
The location of the workshops is not generally part of the doc title. For example:
In the first-page header, each author's name would be listed without an organization.
A section titled "IAB Members at the Time of Approval" would be included.
The IAB would be listed in the Authors' Addresses section as follows:
Internet Architecture Board
EMail: iab@iab.org
RFC 4845 section 1 states: "If the IAB has cause to publish a document as a Best Current Practice (BCP), it would fall under the approval process of the IETF standards stream of RFCs (see RFC 4844])."
The content of this page was last updated on 2023-05-24. It was migrated from the old IAB wiki on 2023-12-05.