Document Action: 'Remote Attestation Procedures Architecture' to Informational RFC (draft-ietf-rats-architecture-22.txt)
The IESG has approved the following document: - 'Remote Attestation Procedures Architecture' (draft-ietf-rats-architecture-22.txt) as Informational RFC 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-architecture/ Technical Summary In network protocol exchanges it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary claims. An attempt is made to provide for a model that is neutral toward processor architectures, the content of claims, and protocols. Working Group Summary This document represents a unification of the working group on architectural considerations. While earlier versions did come with some disagreement, this version has had good cross working group participation and the editor team did a nice job of incorporating feedback as appropriate. The working group also reviewed IPR submitted and ultimately determined to go ahead with this informational document (https://mailarchive.ietf.org/arch/msg/rats/3nCTOkNYW8ydEo0zHZlQoY8F92A/). The document is informational as it lays out the notional architecture for implementation. It is not document as a sufficient level of detail to be a proposed standard. During AD review, the WG discussed the need for the text that is now Appendix A and refined the language in the terminology (Section 4) and the example topologies (Section 5). Document Quality There are existing implementations of the RATS architecture and supporting documents. Industry points to RATS when discussing remote attestations to follow the standards being developed. The approach encompasses other existing formats and protocols that are well excepted for conveying, signing, and validating evidence. This document is an important one to explain the overall architecture and considerations for remote attestation, a very important capability for information security assurance. With industry's push for increased use of encryption, the endpoint must be more secure and there must be a way to detect variances from what is expected on a system. Attestation provides a simplified way to do this over previous posture assessment technologies. This particular document is an important step toward the goal of understanding this simple, but complex set of standards. Personnel Document Shepherd: Kathleen Moriarty Responsible Area Director: Roman Danyliw ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering' to Proposed Standard (draft-ietf-lsr-isis-rfc5316bis-07.txt)
The IESG has approved the following document: - 'IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering' (draft-ietf-lsr-isis-rfc5316bis-07.txt) as Proposed Standard This document is the product of the Link State Routing Working Group. The IESG contact persons are Alvaro Retana, Andrew Alston and John Scudder. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/ Technical Summary This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASs). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. This document builds on RFC 5316 by adding support for IPv6-only operation. This document obsoletes RFC 5316. Working Group Summary "Generally smooth" Document Quality "Unsure if existing implementations yet; however, I believe this will be implemented by most vendors." Personnel Shepherd: Christian Hopps AD: John Scudder ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
NomCom 2022-2023 Call for Nominations
The IETF Nomination Committee (NomCom) for 2022-2023 is seeking nominations from now until October 24. The list of open positions can be found at the NomCom home page: https://datatracker.ietf.org/nomcom/2022/ This also includes the list of those incumbents who have said they are seeking to be renominated. To nominate someone, please click on the "Nominate" link at the top of the home page, or go there directly: https://datatracker.ietf.org/nomcom/2022/nominate/ Please include a brief description why you are nominating them. The "Candidate phone" is optional. If you do not click the "Share nominator name" box at the top of the page, then your nomination will be confidential and the nominee will not be told who you are. Self nominations are welcome! To nominate the same person (including yourself) for more than one position, please use the form multiple times. All nominees will be required to complete a questionnaire specific to the position for which they are nominated. The questionnaires will be available soon (at the NomCom page) and will also be mailed to the nominees directly. The current (slightly tentative) timeline is posted at the NomCom page. The list of nominees will be made available, and an opportunity for community feedback will be made after the nominations are closed. All feedback will be kept confidential to the committee, and all committee discussions and votes are also confidential. Remember that it is easier to refuse a nomination, or decline later, than it is to nominate (or be nominated) later on. We look forward to seeing a wide range of nominations! This is one of the key factors in the future success of the IETF. -Rich Salz, 2022-2023 NomCom Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: (PASSporT Extension for Rich Call Data) to Proposed Standard
The IESG has received a request from the Secure Telephone Identity Revisited WG (stir) to consider the following document: - 'PASSporT Extension for Rich Call 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 2022-10-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 extends PASSporT, a token for conveying cryptographically-signed call information about personal communications, to include rich meta-data about a call and caller that can be signed and integrity protected, transmitted, and subsequently rendered to the called party. This framework is intended to include and extend caller and call specific information beyond human-readable display name comparable to the "Caller ID" function common on the telephone network and is also enhanced with a integrity mechanism that is designed to protect the authoring and transport of this information for different authoritative use-cases. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ 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: 'RTP Payload Format for Versatile Video Coding (VVC)' to Proposed Standard (draft-ietf-avtcore-rtp-vvc-18.txt)
The IESG has approved the following document: - 'RTP Payload Format for Versatile Video Coding (VVC)' (draft-ietf-avtcore-rtp-vvc-18.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/ Technical Summary This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.266 and ISO/IEC International Standard 23090-3, both also known as Versatile Video Coding (VVC) and developed by the Joint Video Experts Team (JVET). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. Working Group Summary The VVC payload specification resembles the RTP payload specification for HEVC (RFC 7798), so discussion in the WG focused on the differences between the VVC and HEVC codecs and the impact on the RTP payload format. The VVC RTP payload specification has been simplified, compared with HEVC. SDP optional parameters have been reduced. While HEVC supported SRST, MRST and MRMT transmission modes, VVC only supports SRST, which has been the most commonly implemented transmission mode for H.264/SVC and HEVC. As a result, the VVC RTP payload specification does not require the tx-mode parameter. The VVC RTP payload specification also has removed discussion of the Slice Loss Indication (SLI) and Reference Picture Selection Indication (RPSI) Feedback Messages, both of which are rarely implemented with modern codecs. In addition to these and other simplifications, the WG discussed support for the Framemarking RTP header extension and concluded that it need not be supported by the VVC RTP payload specification. Document Quality There are existing implementations of the VVC (H.266) encoder and decoder, including the VVC Test Model. See: https://jvet.hhi.fraunhofer.de/ There is a prototype implementation of the VVC RTP payload specification covering the mandatory and some optional features of the media plane. There is no known implementation of the SDP signaling. So far, there have not been any interop events relating to the VVC RTP payload specification. There have been no MIB Doctor, Yang Doctor, Media Type or other expert reviews. Personnel The Document Shepherd is Bernard Aboba. The Responsible AD is Murray Kucherawy. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Completely Encrypting RTP Header Extensions and Contributing Sources' to Proposed Standard (draft-ietf-avtcore-cryptex-08.txt)
The IESG has approved the following document: - 'Completely Encrypting RTP Header Extensions and Contributing Sources' (draft-ietf-avtcore-cryptex-08.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-cryptex/ Technical Summary While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations. This document defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler signaling with the goal of facilitating deployment. Working Group Summary Working group handling was uncontroversial once the document was adopted. In general, the discussions converged rapidly and there were no long-standing disagreements. Document Quality By IETF 111 (draft -02), test vectors and two implementations (libsrtp and jitsi-srtp) existed. There appear to be no concerns about document quality. Personnel Bernard Aboba is the Document Shepherd. Murray Kucherawy is the responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
