NomCom 2017-2018 Third and FINAL Call for Volunteers
The IETF NomCom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in RFC 7437 (BCP 10), and RFC 3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF = 94 (Yokohama) \ 95 (Buenos Aires) \ 96 (Berlin) -*** ANY THREE! 97 (Seoul) / 98 (Chicago) / You can check your eligibility at: https://www.ietf.org/registration/nomcom.py If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2017 - 2018 NomCom is responsible for filling. Some 201 people have already volunteered by ticking the box on the IETF 96 through 98 registration forms. I will contact all of these volunteers shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2018 IETF meeting, and thus the positions for which this NomCom is responsible, are IAOC: Leslie Daigle IAB: Ted Hardie Joe Hildebrand Lee Howard Erik Nordmark Martin Thomson Brian Trammell IESG: Alia Atlas (RTG) Benoit Claise (OPS) Suresh Krishnan (INT) Mirja Kühlewind (TSV) Alexey Melnikov (ART) Kathleen Moriarty (SEC) Adam Roach (ART) All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this NomCom will begin in July 2017 and should be completed in January 2018. The NomCom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a very rewarding experience. As a member of the NomCom it is very important that you be able to attend IETF 100 (Singapore) to conduct interviews. Being at IETF 99 (Prague) is useful for orientation. Being at IETF 101 (London) is not essential. Please volunteer by sending me an email before 23:59 UTC June 26, 2017, as follows: To: nomcom-chair-2017 at ietf dot org Subject: NomCom 2017-18 Volunteer Please include the following information in the email body: Your Full Name: __ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: ___ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: ___ // For confirmation if selected You should expect an email response from me within 5 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that NomCom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the NomCom is a great way to contribute to the IETF! You can find a detailed timeline on the NomCom web site at: https://datatracker.ietf.org/nomcom/2017/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within short order. Thank you! Peter Yee peter at akayla dot com nomcom-chair-2017 at ietf dot org
BCP 26, RFC 8126 on Guidelines for Writing an IANA Considerations Section in RFCs
A new Request for Comments is now available in online RFC libraries. BCP 26 RFC 8126 Title: Guidelines for Writing an IANA Considerations Section in RFCs Author: M. Cotton, B. Leiba, T. Narten Status: Best Current Practice Stream: IETF Date: June 2017 Mailbox:michelle.cot...@iana.org, barryle...@computer.org, nar...@us.ibm.com Pages: 47 Characters: 109907 Obsoletes: RFC 5226 See Also: BCP 26 I-D Tag:draft-leiba-cotton-iana-5226bis-20.txt URL:https://www.rfc-editor.org/info/rfc8126 DOI:10.17487/RFC8126 Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 8175 on Dynamic Link Exchange Protocol (DLEP)
A new Request for Comments is now available in online RFC libraries. RFC 8175 Title: Dynamic Link Exchange Protocol (DLEP) Author: S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry Status: Standards Track Stream: IETF Date: June 2017 Mailbox:sratl...@idirect.net, sj...@cisco.com, dsatt...@broadcom.com, rick.tay...@airbus.com Pages: 82 Characters: 177898 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-manet-dlep-29.txt URL:https://www.rfc-editor.org/info/rfc8175 DOI:10.17487/RFC8175 When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. This document introduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics. This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
RFC 8171 on Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
A new Request for Comments is now available in online RFC libraries. RFC 8171 Title: Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms Author: D. Eastlake 3rd, L. Dunbar, R. Perlman, Y. Li Status: Standards Track Stream: IETF Date: June 2017 Mailbox:d3e...@gmail.com, ldun...@huawei.com, ra...@alum.mit.edu, liyiz...@huawei.com Pages: 55 Characters: 130232 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-trill-directory-assist-mechanisms-12.txt URL:https://www.rfc-editor.org/info/rfc8171 DOI:10.17487/RFC8171 This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi-destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. This document is a product of the Transparent Interconnection of Lots of Links Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
