The Internet Architecture Board provides long-range technical direction for Internet development, ensuring the Internet continues to grow and evolve as a platform for global communication and innovation.
In its work, the IAB strives to:
- Ensure that the Internet is a trusted medium of communication that provides a solid technical foundation for privacy and security, especially in light of pervasive surveillance,
- Establish the technical direction for an Internet that will enable billions more people to connect, support the vision for an Internet of Things, and allow mobile networks to flourish, while keeping the core capabilities that have been a foundation of the Internet’s success, and
- Promote the technical evolution of an open Internet without special controls, especially those which hinder trust in the network.
The IAB has published RFC 8090: Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG).
Abstract: This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names.
On 1 February 2017, the IAB posted a statement on OCSP stapling:
The IAB is responsible for selecting an individual to a serve 3-year term on the ISOC Board of Trustees. The procedure is described in RFC3677. The candidates who accepted their nominations are:
- Niels ten Oever
- Sean Turner
The IAB is requesting feedback on these candidates by Wednesday, March 1, 2017. Please send your response to email@example.com. If you would like your feedback to be anonymized, please indicate such in your response. The IAB expects to finalize its selection on or before March 10, 2017.
The IESG will confirm the candidate by April 21, 2017 and the appointee will begin serving as the new board of trustee member at the ISOC Annual General meeting in June 2017.
The IAB has published the following RFC format-related RFCs:
- RFC 7990 on RFC Format Framework
- Abstract: In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.
- RFC 7991 on The “xml2rfc” Version 3 Vocabulary
- Abstract: This document defines the “xml2rfc” version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749.
- RFC 7992 on HTML Format for RFCs
- Abstract: In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft.
- RFC 7993 on Cascading Style Sheets (CSS) Requirements for RFCs
- Abstract: The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in “HTML for RFCs” (RFC 7992).
- RFC 7994 on Requirements for Plain-Text RFCs
- Abstract: In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, “RFC Series Format Requirements and Future Development”. Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.
- RFC 7995 on PDF Format for RFCs
- Abstract: This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF.
- RFC 7996 on SVG Drawings for RFCs: SVG 1.2 RFC
- Abstract: This document specifies SVG 1.2 RFC — an SVG profile for use in diagrams that may appear in RFCs — and considers some of the issues concerning the creation and use of such diagrams.
- RFC 7997 on The Use of Non-ASCII Characters in RFCs
- Abstract: In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.
- RFC 7998 on “xml2rfc” Version 3 Preparation Tool Description
- Abstract: This document describes some aspects of the “prep tool” that is expected to be created when the new xml2rfc version 3 specification is deployed.
The IAB is pleased to announce the appointment of Kaveh Ranjbar for a two-year term on the IETF Administrative Oversight Committee (IAOC), starting in March 2017.
The IAB is responsible for selecting one IAOC member. The selection was made in accordance with BCP 101 and BCP 113.
A call for nominations was issued on 5 October 2016. Nominations for 9 candidates were received, and 7 of them were willing to serve. The names of the candidates who accepted the nomination were announced on 3 November 2016.
After obtaining written input from all nominees and feedback from the community, the IAB discussed which candidate to choose. After significant discussion, the IAB decided to appoint Kaveh Ranjbar to this position.
The IAB thanks all of the nominees for their willingness to serve theIETF community.
The Internet Architecture Board is pleased to announce the reappointment of Nevil Brownlee as the Independent Submission Editor (ISE).
This appointment is for a one-year term, beginning on 15 February 2017 and ending on 14 February 2018.
This is the usual IAB report to the community about our activities since the previous meeting (in this case, since IETF 96 in Berlin). As ever, we hope that this form allows you to prepare topics you might want to discuss during the open mic. But of course, if you have views you want to make known by email, we’re easy to reach: send mail to firstname.lastname@example.org to reach our public discussion list, and email@example.com to reach just the IAB.
The IAB has a few chartered roles. We confirm the appointments to the IESG and perform standards process oversight and handle appeals. We also perform architectural oversight (including appointing the IRTF Chair), we manage the RFC series and the IETF’s relationship with IANA, and we handle liaisons both to ISOC and to other organizations. We try to ensure that anything we do is part of one of these areas of responsibility, and we try to make sure these are all covered.
Here’s what we’ve been doing since IETF 96. You can find mention of each of these on the IAB pages at https://www.iab.org (where there’s more background, too): Continue reading