Protocol Action: 'Concise Problem Details For CoAP APIs' to Proposed Standard (draft-ietf-core-problem-details-08.txt)
The IESG has approved the following document: - 'Concise Problem Details For CoAP APIs' (draft-ietf-core-problem-details-08.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-problem-details/ Technical Summary This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a REST response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the Problem Details for HTTP APIs defined in RFC 7807. Working Group Summary The document has reached sufficient and broad agreement in the group. There were no controversial parts. Two alternative proposals where presented (bundled and unbundled) and one was agreed upon. Document Quality There is at least one implementation, the basic idea behind the draft is rather straightforward. The WGLC went to the CBOR and HTTPAPI WGs as well. The document was also sent for review to theexperts in media-types@iana and core-parameters@iana as well as the cbor-tags experts. Personnel Jaime Jimenez is the Document Shepherd. Francesca Palombini is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered Deterministic Networking (detnet)
The Deterministic Networking (detnet) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Deterministic Networking (detnet) --- Current status: Active WG Chairs: Lou Berger János Farkas Secretaries: Ethan Grossman Assigned Area Director: John Scudder Routing Area Directors: Alvaro Retana John Scudder Andrew Alston Technical advisors: David Black Mailing list: Address: det...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/detnet Archive: https://mailarchive.ietf.org/arch/browse/detnet/ Group page: https://datatracker.ietf.org/group/detnet/ Charter: https://datatracker.ietf.org/doc/charter-ietf-detnet/ The Deterministic Networking (DetNet) Working Group focuses on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. The Working Group addresses Layer 3 aspects in support of applications requiring deterministic networking. The Working Group collaborates with IEEE802.1 Time-Sensitive Networking (TSN), which is responsible for Layer 2 operations, to define a common architecture for both Layer 2 and Layer 3. Example applications for deterministic networks include professional and home audio/video, multimedia in transportation, engine control systems, and other general industrial and vehicular applications being considered by the IEEE 802.1 TSN Task Group. The Working Group will initially focus on solutions for networks that are under a single administrative control or within a closed group of administrative control; these include not only campus-wide networks but also can include private WANs. The DetNet WG will not spend energy on solutions for large groups of domains such as the Internet. The Working Group is responsible for the overall DetNet architecture and DetNet-specific specifications that encompasses the data plane, OAM (Operations, Administration, and Maintenance), time synchronization, management, control, and security aspects which are required to enable a multi-hop path, and forwarding along the path, with the deterministic properties of controlled latency, low packet loss, low packet delay variation, and high reliability. The work applies to point-to-point (unicast) and point-to-multipoint (multicast) flows which can be characterized in a manner that allows the network to 1) reserve the appropriate resources for the flows in advance, and 2) release/reuse the resources when they are no longer required. The work covers the characterization of flows, the encapsulation of frames, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes. Layer 3 data plane technologies that can be used include: IP and MPLS, and Layer 2 encapsulations that run over IP and/or MPLS, such as pseudowires and GRE. The Working Group will document which deployment environments and types of topologies are within (or outside) the scope of the DetNet architecture. This work focuses on the data plane aspects and is independent from any path setup protocol or mechanism. The Working Group will also document DetNet Controller Plane approaches that reuse existing IETF solutions, such as Path Computation Element (PCE), and identify the Working Group responsible for any extensions needed to support DetNet. Documents produced by the Working Group will be compatible with the work done in IEEE802.1 TSN and other IETF Working Groups. The Working Group's scope generally excludes modifications of transport protocols, OAM, Layer 3 forwarding, and encapsulations, but it may discuss requirements for such modifications and the work will be coordinated with the Working Group responsible for the technology. DetNet is chartered to work in the following areas: Overall architecture: This work encompasses the data plane, OAM, time synchronization, management, control, and security aspects. Data plane: This work will document how to use IP and/or MPLS, and related OAM, to support a data plane method of flow identification and packet treatment over Layer 3. Other IETF defined data plane technologies may also be used. Controller Plane: The DetNet Controller Plane is defined in RFC 8655 as "the aggregation of the Control and Management Planes". This work will document how to use IETF control plane solutions to support DetNet, including the identification of any gaps in existing solutions. Any modification to Controller Plane protocols to address identified gaps should be carried out in their associated Working Groups, but may be done in DetNet if agreed to by the relevant Working Group chairs and responsible Area Directors. Data flow information model: This work will identify the information needed for flow establishment and control and be used by r
Second call for volunteers for NomCom
This is the second call for people to volunteer to server on NomCom. The IETF NomCom appoints people to fill the open slots on the IETF LLC, IETF Trust, the IAB, and the IESG. To volunteer, click here: https://datatracker.ietf.org/nomcom/volunteer/ Here is the list of people who have already volunteered with the affiliation they provided. The 10 voting members are chosen by a verifiable random pick from those who signed up. There are 48 people on the list below. Alissa Cooper Cisco Barry Leiba Futurewei Technologies Bob Hinden Check Point Software Bron Gondwana Fastmail Charles Eckel Cisco Christian Hopps LabN Consulting, LLC Darren DukesCisco Systems Dhruv Dhody Huawei Technologies India Pvt. Ltd. Donald E. Eastlake 3rd Futurewei Technologies Fan YangHuawei Technologies Giuseppe Fioccola Huawei Technologies Greg Mirsky Ericsson Haoyu Song Futurewei Technologies Italo Busi Huawei James Gruessing Nederlandse Publiek Omroep Jordan Head Juniper Networks Ketan TalaulikarArrcus Inc Kyle Rose Akamai Technologies Lixia Zhang UCLA Luc Andre' Burdet Cisco Luigi Iannone Huawei Technologies France S.A.S.U. Mankamana Prasad Mishra Cisco system Mary Barnes Neustar, Inc., a Transunion company Melchior AelmansJuniper Networks Michael Richardson Sandelman Software Works Corporation Michael StJohns NthPermutation Michael zhouhuawei Mike Bishop Akamai Technologies Pablo Camarillo Cisco Systems Rakesh Gandhi Cisco Systems Reshad Rahman Graphiant Russ HousleyVigil Security, LLC Sam Aldrin Google, Inc. Scott Mansfield Ericsson Srihari R. Sangli Juniper Networks Stephen Farrell Trinity College Dublin Ted Lemon Apple Tony Li Juniper Networks Tony Przygienda Juniper Valery Smyslov ELVIS-PLUS Vengada Prasad Govindan Cisco Systems India Pvt Ltd Vittorio BertolaOpen-Xchange Wassim Haddad Ericsson Wei Pan Huawei Yaron Sheffer Intuit Yoav NirDell Technologies Zhaohui (Jeffrey) Zhang Juniper Networks ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (The Use of maxLength in the RPKI) to Best Current Practice
The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'The Use of maxLength in the RPKI' as Best Current Practice 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 2022-07-20. 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 recommends ways to reduce the forged-origin hijack attack surface by prudently limiting the set of IP prefixes that are included in a Route Origin Authorization (ROA). One recommendation is to avoid using the maxLength attribute in ROAs except in some specific cases. The recommendations complement and extend those in RFC 7115. The document also discusses the creation of ROAs for facilitating the use of Distributed Denial of Service (DDoS) mitigation services. Considerations related to ROAs and origin validation in the context of destination-based Remote Triggered Black Hole (RTBH) filtering are also highlighted. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpkimaxlen/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6811: BGP Prefix Origin Validation (Proposed Standard - Internet Engineering Task Force (IETF)) rfc6482: A Profile for Route Origin Authorizations (ROAs) (Proposed Standard - Internet Engineering Task Force (IETF)) rfc4271: A Border Gateway Protocol 4 (BGP-4) (Draft Standard - Internet Engineering Task Force (IETF)) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
