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.
On 4 January 2017, the IAB responded to the ICANN call for comments on Identifier Technology Health Indicators: Definition.
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.
On 7 December 2016, the IAB responded to the ICANN call for public comments on the Revised Proposed Implementation of GNSO Thick Whois Consensus Policy Requiring Consistent Labeling and Display of RDDS (Whois) Output for All gTLDs.
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.
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.