RFC 9042 on Sieve Email Filtering: Delivery by MAILBOXID
A new Request for Comments is now available in online RFC libraries. RFC 9042 Title: Sieve Email Filtering: Delivery by MAILBOXID Author: B. Gondwana, Ed. Status: Standards Track Stream: IETF Date: June 2021 Mailbox:br...@fastmailteam.com Pages: 8 Updates:RFC 5228 I-D Tag:draft-ietf-extra-sieve-mailboxid-09.txt URL:https://www.rfc-editor.org/info/rfc9042 DOI:10.17487/RFC9042 The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming. This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes. This document is a product of the Email mailstore and eXtensions To Revise or Amend 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 9062 on Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM)
A new Request for Comments is now available in online RFC libraries. RFC 9062 Title: Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) Author: S. Salam, A. Sajassi, S. Aldrin, J. Drake, D. Eastlake 3rd Status: Informational Stream: IETF Date: June 2021 Mailbox:ssa...@cisco.com, saja...@cisco.com, aldrin.i...@gmail.com, jdr...@juniper.net, d3e...@gmail.com Pages: 16 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-bess-evpn-oam-req-frmwk-10.txt URL:https://www.rfc-editor.org/info/rfc9062 DOI:10.17487/RFC9062 This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and Provider Backbone Bridge EVPN (PBB-EVPN). The framework defines the layered OAM model encompassing the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer but focuses on the service and network layers. This document is a product of the BGP Enabled Services 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 9046 on Babel Information Model
A new Request for Comments is now available in online RFC libraries. RFC 9046 Title: Babel Information Model Author: B. Stark, M. Jethanandani Status: Informational Stream: IETF Date: June 2021 Mailbox:barbara.st...@att.com, mjethanand...@gmail.com Pages: 20 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-babel-information-model-14.txt URL:https://www.rfc-editor.org/info/rfc9046 DOI:10.17487/RFC9046 The Babel information model provides structured data elements for a Babel implementation reporting its current state and may allow limited configuration of some such data elements. This information model can be used as a basis for creating data models under various data modeling regimes. This information model only includes parameters and parameter values useful for managing Babel over IPv6. This document is a product of the Babel routing protocol 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 9058 on Multilinear Galois Mode (MGM)
A new Request for Comments is now available in online RFC libraries. RFC 9058 Title: Multilinear Galois Mode (MGM) Author: S. Smyshlyaev, Ed., V. Nozdrunov, V. Shishkin, E. Griboedova Status: Informational Stream: Independent Date: June 2021 Mailbox:s...@cryptopro.ru, nozdrunov...@tc26.ru, shishkin...@tc26.ru, griboedovaekater...@gmail.com Pages: 25 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-smyshlyaev-mgm-20.txt URL:https://www.rfc-editor.org/info/rfc9058 DOI:10.17487/RFC9058 Multilinear Galois Mode (MGM) is an Authenticated Encryption with Associated Data (AEAD) block cipher mode based on the Encrypt-then-MAC (EtM) principle. MGM is defined for use with 64-bit and 128-bit block ciphers. MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 and IPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher. 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 9039 on Uniform Resource Names for Device Identifiers
A new Request for Comments is now available in online RFC libraries. RFC 9039 Title: Uniform Resource Names for Device Identifiers Author: J. Arkko, C. Jennings, Z. Shelby Status: Standards Track Stream: IETF Date: June 2021 Mailbox:jari.ar...@piuha.net, flu...@iii.ca, z...@edgeimpulse.com Pages: 15 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-core-dev-urn-11.txt URL:https://www.rfc-editor.org/info/rfc9039 DOI:10.17487/RFC9039 This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information. This document is a product of the Constrained RESTful Environments 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
Statement on Affiliation and Voting Members
There has been much discussion about what the policy is when next week's random selection is performed and we are applying the limit of maximum 2 voting members per primary affiliation (per RFC8713). I will not judge whether different subsidiaries are internally independent or not. For the purposes of voting member affiliations I will err on the side of caution. So, for example, I would count Loon (well, if it was still active) and Google as part of Alpha, the different parts of Cisco as under that umbrella and Futurewei and Huawei as the same. Similarly, we have been equally careful with other volunteers whom we have had to disqualify because their employers appear on the list of contractors to the LLC (another reason for disqualification per RFC8713). Some of these individuals are not involved in any particular contracts with the LLC, but per the above considerations we must be extra careful and have had to unfortunately invalidate them. When it comes to issues of affiliation we must be consistent with this position. Not doing so would be careless and would not be fair to others we have already disqualified. Gabriel Montenegro NomCom Chair 2021-2022 nomcom-chair-2021 at ietf dot org ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 9064 on Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols
A new Request for Comments is now available in online RFC libraries. RFC 9064 Title: Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols Author: D. Oran Status: Informational Stream: IRTF Date: June 2021 Mailbox:daveo...@orandom.net Pages: 23 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-oran-icnrg-qosarch-06.txt URL:https://www.rfc-editor.org/info/rfc9064 DOI:10.17487/RFC9064 This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher-layer QoS objectives. It explicitly excludes any discussion of Quality of Experience (QoE), which can only be assessed and controlled at the application layer or above. This document is not a product of the IRTF Information-Centric Networking Research Group (ICNRG) but has been through formal Last Call and has the support of the participants in the research group for publication as an individual submission. This document is a product of the IRTF. 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, rfc-dist and IRTF-Announce lists.To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist https://www.irtf.org/mailman/listinfo/irtf-announce 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
Updated List of volunteers for the 2021-2022 NomCom
This list has been updated with a few tweaks, deletions and also some additions from folks who expressed willingness in the IETF 107 registration *and* confirmed such willingness to serve in the current NomCom 2021-2022 cycle. This is a preliminary list of 117 qualified volunteers for NomCom 2021-2022. All have been verified by using the Datatracker as qualified for the position of voting member of NomCom per RFC 8989. The challenge period is still under way and ends on Monday, July 5, 2021 at 23:59 UTC. If anyone thinks that a name on the numbered list below is NOT qualified for some reason, please send me email before this deadline at: nomcom-chair-2021 at ietf dot org The next steps are listed on https://datatracker.ietf.org/nomcom/2021/ The preliminary qualified volunteers are: Num Last Name First NameAffiliation === 1Aelmans Melchior Juniper Networks 2BagdonasIgnas Equinix 3Banks Sarah Corelight, Inc. 4Barnes Mary Independent 5Beeram VishnuJuniper Networks 6Benamar Nabil Moulay Ismail University of Meknes, 7Bertola Vittorio Open-Xchange 8Bishop Mike Akamai Technologies 9Bonica Ron Juniper Networks 10 Box Chris BT 11 Burdet LucAndré Cisco 12 BushRandy IIJ Research Lab & Arrcus Inc 13 BusiItalo Huawei 14 ChenMach Huawei 15 ChenHuaimoFuturewei 16 Cheng Weiqiang China Mobile 17 Ciavaglia Laurent Rakuten 18 Clemm Alexander Futurewei 19 Dhody Dhruv Huawei 20 DongJie Huawei Technologies 21 Drake John Juniper Networks 22 EastlakeDonaldFuturewei Technologies, Inc 23 Eckel Charles Cisco Systems 24 Eckert Toerless Futurewei USA 25 EnghardtTheresa Netflix 26 Fan Dawei Huawei 27 Farrell Stephen Trinity College Dublin 28 FioccolaGiuseppe Huawei Technologies 29 Fomin SergeyNokia 30 Fossati ThomasArm 31 GengXuesong Huawei 32 GondwanaBron Fastmail Pty Ltd 33 Gu Yunan Huawei 34 Gundavelli Sri Cisco 35 HaasJeffrey Juniper Networks 36 HabermanBrian JHU 37 Haddad WassimEricsson 38 Hallam-BakerPhillip Threshold Secrets LLC 39 HarrisonTom APNIC 40 Hegde Shraddha Juniper Networks 41 Heitz Jakob Cisco Systems, Inc. 42 Hinden Bob Check Point Software 43 Hopps Christian LabN Consulting 44 Housley Russ Vigil Security, LLC 45 Huitema Christian Private Octopus Inc. 46 Iannone Luigi Huawei 47 Jimenez Jaime Ericsson 48 KrishnanSureshKaloom 49 LearEliot Cisco Systems 50 Leiba Barry Futurewei Technologies 51 Lemon Ted Apple 52 Li Cheng Huawei 53 Li Richard Futurewei Technologies, Inc. 54 Li YizhouHuawei 55 Lin YiHuawei Technologies Co., Ltd. 56 Liu Bing (Remy) Huawei Technologies Co.,Ltd. 57 Lou Zhe Huawei Technologies Duesseldorf Gmb 58 Maisonneuve JulienNokia 59 Makhijani Kiran Futurewei 60 Mankin Allison Salesforce 61 MasinterLarry Interlisp.org 62 MattssonJohn Ericsson 63 McManus Patrick Fastly 64 Michaelson GeorgeAPNIC 65 Min Xiao ZTE Corporation 66 Mishra SanjayVerizon 67 Mizrahi Tal Huawei 68 Moore Keith Network Heretics 69 Nottingham Mark Fastly 70 Paine KirstyUK National Cyber Security Centre ( 71 Pan Wei Huawei 72 PengShuping Huawei Technologies Co.,Ltd. 73
Routing Over Low power and Lossy networks (roll) WG Virtual Meeting: 2021-08-31
The Routing Over Low power and Lossy networks (roll) WG will hold a virtual interim meeting on 2021-08-31 from 18:00 to 19:30 Europe/Helsinki (15:00 to 16:30 UTC). Agenda: Agenda to be determined by 31th July. Information about remote participation: IETF-ROLL-Interim-20210831 Hosted by ROLL WG https://ietf.webex.com/ietf/j.php?MTID=m0f82035057cfa91a3d4a625639f73c02 Tuesday, Aug 31, 2021 11:00 am | 1 hour 30 minutes | (UTC-04:00) Eastern Time (US & Canada) Meeting number: 161 565 5824 Password: pbMbu8Prm56 Join by video system Dial 1615655...@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 161 565 5824 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 8824 on Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
A new Request for Comments is now available in online RFC libraries. RFC 8824 Title: Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) Author: A. Minaburo, L. Toutain, R. Andreasen Status: Standards Track Stream: IETF Date: June 2021 Mailbox:a...@ackl.io, laurent.tout...@imt-atlantique.fr, randrea...@fi.uba.ar Pages: 30 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-lpwan-coap-static-context-hc-19.txt URL:https://www.rfc-editor.org/info/rfc8824 DOI:10.17487/RFC8824 This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. This document is a product of the IPv6 over Low Power Wide-Area 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
