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 selected Ted Hardie as the new IAB Chair.
The IAB would like to thank Andrew Sullivan for his service in the role over the past two years.
This is the usual IAB report to the community about our activities since the previous meeting (in this case, since IETF 97 in Seoul). 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 email@example.com to reach our public discussion list, and firstname.lastname@example.org to reach just the IAB. Continue reading
The IAB has published RFC 8128: IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee.
Abstract: This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).
On 2 March 2017, the IAB provided comments to United States National Telecommunications and Information Administration (NTIA) on the Green Paper: Fostering the Advancement of the Internet of Things that was released on January 12, 2017.
The Green Paper can be found on the NTIA website at <https://www.ntia.doc.gov/files/ntia/publications/iot_green_paper_01122017.pdf>.
The Request for Comments [Docket Number 170105023-7023-01] on the Green Paper can be found at <https://www.ntia.doc.gov/federal-register-notice/2017/request-comments-benefits-challenges-and-potential-roles-government>.
The text of the IAB comments can be found at <https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-comments-to-ntia-on-fostering-the-advancement-of-iot/>.
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.