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 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 email@example.com to reach our public discussion list, and firstname.lastname@example.org 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
The Internet Architecture Board (IAB), following discussions in the Internet Engineering Task Force (IETF), advises its partner Standards Development Organizations (SDOs) and organizations that the pool of unassigned IPv4 addresses has been exhausted, and as a result we are seeing an increase in both dual-stack (that is, both IPv4 and IPv6) and IPv6-only deployments, a trend that will only accelerate. Therefore, networking standards need to fully support IPv6. The IETF as well as other SDOs need to ensure that their standards do not assume IPv4.
The IAB expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. Future IETF protocol work will then optimize for and depend on IPv6.
Preparation for this transition requires ensuring that many different environments are capable of operating completely on IPv6 without being dependent on IPv4 [see RFC 6540]. We recommend that all networking standards assume the use of IPv6, and be written so they do not require IPv4. We recommend that existing standards be reviewed to ensure they will work with IPv6, and use IPv6 examples. Backward connectivity to IPv4, via dual-stack or a transition technology, will be needed for some time. The key issue for SDOs is to remove any obstacles in their standards which prevent or slow down the transition in different environments.
In addition, the IETF has found it useful to add IPv6 to its external resources (e.g., Web, mail) and to also run IPv6 on its conference network since this helps our participants and contributors and also sends the message that we are serious about IPv6. That approach might be applicable to other SDOs.
We encourage the industry to develop strategies for IPv6-only operation. We welcome reports of where gaps in standards remain, requiring further developments in IPv6 or other protocols. We are also ready to provide support or assistance in bridging those gaps.
As described in BCP 101 (RFC 4071) and BCP 113 (RFC 4333), the IESG and the IAB each select one person for a two-year IAOC term in alternate years. This year, the IAB will select one person for a term beginning in March 2017.
Following the call for nominations, which ran from 5 October 2016 through 2 November 2016, the IAB contacted each person that was nominated, asking them to accept or reject their nomination. At this point, 7 people have indicated a willingness to serve. They are:
Abdelhamid AL Rahamneh
Gatta Sambasiva Rao
The IAB is actively soliciting confidential comments on these people and their ability to serve on the IAOC. The IAB needs to receive these comments by 30 November 2016 in order to make a selection in December 2016. Please send comments to email@example.com and firstname.lastname@example.org.
Note that the NomCom will also be selecting a person to serve on the IAOC for a two-year term. This process is orthogonal, the IAB is not privy to comments you might have submitted to the NomCom.
The IAB has re-appointed Paul Wouters to serve a two-year term on the ICANN Technical Liaison Group (TLG). The IAB thanks Paul for his willingness to serve the community in this capacity.
As part of its oversight responsibility for the Independent Stream, the IAB is soliciting comments from the community on the performance of the Independent Stream Editor, Nevil Brownlee. We are interested in comments on what has gone well or badly in the last several years of operation of the Independent Stream and Nevil’s activities as ISE.
Please send comments to iab-chair at iab.org. In addition, please CC execd at iab.org.
We would appreciate receiving comments by Tuesday, November 29, 2016 as the IAB will likely begin the next steps in the oversight process shortly after the end of IETF 97 in Seoul.