RFC 9004 on Updates for the Back-to-Back Frame Benchmark in RFC 2544
A new Request for Comments is now available in online RFC libraries. RFC 9004 Title: Updates for the Back-to-Back Frame Benchmark in RFC 2544 Author: A. Morton Status: Informational Stream: IETF Date: May 2021 Mailbox:acmor...@att.com Pages: 13 Updates:RFC 2544 I-D Tag:draft-ietf-bmwg-b2b-frame-04.txt URL:https://www.rfc-editor.org/info/rfc9004 DOI:10.17487/RFC9004 Fundamental benchmarking methodologies for network interconnect devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-Back Frames benchmark of RFC 2544, based on further experience. This memo updates Section 26.4 of RFC 2544. This document is a product of the Benchmarking Methodology Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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
RFC 9020 on YANG Data Model for Segment Routing
A new Request for Comments is now available in online RFC libraries. RFC 9020 Title: YANG Data Model for Segment Routing Author: S. Litkowski, Y. Qu, A. Lindem, P. Sarkar, J. Tantsura Status: Standards Track Stream: IETF Date: May 2021 Mailbox:slitkows.i...@gmail.com, yingzhen...@futurewei.com, a...@cisco.com, pushpasis.i...@gmail.com, jefftant.i...@gmail.com Pages: 39 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-spring-sr-yang-30.txt URL:https://www.rfc-editor.org/info/rfc9020 DOI:10.17487/RFC9020 This document defines three YANG data models. The first is for Segment Routing (SR) configuration and operation, which is to be augmented by different Segment Routing data planes. The next is a YANG data model that defines a collection of generic types and groupings for SR. The third module defines the configuration and operational states for the Segment Routing MPLS data plane. This document is a product of the Source Packet Routing in Networking 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
RFC 9014 on Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks
A new Request for Comments is now available in online RFC libraries. RFC 9014 Title: Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks Author: J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake Status: Standards Track Stream: IETF Date: May 2021 Mailbox:jorge.raba...@nokia.com, senthil.sathap...@nokia.com, wim.henderi...@nokia.com, saja...@cisco.com, jdr...@juniper.net Pages: 24 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-bess-dci-evpn-overlay-10.txt URL:https://www.rfc-editor.org/info/rfc9014 DOI:10.17487/RFC9014 This document describes how Network Virtualization Overlays (NVOs) can be connected to a Wide Area Network (WAN) in order to extend the Layer 2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) technologies used in the WAN, such as Virtual Private LAN Services (VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN, or PBB-EVPN. It also describes how the existing technical specifications apply to the interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES), to provide multihoming. This document also describes the use of the Unknown MAC Route (UMR) to avoid issues of a Media Access Control (MAC) scale on Data Center Network Virtualization Edge (NVE) devices. This document is a product of the BGP Enabled Services 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
Grant Negotiation and Authorization Protocol (gnap) WG Virtual Meeting: 2021-06-15
The Grant Negotiation and Authorization Protocol (gnap) WG will hold a virtual interim meeting on 2021-06-15 from 19:00 to 20:00 Asia/Jerusalem (16:00 to 17:00 UTC). Agenda: TBD Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=514cd706-0d04-4076-aa10-428f41ca57f5 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Experimental DMARC Extension For Public Suffix Domains' to Experimental RFC (draft-ietf-dmarc-psd-14.txt)
The IESG has approved the following document: - 'Experimental DMARC Extension For Public Suffix Domains' (draft-ietf-dmarc-psd-14.txt) as Experimental RFC This document is the product of the Domain-based Message Authentication, Reporting & Conformance Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ Technical Summary Domain-based Message Authentication, Reporting, and Conformance (DMARC) permits a domain-controlling organization to express domain- level policies and preferences for message validation, disposition, and reporting, which a mail-receiving organization can use to improve mail handling. DMARC distinguishes the portion of a name that is a Public Suffix Domain (PSD), below which organizational domain names are created. The basic DMARC capability allows organizational domains to specify policies that apply to their subdomains, but it does not give that capability to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs. Some implementations of DMARC consider a PSD to be ineligible for DMARC enforcement. This specification addresses that case. Working Group Summary Generally, the working group came to consensus fairly quickly about this proposal because it's fairly minimal, straightforward, and well understood. However, see the IESG Note below. Document Quality There are several expressions of interest with respect to implementation. There is one reference implementation. Personnel Murray Kucherawy wrote the original Document Shepherd writeup, and Alexey Melnikov started IETF Last Call as Area Director. Since then, their roles have swapped; Alexey is the shepherding co-chair, and Murray is the Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'RTP-mixer formatting of multiparty Real-time text' to Proposed Standard (draft-ietf-avtcore-multi-party-rtt-mix-20.txt)
The IESG has approved the following document: - 'RTP-mixer formatting of multiparty Real-time text' (draft-ietf-avtcore-multi-party-rtt-mix-20.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ Technical Summary: Enhancements for RFC 4103 real-time text mixing are provided in this document, suitable for a centralized conference model that enables source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multi-party real-time text session. The specified mechanism builds on the standard use of the CSRC list in the RTP packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two- party sessions. Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The possibility to implement the solution in a wide range of existing RTP implementations made the RTP-mixer model be selected to be fully specified in this document. A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multi-party coded real-time text stream using the RTP-mixer method. The capability is indicated by use of an SDP media attribute "rtt-mixer". The document updates RFC 4103 "RTP Payload for Text Conversation". A specification of how a mixer can format text for the case when the endpoint is not multi-party aware is also provided. Working Group Summary: WG Last Call of "RTP-mixer formatting of multi-party Real-time text" was announced on November 25, 2020: https://mailarchive.ietf.org/arch/msg/avt/tjGlWlXL5a54nhgl5nRV3jkD_tk/ WGLC concluded on December 9, 2020. Of the 6 participants responding to the WGLC, 3 supported Advancement to Proposed Standard, and 3 respondents provided comments, which were addressed by the author. Document Quality: There are no existing implementations of the specification. Personnel: Document Shepherd is Bernard Aboba. Responsible AD is Murray Kucherawy. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')' to Informational RFC (draft-ietf-emu-rfc5448bis-10.txt)
The IESG has approved the following document: - 'Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')' (draft-ietf-emu-rfc5448bis-10.txt) as Informational RFC This document is the product of the EAP Method Update Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/ Technical Summary The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the primary authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA. This memo replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this document obsoletes RFC 5448 and updates RFC 4187. EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC- SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA. This version of EAP-AKA' specification specifies the protocol behaviour for both 4G and 5G deployments, whereas the previous version only did this for 4G. Working Group Summary There was consensus for the document in the working group. Document Quality This document is used by 3GPP standards including 5G standards and has had review from members of that community. Personnel Joe Salowey is the document shepherd. Roman Danyliw is the Responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
NomCom 2021-2022 Call for Volunteers
The IETF NomCom appoints people to fill the open slots on the IETF 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 RFC 8989 (one-off update to RFC 8713 / BCP 10) tells us who is eligible to volunteer as anyone who satisfies any of the three following conditions: Path 1: The person has attended 3 out of the last 5 IETF meetings, including meetings held entirely online. For the 2021-2022 NomCom, the meetings concerned will be IETF 106, 107, 108, 109, and 110 Path 2: The person has been a Working Group Chair or Secretary within the 3 years prior to the day the first call for NomCom volunteers is sent to the community Path 3: The person has been a listed author or editor (on the front page) of at least two IETF Stream RFCs within the last 5 years prior to the day the call for NomCom volunteers is sent to the community. An Internet-Draft that has been approved by the IESG and is in the RFC Editor queue counts the same as a published RFC, with the relevant date being the date the draft was added to the RFC Editor queue. [Normative details are in RFC8989.] You can check your eligibility at: https://datatracker.ietf.org/accounts/profile/ (after logging in, you will see your eligibility displayed in the field "Nomcom Eligible"). If you qualify, please volunteer as explained below. However, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2021-2022 NomCom is responsible for filling. Details of Positions to Be Filled (details to be finalized) An asterisk (*) next to a person's name indicates they do not intend to accept renomination. LLC Board (3-year term) • Jason Livingood IETF Trust (3-year term) • Kathleen Moriarty IAB (2-year term) • 6 positions IESG (2-year term) • 1 position, ART AD • 1 position, INT AD • 1 position, OPS AD • 1 position, RTG AD • 1 position, SEC AD • 1 position, TSV AD The primary activity for this NomCom will begin in July 2021 and should be completed by January 2022. 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 meetings either remotely or in-person during IETF 112 (Madrid 6-12 November 2021) to conduct interviews. Remote 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 26-30 July (exact time and date to be determined after NomCom membership is finalized on July 15), prior to IETF 111. Please volunteer by sending me an email before 23:59 UTC on Wednesday June 23, 2021, as follows: To: nomcom-chair-2...@ietf.org Subject: NomCom 2021-22 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: // Email addresses used to register for the past 5 IETF meetings // Preferred email address first 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/2021/ Within the next few weeks, I may add more details on the timeline, as well as details of the randomness seeds to be used for the RFC 3797 selection process. Thank you! Gabriel Montenegro nomcom-chair-2021 at ietf dot org ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Finding and Using Geofeed Data' to Proposed Standard (draft-ietf-opsawg-finding-geofeeds-17.txt)
The IESG has approved the following document: - 'Finding and Using Geofeed Data' (draft-ietf-opsawg-finding-geofeeds-17.txt) as Proposed Standard This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds/ Technical Summary Providers of Internet content and other services may wish to customize those services based on the geographic location of the user of the service. This is often done using the source IP address used to contact the service. Also, infrastructure and other services might wish to publish the locale of their services. [RFC8805] defines geofeed, a syntax to associate geographic locales with IP addresses. But it does not specify how to find the relevant geofeed data given an IP address. This document specifies how to augment the Routing Policy Specification Language (RPSL) [RFC4012] inetnum: class [INETNUM] to refer to geofeed data, and how to prudently use them. In all places inetnum: is used, inet6num: should also be assumed [INET6NUM]. Working Group Summary There seemed to be a reasonable amount of discussion during the WG phase, but nothing that seemed to be particular controversial or rough. Document Quality There are active discussions in one RIR to implement the proposed field in their deployed RPSL Whois. There are discussions commencing in another RIR. Commentary included an author of a third RPSL implementation. I would like to thank George, the doc shepherd for performing a diligent shepherd's review and writeup. Personnel The document Shepherd is George Michaelson. The responsible Area Director is Robert Wilton. IESG Note This document defines a "remarks: Geofeed" attribute until a new "geofeed:" attribute in the inetnum: class can be defined. The authors are actively working with the relevant parties to get the geofeed: attribute defined aligning with the specification defined in this document. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
JSON Path (jsonpath) WG Virtual Meeting: 2021-06-15
The JSON Path (jsonpath) WG will hold a virtual interim meeting on 2021-06-15 from 09:00 to 11:00 UTC. Agenda: # jsonpath IETF Working Group May 2021 Interim Agenda Date: 2021-06-15 Time: 9:00 - 11:00 UTC Chair: Tim Bray Chair: James Gruessing Area Director: Francesca Palombini * [Datatracker](https://datatracker.ietf.org/group/jsonpath/about/) * [Jabber](xmpp:jsonp...@jabber.ietf.org?join) * [Minutes](https://codimd.ietf.org/notes-interim-2021-jsonpath-02) ## VC Details https://meetings.conf.meetecho.com/interim/?short=84108259-728f-49d3-8f8a-b068eeae44bd ## Agenda ### Administrivia * Note Takers * Blue Sheets * Jabber Scribe * Agenda Bashing ### Discussion of Issues List of issues to discuss to be finalised later ### AOB Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=84108259-728f-49d3-8f8a-b068eeae44bd ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Reminder: IETF 111 Birds of a Feather (BOF) proposals requested by 28 May
Hi, This is a friendly follow-up reminder that preliminary proposals for Birds-of-a-Feather (BOF) sessions during the upcoming IETF 111 meeting are requested by 28 May 2021. The intention is to allow the IESG and IAB more time to work with BOF proponents to clarify and refine proposals ahead of the IETF 111 BOF proposal deadline on 11 June 2021. Instructions for submitting a BOF proposal are available at https://ietf.org/how/bofs/ Please also read https://www.rfc-editor.org/rfc/rfc5434, Considerations for Having a Successful Birds-of-a-Feather Session, if you are not familiar with it. BOFs are just one of a number of ways of bringing new work into the IETF. If you are considering a BOF request but you are unsure whether to submit it, please tell the IESG now by sending an email to i...@ietf.org, or speak to an individual Area Director (https://www.ietf.org/about/groups/iesg/members/) about your idea. Thanks, Lars Eggert IETF Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
