Protocol Action: 'Packetization Layer Path MTU Discovery for Datagram Transports' to Proposed Standard (draft-ietf-tsvwg-datagram-plpmtud-22.txt)
The IESG has approved the following document: - 'Packetization Layer Path MTU Discovery for Datagram Transports' (draft-ietf-tsvwg-datagram-plpmtud-22.txt) as Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Martin Duke and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ Technical Summary: This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It describes an extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole (where packets are discarded). The method can probe a network path with progressively larger packets to discover whether the maximum packet size can be increased. This allows a sender to determine an appropriate packet size, providing functionality for datagram transports that is equivalent to the Packetization Layer PMTUD specification for TCP, specified in RFC 4821. The document updates RFC 4821 to specify the method for datagram PLs, and updates RFC 8085 as the method to use in place of RFC 4821 with UDP datagrams. Section 7.3 of RFC4960 recommends an endpoint apply the techniques in RFC4821 on a per-destination-address basis. RFC4960 is updated to recommend that SCTP uses the method specified in this document instead of the method in RFC4821. The document also provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports. When published, this specification updates RFC 4821, RFC 4960 and RFC 8085. Working Group Summary: There were no major controversies or points of questionable consensus in the process of working on this document. The document is somewhat related to work in other working groups (such as QUIC), since it lays out the framework for path MTU discovery that can be used in any datagram-based protocol. Document Quality: There have been a number of separate implementations at different stages of the document's maturity. An implementation for SCTP targets the FreeBSD kernel, and is starting the review process to be included. This code also is the basis for a userland stack currently used in browsers for WebRTC data channels. Another implementation with UDP options was done for the FreeBSD kernel, though has not tracked the draft since 2018. Three early implementations were also done as part of the EU MAMI project, to test possible algorithms and check if the specification could be implemented, but these did not enter production code. Two of these implementations were with UDP application protocols, for testing, and the third was for a QUIC implementation. Personnel: Wesley Eddy is the document shepherd. Magnus Westerlund is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Nomcom 2020-2021 Second Call For Volunteers
This is the second sending of the call for volunteers for the 2020-2021 NomCom. I wanted to mention a few updates from the previous email (sent 2 weeks ago): - I've fixed the URL at the bottom of the email to point to https://datatracker.ietf.org/nomcom/2020/ instead of /2019/. This was a test to see if anyone was paying attention. Apparently, some people were. ;) - The IETF 108 registration form includes a checkbox that will let you volunteer. You can use this instead of emailing me, when you register for IETF 108. - I currently have 39 volunteers. Last year had 149. I need more volunteers! - The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, 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 BCP 10 (RFC 8713). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the five listed meetings. 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 2020 - 2021 NomCom is responsible for filling. People commonly volunteer by ticking the box on IETF registration forms. The IETF 106 form did not ask whether people were willing to volunteer. IETF 107 did ask, but all those registrations were canceled. I have asked the Secretariat if it is possible to get the list if volunteers from canceled IETF 107 registrations. If that list is available, I will contact all who are verified as eligible. But given the uncertainty of this process, I would encourage people to volunteer directly (see the bottom of this email for instructions). Thank you for volunteering! The list of people and posts whose terms end with the March 2021 IETF meeting, and thus the positions for which this NomCom is responsible, are IETF Trust: Joel Halpern LLC: Maja Andjelkovic IAB: Jari Arkko Jeff Tantsura Mark Nottingham Stephen Farrell Wes Hardaker Zhenbin Li IESG: Alissa Cooper, IETF Chair/GEN AD Alvaro Retana, RTG AD Barry Leiba, ART AD Deborah Brungard, RTG AD Éric Vyncke, INT AD Magnus Westerlund, TSV AD Roman Danyliw, SEC AD Warren Kumari, OPS AD All appointments are for 2 years. The Routing area has 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (that have more than one AD) have at least one continuing AD. The primary activity for this NomCom will begin in July 2020 and should be completed in January 2021. 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 willing and able to attend either videoconference or in-person meetings (which may not happen) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Videoconference attendance will be supported whether or not there are in-person meetings. Orientation and setting of the NomCom schedule will be done by videoconference during the week 20-24 July (exact time and date to be determined after NomCom membership is finalized on July 12), the week prior to IETF 108. Being at IETF 110 (Prague) is not essential. Please volunteer by sending me an email before 23:59 UTC June 24, 2020, as follows: To: nomcom-chair-2...@ietf.org Subject: NomCom 2020-21 Volunteer Please include the following information in the email bo
RFC 8776 on Common YANG Data Types for Traffic Engineering
A new Request for Comments is now available in online RFC libraries. RFC 8776 Title: Common YANG Data Types for Traffic Engineering Author: T. Saad, R. Gandhi, X. Liu, V. Beeram, I. Bryskin Status: Standards Track Stream: IETF Date: June 2020 Mailbox:ts...@juniper.net, rgan...@cisco.com, xufeng.liu.i...@gmail.com, vbee...@juniper.net, i_brys...@yahoo.com Pages: 84 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-teas-yang-te-types-13.txt URL:https://www.rfc-editor.org/info/rfc8776 DOI:10.17487/RFC8776 This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities. This document is a product of the Traffic Engineering Architecture and Signaling 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
