Last Call: (YANG Groupings for TCP Clients and TCP Servers) to Proposed Standard
The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'YANG Groupings for TCP Clients and TCP Servers' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines three YANG 1.1 modules to support the configuration of TCP clients and TCP servers. The modules include basic parameters of a TCP connection relevant for client or server applications, as well as client configuration required for traversing proxies. The modules can be used either standalone or in conjunction with configuration of other stack protocol layers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (YANG Groupings for TLS Clients and TLS Servers) to Proposed Standard
The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'YANG Groupings for TLS Clients and TLS Servers' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines three YANG 1.1 modules: the first defines features and groupings common to both TLS clients and TLS servers, the second defines a grouping for a generic TLS client, and the third defines a grouping for a generic TLS server. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (Informational - Internet Engineering Task Force (IETF)) rfc6209: Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) (Informational - Internet Engineering Task Force (IETF)) rfc6367: Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational - Internet Engineering Task Force (IETF)) rfc8492: Secure Password Ciphersuites for Transport Layer Security (TLS) (Informational - Independent Submission) rfc8998: ShangMi (SM) Cipher Suites for TLS 1.3 (Informational - Independent Submission) rfc9150: TLS 1.3 Authentication and Integrity-Only Cipher Suites (Informational - Independent Submission) rfc9189: GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2 (Informational - Independent Submission) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (YANG Groupings for SSH Clients and SSH Servers) to Proposed Standard
The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'YANG Groupings for SSH Clients and SSH Servers' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines three YANG 1.1 modules: the first defines features and groupings common to both SSH clients and SSH servers, the second defines a grouping for a generic SSH client, and the third defines a grouping for a generic SSH server. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5647: AES Galois Counter Mode for the Secure Shell Transport Layer Protocol (Informational - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (YANG Groupings for HTTP 1.1/2.0 Clients and HTTP Servers) to Proposed Standard
The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'YANG Groupings for HTTP 1.1/2.0 Clients and HTTP Servers' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Area Proxy for IS-IS' to Experimental RFC (draft-ietf-lsr-isis-area-proxy-12.txt)
The IESG has approved the following document: - 'Area Proxy for IS-IS' (draft-ietf-lsr-isis-area-proxy-12.txt) as Experimental RFC This document is the product of the Link State Routing Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ Technical Summary Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. Working Group Summary Shepherd writeup indicates broad consensus and no controversy. The WG agreed on experimental track for this document. Document Quality Shepherd writeup mentions one known shipping implementation. Personnel The Document Shepherd for this document is Christian Hopps. The Responsible Area Director is John Scudder. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered Locator/ID Separation Protocol (lisp)
The Locator/ID Separation Protocol (lisp) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Locator/ID Separation Protocol (lisp) --- Current status: Active WG Chairs: Padma Pillay-Esnault Luigi Iannone Secretaries: Alberto Rodriguez-Natal Assigned Area Director: Jim Guichard Routing Area Directors: John Scudder Jim Guichard Andrew Alston Mailing list: Address: l...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: https://mailarchive.ietf.org/arch/browse/lisp/ Group page: https://datatracker.ietf.org/group/lisp/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lisp/ LISP supports an overlay routing architecture that decouples the routing locators and endpoint identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the endpoint space. LISP requires no changes to endpoints or routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol, so new features and services can be added easily and quickly to the network using overlays. The LISP WG is chartered to continue work on the LISP protocol, including minor extensions for which the working group has consensus on deeming them necessary for the use cases identified by the working group as main LISP applications. Such use cases have to be documented in an applicability document providing rationale for the work done. The working group will work on the following items: - Moving to Standard Track: The core specifications of LISP have been published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue the work of moving select specifications to “Standard Track” (e.g., LISP Canonical Address Format [RFC8060], LISP Multicast [RFC6831][RFC8378], etc). - Map Server Reliable Transport: LISP control plane messages are transported over UDP, however, in some cases, the use of a reliable transport protocol (such as TCP) is a better fit, since it actually helps reduce periodic signaling. - YANG Models: The management of LISP protocol and deployments including data models, OAM, as well as allowing for programmable management interfaces. - LISP for Traffic Engineering: Specifics on how to do traffic engineering on LISP deployments could be useful. For instance, encode in a mapping not only the routing locators associated to EIDs, but also an ordered set of re-encapsulating tunnel routers (RTRs) used to specify a path. - NAT-Traversal: LISP protocol extensions to support a NAT-traversal solution in deployments where LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node). The LISP WG will collaborate with the TSVWG working on NAT-Traversal. - Privacy and Security: The WG will work on EID anonymity, VPN segmentation leveraging the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized. - LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be used to connect LISP sites with non-LISP sites. However, LISP deployments could benefit from more advanced interworking, for instance by defining mechanisms to discover such external connectivity. - Mobility: Some LISP deployment scenarios include endpoints that move across different LISP xTRs and/or LISP xTRs that are themselves mobile. Support needs to be provided to achieve seamless connectivity. - LISP Applicability: LISP has proved to be a very flexible protocol that can be used in various use cases not considered during its design phase. [RFC7215], while remaining a good source of information, covers one single use case, which is no longer the main LISP application scenario. The LISP WG will document LISP deployments for the most recent and relevant use cases, so as to update and complement [RFC7215] as needed. Milestones: Nov 2023 - Submit LISP Name Encoding document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Reliable Transport document to the IESG for consideration (Map Server Reliable Transport) [STANDARDS TRACK] Mar 2024 - Submit LISP YANG model document to the IESG for consideration (YANG Models) [EXPERIMENTAL] Mar 2024 - Submit LISP Traffic Engineering document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Geo-Coordinates document to the IESG for consideration (Mobility) [EXPERIMENTAL] Nov 2024 - Submit LISP NAT Traversal document to the IESG for consideration (NAT Traversal) [STANDARDS TRACK] Nov 2024 - Submit LISP DDT bis document to the IESG for consideration [STANDARDS TRACK] Nov 2024 - Submit LISP LCAF bis document to the IESG for consideration [STANDARDS TRACK] Mar 2025 - Submit LISP Privacy and Security document(s) to the IESG for consideration (Privacy and Security
Formal IESG Teleconference Webex and Dial-in Information: 1 February 2024
All members of the community are welcome to attend formal IESG telechats as observers. Observers are not invited to participate in the discussion. The next formal IESG telechat will be held on Thursday, 1 February 2024 at 07:00 US/Canada Pacific (15:00 UTC). The meeting is scheduled for two hours (07:00-09:00 US/Canada Pacific). Webex and Dial-in information is at the bottom of this message. The agenda for the upcoming telechat can be found at <https://datatracker.ietf.org/iesg/agenda/> A calendar of upcoming public telechats can be downloaded or subscribed to at: https://calendar.google.com/calendar/ical/ietf.org_egdabaf39ch5v8a13dt39mvee4%40group.calendar.google.com/public/basic.ics Topic: IESG Formal Telechat Date: 1 February 2024 Time: 07:00 US/Canada Pacific 09:00 US/Canada Central 10:00 US/Canada Eastern 15:00 UTC 15:00 United Kingdom 16:00 Germany, France, Belgium, Sweden 17:00 Finland 18:00 Kenya 20:30 India --- JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m3cc48bcbd48465d4da48d0197a6e7bb2 Meeting number: 2427 431 7054 Meeting password: 12345 JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 2427 431 7054 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Retiring the Tao of the IETF) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Retiring the Tao of the IETF' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document retires and obsoletes the Tao of the IETF as an IETF- maintained document. It includes the rationale for the retirement and the last edition of the Tao as published via the process described in RFC 6722. Information that new participants need to engage in the work of the IETF will continue to be updated on the IETF website in a more timely and accessible manner. This is the way. The file can be obtained via https://datatracker.ietf.org/doc/draft-tenoever-tao-retirement/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Application-Layer Traffic Optimization (alto)
The Application-Layer Traffic Optimization (alto) WG in the Operations and Management Area has concluded. The IESG contact persons are Martin Duke, Warren Kumari, and Robert Wilton. The ALTO working group has completed its deliverables and is closing. Thanks to everyone for their hard work! The mailing list will remain open to help the ALTO community coordinate on deployments and to improve the maturity of potential future work. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC Series Working Group (rswg) EDWG Virtual Meeting: 2024-02-05
The RFC Series Working Group (rswg) Editorial Stream Working Group will hold a virtual interim meeting on 2024-02-05 from 12:00 to 13:00 America/New_York (17:00 to 18:00 UTC). Agenda: Agenda will be determined by the issues that are open on the mail list. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=8f3f2125-0aca-409c-b7fb-112f92853410 Mail list: r...@rfc-editor.org -- A calendar subscription for all rswg meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=rswg ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Light-Weight Implementation Guidance (lwig)
The Light-Weight Implementation Guidance (lwig) WG in the Internet Area has concluded. The IESG contact persons are Erik Kline and Éric Vyncke. LWIG is now closed. The one working group document (draft-ietf-lwig-curve-representations) will become AD-sponsored but retain its current datatracker state. Any significant discussion about this document will find a suitable forum, if needed. The working group mailing list will remain open, but discussion is recommended to move to other fora, such as IOTOPS WG (iot...@ietf.org). Thanks to all who participated, contributed text, and chaired. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol' to Proposed Standard (draft-ietf-alto-oam-yang-17.txt)
The IESG has approved the following document: - 'YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol' (draft-ietf-alto-oam-yang-17.txt) as Proposed Standard This document is the product of the Application-Layer Traffic Optimization Working Group. The IESG contact persons are Warren Kumari, Robert Wilton and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/ Technical Summary This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. Working Group Summary No controversy was raised during the development of this specification. The authors were very responsive in taking care of all the comments and making the required changes. However, there were some aspects that required some cycles before proceeding with the current design in the spec, e.g.,: * How to handle data types defined in ALTO IANA registries and whether to consider an IANA-maintained YANG module based upon these registries. The decision was to make use of plain identities directly into the base ALO module. The reasoning for this decision was that many WG participants think that the registries won't be updated frequently and that having an IANA-maintained module is "overdesign". The Shepherd disagrees with that argument as this questions the value of having the registry in the first place, but this is not a blocking point. Let's hope that netmod WG can revise the YANG Authors Guidelines to include guidelines for IANA-maintained YANG modules. * Whether and how to supply server-to-server communication for multi-domain settings: the decision was to restrict the scope of the discovery, but leave the communication out of scope. * Whether and how to model how ALTO data is aggregated and stored: The decision is to consider these as implementation-specific and out of the scope of the base model. * Notifications for resource limits: the base module includes specific data nodes (notify-res-mem-limit, notify-upd-stream-limit) to trigger notifications. There was an alternate proposal to build on RFC 8632 but that was considered as more complex to integrate. * During the AD review, text about data sources was removed as out of scope for the working group. Document Quality There is one known implementation. Personnel The Document Shepherd for this document is Mohamed Boucadair. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
The Tools Team (tools) TEAM Virtual Meeting: 2024-03-05
The The Tools Team (tools) Team will hold a virtual interim meeting on 2024-03-05 from 13:00 to 14:00 America/Chicago (19:00 to 20:00 UTC). Agenda: https://notes.ietf.org/tools-team-20240305 Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=9395eece-168b-4290-bf48-0ca6cd85ed1d -- A calendar subscription for all tools meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=tools ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Call for feedback: IESG appointment to the IETF Trust
The IESG is responsible for appointing one person to the IETF Trust for a two-year term that begins in March 2024. Following the call for nominations [1], the following candidates have accepted a nomination: • Kristin Berdan • Donald Eastlake • Stephan Wenger Please send feedback about these candidates to iesg-o...@ietf.org. This feedback will be held in confidence by the IESG. Please provide the feedback by 23:59 UTC on Monday, February 19, 2024. We thank you in advance for your help. IESG Secretary, on behalf of the IESG [1] https://mailarchive.ietf.org/arch/msg/ietf-announce/uAKomeff8C0k0yRmUGv6Ba3QGkY/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices' to Proposed Standard (draft-ietf-nfsv4-scsi-layout-nvme-07.txt)
The IESG has approved the following document: - 'Using the Parallel NFS (pNFS) SCSI Layout to access NVMe storage devices' (draft-ietf-nfsv4-scsi-layout-nvme-07.txt) as Proposed Standard This document is the product of the Network File System Version 4 Working Group. The IESG contact person is Zaheduzzaman Sarker. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-nfsv4-scsi-layout-nvme/ Technical Summary This document specifies how to use the Parallel Network File System (pNFS) Small Computer System Interface (SCSI) Layout Type to access storage devices using the Non-Volatile Memory Express (NVMe) protocol family. Working Group Summary Working group consensus was sufficiently broad across the working group to progress this document. The only controversy about this draft was if IETF and NFSv4 was the right forum and if this draft was in scope. There are agreement within the WG and with the AD that this is within scope. Document Quality 2 independent implementations have been created. This is draft presents an evolution of storage layouts as storage advances and should be implemented more over time. The relevant technical experts to understand NVMe and SCSI are also members of the NFSv4 working group. This document uses NVMe and SCSI but only extends the usage of NFSv4 to newer NVMe and SCSI protocol devices. Personnel The Document Shepherd for this document is Christopher Inacio. The Responsible Area Director is Zaheduzzaman Sarker. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (A YANG Data Model for In-Situ OAM) to Proposed Standard
The IESG has received a request from the IP Performance Measurement WG (ippm) to consider the following document: - 'A YANG Data Model for In-Situ OAM' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In-situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method to produce operational and telemetry information that may be exported using the in-band or out-of-band method. RFC9197 and RFC9326 discuss the data fields and associated data types for IOAM. This document defines a YANG module for the configuration of IOAM functions. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3532/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Media Over QUIC (moq) WG Interim Meeting: 2024-02-08
The Media Over QUIC (moq) WG will hold an interim meeting on 2024-02-08 from 12:30 to 17:00 America/Denver (19:30 to 00:00 UTC). Meeting Location: Denver, CO, US Agenda: We will be updating the logistics here: https://github.com/moq-wg/wg-materials/blob/main/interim-24-02/arrangements.md. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=410785d0-0379-453a-809b-98326a881b7b -- A calendar subscription for all moq meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=moq ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Media Over QUIC (moq) WG Interim Meeting: 2024-02-08
The Media Over QUIC (moq) WG will hold an interim meeting on 2024-02-08 from 09:30 to 12:30 America/Denver (16:30 to 19:30 UTC). Meeting Location: Denver, CO, US Agenda: We will be updating the logistics here: https://github.com/moq-wg/wg-materials/blob/main/interim-24-02/arrangements.md. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=ea6add4c-2c74-4c2a-956e-5d60f3cb3c02 -- A calendar subscription for all moq meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=moq ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Media Over QUIC (moq) WG Interim Meeting: 2024-02-07
The Media Over QUIC (moq) WG will hold an interim meeting on 2024-02-07 from 12:30 to 17:00 America/Denver (19:30 to 00:00 UTC). Meeting Location: Denver, CO, US Agenda: We will be updating the logistics here: https://github.com/moq-wg/wg-materials/blob/main/interim-24-02/arrangements.md. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=f77f9357-45b9-4268-81ea-68ad50712d46 -- A calendar subscription for all moq meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=moq ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Media Over QUIC (moq) WG Interim Meeting: 2024-02-07
The Media Over QUIC (moq) WG will hold an interim meeting on 2024-02-07 from 09:30 to 12:30 America/Denver (16:30 to 19:30 UTC). Meeting Location: Denver, CO, US Agenda: We will be updating the logistics here: https://github.com/moq-wg/wg-materials/blob/main/interim-24-02/arrangements.md. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=2728312e-02b2-4e91-8e6f-778378d82f60 -- A calendar subscription for all moq meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=moq ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element' to Proposed Standard (draft-ietf-opsawg-rfc7125-update-07.txt)
The IESG has approved the following document: - 'An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element' (draft-ietf-opsawg-rfc7125-update-07.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-rfc7125-update/ Technical Summary RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated. This document removes stale information from the IPFIX registry and avoids future conflicts with the authoritative TCP Header Flags registry. This document obsoletes RFC 7125. Working Group Summary There was one point of controversy, but that has been resolved. Otherwise, there is nothing else worth noting. Document Quality This work represents a cleanup of the tcpControlBits as it relates to IPFIX so that operators can interpret flow data more accurately. Implementations insofar as TCP and IPFIX have existed for a long time. Implementations for this update are very likely. Personnel The Document Shepherd for this document is Joe Clarke. The Responsible Area Director is Robert Wilton. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Modeling (netmod) WG Virtual Meeting: 2024-02-06
The Network Modeling (netmod) WG will hold a virtual interim meeting on 2024-02-06 from 09:00 to 11:00 America/New_York (14:00 to 16:00 UTC). Agenda: To discuss the "immutable-flag" draft. https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=46cfea50-b516-4504-ad3a-67b04dd82ff2 -- A calendar subscription for all netmod meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=netmod ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (A YANG Data Model for Microwave Topology) to Proposed Standard
The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'A YANG Data Model for Microwave Topology' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model to describe microwave/ millimeter radio links in a network topology. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ccamp-mw-topo-yang/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Finding and Using Geofeed Data) to Proposed Standard
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Finding and Using Geofeed Data' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies how to augment the Routing Policy Specification Language inetnum: class to refer specifically to geofeed comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure to authenticate the geofeed data files. This document obsoletes RFC 9092. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8805: A Format for Self-Published IP Geolocation Feeds (Informational - Independent Submission) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication' to Proposed Standard (draft-ietf-netconf-over-tls13-04.txt)
The IESG has approved the following document: - 'Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication' (draft-ietf-netconf-over-tls13-04.txt) as Proposed Standard This document is the product of the Network Configuration 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-netconf-over-tls13/ Technical Summary RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data. Working Group Summary Good support, nothing rough, very smooth sailing. Document Quality Short, but well written. I don't know if there are implementations yet, but they will very likely follow over time, and we should update security best-practice regardless. Personnel The Document Shepherd for this document is Kent Watsen. The Responsible Area Director is Robert Wilton. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Deterministic Networking (DetNet): Packet Ordering Function' to Informational RFC (draft-ietf-detnet-pof-11.txt)
The IESG has approved the following document: - 'Deterministic Networking (DetNet): Packet Ordering Function' (draft-ietf-detnet-pof-11.txt) as Informational RFC This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Jim Guichard, Andrew Alston, John Scudder and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-pof/ Technical Summary Replication and Elimination functions of DetNet Architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications. The Packet Ordering Function (POF) algorithm described herein enables to restore the correct packet order when replication and elimination functions are used in DetNet networks. Working Group Summary There were no notable elements of the WG process to development this document. Document Quality No specific implementations have been discussed or disclosed. Personnel The Document Shepherd for this document is Lou Berger. The Responsible Area Director is Roman Danyliw. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Internationalization Updates to RFC 5280' to Proposed Standard (draft-ietf-lamps-rfc8399bis-05.txt)
The IESG has approved the following document: - 'Internationalization Updates to RFC 5280' (draft-ietf-lamps-rfc8399bis-05.txt) as Proposed Standard This document is the product of the Limited Additional Mechanisms for PKIX and SMIME Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc8399bis/ Technical Summary The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates. This document (once approved) obsoletes RFC 8399. Working Group Summary There was broad WG agreement to avoid the security issues arising from using A-labels instead of U-labels. Document Quality This document fixes important security vulnerabilities in deployed email systems by removing some of the complexity around how internationalized email addresses are encoded. Personnel The Document Shepherd for this document is Tim Hollebeek. The Responsible Area Director is Roman Danyliw. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Key Provisioning for Group Communication using ACE' to Proposed Standard (draft-ietf-ace-key-groupcomm-18.txt)
The IESG has approved the following document: - 'Key Provisioning for Group Communication using ACE' (draft-ietf-ace-key-groupcomm-18.txt) as Proposed Standard This document is the product of the Authentication and Authorization for Constrained Environments Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ Technical Summary This document defines how to use the Authentication and Authorization for Constrained Environments (ACE) framework to distribute keying material and configuration parameters for secure group communication. Candidate group members acting as Clients and authorized to join a group can do so by interacting with a Key Distribution Center (KDC) acting as Resource Server, from which they obtain the keying material to communicate with other group members. While defining general message formats as well as the interface and operations available at the KDC, this document supports different approaches and protocols for secure group communication. Therefore, details are delegated to separate application profiles of this document, as specialized instances that target a particular group communication approach and define how communications in the group are protected. Compliance requirements for such application profiles are also specified. Working Group Summary No controversies. Document Quality This draft in itself cannot be implemented. The API and message template formats that it defines have to be instantiated by its profiles (such as key-groupcomm-oscore), which can rather be implemented. The latest has been implemented in the java ACE implementation for Californium https://bitbucket.org/marco-tiloca-sics/ace-java/ Personnel The Document Shepherd for this document is Daniel Migault. The Responsible Area Director is Paul Wouters. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: # DNS Operations (DNSOP) Working Group ## interim-2024-dnsop-01 ### Chairs * Benno Overeinder [be...@nlnetlabs.nl](be...@nlnetlabs.nl) * Suzanne Woolf [suzworldw...@gmail.com](suzworldw...@gmail.com) * Tim Wicinski [tjw.i...@gmail.com](tjw.i...@gmail.com) ### IESG Overlord * Warren Kumari [war...@kumari.net](war...@kumari.net) ### Document Status * [Github](https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-document-status.md) * [Datatracker](https://datatracker.ietf.org/wg/dnsop/documents/) * [Propose Slides](https://datatracker.ietf.org/meeting/interim-2024-dnsop-01/session/dnsop) ## Session interim-2024-dnsop-01 * Date: 30 January 2024 * Time: 17:00-18:00 UTC * [MeetEcho](https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f) * [Jabber](dn...@jabber.ietf.org) * [Zulip](https://zulip.ietf.org/#narrow/stream/dnsop) * [Minutes](https://notes.ietf.org/notes-ietf-interim-2024-dnsop-01-dnsop) ## Agenda ### Administrivia * Agenda Bashing, Blue Sheets, etc, 5 min ### New Business * Presentation on state of DELEG draft. - 15 minutes * Legacy resolver compliance testing results. - 5 minutes * Open discussion points in the draft: - 10 minutes * Open Discussiontime for discussions - 20 minutes * IETF Process Time * BoF? New WG ? Another Hour Needed at next IETF Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3d47363c-d68e-46b7-aedf-094716d4d64f -- A calendar subscription for all dnsop meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=dnsop ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Internationalized Email Addresses in X.509 Certificates) to Proposed Standard
The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Internationalized Email Addresses in X.509 Certificates' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address. This document updates RFC 5280 and obsoletes RFC 8398. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc8398bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane) to Informational RFC
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the principles for using Operations, Administration, and Maintenance protocols and mechanisms in the Deterministic Networking networks with the IP data plane. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-oam/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Domain Keys Identified Mail (dkim)
The Domain Keys Identified Mail (dkim) WG in the Applications and Real-Time Area has concluded. The IESG contact persons are Murray Kucherawy and Francesca Palombini. The mailing list will remain open. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane' to Proposed Standard (draft-ietf-detnet-mpls-oam-15.txt)
The IESG has approved the following document:
- 'Operations, Administration and Maintenance (OAM) for Deterministic
Networks (DetNet) with MPLS Data Plane'
(draft-ietf-detnet-mpls-oam-15.txt) as Proposed Standard
This document is the product of the Deterministic Networking Working Group.
The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder.
A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/
Technical Summary
This document defines format and usage principles of the
Deterministic Network (DetNet) service Associated Channel (ACH) over
a DetNet network with the MPLS data plane. The DetNet service ACH
can be used to carry test packets of active Operations,
Administration, and Maintenance protocols that are used to detect
DetNet failures and measure performance metrics.
Working Group Summary
"The normal WG process has been followed and the documents
reflect WG consensus with nothing special worth mentioning."
Document Quality
"While there is interest in this specification from multiple
vendors, there are no publicly known implementations yet. The
document is one of the key deliverables of the WG."
Personnel
The Document Shepherd for this document is János Farkas. The Responsible
Area Director is John Scudder.
RFC Editor Note
Please consider alphabetizing Section 2.1. ("Terminology and Acronyms").
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (A YANG Data Model for L1 Connectivity Service Model (L1CSM)) to Proposed Standard
The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'A YANG Data Model for L1 Connectivity Service Model (L1CSM)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. This YANG model is in compliance of Network Management Datastore Architecture (NMDA). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ccamp-l1csm-yang/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Management (nmrg) RG Virtual Meeting: 2024-02-06
The Network Management (nmrg) RG will hold a virtual interim meeting on 2024-02-06 from 17:30 to 19:00 Europe/Paris (16:30 to 18:00 UTC). Agenda: Progress on group research agenda topics agenda details will be provided soon Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=4bac7b91-aed3-4504-b778-2fe4d031781c -- A calendar subscription for all nmrg meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=nmrg ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (JMAP for Sieve Scripts) to Proposed Standard
The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'JMAP for Sieve Scripts' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (WebP Image Format) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'WebP Image Format' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-02-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. NOTE: This document was previously approved for publication by the IESG. However, due to substantial changes made during AUTH48, the decision was made to do a second Last Call before resuming the publication process. Abstract This document defines the WebP image format and registers a media type supporting its use. The file can be obtained via https://datatracker.ietf.org/doc/draft-zern-webp/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5840/ https://datatracker.ietf.org/ipr/5841/ https://datatracker.ietf.org/ipr/5842/ https://datatracker.ietf.org/ipr/5843/ https://datatracker.ietf.org/ipr/5844/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'YANG Schema Item iDentifier (YANG SID)' to Proposed Standard (draft-ietf-core-sid-24.txt)
The IESG has approved the following document: - 'YANG Schema Item iDentifier (YANG SID)' (draft-ietf-core-sid-24.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments 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-core-sid/ Technical Summary: The present document and RFC 9254 together provide the foundation to extend YANG-based management down to constrained devices (RFC 7228). In particular, the present document defines the semantics, the registration, and assignment processes of YANG Schema Item iDentifiers (YANG SIDs), globally unique 63-bit unsigned integers used to identify YANG items. To enable these processes, the document also defines a file format used to persist and publish assigned YANG SIDs. The companion document RFC 9254 defines encoding rules for serializing YANG using the Concise Binary Object Representation (CBOR) [RFC8949]. The two other documents draft-ietf-core-comi and draft-ietf-core-yang-library apply the two documents above, by using the CoAP protocol (RFC 7252) for access and providing information to be used in conjunction with CoRE resource discovery (RFC 6690). Working Group Summary: The suite of documents spans specific areas of interest of several WGs, in particular NETMOD, CBOR, and CORE, as well as NETCONF. This required coordination between authors and reviewers that see different of these WGs as their central point of activity. While the documents were stable already for a while, a specific issue on representing YANG unions required somewhat unsavory resolutions, which held up the process considerably. The document went through many changes during IESG review, therefore the document was moved back to the WG and a new round of Last Calls was initiated. Document Quality: Since the document became a WG document in October 2016, several reviews were provided by members of the concerned WGs. Of particular interest is the review by Jürgen Schönwälder : <https://mailarchive.ietf.org/arch/msg/netmod/SMw0cJ_t-NcV6hfDNtf9lYqMp6U> Jürgen as well as Andy Bierman were very helpful in resolving remaining issues about this document as well. Andy also is a co-author of the draft-ietf-core-comi specification using the present document and the companion document draft-ietf-core-yang-cbor. The SID process is implemented in PYANG modules. Various parts of the protocol are implemented in proprietary software, however there is no single go-to implementation that could be mentioned here. The working group has requested feedback on the media-types review request, archived at: <https://mailarchive.ietf.org/arch/msg/media-types/XMn1cIDryOtRbXdGJUHQCse1tGc> Personnel: Document Shepherd: Jaime Jiménez Area Director: Francesca Palombini Carsten Bormann served as Document Shepherd up until version -15 included, thus taking care of most of the shepherding process and especially providing the original version of this writeup. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Time Protocols (ntp) WG Virtual Meeting: 2024-01-25
The Network Time Protocols (ntp) WG will hold a virtual interim meeting on 2024-01-25 from 12:00 to 13:30 America/New_York (17:00 to 18:30 UTC). Agenda: Network Time Protocols (ntp) working group - Jan 2023 Virtual Interim Thursday, 25 January 2023 17:00 - 18:30 UTC (via meetecho - link TBS) Draft Agenda 1. Administrative and Agenda Bashing (Chairs) 2. NTP/TICTOC WG Document Status Review/Update (Chairs) https://datatracker.ietf.org/doc/draft-ietf-ntp-update-registries/ https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/ 3. NTP over PTP - WGLC Results https://datatracker.ietf.org/doc/draft-ietf-ntp-over-ptp/ 4. NTPv5 Requirements - WGLC Results https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/ 5. Ongoing working group efforts (any updates?) - NTPv5 Protocol Specification https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5/ - Roughtime https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/ https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime-ecosystem/ - NTS for PTP https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp-05 6. AOB and Way Forward Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=ca23d776-0a73-45f8-a8a1-9799f9ac34d1 -- A calendar subscription for all ntp meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=ntp ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (EAP-based Authentication Service for CoAP) to Proposed Standard
The IESG has received a request from the Authentication and Authorization for Constrained Environments WG (ace) to consider the following document: - 'EAP-based Authentication Service for CoAP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an authentication service that uses the Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called CoAP-EAP. One of the main goals is to authenticate a CoAP-enabled IoT device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constrained RESTful Environments (OSCORE), enabling the establishment of a security association between them. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'CBOR Web Token (CWT) Claims in COSE Headers' to Proposed Standard (draft-ietf-cose-cwt-claims-in-headers-10.txt)
The IESG has approved the following document: - 'CBOR Web Token (CWT) Claims in COSE Headers' (draft-ietf-cose-cwt-claims-in-headers-10.txt) as Proposed Standard This document is the product of the CBOR Object Signing and Encryption Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/ Technical Summary This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Working Group Summary The document received good feedback on the mailing list. It seems well supported by the working group. There were no major controversies. Document Quality No known implementations of this specific document, but many implementations of COSE headers exist, in particular: - https://github.com/erdtman/cose-js - https://github.com/veraison/go-cose (plans to implement) - https://github.com/transmute-industries/cose (plans to implement) This document is particularly relevant to RATS, SCITT and OAUTH at IETF and VCWG at W3C. It’s clear from discussions on the list that reviews have taken place from members who are active in these groups. There is only a small fragment of CDDL and it is very similar to the examples described in https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ Document Personnel The Document Shepherd for this document is Orie Steele. The Responsible Area Director is Paul Wouters. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Formal IESG Teleconference Webex and Dial-in Information: 18 January 2024
All members of the community are welcome to attend formal IESG telechats as observers. Observers are not invited to participate in the discussion. The next formal IESG telechat will be held on Thursday, 18 January 2024 at 07:00 US/Canada Pacific (15:00 UTC). The meeting is scheduled for two hours (07:00-09:00 US/Canada Pacific). Webex and Dial-in information is at the bottom of this message. The agenda for the upcoming telechat can be found at <https://datatracker.ietf.org/iesg/agenda/> A calendar of upcoming public telechats can be downloaded or subscribed to at: https://calendar.google.com/calendar/ical/ietf.org_egdabaf39ch5v8a13dt39mvee4%40group.calendar.google.com/public/basic.ics Topic: IESG Formal Telechat Date: 18 January 2024 Time: 07:00 US/Canada Pacific 09:00 US/Canada Central 10:00 US/Canada Eastern 15:00 UTC 15:00 United Kingdom 16:00 Germany, France, Belgium, Sweden 17:00 Finland 18:00 Kenya 20:30 India --- JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m3cc48bcbd48465d4da48d0197a6e7bb2 Meeting number: 2427 431 7054 Meeting password: 12345 JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 2427 431 7054 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-12-10
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-12-10 from 21:00 to 22:00 Europe/Amsterdam (20:00 to 21:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=b1b479fb-9333-4f70-b720-40349b68bcd0 -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-10-22
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-10-22 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=1932bae0-efa3-46d8-902a-93699f01c4d3 -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-09-24
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-09-24 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=49442bb7-d420-41f4-a78b-eadf825b506e -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-08-27
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-08-27 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=be8f4cc4-4144-4b8b-93c3-87936bb6f35b -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-06-25
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-06-25 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=abf4207f-afab-4ad6-9e1f-3a855fd3f091 -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-05-28
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-05-28 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=944aa53e-3f9b-4ac1-ac1f-db35ba005750 -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-04-23
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-04-23 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=b80fb0a5-0065-4c6c-bb6c-3388ec0ce4eb -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-04-09
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-04-09 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=0017366c-e3d4-4c0c-82f4-1c602fec2e95 -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-02-27
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-02-27 from 21:00 to 22:00 Europe/Amsterdam (20:00 to 21:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=40587977-5f40-4167-94f6-b611d08c2a30 -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Lightweight Authenticated Key Exchange (lake) WG Virtual Meeting: 2024-02-13
The Lightweight Authenticated Key Exchange (lake) WG will hold a virtual interim meeting on 2024-02-13 from 15:00 to 16:00 Europe/Paris (14:00 to 15:00 UTC). Agenda: TBA Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=d1c1352a-7425-400e-8024-216328a97c3a -- A calendar subscription for all lake meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=lake ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (YANG Model for OSPFv3 Extended LSAs) to Proposed Standard
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'YANG Model for OSPFv3 Extended LSAs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (A YANG Data Model for a Truststore) to Proposed Standard
The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'A YANG Data Model for a Truststore' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG module for configuring bags of certificates and bags of public keys that can be referenced by other data models for trust. Notifications are sent when certificates are about to expire. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (A YANG Data Model for a Keystore) to Proposed Standard
The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'A YANG Data Model for a Keystore' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a YANG module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted or hidden. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (YANG Data Types and Groupings for Cryptography) to Proposed Standard
The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'YANG Data Types and Groupings for Cryptography' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-24. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7093: Additional Methods for Generating Key Identifiers Values (Informational - Independent Submission) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2024-01-23
The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2024-01-23 from 21:00 to 22:00 Europe/Amsterdam (20:00 to 21:00 UTC). Agenda: The agenda for each meeting will be proposed on the CELLAR working group mailing list (cel...@ietf.org). Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=b30e4eed-1175-40ff-a505-ec007afd645e -- A calendar subscription for all cellar meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=cellar ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Updates for PCEPS: TLS Connection Establishment Restrictions' to Proposed Standard (draft-ietf-pce-pceps-tls13-04.txt)
The IESG has approved the following document: - 'Updates for PCEPS: TLS Connection Establishment Restrictions' (draft-ietf-pce-pceps-tls13-04.txt) as Proposed Standard This document is the product of the Path Computation Element Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ Technical Summary Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for PCEP (Path Computation Element Communication Protocol). This document adds restrictions to specify what PCEPS implementations do if a PCEPS supports more than one version of the TLS protocol and to restrict the use of TLS 1.3’s early data. Working Group Summary The WG process appears to have gone smoothly. The shepherd writeup notes general broad agreement. Document Quality At least one WG contributor indicates their implementation was straightforward (noted in shepherd writup). Personnel The Document Shepherd for this document is Andrew Stone. The Responsible Area Director is John Scudder. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)' to Informational RFC (draft-ietf-detnet-oam-framework-11.txt)
The IESG has approved the following document: - 'Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)' (draft-ietf-detnet-oam-framework-11.txt) as Informational RFC This document is the product of the Deterministic Networking Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/ Technical Summary Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operation, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective, such as packet delay, delay variation, and packet loss ratio, assigned to each DetNet flow. Working Group Summary Shepherd writeup notes good support considering the subject matter, and a lack of drama. Document Quality Since the document is a framework, there's no question of implementation. Two other working group documents informatively reference this framework. Personnel The Document Shepherd for this document is Lou Berger. The Responsible Area Director is John Scudder. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'OpenPGP' to Proposed Standard (draft-ietf-openpgp-crypto-refresh-13.txt)
The IESG has approved the following document: - 'OpenPGP' (draft-ietf-openpgp-crypto-refresh-13.txt) as Proposed Standard This document is the product of the Open Specification for Pretty Good Privacy Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/ Technical Summary This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP). Working Group Summary This draft is the sole deliverable of the currently chartered OPENPGP WG reopened in 2020. The OPENPGP WG previously closed in 2017 without finishing this deliverable. In 2021, the WG adopted the document largely based on this prior work. In 2022, an alternative to this WG document was proposed (draft-koch-openpgp-2015-rfc4880bis) by a significant implementer. The WG consensus was to continue ahead with this document. See https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/. In October 2023 during the second WG last call, this same implementer raised concerns about backwards compatibility. See https://mailarchive.ietf.org/arch/msg/openpgp/BLgKYP9CbGtMsIJRV3Ws9jh57Tw/ and https://mailarchive.ietf.org/arch/msg/openpgp/moMPKZj83kmr5x2Zd9uGGUqxIS8/. The WG consensus was to continue with publication. These and related concerns were raised in IETF Last Call. See https://mailarchive.ietf.org/arch/msg/last-call/H6RmSWvc5LOcJjSig-i4awjQFFw/. The WG chairs summarized the situation in https://mailarchive.ietf.org/arch/msg/last-call/b5LQGVlvWvudI3qF42ntvd8wblU/ as: ==[ snip ]== ... the main developer of a significant implementation is in the "rough" part of ... consensus ... the WG did explicitly consider [the identified concerns] during the work. ==[ snip ]== Document Quality There are multiple implementations that were used to produce the examples in the draft. The OpenPGP interoperability test suite is coordinated by the Sequoia project at: https://tests.sequoia-pgp.org/ Personnel The Document Shepherd for this document is Stephen Farrell. The Responsible Area Director is Roman Danyliw. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6' to Proposed Standard (draft-ietf-rtgwg-vrrp-rfc5798bis-18.txt)
The IESG has approved the following document: - 'Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6' (draft-ietf-rtgwg-vrrp-rfc5798bis-18.txt) as Proposed Standard This document is the product of the Routing Area Working Group. The IESG contact persons are Jim Guichard, Andrew Alston and John Scudder. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/ Technical Summary This document defines version 3 of the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6", and obsoletes the prevision specification of this version documented in RFC 5798. VRRP specifies an election protocol that dynamically assigns responsibility for a Virtual Router to one of the VRRP Routers on a LAN. The VRRP Router controlling the IPv4 or IPv6 address(es) associated with a Virtual Router is called the Active Router, and it forwards packets sent to these IPv4 or IPv6 addresses. Active Routers are configured with virtual IPv4 or IPv6 addresses, and Backup Routers infer the address family of the virtual addresses being advertised based on the IP protocol version. Within a VRRP Router, the Virtual Routers in each of the IPv4 and IPv6 address families are independent of one another and always treated as separate Virtual Router instances. The election process provides dynamic failover in the forwarding responsibility should the Active Router become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup Routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. The VRRP terminology has been updated to conform to inclusive language guidelines for IETF technologies. The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines. Working Group Summary Consensus for publication reached and no major controversy. Personnel The Document Shepherd for this document is Yingzhen Qu. The Responsible Area Director is Jim Guichard. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The ALTO Transport Information Publication Service' to Proposed Standard (draft-ietf-alto-new-transport-22.txt)
The IESG has approved the following document: - 'The ALTO Transport Information Publication Service' (draft-ietf-alto-new-transport-22.txt) as Proposed Standard This document is the product of the Application-Layer Traffic Optimization Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/ Technical Summary The ALTO Protocol (RFC 7285) leverages HTTP/1.1 and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources, and the server responds with the complete content of each resource one at a time. ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895) defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO server can incrementally push resource updates to clients whenever monitored network information resources change, allowing the clients to monitor multiple resources at the same time. However, HTTP/2 and later versions already support concurrent, non-blocking transport of multiple streams in the same HTTP connection. To take advantage of newer HTTP features, this document introduces the ALTO Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to give an ALTO client the new capability to explicitly, concurrently (non-blocking) request (pull) specific incremental updates using native HTTP/2 or HTTP/3, while still functioning for HTTP/1.1. Working Group Summary No controversy was raised during the development of this specification from the WG participants. There were some discussions about various design options to meet the new transport requirements, naturally. These options were presented and discussed in many WG meetings. No objections from the WG were raised against the actual design (especially during the two WGLCs organized for this document). Some concerns were raised by some directorate reviewers, e.g., server Push usage, 1:1 relationship between clients and connections, etc. The document includes NEW text to motivate these design choices when appropriate. The specification was also updated to reflect the comments from the reviewers (e.g., ordering requirement, explicit the transport requirements, avoid the impression of design-by-example by indicating the expected behavior (e.g., increment by 1), etc. The author also included a new section to describe to what extent this work adheres to "Building Protocols with HTTP" BCP. The authors also updated the language to align with the recommendation in RFC9205#Section 3.1. During the IETF LC, the server Push usage and 1:1 relationship between clients and connections were re-challenged, especially given the considerations in the last paragraph of Section 4.11 of RFC 9205. As an outcome, the design was updated by removing the 1:1 connection affinity and the appendix related to Server Push. The text was also updated to highlight the URLs that point to specific server instances. Document Quality There is one known implementation. Personnel The Document Shepherd for this document is Mohamed Boucadair. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Updates to X.509 Policy Validation) to Proposed Standard
The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Updates to X.509 Policy Validation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm. The original algorithm built a structure which scaled exponentially in the worst case, leaving implementations vulnerable to denial-of- service attacks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-policy-graph/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/6053/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Secure Asset Transfer Protocol (satp) WG Virtual Meeting: 2024-01-30
The Secure Asset Transfer Protocol (satp) WG will hold a virtual interim meeting on 2024-01-30 from 16:00 to 17:00 Europe/London (16:00 to 17:00 UTC). Agenda: - Working documents review and comments - Thomas - Update to Threats considerations - discuss WG Last Call for the Architecture draft - Update from Network Identifier team - AOB Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=59ff4eed-f935-41fd-a1ea-4dd451d39878 -- A calendar subscription for all satp meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=satp ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Reminder: Call for nominations: IESG appointment to the IETF Trust
The purpose of the IETF Trust is to acquire, hold, maintain, and license certain existing and future intellectual property and other property used in connection with the administration of the IETF. More information about the IETF Trust can be found at https://trustee.ietf.org/. According to RFC 8714, the IESG is required to appoint one person to the IETF Trust, for a term of two years. The IESG is hence asking for volunteers to serve as the IESG appointee to the IETF Trust for the term beginning in March 2024 and ending in March 2026. DESIRABLE QUALIFICATIONS AND SELECTION CRITERIA The Trust is mostly a quiet organization, and being a trustee generally involves little work beyond monthly online meetings. Trustees ideally should be: • Familiar with copyright and trademark law. • Familiar with the RFC publication process as described in RFC 9280 and related documents. • Familiar with the Trust's copyright licenses and with RFCs 8721 and 5378. • Willing to serve multiple terms as a trustee to provide continuity of oversight. NOMINATIONS AND ELIGIBILITY The IESG is making a public call for nominations. Self-nominations are permitted. All IETF participants, including working group chairs, IETF NomCom members, IAB members, IESG members, and candidates for the IETF LLC Board are eligible for nomination. Of course, IESG members who accept nomination will recuse themselves from selection discussions. Persons who are under consideration by the NomCom in the 2023-2024 cycle for the open IETF Trust position are also welcome to apply. Please send nominations to i...@ietf.org. Please include the following with each nomination: • Name • Contact information • Candidate background and qualifications SELECTION The IESG will publish the list of nominated persons prior to making a decision, allowing time for the community to provide any relevant comments to the IESG. The IESG will review the nomination material, any comments provided by the community, and may decide to interview the candidates before making a selection. CARE OF PERSONAL INFORMATION The following procedures will be used in managing candidates' personal information: The list of candidate names will be published at the close of the nominations period. A candidate that refuses the nomination will not be included on the list. Except as noted above, all information provided to the IESG during this process will be kept as confidential to the IESG. TIMEFRAME The nominations period opened Friday, 2023-12-08, and closes on Friday, 2024-01-19 at 23:59 UTC. The list of candidates will be posted shortly after the close of nominations, and the community will then have four weeks to provide comments on the candidates to the IESG. The IESG will consider the community feedback and make its decision. If the candidate pool overlaps with the NomCom's IETF Trust candidate pool, the IESG will wait to announce a selection until the NomCom announces its selections for the IETF Trust, to avoid a race condition. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Oblivious HTTP Application Intermediation (ohai) WG Virtual Meeting: 2024-01-23
The Oblivious HTTP Application Intermediation (ohai) WG will hold a virtual interim meeting on 2024-01-23 from 20:00 to 21:00 UTC. Agenda: Discuss Chunked Oblivious HTTP Messages (https://datatracker.ietf.org/doc/draft-ohai-chunked-ohttp/) as candidate for WG adoption. Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=56235ef8-d30d-409b-9a6d-fe718ec068bc -- A calendar subscription for all ohai meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=ohai ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Formal IESG Teleconference Webex and Dial-in Information: 4 January 2024
All members of the community are welcome to attend formal IESG telechats as observers. Observers are not invited to participate in the discussion. The next formal IESG telechat will be held on Thursday, 4 January 2024 at 07:00 US/Canada Pacific (15:00 UTC). The meeting is scheduled for two hours (07:00-09:00 US/Canada Pacific). Webex and Dial-in information is at the bottom of this message. The agenda for the upcoming telechat can be found at <https://datatracker.ietf.org/iesg/agenda/> A calendar of upcoming public telechats can be downloaded or subscribed to at: https://calendar.google.com/calendar/ical/ietf.org_egdabaf39ch5v8a13dt39mvee4%40group.calendar.google.com/public/basic.ics Topic: IESG Formal Telechat Date: 4 January 2024 Time: 07:00 US/Canada Pacific 09:00 US/Canada Central 10:00 US/Canada Eastern 15:00 UTC 15:00 United Kingdom 16:00 Germany, France, Belgium, Sweden 17:00 Finland 18:00 Kenya 20:30 India --- JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m3cc48bcbd48465d4da48d0197a6e7bb2 Meeting number: 2427 431 7054 Meeting password: 12345 JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 2427 431 7054 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Deterministic Networking (detnet) WG Virtual Meeting: 2024-02-06
The Deterministic Networking (detnet) WG will hold a virtual interim meeting on 2024-02-06 from 08:00 to 10:00 America/New_York (13:00 to 15:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=f2fb81ce-1c4a-418c-8621-b05fa6686ef3 -- A calendar subscription for all detnet meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=detnet ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Stay Home Meet Occasionally Online (shmoo)
The Stay Home Meet Occasionally Online (shmoo) WG in the General Area has concluded. The IESG contact person is Lars Eggert. The mailing list will remain open. With the publication of RFC9501, the chartered work of the group has completed. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Internationalization Updates to RFC 5280) to Proposed Standard
The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Internationalization Updates to RFC 5280' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates. This document (once approved) obsoletes RFC 8399. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc8399bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered Path Computation Element (pce)
The Path Computation Element (pce) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) --- Current status: Active WG Chairs: Julien Meuric Dhruv Dhody Secretaries: Andrew Stone Assigned Area Director: John Scudder Routing Area Directors: John Scudder Jim Guichard Andrew Alston Mailing list: Address: p...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/pce Archive: https://mailarchive.ietf.org/arch/browse/pce/ Group page: https://datatracker.ietf.org/group/pce/ Charter: https://datatracker.ietf.org/doc/charter-ietf-pce/ The PCE Working Group is chartered to specify the required protocols to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point traffic-engineered LSPs, as well as new path setup types of Segment Routing (SR), BIER, and Detnet. In this architecture path computation does not necessarily occur on the head-end (ingress) node, but on some other path computation entity that may not be physically located on each head-end node. The TEAS Working Group is responsible for defining and extending architectures for Traffic Engineering (TE) and it is expected that the PCE and TEAS WGs will work closely together on elements of TE architectures that utilize PCE. The PCE WG works on the application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area, or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between Path Computation Clients (PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG works on the mechanisms for inter-domain as well as multi-layer path computation and PCEP extensions for communication between several domains or network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) and Flexible Grid while keeping consistency with the GMPLS protocols specified in the CCAMP and TEAS WGs. Work Items: - PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP path computation models involving PCEs. This includes the case of computing the paths of intra- and inter-domain TE LSPs. Such path computation includes the generation of primary, protection, and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with the TEAS Working Group, development of PCE- based architectures for Traffic Engineering including PCE as a Central Controller (PCECC) and Centralized Control Dynamic Routing (CCDR). The PCEP extensions are developed in the PCE Working Group. - In cooperation with protocol-specific Working Groups (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for expressing path computation requests and responses in the various GMPLS-controlled networks, including WSON and Flexible Grid. - Specification of PCEP extensions for path computation in multi-layer and inter-domain networks. - Specification of the PCEP extensions used by a stateful PCE for recommending a new path for an existing or new LSP to the PCC/PCE. Further protocol extensions must cover the case where the receiving PCC/PCE chooses not to follow the recommendation. The PCEP extensions for state synchronization are also in scope. - Specification of the PCEP extensions for SR-MPLS and SRv6 paths as per the SR Policy architecture in cooperation with SPRING Working Group. - Specification of the PCEP extensions for new path setup types (such as BIER and DETNET) in cooperation with the respective Working Groups. Milestones: Nov 2023 - Submit PCEP YANG Model as a Proposed Standard Nov 2023 - Submit PCEP Native-IP extensions as a Proposed Standard Mar 2024 - Submit PCEP extensions for SR Policy as Proposed Standard Mar 2024 - Submit PCEP extensions for Multipath as Proposed Standard Dec 2024 - Submit Enhancements to Stateful PCE Mar 2025 - Evaluate WG progress, recharter or close ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Inter-Domain Routing (idr) WG Virtual Meeting: 2024-01-29
The Inter-Domain Routing (idr) WG will hold a virtual interim meeting on 2024-01-29 from 10:00 to 12:30 America/New_York (15:00 to 17:30 UTC). Agenda: IDR agenda - Technologies focus on BGP transport Examples of technologies for basic BGP 1) CAR/CT drafts (WG LCs will be in process during this time) 2) Generic AIGP 3) Multiple Next-Hops 4) SendHoldtimer You may request a slot for this interim, but the IDR chairs will determine if your draft will fit better in the "new drafts" interim or another interim. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=de2abbf6-57ba-4816-80c2-3d250d7e2057 -- A calendar subscription for all idr meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=idr ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID) to Proposed Standard
The IESG has received a request from the Drone Remote ID Protocol WG (drip) to consider the following document: - 'DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-01-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Drone Remote Identification Protocol (DRIP), plus trust policies and periodic access to registries, augments Unmanned Aircraft System (UAS) Remote Identification (RID), enabling local real time assessment of trustworthiness of received RID messages and observed UAS, even by Observers then lacking Internet access. This document defines DRIP message types and formats to be sent in Broadcast RID Authentication Messages to verify that attached and recent detached messages were signed by the registered owner of the DRIP Entity Tag (DET) claimed. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-drip-auth/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc9153: Drone Remote Identification Protocol (DRIP) Requirements and Terminology (Informational - Internet Engineering Task Force (IETF)) rfc9434: Drone Remote Identification Protocol (DRIP) Architecture (Informational - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Entity Attestation Token (EAT)' to Proposed Standard (draft-ietf-rats-eat-24.txt)
The IESG has approved the following document: - 'The Entity Attestation Token (EAT)' (draft-ietf-rats-eat-24.txt) as Proposed Standard This document is the product of the Remote ATtestation ProcedureS Working Group. The IESG contact persons are Paul Wouters and Roman Danyliw. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ Technical Summary An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Working Group Summary In additional to the history noted in the shepherd report, the WG held significant discussions on which claims should be sought for early allocation. Document Quality EAT Libraries: - CBOR Formats - open source project o Rust: https://github.com/carl-wallace/cbor_formats - EAT library - open source project o C: https://github.com/laurencelundblade/ctoken - A command line utility based on EAT library - open source project o C: https://github.com/laurencelundblade/xclaim EAT Profiles: - PSA o Golang: https://github.com/veraison/psatoken o C: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/initial_attestation o Python: https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/iat-verifier - CCA o Golang: https://github.com/veraison/ccatoken o C: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git/tree/lib/attestation - FIDO FDO - open source project o Java: https://github.com/secure-device-onboard/pri-fidoiot/blob/master/protocol/src/main/java/org/fidoalliance/fdo/protocol/message/EatPayloadBase.java. - Global Platform - very early code of an EAT profile, may evolve into open source o https://github.com/GlobalPlatform/TPS-API-Reference-Implementations. - Microsoft Azure Attestation - proprietary o https://github.com/CCC-Attestation/meetings/blob/main/materials/GregKostal_EAT_in_MAA.pdf Personnel The Document Shepherd for this document is Ned Smith. The Responsible Area Director is Roman Danyliw. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Inter-Domain Routing (idr) WG Virtual Meeting: 2024-02-26
The Inter-Domain Routing (idr) WG will hold a virtual interim meeting on 2024-02-26 from 10:00 to 13:00 America/New_York (15:00 to 18:00 UTC). Agenda: New Draft IDR Interm Pre-119 To obtain a spot, you must publish a draft by 2/21 and send slides by 2/23. At IETF 119, the AD will require that a draft has an email discussion on the IDR mail list before allowing it to be presented at an IDR at IETF-119. This interim can help you generate a discussion of your draft on the IDR mail list. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=21084e49-44d4-47d0-8458-b6652bd92d2d -- A calendar subscription for all idr meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=idr ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WebTransport (webtrans) WG Virtual Meeting: 2024-02-22
The WebTransport (webtrans) WG will hold a virtual interim meeting on 2024-02-22 from 13:00 to 15:00 America/Los_Angeles (21:00 to 23:00 UTC). Agenda: 1. Preliminaries (Chairs, 15 min) Note Well, Note Takers, Agenda Bashing, Draft status 2. W3C WebTransport Update, Will Law and Jan-Ivar Bruaroey (15 minutes) https://w3c.github.io/webtransport/ 3. WebTransport over HTTP/2, Eric Kinnear (40 minutes) https://tools.ietf.org/html/draft-ietf-webtrans-http2 4. WebTransport over HTTP/3, Victor Vasiliev (40 minutes) https://tools.ietf.org/html/draft-ietf-webtrans-http3 5. Wrap up and Summary, Chairs & ADs (10 minutes) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=cc7fbc93-06ff-4fec-bac7-26d6ef39bbc9 -- A calendar subscription for all webtrans meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=webtrans ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Audio/Video Transport Core Maintenance (avtcore) WG Virtual Meeting: 2024-02-13
The Audio/Video Transport Core Maintenance (avtcore) WG will hold a virtual interim meeting on 2024-02-13 from 12:00 to 14:00 America/New_York (17:00 to 19:00 UTC). Agenda: TBD Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=abb3a2f4-b816-4997-be6c-db94d4c22016 -- A calendar subscription for all avtcore meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=avtcore ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Transfer dIGital cREdentialS Securely (tigress) WG Virtual Meeting: 2024-01-25
The Transfer dIGital cREdentialS Securely (tigress) WG will hold a virtual interim meeting on 2024-01-25 from 12:00 to 13:00 America/Chicago (18:00 to 19:00 UTC). Agenda: We will take a decision around which proposal we will move forward with and next steps. A detailed agenda will be posted in early Jan. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=66cafa6b-a205-42b5-bd4f-5fd16f3df17a -- A calendar subscription for all tigress meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=tigress ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Configuration (netconf) WG Virtual Meeting: 2024-01-25
The Network Configuration (netconf) WG will hold a virtual interim meeting on 2024-01-25 from 06:00 to 08:00 America/Los_Angeles (14:00 to 16:00 UTC). Agenda: Finish discussion of NETCONF-next and RESTCONF-next issues, and outline plans for next steps. Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=9fcbb41e-5b33-48b8-86d7-f53a6799f234 -- A calendar subscription for all netconf meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=netconf ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered WebRTC Ingest Signaling over HTTPS (wish)
The WebRTC Ingest Signaling over HTTPS (wish) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. WebRTC Ingest Signaling over HTTPS (wish) --- Current status: Active WG Chairs: Sean Turner Nils Ohlmeier Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Mailing list: Address: w...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/wish Archive: https://mailarchive.ietf.org/arch/browse/wish/ Group page: https://datatracker.ietf.org/group/wish/ Charter: https://datatracker.ietf.org/doc/charter-ietf-wish/ The WISH working group is chartered to specify a simple, extensible, HTTPS-based set of signaling protocols to establish one-way WebRTC-based audiovisual sessions between broadcasting tools, media players and real-time media broadcast networks. Background: WebRTC defines a set of wire protocols for real-time media transmission, as well as a profile of the Session Description Protocol (SDP) for setting up and controlling the associated media streams. Because of its typical use cases, and to increase overall flexibility, WebRTC did not specify a wire protocol for exchanging SDP messages, leaving the creation of such protocols up to the applications that use WebRTC. This works well when WebRTC clients are vertically integrated with the servers they communicate with, as it allows for rapid iteration of new features. At the same time, the use of WebRTC as a mechanism for large-scale media broadcast is gaining popularity, and unlike more vertically integrated uses of WebRTC, WebRTC-based media distribution networks would benefit immensely from being able to re-use the several broadcasting tools that have been developed over time. To date, these media distribution networks have employed their own proprietary signaling protocols to establish the connection between broadcasting tools and the network, generally requiring either bespoke software or customized modifications to existing tools. With the large number of available tools and the growing number of real-time media distribution networks, this ad-hoc approach to creating custom protocols for establishing sessions clearly does not scale. The real-time broadcasting ecosystem would benefit immensely from a set of common protocols to meet this goal. Deliverables: The product of this working group will be a specification for a simple, extensible, HTTPS-based signaling protocol set to establish one-way WebRTC-based audiovisual sessions between broadcasting tools and real-time media broadcast networks, and between those networks and the media players. This working group will use existing HTTPS, WebRTC, and SDP mechanisms to the extent possible. While no extensions to those core protocols is expected, the working group may consider such extensions if they are necessary to meet the requirements of broadcasting tools and networks. Any such work will be coordinated with the HTTPBIS, MMUSIC, and/or MOPS working groups, as appropriate. Additionally, this working group will coordinate with HTTPBIS and HTTPAPI to assure that the HTTP protocol is being used according to current best practice. While there may be other problems that the proposed mechanism may solve or nearly solve, such as general purpose bidirectional realtime communication (telephony, video conferencing etc), adding explicit protocol support for those use cases is not in scope for the WISH working group. Milestones: Dec 2024 - Submit WebRTC-HTTP egress protocol to IESG for publication ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered Open Specification for Pretty Good Privacy (openpgp)
The Open Specification for Pretty Good Privacy (openpgp) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Open Specification for Pretty Good Privacy (openpgp) --- Current status: Active WG Chairs: Stephen Farrell Daniel Gillmor Assigned Area Director: Roman Danyliw Security Area Directors: Roman Danyliw Paul Wouters Mailing list: Address: open...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/openpgp Archive: https://mailarchive.ietf.org/arch/browse/openpgp/ Group page: https://datatracker.ietf.org/group/openpgp/ Charter: https://datatracker.ietf.org/doc/charter-ietf-openpgp/ OpenPGP standardized mechanisms for object encryption, object signing, and identity certification. The working group is chartered to work on improvements and additions to the OpenPGP format and ecosystem to address certain issues that have been identified by the community, as set out in the list of in-scope topics below. Due to the WG having been dormant for a number of years, there is somewhat of a backlog of topics, and as addressing all of these topics at once seems difficult, the WG will follow the process defined below to prioritize current lists of milestones, selected from this long list of in-scope topics. # In-scope Topics The working group will produce a number of specifications that are adjacent to the OpenPGP specification and provide guidance to OpenPGP libraries and/or applications. These improvements may include: ## Security improvements - **Post-Quantum Cryptography (PQC)**: The addition and facilitation of post-quantum algorithms for encryption and signing (using draft-wussler-openpgp-pqc) as initial input). - **Forward secrecy**: enable encrypted OpenPGP communication that cannot be decrypted when long-term keys are compromised. - **Context binding**: facilitate [domain separation for signing and/or encryption](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/145). ## New functionality - **Automatic Forwarding**: using proxy re-encryption (using draft-wussler-openpgp-forwarding) as initial input). - **Persistent Symmetric Keys**: for long-term storage of symmetric key material, symmetrically encrypted messages, and symmetric attestations (using draft-huigens-openpgp-persistent-symmetric-keys as initial input). - **First-Party Approval of Third-Party Certifications (1PA3PC)**: to mitigate certificate flooding attacks (using draft-dkg-openpgp-1pa3pc as initial input). - **Superseded Keys**: to facilitate [transition to new keys without revoking the old ones](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/222). - **Stateless OpenPGP Interface (SOP)**: using draft-dkg-openpgp-stateless-cli as initial input. - **PGP/MIME Separate Encrypted Parts**: Extending RFC3156 to describe [messages composed of multiple encrypted parts](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/171). - **cert-d**: A common certificate storage mechanism (using draft-nwjw-openpgp-cert-d as initial input). ## Network-based Key Discovery Mechanisms - **HTTP Keyserver Protocol (HKP)**: using draft-gallagher-openpgp-hkp as initial input. - **Web Key Directory (WKD)**: using draft-koch-openpgp-webkey-service as initial input. ## Key Verification Mechanisms - **Web-of-Trust (WoT)**: Specifying semantics for the WoT calculus (using [the OpenPGP Web of Trust draft](https://sequoia-pgp.gitlab.io/sequoia-wot/) as initial input). - **Key Transparency**: in collaboration with the [Key Transparency Working Group](https://datatracker.ietf.org/wg/keytrans/about/), e.g., integrating its outputs. - **Key Verification**: Improved manual key verification, for example using a QR code. ## Miscellaneous Cleanup Work - **Semantics**: Define semantics of mechanisms provided by OpenPGP. This includes, but is not limited to, defining validity of signatures, acceptance and placement of signature subpackets, as well as structure and meaning of certificates and messages. - **User ID Conventions**: Properly document User ID conventions (using draft-dkg-openpgp-userid-conventions as initial input). - **Revocation**: Clarify and improve revocation semantics and workflows, including replacement of the deprecated Revocation Key mechanism (using draft-dkg-openpgp-revocation as initial input). - **Message Grammar**: [Simplify](https://mailarchive.ietf.org/arch/msg/openpgp/uepOF6XpSegMO4c59tt9e5H1i4g/) the OpenPGP Message Grammar; e.g., by limiting nesting, or by constraining sequences of packet types. - **PGP/MIME One-Pass Signatures**: Extending RFC3156 to permit [one-pass signature verification for v6 signatures](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/116) # Working Group Process All work items will require demonstration of interoperable support by at least two independent implementations before being submitted to the IESG
WG Action: Rechartered Javascript Object Signing and Encryption (jose)
The Javascript Object Signing and Encryption (jose) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Javascript Object Signing and Encryption (jose) --- Current status: Active WG Chairs: John Bradley John Preuß Mattsson Karen O'Donoghue Assigned Area Director: Roman Danyliw Security Area Directors: Roman Danyliw Paul Wouters Mailing list: Address: j...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: https://mailarchive.ietf.org/arch/browse/jose/ Group page: https://datatracker.ietf.org/group/jose/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jose/ The original [JSON Object Signing and Encryption (JOSE) working group][1] standardized JSON-based representations for: Integrity-protected objects (JSON Web Signatures/JWS, RFC 7515), Encrypted objects (JSON Web Encryption/JWE, RFC7516), Key representations (JSON Web Key/JWK, RFC 7517), Algorithm definitions (JSON Web Algorithms/JWA, RFC 7518), and Test vectors for the above (Examples of Protecting Content Using JSON Object Signing and Encryption, RFC 7520). These were used to define the JSON Web Token (JWT) (RFC 7519), which in turn, has seen widespread deployment in areas as diverse as [digital identity][2] and [secure telephony][3]. As adoption of these standards to express and communicate sensitive data has grown, so too has an increasing societal focus on privacy. User consent, minimal disclosure, and unlinkability are common privacy themes in identity solutions. A multi-decade research activity for a sizeable academic and applied cryptography community has focused on these privacy and knowledge mechanisms (often referred to as anonymous credentials). Certain cryptographic techniques developed in this space involve pairing-friendly curves and zero-knowledge proofs (ZKPs) (to name just a few). Some of the benefits of ZKP algorithms include unlinkability, selective disclosure, and the ability to use predicate proofs. The current container formats defined by JOSE and JWT are not able to represent data using ZKP algorithms. Among the reasons are that most require an additional transform or finalize step, many are designed to operate on sets and not single messages, and the interface to ZKP algorithms has more inputs than conventional signing algorithms. The reconstituted JOSE working group will address these new needs, while reusing aspects of JOSE and JWT, where applicable. This group is chartered to work on the following goals: - An Informational document detailing Use Cases and Requirements for new specifications enabling JSON-based selective disclosure and zero-knowledge proofs. - Standards Track document(s) specifying representation(s) of independently-disclosable integrity-protected sets of data and/or proofs using JSON-based data structures, which also aims to prevent the ability to correlate by different verifiers. - Standards Track document(s) specifying representation(s) of JSON-based claims and/or proofs enabling selective disclosure of these claims and/or proofs, and that also aims to prevent the ability to correlate by different verifiers. - Standards Track document(s) specifying how to use existing cryptographic algorithms and defining their algorithm identifiers. The working group will not invent new cryptographic algorithms. - Standards Track document(s) specifying how to represent keys for these new algorithms as JSON Web Keys (JWKs). - Informational document(s) defining test vectors for these new specifications. - Standards Track document(s) defining CBOR-based representations corresponding to all the above, building upon the COSE and CWT specifications in the same way that the above build on JOSE and JWT. One or more of these goals may be combined into a single document, in which case the concrete milestones for these goals will be satisfied by the consolidated document(s). The JOSE working group will also maintain the JOSE standard and facilitate discussion of clarifications, improvements, and extensions to JWS, JWE, JWA, and JWK. The WG will evaluate, and potentially adopt, proposed standard documents dealing with algorithms that would fit the criteria of being IETF consensus algorithms. Potential candidates would include those algorithms that have been evaluated by the CFRG and algorithms which have gone through a public review and evaluation process such as was done for the NIST SHA-3 algorithms. Potential candidates would not include national-standards-based algorithms that have not gone through a similar public review process. The WG may also publish informational and BCP documents describing the proper use of these algorithms in JOSE. An informal goal of the working group is close coordination with the [rechartered W3C Verifiable Credentials WG][4], which has taken a dependency on this work for
WG Action: Rechartered Transport and Services Working Group (tsvwg)
The Transport and Services Working Group (tsvwg) WG in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Transport and Services Working Group (tsvwg) --- Current status: Active WG Chairs: Gorry Fairhurst Marten Seemann Assigned Area Director: Martin Duke Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: ts...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tsvwg Archive: https://mailarchive.ietf.org/arch/browse/tsvwg/ Group page: https://datatracker.ietf.org/group/tsvwg/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tsvwg/ The Transport and Services Working Group (TSVWG) is the forum for development and publication of RFCs dealing with transport-layer topics that are not in scope of an existing working group or do not justify the formation of a new working group. A non-exhaustive list of transport topics includes mechanisms that deal with packetization and reassembly, ports, maximum transmission unit discovery, reordering, congestion control, loss detection and recovery, queue management, explicit congestion notification, multihoming, stream multiplexing, and quality of service (including DSCP and RSVP). Transport-layer protocols include TCP, QUIC, SCTP, UDP, and DCCP. TSVWG maintains these protocols and mechanisms in the absence of a specialized working group. The TSVWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones, with the approval of the responsible AD. The currently active TSVWG work items mostly fall under the following topics: (A) Maintenance and extension of the Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Datagram Congestion Control Protocol (DCCP), as these do not have dedicated working groups. (B) Explicit Congestion Notification (ECN), as the working group improves existing directives for tunnelling and observes the recently launched experiment with Low Latency, Low Loss, and Scalable Throughput (L4S). (C) Maintenance of IP Differentiated Services (DiffServ) mechanisms, which involves mostly advisory documents on the use of DiffServ in specific application scenarios. Other work items related to DiffServ require Area Director approval. Work in TSVWG must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the AD, who, depending on the scope of the proposed work item, may decide that an IESG review of adoption is needed first. Milestones: Done - Submit 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' as a BCP RFC Done - Submit 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' as a Proposed Standard RFC Dec 2023 - Submit " Transport Options for UDP" as a Proposed Standard RFC Dec 2023 - Submit "Datagram PLPMTUD for UDP Options" for publication as a Proposed Standard RFC. Dec 2023 - Submit "A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services" as a Proposed Standard RFC Dec 2023 - Submit "User Ports for Experiments " for publication as a Proposed Standard RFC. Dec 2023 - Submit " DCCP Extensions for Multipath Operation with Multiple Addresses" as a Proposed Standard RFC Mar 2024 - Submit "DTLS over SCTP" as a Proposed Standard RFC Jul 2024 - Submit "Careful convergence of congestion control from retained state" for publication as a Proposed Standard RFC. Nov 2024 - Submit "Operational Guidance for Deployment of L4S in the Internet" as an Informational RFC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered TCP Maintenance and Minor Extensions (tcpm)
The TCP Maintenance and Minor Extensions (tcpm) WG in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. TCP Maintenance and Minor Extensions (tcpm) --- Current status: Active WG Chairs: Yoshifumi Nishida Michael Tüxen Ian Swett Assigned Area Director: Martin Duke Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: t...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: https://mailarchive.ietf.org/arch/browse/tcpm/ Group page: https://datatracker.ietf.org/group/tcpm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tcpm/ TCP is currently one of the Internet's predominant transport protocols. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track. * The WG maintains Multipath TCP (MPTCP) and is a home for minor MPTCP enhancements including updates to the existing multipath congestion control. The preferred venue for Congestion control work is generally CCWG or ICCRG. However, TCPM can take on such work in coordination with those groups, especially if it relies on TCP-specific protocol elements. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Milestones: Nov 2022 - Submit RFC6937bis document to the IESG for publication as a Proposed Standard RFC Dec 2022 - Submit specification of more accurate ECN feedback in TCP to the IESG for publication as a Proposed Standard RFC Jan 2023 - Submit document on adding Explicit Congestion Notification (ECN) to TCP Control Packets to the IESG for publication as Experimental RFC Dec 2023 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC Oct 2024 - Submit document on adding acknowledgement rate handling for TCP to the IESG for publication as Experimental RFC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG' to Proposed Standard (draft-ietf-ippm-stamp-on-lag-06.txt)
The IESG has approved the following document: - 'Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG' (draft-ietf-ippm-stamp-on-lag-06.txt) as Proposed Standard This document is the product of the IP Performance Measurement Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-on-lag/ Technical Summary This document extends Simple Two-Way Active Measurement Protocol (STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance based traffic steering policy across the member links. Working Group Summary The one point of controversy was around the applicability or rather the wording of this draft. Micro-sessions could be useful in more cases than measuring LAG groups and to be able to measure LAG groups you need a very specific deployment. There were suggestions to remove all mentions of LAG from the document and generalize the concept. Document Quality Several implementations of the sister specification (draft-ietf-ippm-otwamp-on-lag) have been announced. But non of this specification so far. Personnel The Document Shepherd for this document is Marcus Ihlar. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A Profile for Route Origin Authorizations (ROAs)' to Proposed Standard (draft-ietf-sidrops-rfc6482bis-09.txt)
The IESG has approved the following document: - 'A Profile for Route Origin Authorizations (ROAs)' (draft-ietf-sidrops-rfc6482bis-09.txt) as Proposed Standard This document is the product of the SIDR Operations 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-sidrops-rfc6482bis/ Technical Summary This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. Working Group Summary It took a while to get to consensus, but it seems solid now. Document Quality While it is not really a protocol document, there are two linked implementations of the sorting in the document. The document does contain an example ROA which contains a non-RFC3849-compliant IP address. This seems OK to me. Personnel Chris Morrow is DS. Warren "Ace" Kumari is RAD ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'HTTP Proxy-Status Parameter for Next-Hop Aliases' to Proposed Standard (draft-ietf-httpbis-alias-proxy-status-07.txt)
The IESG has approved the following document: - 'HTTP Proxy-Status Parameter for Next-Hop Aliases' (draft-ietf-httpbis-alias-proxy-status-07.txt) as Proposed Standard This document is the product of the HTTP 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-httpbis-alias-proxy-status/ Technical Summary This document defines the next-hop-aliases HTTP Proxy-Status Parameter. This parameter carries the list of aliases and canonical names an intermediary received during DNS resolution as part establishing a connection to the next hop. Working Group Summary There was a reasonable breadth of discussion regarding this document. Nothing was controversial. Document Quality Apple and its partners have implemented and deployed. Personnel The Document Shepherd for this document is Mark Nottingham. The Responsible Area Director is Francesca Palombini. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Network Modeling (netmod) WG Virtual Meeting: 2024-01-23
The Network Modeling (netmod) WG will hold a virtual interim meeting on 2024-01-23 from 09:00 to 11:00 America/New_York (14:00 to 16:00 UTC). Agenda: To discuss draft-ietf-netmod-system-config-04, per the action item from NETMOD WG's 118 session. Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/04/ Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=ca81773f-0540-42e3-b48b-69d01ce24732 -- A calendar subscription for all netmod meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=netmod ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG' to Proposed Standard (draft-ietf-ippm-otwamp-on-lag-08.txt)
The IESG has approved the following document: - 'One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG' (draft-ietf-ippm-otwamp-on-lag-08.txt) as Proposed Standard This document is the product of the IP Performance Measurement Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-otwamp-on-lag/ Technical Summary This document defines extensions to One-way Active Measurement Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance based traffic steering policy across the member links. Working Group Summary The one point of controversy was around the applicability or rather the wording of this draft. Micro-sessions could be useful in more cases than measuring LAG groups and to be able to measure LAG groups you need a very specific deployment. There were suggestions to remove all mentions of LAG from the document and generalize the concept. Document Quality The protocol defined in the document has been implemented by Huawei, ZTE and New H3C. China Mobile has wide field deployment. Personnel The Document Shepherd for this document is Marcus Ihlar. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Locator/ID Separation Protocol (lisp)
The Locator/ID Separation Protocol (lisp) WG in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2023-12-21. Locator/ID Separation Protocol (lisp) --- Current status: Active WG Chairs: Padma Pillay-Esnault Luigi Iannone Secretaries: Alberto Rodriguez-Natal Assigned Area Director: Jim Guichard Routing Area Directors: John Scudder Jim Guichard Andrew Alston Mailing list: Address: l...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: https://mailarchive.ietf.org/arch/browse/lisp/ Group page: https://datatracker.ietf.org/group/lisp/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lisp/ LISP supports an overlay routing architecture that decouples the routing locators and endpoint identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the endpoint space. LISP requires no changes to endpoints or routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol, so new features and services can be added easily and quickly to the network using overlays. The LISP WG is chartered to continue work on the LISP protocol, including minor extensions for which the working group has consensus on deeming them necessary for the use cases identified by the working as main LISP applications. Such use cases have to be documented in an applicability document providing rationale for the work done. The working group will work on the following items: - Moving to Standard Track: The core specifications of LISP have been published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue the work of moving select specifications to “Standard Track” (e.g., LISP Canonical Address Format [RFC8060], LISP Multicast [RFC6831][RFC8378], etc). - Map Server Reliable Transport: LISP control plane messages are transported over UDP, however, in some cases, the use of a reliable transport protocol is a better fit, since it actually helps reduce periodic signaling. - YANG Models: The management of LISP protocol and deployments include data models, OAM, as well as allowing for programmable management interfaces. - LISP for Traffic Engineering: Specifics on how to do traffic engineering on LISP deployments could be useful. For instance, encode in a mapping not only the routing locators associated to EIDs, but also an ordered set of re-encapsulating tunnel routers (RTRs) used to specify a path. - NAT-Traversal: Support for a NAT-traversal solution in deployments where LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node). - Privacy and Security: The WG will work on EID anonymity, VPN segmentation leveraging on the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized. - LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be used to connect LISP sites with non-LISP sites. However, LISP deployments could benefit from more advanced internet-working, for instance by defining mechanisms to discover such external connectivity. - Mobility: Some LISP deployment scenarios include endpoints that move across different LISP xTRs and/or LISP xTRs that are themselves mobile. Support needs to be provided to achieve seamless connectivity. - LISP Applicability: LISP has proved to be a very flexible protocol that can be used in various use cases not considered during its design phase. [RFC7215], while remaining a good source of information, covers one single use case, which is no longer the main LISP application scenario. The LISP WG will document LISP deployments for the most recent and relevant use cases, so as to update and complement [RFC7215] as needed. Milestones: Nov 2023 - Submit LISP Name Encoding document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Reliable Transport document to the IESG for consideration (Map Server Reliable Transport) [STANDARDS TRACK] Mar 2024 - Submit LISP YANG model document to the IESG for consideration (YANG Models) [EXPERIMENTAL] Mar 2024 - Submit LISP Traffic Engineering document to the IESG for consideration (Extension) [EXPERIMENTAL] Mar 2024 - Submit LISP Geo-Coordinates document to the IESG for consideration (Mobility) [EXPERIMENTAL] Nov 2024 - Submit LISP NAT Traversal document to the IESG for consideration (NAT Traversal) [STANDARDS TRACK] Nov 2024 - Submit LISP DDT bis document to the IESG for consideration [STANDARDS TRACK] Nov 2024 - Submit LISP LCAF bis document to the IESG for consideration [STANDARDS TRACK] Mar 2025 - Submit LISP Privacy and Security document(s) to the IESG
Last Call: (DTN Management Architecture) to Informational RFC
The IESG has received a request from the Delay/Disruption Tolerant Networking WG (dtn) to consider the following document: - 'DTN Management Architecture' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices. This document describes a DTN management architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over uni-directional links and other places where BP is the preferred transport. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'CDNI delegation using Automated Certificate Management Environment' to Proposed Standard (draft-ietf-cdni-delegation-acme-04.txt)
The IESG has approved the following document: - 'CDNI delegation using Automated Certificate Management Environment' (draft-ietf-cdni-delegation-acme-04.txt) as Proposed Standard This document is the product of the Content Delivery Networks Interconnection 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-cdni-delegation-acme/ Technical Summary This document defines metadata to support delegating the delivery of HTTPS content between two or more interconnected CDNs. Specifically, this document defines a CDNI Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC9115. RFC9115 allows delegating entities to remain in full control of the delegation and be able to revoke it any time and this avoids the need to share private cryptographic key material between the involved entities. Working Group Summary There were no major controversies or discontent. Discussions were primarily around scope, specifically, minimizing the contents of the draft to only what is needed for CDNI to support delegation and avoiding any implementation of security protocols. CDNI supports configuration and capability negotiation between CDNs; it does not implement security protocols. Document Quality The draft specifically provides for configuring ACME across CDNs and so relates to the work of the ACME WG. The draft was reviewed by Thomas Fossati, one of the co-authors of RFC8739 and RFC9115, prior to WGLC and all his comments were addressed. Personnel The Document Shepherd for this document is Kevin J. Ma. The Responsible Area Director is Francesca Palombini. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
The Tools Team (tools) TEAM Virtual Meeting: 2024-02-13
The The Tools Team (tools) Team will hold a virtual interim meeting on 2024-02-13 from 13:00 to 14:00 America/Chicago (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=25d8575d-cc7a-4719-b1a5-b7ba1569d581 -- A calendar subscription for all tools meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=tools ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
The Tools Team (tools) TEAM Virtual Meeting: 2024-01-09
The The Tools Team (tools) Team will hold a virtual interim meeting on 2024-01-09 from 13:00 to 14:00 America/Chicago (19:00 to 20:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?group=3b360796-363f-4c35-9f11-37f61e7afed6 -- A calendar subscription for all tools meetings is available at https://datatracker.ietf.org/meeting/upcoming.ics?show=tools ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Call for nominations: IESG appointment to the IETF Trust
The purpose of the IETF Trust is to acquire, hold, maintain, and license certain existing and future intellectual property and other property used in connection with the administration of the IETF. More information about the IETF Trust can be found at https://trustee.ietf.org/. According to RFC 8714, the IESG is required to appoint one person to the IETF Trust, for a term of two years. The IESG is hence asking for volunteers to serve as the IESG appointee to the IETF Trust for the term beginning in March 2024 and ending in March 2026. DESIRABLE QUALIFICATIONS AND SELECTION CRITERIA The Trust is mostly a quiet organization, and being a trustee generally involves little work beyond monthly online meetings. Trustees ideally should be: • Familiar with copyright and trademark law. • Familiar with the RFC publication process as described in RFC 9280 and related documents. • Familiar with the Trust's copyright licenses and with RFCs 8721 and 5378. • Willing to serve multiple terms as a trustee to provide continuity of oversight. NOMINATIONS AND ELIGIBILITY The IESG is making a public call for nominations. Self-nominations are permitted. All IETF participants, including working group chairs, IETF NomCom members, IAB members, IESG members, and candidates for the IETF LLC Board are eligible for nomination. Of course, IESG members who accept nomination will recuse themselves from selection discussions. Persons who are under consideration by the NomCom in the 2023-2024 cycle for the open IETF Trust position are also welcome to apply. Please send nominations to i...@ietf.org. Please include the following with each nomination: • Name • Contact information • Candidate background and qualifications SELECTION The IESG will publish the list of nominated persons prior to making a decision, allowing time for the community to provide any relevant comments to the IESG. The IESG will review the nomination material, any comments provided by the community, and may decide to interview the candidates before making a selection. CARE OF PERSONAL INFORMATION The following procedures will be used in managing candidates' personal information: The list of candidate names will be published at the close of the nominations period. A candidate that refuses the nomination will not be included on the list. Except as noted above, all information provided to the IESG during this process will be kept as confidential to the IESG. TIMEFRAME The nominations period will opens today, Friday, 2023-12-08, and closes on Friday, 2024-01-19 at 23:59 UTC. The list of candidates will be posted shortly after the close of nominations, and the community will then have four weeks to provide comments on the candidates to the IESG. The IESG will consider the community feedback and make its decision. If the candidate pool overlaps with the NomCom's IETF Trust candidate pool, the IESG will wait to announce a selection until the NomCom announces its selections for the IETF Trust, to avoid a race condition. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Area Proxy for IS-IS) to Experimental RFC
The IESG has received a request from the Link State Routing WG (lsr) to consider the following document: - 'Area Proxy for IS-IS' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Link state routing protocols have hierarchical abstraction already built into them. However, when lower levels are used for transit, they must expose their internal topologies to each other, leading to scale issues. To avoid this, this document discusses extensions to the IS-IS routing protocol that allow level 1 areas to provide transit, yet only inject an abstraction of the level 1 topology into level 2. Each level 1 area is represented as a single level 2 node, thereby enabling greater scale. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4016/ https://datatracker.ietf.org/ipr/3357/ https://datatracker.ietf.org/ipr/3221/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP) to Informational RFC
The IESG has received a request from the Deterministic Networking WG (detnet) to consider the following document: - 'Deterministic Networking (DetNet): DetNet PREOF via MPLS over UDP/IP' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-12-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how DetNet IP data plane can support the Packet Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for DetNet MPLS Data Plane and the mechanisms defined by MPLS-over-UDP technology. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-ip-preof/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Formal IESG Teleconference Webex and Dial-in Information: 14 December 2023
All members of the community are welcome to attend formal IESG telechats as observers. Observers are not invited to participate in the discussion. The next formal IESG telechat will be held on Thursday, December 14, 2023 at 07:00 US/Canada Pacific (15:00 UTC). The meeting is scheduled for two hours (07:00-09:00 US/Canada Pacific). Webex and Dial-in information is at the bottom of this message. The agenda for the upcoming telechat can be found at <https://datatracker.ietf.org/iesg/agenda/> A calendar of upcoming public telechats can be downloaded or subscribed to at: https://calendar.google.com/calendar/ical/ietf.org_egdabaf39ch5v8a13dt39mvee4%40group.calendar.google.com/public/basic.ics Topic: IESG Formal Telechat Date: December 14, 2023 Time: 07:00 US/Canada Pacific 09:00 US/Canada Central 10:00 US/Canada Eastern 15:00 UTC 15:00 United Kingdom 16:00 Germany, France, Belgium, Sweden 17:00 Finland 18:00 Kenya 20:30 India --- JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m3cc48bcbd48465d4da48d0197a6e7bb2 Meeting number: 2427 431 7054 Meeting password: 12345 JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 2427 431 7054 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' to Best Current Practice (draft-ietf-tsvwg-ecn-encap-guidelines-22.txt)
The IESG has approved the following document: - 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' (draft-ietf-tsvwg-ecn-encap-guidelines-22.txt) as Best Current Practice This document is the product of the Transport and Services Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/ Technical Summary The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking among IP layer and lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. This document is included in BCP 89 and updates the advice to subnetwork designers about ECN in RFC 3819. Working Group Summary Sebastian Moeller repeatedly questioned on the mailing list the use of recommendations that were based on an earlier BCP, i.e. RFC 7141, saying that some of the earlier concepts recommended in RFC 7141 were yet to be implemented. The chairs and editors are content that the current revision has considered this feedback and looked into these topics, and that citing RFC 7141 is consistent with good practice. Document Quality This is a BCP that is not directly implementable, but 4 RFCs and 3 I-Ds reference it. Personnel The Document Shepherd for this document is Gorry Fairhurst. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' to Proposed Standard (draft-ietf-tsvwg-rfc6040update-shim-23.txt)
The IESG has approved the following document: - 'Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim' (draft-ietf-tsvwg-rfc6040update-shim-23.txt) as Proposed Standard This document is the product of the Transport and Services Working Group. The IESG contact persons are Zaheduzzaman Sarker and Martin Duke. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ Technical Summary RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of ECN consistent for all forms of IP in IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim header(s) and updates the specifications of those that do not mention ECN propagation (that is RFC 2661, RFC 3931, RFC 2784, RFC 4380 and RFC 7450, which respectively specify L2TPv2, L2TPv3, GRE, Teredo and AMT). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. Working Group Summary The WG reached consensus following a WGLC that concluded on 25th April 2021, and rev 14 was thought to resolve the WG comments. This document has a dependency on ietf-tsvwg-ecn-encap-guidelines, and that document has stalled publication of this draft. Since rev-14, the author has continued to correct text and respond to Shepherd comments. Document Quality There are a wide variety of tunnel specifications and implementations, some of these are thought to follow the design described in this document. Personnel The Document Shepherd for this document is Gorry Fairhurst. The Responsible Area Director is Martin Duke. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
